差點被開除：一次訂單號重複的事故

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

系統出現了兩個一模一樣的訂單號，訂單的內容卻不是不一樣的，而且系統在按照訂單號查詢的時候一直拋錯，也沒法正常回調，而且事情發生的不止一次，所以這次系統升級一定要解決掉。

經手的同事之前也改過幾次，不過效果始終不好：總會出現訂單號重複的問題，所以趁着這次問題我好好的理了一下我同事寫的代碼。
這裏簡要展示下當時的代碼：

      /**
    * OD單號生成
    * 訂單號生成規則：OD + yyMMddHHmmssSSS + 5位數(商戶ID3位+隨機數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();
   }
  
  
      /** 生成指定位數的隨機數 **/
      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);
      }

可以看到，這段代碼寫的其實不怎麼好，代碼部分暫且不議，代碼中使訂單號不重複的主要因素點是隨機數和毫秒，可是這裏的隨機數只有兩位

在高併發環境下極容易出現重複問題，同時毫秒這一選擇也不是很好，在多核CPU多線程下，一定時間內(極小的)這個毫秒可以說是固定不變的(測試驗證過)，所以這裏我先以100個併發測試下這個訂單號生成，關注微信訂閱號碼匠筆記，回覆架構獲取一些列的架構知識。測試代碼如下：

    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("生成訂單數："+orderNos.size());
        System.out.println("過濾重複後訂單數："+filterOrderNos.size());
        System.out.println("重複訂單數："+(orderNos.size()-filterOrderNos.size()));
    }

果然，測試的結果如下：

生成訂單數：100
過濾重複後訂單數：87
重複訂單數：13

當時我就震驚🤯了，一百個併發裏面竟然有13個重複的！！！，我趕緊讓同事先不要發版，這活兒我接了！

對這一燙手的山竽拿到手裏沒有一個清晰的解決方案可是不行的，我大概花了6+分鐘和同事商量了下業務場景，決定做如下更改：

去掉商戶ID的傳入(按同事的說法,傳入商戶ID也是爲了防止重複訂單的，事實證明並沒有叼用)
毫秒僅保留三位(縮減長度同時保證應用切換不存在重複的可能)
使用線程安全的計數器做數字遞增(三位數最低保證併發800不重複,代碼中我給了4位)
更換日期轉換爲java8的日期類以格式化(線程安全及代碼簡潔性考量)

經過以上思考後我的最終代碼是：

    /** 訂單號生成(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();
    }

當然代碼寫完成了可不能這麼隨隨便便結束了，現在得走一個測試main函數看看：

    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.size());
        System.out.println("過濾重複後訂單數："+filterOrderNos.size());
        System.out.println("重複訂單數："+(orderNos.size()-filterOrderNos.size()));
    }
    
    /**
        測試結果： 
        生成訂單數：8000
        過濾重複後訂單數：8000
        重複訂單數：0
    **/

真好，一次就成功了，可以直接上線了。。。

然而，我回過頭來看以上代碼，雖然最大程度解決了併發單號重複的問題，不過對於我們的系統架構還是有一個潛在的隱患：如果當前應用有多個實例(集羣)難道就沒有重複的可能了？關注微信訂閱號碼匠筆記，回覆架構獲取一些列的架構知識。

鑑於此問題就必然需要一個有效的解決方案，所以這時我就思考：多個實例應用訂單號如何區分開呢？以下爲我思考的大致方向：

使用UUID(在第一次生成訂單號時初始化一個)
使用redis記錄一個增長ID
使用數據庫表維護一個增長ID
應用所在的網絡IP
應用所在的端口號
使用第三方算法(雪花算法等等)
使用進程ID(某種程度下是一個可行的方案)

在此我想了下，我們的應用是跑在docker裏面，而且每個docker容器內的應用端口都一樣，不過網路IP不會存在重複的問題，至於進程也有存在重複的可能，對於UUID的方式之前喫過虧，總之吧，redis或DB也算是一種比較好的方式，不過獨立性較差。。。

同時還有一個因素也很重要，就是所有涉及到訂單號生成的應用都是在同一臺宿主機(linux實體服務器)上，所以就目前的系統架構我選用了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("生成訂單數："+orderNos.size());
        System.out.println("過濾重複後訂單數："+filterOrderNos.size());
        System.out.println("重複訂單數："+(orderNos.size()-filterOrderNos.size()));
    }
}

/**
  訂單樣例：20082115575546011022
  生成訂單數：8000
  過濾重複後訂單數：8000
  重複訂單數：0
**/

最後

代碼說明及幾點建議

generateOrderNo()方法內不需要加鎖，因爲AtomicInteger內使用的是CAS自旋轉鎖(保證可見性的同時也保證原子性,具體的請自行了解)
getLocalIpSuffix()方法內不需要對不爲null的邏輯加同步鎖(雙向校驗鎖，整體是一種安全的單例模式)
本人實現的方式並不是解決問題的唯一方式，具體解決問題需要視當前系統架構具體而論
任何測試都是必要的，我同事在前幾次嘗試解決這個問題後都沒有自測，不測試有損開發專業性！

作者：funnyZpC
cnblogs.com/funnyzpc/p/13541713.html

差點被開除：一次訂單號重複的事故

【面試準備】又一次失敗的面試經歷，題目離譜～資深軟件測試工程師

dotnet 8 版本與銀河麒麟V10和UOS系統的 glibc 兼容性

博士畢業選擇回老家縣城大專任教，事業編、副教授待遇、外加幾十萬安家費...

CTO強烈禁止使用Calendar，那用啥？

面試官：int(1) 和 int(10) 有什麼區別？

有才！IT界新晉文豪作品一品

Redis 6種淘汰機制，看看你知道哪些？

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結