1次訂單事故，扣了我3個(gè)月績(jī)效！
去年年底的時(shí)候，我們線上出了一次事故。
這個(gè)事故的表象是這樣的：系統(tǒng)出現(xiàn)了兩個(gè)一模一樣的訂單號(hào)，訂單的內(nèi)容卻不是不一樣的，而且系統(tǒng)在按照訂單號(hào)查詢的時(shí)候一直拋錯(cuò)，也沒法正常回調(diào)，而且事情發(fā)生的不止一次，所以 這次系統(tǒng)升級(jí)一定要解決掉。
經(jīng)手的同事之前也改過幾次，不過效果始終不好：總會(huì)出現(xiàn)訂單號(hào)重復(fù)的問題， 所以趁著這次問題我好好的理了一下我同事寫的代碼。
這里簡(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);
}
可以看到，這段代碼寫的其實(shí)不怎么好，代碼部分暫且不議，代碼中使訂單號(hào)不重復(fù)的主要因素點(diǎn)是隨機(jī)數(shù)和毫秒，可是這里的隨機(jī)數(shù)只有兩位。
在高并發(fā)環(huán)境下極容易出現(xiàn)重復(fù)問題，同時(shí)毫秒這一選擇也不是很好，在多核 CPU 多線程下，一定時(shí)間內(nèi)（極小的）這個(gè)毫秒可以說是固定不變的（測(cè)試驗(yàn)證過）。
所以這里我先以 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("過濾重復(fù)后訂單數(shù)："+filterOrderNos.size());
System.out.println("重復(fù)訂單數(shù)："+(orderNos.size()-filterOrderNos.size()));
}
果然，測(cè)試的結(jié)果如下：
生成訂單數(shù)：100
過濾重復(fù)后訂單數(shù)：87
重復(fù)訂單數(shù)：13
當(dāng)時(shí)我就震驚了，一百個(gè)并發(fā)里面竟然有 13 個(gè)重復(fù)的?。?！我趕緊讓同事先不要發(fā)版，這活兒我接了！
對(duì)這一燙手的山竽拿到手里沒有一個(gè)清晰的解決方案可是不行的，我大概花了 6 分多鐘和同事商量了下業(yè)務(wù)場(chǎng)景。
最后決定做如下更改：
去掉商戶 ID 的傳入（按同事的說法，傳入商戶 ID 也是為了防止重復(fù)訂單的，事實(shí)證明并沒有叼用）
毫秒僅保留三位（縮減長(zhǎng)度同時(shí)保證應(yīng)用切換不存在重復(fù)的可能）
使用線程安全的計(jì)數(shù)器做數(shù)字遞增（三位數(shù)最低保證并發(fā) 800 不重復(fù)，代碼中我給了 4 位）
更換日期轉(zhuǎn)換為 java8 的日期類以格式化（線程安全及代碼簡(jiǎn)潔性考量）
經(jīng)過以上思考后我的最終代碼是：
/** 訂單號(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)然代碼寫完成了可不能這么隨隨便便結(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("過濾重復(fù)后訂單數(shù)："+filterOrderNos.size());
System.out.println("重復(fù)訂單數(shù)："+(orderNos.size()-filterOrderNos.size()));
}
/**
測(cè)試結(jié)果：
生成訂單數(shù)：8000
過濾重復(fù)后訂單數(shù)：8000
重復(fù)訂單數(shù)：0
**/
真好，一次就成功了，可以直接上線了。。。
然而，我回過頭來看以上代碼，雖然最大程度解決了并發(fā)單號(hào)重復(fù)的問題，不過對(duì)于我們的系統(tǒng)架構(gòu)還是有一個(gè)潛在的隱患。
如果當(dāng)前應(yīng)用有多個(gè)實(shí)例（集群）難道就沒有重復(fù)的可能了？鑒于此問題就必然需要一個(gè)有效的解決方案，所以這時(shí)我就思考：多個(gè)實(shí)例應(yīng)用訂單號(hào)如何區(qū)分開呢？
以下為我思考的大致方向：
使用 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)用端口都一樣，不過網(wǎng)路 IP 不會(huì)存在重復(fù)的問題，至于進(jìn)程也有存在重復(fù)的可能，對(duì)于 UUID 的方式之前吃過虧。
總之吧，Redis 或 DB 也算是一種比較好的方式，不過獨(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("過濾重復(fù)后訂單數(shù)："+filterOrderNos.size());
System.out.println("重復(fù)訂單數(shù)："+(orderNos.size()-filterOrderNos.size()));
}
}
/**
訂單樣例：20082115575546011022
生成訂單數(shù)：8000
過濾重復(fù)后訂單數(shù)：8000
重復(fù)訂單數(shù)：0
**/
最后，代碼說明及幾點(diǎn)建議：
generateOrderNo() 方法內(nèi)不需要加鎖，因?yàn)?AtomicInteger 內(nèi)使用的是 CAS 自旋轉(zhuǎn)鎖（保證可見性的同時(shí)也保證原子性，具體的請(qǐng)自行了解）
getLocalIpSuffix() 方法內(nèi)不需要對(duì)不為 null 的邏輯加同步鎖（雙向校驗(yàn)鎖，整體是一種安全的單例模式）
本人實(shí)現(xiàn)的方式并不是解決問題的唯一方式，具體解決問題需要視當(dāng)前系統(tǒng)架構(gòu)具體而論
任何測(cè)試都是必要的，我同事在前幾次嘗試解決這個(gè)問題后都沒有自測(cè)，不測(cè)試有損開發(fā)專業(yè)性！
出處：cnblogs.com/funnyzpc/p/13541713.html
長(zhǎng)按進(jìn)入小程序，進(jìn)行打卡簽到
（更多精彩值得期待……）
最近熱文： 一周內(nèi)被程序員瘋轉(zhuǎn)5.6W次，最終被大廠封殺！ 字節(jié)跳動(dòng)《算法中文手冊(cè)》火了，完整版 PDF 開放下載！ 改個(gè)圓角200萬(wàn)？原研哉是怎么“說服”小米的？ Kubernetes部署MySQL主從服務(wù) 程序員 從 幼稚 到 成熟 LeetCode1-220題匯總，希望對(duì)你有點(diǎn)幫助！ 2T技術(shù)資源大放送！包括但不限于：C/C++，Linux，Python，Java，人工智能，考研，軟考，英語(yǔ)，等等。在公眾號(hào)內(nèi)回復(fù)「資源」，即可免費(fèi)獲??！回復(fù)「社群」，可以邀請(qǐng)你加入讀者群！ ??給個(gè)「在看」，是對(duì)我最大的支持??
評(píng)論
圖片
表情