java生成訂單編號

隨着項目用戶數量的擴大，高併發隨之而來。那麼如何在當前系統生成惟一編號呢？

一臺數據庫能夠用自增，集羣呢？固然也有隨之的解決方案，可是最好的仍是在項目生成了惟一的編號再插入到數據庫。而不是數據庫插入了再返回來，由於這中間多了一步查詢的過程。

固然不少人會講用這個那個技術，好比 redis 等等，固然能作到。你redis研究的很深，集成事務等等。可是又怎麼樣呢？redis最擅長的仍是 key—value，每秒的吞吐量有10萬，可是集成了事務等等有嗎？確定沒有。

你別忘了這是個算法問題，你就沒想一想這個問題要怎麼實現，細節。這是一個簡單的問題，不須要涉及到高等數學。

下面是我生成編號的一個類。

思路：首先獲取 年月日時分秒毫秒的一個時間戳（格式很規範，這樣生成的編號特別是訂單一目瞭然），再在這一毫秒內對惟一作一個區別。就是一個編號哪來的那麼複雜。

import java.text.SimpleDateFormat;import java.util.Date;import java.util.UUID;/**         * Title: 生成UUID */      public class CodecUtil {   private static Integer number;//惟一數字,集羣第一臺=0，第二臺=200000,第三臺=400000   private static int maxNum=200000;//最大值,集羣第一臺=200000，第二臺=400000,第三臺=600000   private static SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmssSSS");//年月日格式   /**    * uuid生成沒有 — 的編號    * @return    */   public static String createUUID(){      String uuid = UUID.randomUUID().toString();      return uuid.replaceAll("\\-", "");   }   /**    * 生成訂單編號 17+ 位數    *  思路:一個業務在1毫秒內併發的數量有多少，有一萬那真是頂天了,意味着 一秒 有1000萬的併發。kafaka,redis的性能不過10萬，那我把 number的上限設置成20 萬,那就是一秒200000*1000=2億的併發,不夠再集羣    *  宕機了，進程死了，這個跟程序沒有關係。你別忘了前面精確到毫秒的17位數，咱們只關心一毫秒內的併發問題    * @return    */   public static String createOrderId(){      number++;//惟一數字自增      if(number>=maxNum){ // 值的上限，超過就歸零         number=maxNum-200000;      }      return sdf.format(new Date())+number;//返回時間+一毫秒內惟一數字的編號，區分機器能夠加字母ABC...   }}