記一次訂單號事故

funnyZpC發表於2020-08-21

記一次訂單號事故

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

經手的同事之前也改過幾次，不過效果始終不好：總會出現訂單號重複的問題，
所以趁著這次問題我好好的理了一下我同事寫的程式碼。

這裡簡要展示下當時的程式碼：

      /**
  	 * 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的邏輯加同步鎖(雙向校驗鎖，整體是一種安全的單例模式)
  • 本人實現的方式並不是解決問題的唯一方式，具體解決問題需要視當前系統架構具體而論
  • 任何測試都是必要的，我同事在前幾次嘗試解決這個問題後都沒有自測，不測試有損開發專業性！

相關文章