UUID這么簡單，但是我卻險些釀成大禍旗扑，為什么會出現(xiàn)訂單重復(fù)呢?

背景

去年年底的時候蹦骑，我們線上出了一次事故，這個事故的表象是這樣的:

系統(tǒng)出現(xiàn)了兩個一模一樣的訂單號臀防，訂單的內(nèi)容卻不是不一樣的眠菇，而且系統(tǒng)在按照 訂單號查詢的時候一直拋錯，也沒法正掣ぶ裕回調(diào)捎废，而且事情發(fā)生的不止一次，所以 這次系統(tǒng)升級一定要解決掉致燥。
經(jīng)手的同事之前也改過幾次登疗，不過效果始終不好：總會出現(xiàn)訂單號重復(fù)的問題， 所以趁著這次問題我好好的理了一下我同事寫的代碼篡悟。
這里簡要展示下當(dāng)時的代碼：

     /**
    * OD單號生成
    * 訂單號生成規(guī)則：OD + yyMMddHHmmssSSS + 5位數(shù)(商戶ID3位+隨機數(shù)2位) 22位
    */
   public static String getYYMMDDHHNumber(String merchId){
          StringBuffer orderNo = new StringBuffer(new SimpleDateFormat("yyMMddHHmmssSSS").format(new Date()));
          if(StringUtils.isNotBlank(merchId)){
              if(merchId.length()>3){
                  orderNo.append(merchId.substring(0,3));
              }else {
                  orderNo.append(merchId);
              }
          }
          int orderLength = orderNo.toString().length();
          String randomNum = getRandomByLength(20-orderLength);
          orderNo.append(randomNum);
          return orderNo.toString();
   }

      /** 生成指定位數(shù)的隨機數(shù) **/
      public static String getRandomByLength(int size){
          if(size>8 || size<1){
              return "";
          }
          Random ne = new Random();
          StringBuffer endNumStr = new StringBuffer("1");
          StringBuffer staNumStr = new StringBuffer("9");
          for(int i=1;i<size;i++){
              endNumStr.append("0");
              staNumStr.append("0");
          }
          int randomNum = ne.nextInt(Integer.valueOf(staNumStr.toString()))+Integer.valueOf(endNumStr.toString());
          return String.valueOf(randomNum);
      }

發(fā)現(xiàn)問題

可以看到谜叹，這段代碼寫的其實不怎么好，代碼部分暫且不議搬葬，代碼中使訂單號不重復(fù)的主要因素點是隨機數(shù)和毫秒荷腊，可是這里的隨機數(shù)只有兩位
在高并發(fā)環(huán)境下極容易出現(xiàn)重復(fù)問題，同時毫秒這一選擇也不是很好急凰，在多核CPU多線程下女仰，一定時間內(nèi)(極小的)這個毫秒可以說是固定不變的(測試驗證過)猜年，所以這里我先以100個并發(fā)測試下這個訂單號生成，測試代碼如下：

  public static void main(String[] args) {
        final String merchId = "12334";
        List<String> orderNos = Collections.synchronizedList(new ArrayList<String>());
        IntStream.range(0,100).parallel().forEach(i->{
            orderNos.add(getYYMMDDHHNumber(merchId));
        });

        List<String> filterOrderNos = orderNos.stream().distinct().collect(Collectors.toList());

        System.out.println("生成訂單數(shù)："+orderNos.size());
        System.out.println("過濾重復(fù)后訂單數(shù)："+filterOrderNos.size());
        System.out.println("重復(fù)訂單數(shù)："+(orderNos.size()-filterOrderNos.size()));
    }

果然疾忍，測試的結(jié)果如下：

生成訂單數(shù)：100
過濾重復(fù)后訂單數(shù)：87
重復(fù)訂單數(shù)：13

訂單出現(xiàn)重復(fù)

當(dāng)時我就震驚了乔外，一百個并發(fā)里面竟然有13個重復(fù)的！Ｒ徽帧杨幼！，我趕緊讓同事先不要發(fā)版聂渊，這活兒我接了差购！
對這一燙手的山竽拿到手里沒有一個清晰的解決方案可是不行的，我大概花了6+分鐘和同事商量了下業(yè)務(wù)場景汉嗽，決定做如下更改：
去掉商戶ID的傳入(按同事的說法,傳入商戶ID也是為了防止重復(fù)訂單的欲逃，事實證明并沒有叼用)
毫秒僅保留三位(縮減長度同時保證應(yīng)用切換不存在重復(fù)的可能)
使用線程安全的計數(shù)器做數(shù)字遞增(三位數(shù)最低保證并發(fā)800不重復(fù),代碼中我給了4位)
更換日期轉(zhuǎn)換為java8的日期類以格式化(線程安全及代碼簡潔性考量)
經(jīng)過以上思考后我的最終代碼是：

  /** 訂單號生成(NEW) **/
    private static final AtomicInteger SEQ = new AtomicInteger(1000);
    private static final DateTimeFormatter DF_FMT_PREFIX = DateTimeFormatter.ofPattern("yyMMddHHmmssSS");
    private static ZoneId ZONE_ID = ZoneId.of("Asia/Shanghai");
    public static String generateOrderNo(){
        LocalDateTime dataTime = LocalDateTime.now(ZONE_ID);
        if(SEQ.intValue()>9990){
            SEQ.getAndSet(1000);
        }
        return  dataTime.format(DF_FMT_PREFIX)+SEQ.getAndIncrement();
    }

當(dāng)然代碼寫完成了可不能這么隨隨便便結(jié)束了，現(xiàn)在得走一個測試main函數(shù)看看：

 public static void main(String[] args) {

        List<String> orderNos = Collections.synchronizedList(new ArrayList<String>());
        IntStream.range(0,8000).parallel().forEach(i->{
            orderNos.add(generateOrderNo());
        });

        List<String> filterOrderNos = orderNos.stream().distinct().collect(Collectors.toList());

        System.out.println("生成訂單數(shù)："+orderNos.size());
        System.out.println("過濾重復(fù)后訂單數(shù)："+filterOrderNos.size());
        System.out.println("重復(fù)訂單數(shù)："+(orderNos.size()-filterOrderNos.size()));
    }

    /**
        測試結(jié)果： 
        生成訂單數(shù)：8000
        過濾重復(fù)后訂單數(shù)：8000
        重復(fù)訂單數(shù)：0
    **/

有驚無險

真好饼暑，一次就成功了稳析，可以直接上線了。弓叛。彰居。
然而，我回過頭來看以上代碼邪码，雖然最大程度解決了并發(fā)單號重復(fù)的問題裕菠，不過對于我們的系統(tǒng)架構(gòu)還是有一個潛在的隱患：如果當(dāng)前應(yīng)用有多個實例(集群)難道就沒有重復(fù)的可能了？
鑒于此問題就必然需要一個有效的解決方案闭专，所以這時我就思考：多個實例應(yīng)用訂單號如何區(qū)分開呢奴潘？以下為我思考的大致方向：

  1. 使用UUID(在第一次生成訂單號時初始化一個)
  2. 使用redis記錄一個增長ID
  3. 使用數(shù)據(jù)庫表維護一個增長ID
  4. 應(yīng)用所在的網(wǎng)絡(luò)IP
    應(yīng)用所在的端口號
    使用第三方算法(雪花算法等等)
    使用進程ID(某種程度下是一個可行的方案)

在此我想了下，我們的應(yīng)用是跑在docker里面影钉，而且每個docker容器內(nèi)的應(yīng)用端口都一樣画髓，不過網(wǎng)路IP不會存在重復(fù)的問題，至于進程也有存在重復(fù)的可能平委，對于UUID的方式之前吃過虧奈虾，總之吧，redis或DB也算是一種比較好的方式廉赔，不過獨立性較差肉微。。蜡塌。

同時還有一個因素也很重要协饲，就是所有涉及到訂單號生成的應(yīng)用都是在同一臺宿主機(linux實體服務(wù)器)上蠕搜， 所以就目前的系統(tǒng)架構(gòu)我選用了IP的方式秆撮。
一下是我的代碼：

import org.apache.commons.lang3.RandomUtils;

import java.net.InetAddress;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

public class OrderGen2Test {

    /** 訂單號生成 **/
    private static ZoneId ZONE_ID = ZoneId.of("Asia/Shanghai");
    private static final AtomicInteger SEQ = new AtomicInteger(1000);
    private static final DateTimeFormatter DF_FMT_PREFIX = DateTimeFormatter.ofPattern("yyMMddHHmmssSS");
    public static String generateOrderNo(){
        LocalDateTime dataTime = LocalDateTime.now(ZONE_ID);
        if(SEQ.intValue()>9990){
            SEQ.getAndSet(1000);
        }
        return  dataTime.format(DF_FMT_PREFIX)+ getLocalIpSuffix()+SEQ.getAndIncrement();
    }

    private volatile static String IP_SUFFIX = null;
    private static String getLocalIpSuffix (){
        if(null != IP_SUFFIX){
            return IP_SUFFIX;
        }
        try {
            synchronized (OrderGen2Test.class){
                if(null != IP_SUFFIX){
                    return IP_SUFFIX;
                }
                InetAddress addr = InetAddress.getLocalHost();
                //  172.17.0.4  172.17.0.199 ,
                String hostAddress = addr.getHostAddress();
                if (null != hostAddress && hostAddress.length() > 4) {
                    String ipSuffix = hostAddress.trim().split("\\.")[3];
                    if (ipSuffix.length() == 2) {
                        IP_SUFFIX = ipSuffix;
                        return IP_SUFFIX;
                    }
                    ipSuffix = "0" + ipSuffix;
                    IP_SUFFIX = ipSuffix.substring(ipSuffix.length() - 2);
                    return IP_SUFFIX;
                }
                IP_SUFFIX = RandomUtils.nextInt(10, 20) + "";
                return IP_SUFFIX;
            }
        }catch (Exception e){
            System.out.println("獲取IP失敗:"+e.getMessage());
            IP_SUFFIX =  RandomUtils.nextInt(10,20)+"";
            return IP_SUFFIX;
        }
    }

    public static void main(String[] args) {
        List<String> orderNos = Collections.synchronizedList(new ArrayList<String>());
        IntStream.range(0,8000).parallel().forEach(i->{
            orderNos.add(generateOrderNo());
        });

        List<String> filterOrderNos = orderNos.stream().distinct().collect(Collectors.toList());

        System.out.println("訂單樣例："+ orderNos.get(22));
        System.out.println("生成訂單數(shù)："+orderNos.size());
        System.out.println("過濾重復(fù)后訂單數(shù)："+filterOrderNos.size());
        System.out.println("重復(fù)訂單數(shù)："+(orderNos.size()-filterOrderNos.size()));
    }
}

/**
  訂單樣例：20082115575546011022
  生成訂單數(shù)：8000
  過濾重復(fù)后訂單數(shù)：8000
  重復(fù)訂單數(shù)：0
**/

最后

代碼說明及幾點建議:

  • generateOrderNo()方法內(nèi)不需要加鎖，因為AtomicInteger內(nèi)使用的是CAS自旋轉(zhuǎn)鎖(保證可見性的同時也保證原子性,具體的請自行了解)
    getLocalIpSuffix()方法內(nèi)不需要對不為null的邏輯加同步鎖(雙向校驗鎖奴愉，整體是一種安全的單例模式) 本人實現(xiàn)的方式并不是解決問題的唯一方式，具體解決問題需要視當(dāng)前系統(tǒng)架構(gòu)具體而論
    任何測試都是必要的铁孵，我同事在前幾次嘗試解決這個問題后都沒有自測锭硼，不測試有損開發(fā)專業(yè)性！
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末蜕劝，一起剝皮案震驚了整個濱河市檀头，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌熙宇，老刑警劉巖鳖擒，帶你破解...
    沈念sama閱讀 216,372評論 6贊 498
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異烫止，居然都是意外死亡，警方通過查閱死者的電腦和手機戳稽，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,368評論 3贊 392
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門馆蠕，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人惊奇，你說我怎么就攤上這事互躬。” “怎么了颂郎？”我有些...
    開封第一講書人閱讀 162,415評論 0贊 353
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵吼渡，是天一觀的道長。 經(jīng)常有香客問我乓序，道長寺酪，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 58,157評論 1贊 292
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任替劈，我火速辦了婚禮寄雀，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘陨献。我一直安慰自己盒犹，他們只是感情好，可當(dāng)我...
    茶點故事閱讀 67,171評論 6贊 388
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布眨业。 她就那樣靜靜地躺著急膀，像睡著了一般。 火紅的嫁衣襯著肌膚如雪龄捡。 梳的紋絲不亂的頭發(fā)上卓嫂，一...
    開封第一講書人閱讀 51,125評論 1贊 297
  • 城市分裂傳說
    那天，我揣著相機與錄音墅茉，去河邊找鬼命黔。 笑死呜呐，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的悍募。 我是一名探鬼主播蘑辑，決...
    沈念sama閱讀 40,028評論 3贊 417
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼坠宴！你這毒婦竟也來了洋魂？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 38,887評論 0贊 274
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤喜鼓，失蹤者是張志新（化名）和其女友劉穎副砍，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體庄岖，經(jīng)...
    沈念sama閱讀 45,310評論 1贊 310
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡豁翎，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,533評論 2贊 332
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了隅忿。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片心剥。...
    茶點故事閱讀 39,690評論 1贊 348
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖背桐，靈堂內(nèi)的尸體忽然破棺而出优烧，到底是詐尸還是另有隱情，我是刑警寧澤链峭，帶...
    沈念sama閱讀 35,411評論 5贊 343
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布畦娄，位于F島的核電站，受9級特大地震影響弊仪，放射性物質(zhì)發(fā)生泄漏熙卡。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點故事閱讀 41,004評論 3贊 325
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一撼短、第九天 我趴在偏房一處隱蔽的房頂上張望再膳。 院中可真熱鬧，春花似錦曲横、人聲如沸喂柒。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,659評論 0贊 22
  • 一樁弒父案禾嫉，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽灾杰。三九已至，卻和暖如春熙参，著一層夾襖步出監(jiān)牢的瞬間艳吠，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,812評論 1贊 268
  • 情欲美人皮
    我被黑心中介騙來泰國打工孽椰， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留昭娩，地道東北人凛篙。 一個月前我還...
    沈念sama閱讀 47,693評論 2贊 368
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像栏渺，于是被迫代替她去往敵國和親呛梆。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,577評論 2贊 353