記一次訂單號事故

時間  2020-08-22
標籤 一次 訂單號 事故 简体版
原文   原文鏈接

記一次訂單號事故

去年年末的時候，咱們線上出了一次事故，這個事故的表象是這樣的:
系統出現了兩個如出一轍的訂單號，訂單的內容卻不是不同的，並且系統在按照
訂單號查詢的時候一直拋錯，也無法正常回調，並且事情發生的不止一次，因此
此次系統升級必定要解決掉。java

經手的同事以前也改過幾回，不過效果始終很差：總會出現訂單號重複的問題，
因此趁着此次問題我好好的理了一下我同事寫的代碼。linux

這裏簡要展現下當時的代碼：redis

/**
  	 * 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()));
    }

果真，測試的結果以下：docker

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

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

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

  • 去掉商戶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的邏輯加同步鎖(雙向校驗鎖，總體是一種安全的單例模式)
  • 本人實現的方式並非解決問題的惟一方式，具體解決問題須要視當前系統架構具體而論
  • 任何測試都是必要的，我同事在前幾回嘗試解決這個問題後都沒有自測，不測試有損開發專業性！
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程