商品詳情頁-購買-訂單確認頁（此時還沒有生產訂單只是商品資料可來自快取）-提交訂單（執行2-7邏輯）-支付頁
快取中預熱的（提前從資料庫中把資料放入快取）是要參加秒殺商品資訊（包括庫存數量)，並對商品設定過期時間，這個時間應該是秒殺商品的結束時間,這麼做主要是緩解資料庫壓力提公升響應速度。
併發秒殺（提交訂單）時候先從快取中查詢是否有此商品，沒有說明秒殺結束了，有的話去預扣商品的庫存數量。
如果預扣成功說明庫存充足可以下單，響應給前端乙個狀態，並去發訊息到訊息中介軟體，訂單服務去消費此訊息然後開始真正的資料庫庫存扣減，扣減成功開始生成訂單並入庫。非同步解耦訂單生成邏輯提公升下單介面吞吐量。
前端訂單確認頁面可以去輪詢查詢訂單生成結果，一般有三種結果：生成訂單失敗既秒殺失敗或者還未消費到訊息（排隊中）如果成功則去支付頁面。
這裡的非同步生成訂單不存在分布式事務問題，因為預扣庫存僅僅是去快取中扣減庫存數量，如果此時失敗並不會傳送訊息，如果成功那麼訊息也應該被消費。由於採用是輪詢結果的方式所以即便訂單生成失敗使用者重新下單即可並不是必須要保證最終一致的場景。
訂單成功後是從資料庫獲取的訂單資訊快取中並沒有。
高並發生成唯一訂單號
最近開發一套會員系統，涉及到訂單號生成，在高並發條前提下，如何生成唯一的訂單號值得斟酌，我這裡提供一種較為可行的方案 public static string getorderidbyuuid 0 代表前面補充0 4 代表長度為4 d 代表引數為正數型 return time string.form...
高併發 高可用
高併發 提高系統併發能力的方法主要有兩種 前者垂直擴充套件可以通過提公升單機硬體效能，或者提公升單機架構效能，來提高併發性，但單機效能總是有極限的，網際網路分布式架構設計高併發終極解決方案還是後者 水平擴充套件。網際網路分層架構中，各層次水平擴充套件的實踐又有所不同 1 反向 層可以通過 dns輪詢...
高併發 高併發測試筆記
問 高併發測試 一般你們用什麼工具來模擬 10萬級別的客戶端併發？在普通的電腦上可以模擬嗎 10萬併發需要至少10萬的套接字，套接字在核心中占用記憶體100000 6k 2 1g記憶體，系統需要能夠開啟10w個fd。一般的系統能夠能模擬 問 預設每個程序只能開1024個fd，修改後最大可以10w，那...