1次訂單事故,扣了我3個(gè)月績(jī)效!
圖片來(lái)自 Pexels
這個(gè)事故的表象是這樣的:系統(tǒng)出現(xiàn)了兩個(gè)一模一樣的訂單號(hào),訂單的內(nèi)容卻不是不一樣的,而且系統(tǒng)在按照訂單號(hào)查詢的時(shí)候一直拋錯(cuò),也沒(méi)法正?;卣{(diào),而且事情發(fā)生的不止一次,所以 這次系統(tǒng)升級(jí)一定要解決掉。
經(jīng)手的同事之前也改過(guò)幾次,不過(guò)效果始終不好:總會(huì)出現(xiàn)訂單號(hào)重復(fù)的問(wèn)題, 所以趁著這次問(wèn)題我好好的理了一下我同事寫(xiě)的代碼。
這里簡(jiǎn)要展示下當(dāng)時(shí)的代碼:
- /**
- * OD單號(hào)生成
- * 訂單號(hào)生成規(guī)則:OD + yyMMddHHmmssSSS + 5位數(shù)(商戶ID3位+隨機(jī)數(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ù)的隨機(jī)數(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);
- }
可以看到,這段代碼寫(xiě)的其實(shí)不怎么好,代碼部分暫且不議,代碼中使訂單號(hào)不重復(fù)的主要因素點(diǎn)是隨機(jī)數(shù)和毫秒,可是這里的隨機(jī)數(shù)只有兩位。
在高并發(fā)環(huán)境下極容易出現(xiàn)重復(fù)問(wèn)題,同時(shí)毫秒這一選擇也不是很好,在多核 CPU 多線程下,一定時(shí)間內(nèi)(極小的)這個(gè)毫秒可以說(shuō)是固定不變的(測(cè)試驗(yàn)證過(guò))。
所以這里我先以 100 個(gè)并發(fā)測(cè)試下這個(gè)訂單號(hào)生成,關(guān)注微信訂閱號(hào)碼匠筆記,回復(fù)架構(gòu)獲取一些列的架構(gòu)知識(shí)。
測(cè)試代碼如下:
- 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("過(guò)濾重復(fù)后訂單數(shù):"+filterOrderNos.size());
- System.out.println("重復(fù)訂單數(shù):"+(orderNos.size()-filterOrderNos.size()));
- }
果然,測(cè)試的結(jié)果如下:
- 生成訂單數(shù):100
- 過(guò)濾重復(fù)后訂單數(shù):87
- 重復(fù)訂單數(shù):13
生成訂單數(shù):100過(guò)濾重復(fù)后訂單數(shù):87重復(fù)訂單數(shù):13
當(dāng)時(shí)我就震驚了,一百個(gè)并發(fā)里面竟然有 13 個(gè)重復(fù)的!!!我趕緊讓同事先不要發(fā)版,這活兒我接了!
對(duì)這一燙手的山竽拿到手里沒(méi)有一個(gè)清晰的解決方案可是不行的,我大概花了 6 分多鐘和同事商量了下業(yè)務(wù)場(chǎng)景。
最后決定做如下更改:
- 去掉商戶 ID 的傳入(按同事的說(shuō)法,傳入商戶 ID 也是為了防止重復(fù)訂單的,事實(shí)證明并沒(méi)有叼用)
- 毫秒僅保留三位(縮減長(zhǎng)度同時(shí)保證應(yīng)用切換不存在重復(fù)的可能)
- 使用線程安全的計(jì)數(shù)器做數(shù)字遞增(三位數(shù)最低保證并發(fā) 800 不重復(fù),代碼中我給了 4 位)
- 更換日期轉(zhuǎn)換為 java8 的日期類以格式化(線程安全及代碼簡(jiǎn)潔性考量)
經(jīng)過(guò)以上思考后我的最終代碼是:
- /** 訂單號(hào)生成(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)然代碼寫(xiě)完成了可不能這么隨隨便便結(jié)束了,現(xiàn)在得走一個(gè)測(cè)試 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("過(guò)濾重復(fù)后訂單數(shù):"+filterOrderNos.size());
- System.out.println("重復(fù)訂單數(shù):"+(orderNos.size()-filterOrderNos.size()));
- }
- /**
- 測(cè)試結(jié)果:
- 生成訂單數(shù):8000
- 過(guò)濾重復(fù)后訂單數(shù):8000
- 重復(fù)訂單數(shù):0
- **/
真好,一次就成功了,可以直接上線了。。。
然而,我回過(guò)頭來(lái)看以上代碼,雖然最大程度解決了并發(fā)單號(hào)重復(fù)的問(wèn)題,不過(guò)對(duì)于我們的系統(tǒng)架構(gòu)還是有一個(gè)潛在的隱患。
如果當(dāng)前應(yīng)用有多個(gè)實(shí)例(集群)難道就沒(méi)有重復(fù)的可能了?鑒于此問(wèn)題就必然需要一個(gè)有效的解決方案,所以這時(shí)我就思考:多個(gè)實(shí)例應(yīng)用訂單號(hào)如何區(qū)分開(kāi)呢?
以下為我思考的大致方向:
- 使用 UUID(在第一次生成訂單號(hào)時(shí)初始化一個(gè))
- 使用 Redis 記錄一個(gè)增長(zhǎng) ID
- 使用數(shù)據(jù)庫(kù)表維護(hù)一個(gè)增長(zhǎng) ID
- 應(yīng)用所在的網(wǎng)絡(luò) IP
- 應(yīng)用所在的端口號(hào)
- 使用第三方算法(雪花算法等等)
- 使用進(jìn)程 ID(某種程度下是一個(gè)可行的方案)
在此我想了下,我們的應(yīng)用是跑在 Docker 里面,而且每個(gè) Docker 容器內(nèi)的應(yīng)用端口都一樣,不過(guò)網(wǎng)路 IP 不會(huì)存在重復(fù)的問(wèn)題,至于進(jìn)程也有存在重復(fù)的可能,對(duì)于 UUID 的方式之前吃過(guò)虧。
總之吧,Redis 或 DB 也算是一種比較好的方式,不過(guò)獨(dú)立性較差。。。
同時(shí)還有一個(gè)因素也很重要,就是所有涉及到訂單號(hào)生成的應(yīng)用都是在同一臺(tái)宿主機(jī)(Linux 實(shí)體服務(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 {
- /** 訂單號(hào)生成 **/
- 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("過(guò)濾重復(fù)后訂單數(shù):"+filterOrderNos.size());
- System.out.println("重復(fù)訂單數(shù):"+(orderNos.size()-filterOrderNos.size()));
- }
- }
- /**
- 訂單樣例:20082115575546011022
- 生成訂單數(shù):8000
- 過(guò)濾重復(fù)后訂單數(shù):8000
- 重復(fù)訂單數(shù):0
- **/
最后,代碼說(shuō)明及幾點(diǎn)建議:
- generateOrderNo() 方法內(nèi)不需要加鎖,因?yàn)?AtomicInteger 內(nèi)使用的是 CAS 自旋轉(zhuǎn)鎖(保證可見(jiàn)性的同時(shí)也保證原子性,具體的請(qǐng)自行了解)
- getLocalIpSuffix() 方法內(nèi)不需要對(duì)不為 null 的邏輯加同步鎖(雙向校驗(yàn)鎖,整體是一種安全的單例模式)
- 本人實(shí)現(xiàn)的方式并不是解決問(wèn)題的唯一方式,具體解決問(wèn)題需要視當(dāng)前系統(tǒng)架構(gòu)具體而論
- 任何測(cè)試都是必要的,我同事在前幾次嘗試解決這個(gè)問(wèn)題后都沒(méi)有自測(cè),不測(cè)試有損開(kāi)發(fā)專業(yè)性!
作者:funnyZpC
編輯:陶家龍
出處:cnblogs.com/funnyzpc/p/13541713.html