阿里雙十一的高頻交易分享

 

        即將發生的網路電商的大事件，莫過於越來越接近的大陸雙十一。屢創高峰的雙十一購物節，究竟阿里巴巴是怎麼在技術上克服這種巨量湧入的交易量呢？

        前陣子到中國東北剛好因為業務合作需要而結識了一位在杭州擔任阿里巴巴架構師的高手。晚餐大家在酒醉耳酣之際，我們聊起這件事，做經驗交流。 

 

        首先，什麼使用 NoSQL、分散式快取、反向代理、CDN...這些應付巨量『訪問』的技術，已經是業界常識，我在乎的是『真正的交易行為』，消化那種客戶訂單所產生的帳務與數量變化的處理方式。阿里在這一塊仍是依賴具有 ATOM 特性的 RDB（關聯式數據庫），牽涉到金額和訂單絕不能混亂的議題，使用 RDB 是可以想見的選擇，而 RDB 最被詬病的弱點，恰好就是平行處理與巨量請求，所以這次的請益得到的知識相當寶貴。

        聊了一整晚，我將幾項手法的重點歸納如下：

• 地區數據分庫：

          首先，為了分散全中國湧入的交易量，依地區將數據分庫來讓客戶可以在地區性最近的機房進行交易，這是最基本的起手式。也就是北上廣深各自存取不同的數據庫，分散交易量這是基本的概念。
  
          但是數據分庫後，彼此之間如何一致地同步呢？
  
          答案是當下不做同步，那商品的數量如何控制呢？由於雙十一要開賣的商品是在幾天前就已經上架完畢，只是關閉不顯現，不同地區的商品數量其實是根據過去的交易紀錄分析預測出來做分配的，也就是配置在不同地區的同一件商品，數量從一開始就不同，北京看到的可能是一萬件庫存，上海看到的是兩萬件，而廠商就是要準備總共三萬件供應品。
  
          所以其實會有那種現象，北京看到該商品已經售完沒有存貨的信息，但上海可能還能搶到。但這不會影響購物體驗，因為使用者並不會發覺有這樣的差異，除非這時候他能 VPN 到不同地區的商品頁面才有機會看到不一致的商品數量。

• 商品品類分庫：

          除了地區外，較熱賣的商品類別和較為冷門的二線商品也不會在同一個數據庫內，例如大熱門的 3C 商品和保健運動類商品就會被分開。甚至佔據大量交易的可能還會細分許多，例如 3C 的筆電和手機可能就被放在不同的數據庫了，從使用者挑選商品進購物車的當下，就已經被安排在不同的數據庫內做操作，不會彼此影響。

• 訂單編號編碼邏輯：

          許多開發人員都被訓練成依賴數據庫自動生成的 Identity 當作叢集（PK）唯一鍵值，但這種做法其實嚴重拖累效能。所以阿里內部會有自己的訂單編號生成算法，例如先以地區碼＋商品代碼＋時間戳記等等產生唯一的訂單編號，這樣編號的產生就可以被分散到大量的 AP 服務器集群內，各自平行演算，不用消耗數據庫的能力。

• 預先塞入預估總量的數據單量：

          既然訂單編號可以透過阿里自訂的演算方式產生，那就可以在雙十一之前就預先產生好。因為雙十一的高峰期很容易預估，其實系統只要挺過那個高峰，後面就不用擔心了。所以他們會過去經驗預估這次的訂單數量，事先把雙十一的高峰時段會用到的訂單號產生後事先寫入數據庫內！對，剛不是說過訂單編號內有時間戳記的編碼嗎？所以要產生的範圍是可以鎖定只要產生午夜到凌晨三點這個區間的所有可用的訂單編號，將這些『空白的』預先 Insert 到數據庫內，等到客戶真正下單的時候，演算出客戶的訂單編號用 update 的方式回寫內容。
  
          為何要這樣做呢？因為數據庫在檢查 insert 進來的 PK 必須唯一值的必須做 table lock 鎖住整張表，這一 lock 就會阻擋其他交易寫入，所以預先塞好訂單可以做到訂單數據平行寫入。

        此外，阿里架構師也跟我們分享了在雙十一之前，他們要演練總共 160+ 備援方案，包含網路切換和機房移轉等例行性作業，達到雙十一萬無一失的準備作業，因為那個當下只要服務掉幾分鐘離線，就可能損失上億，對於中國這一流的網路電商服務，真的是佩服他們技術人員的準備與備戰的態度。

        以上分享，希望可以擴展國內的技術視野，希望台灣電商也能有半個雙十一交易量的機會，應用到這些技巧。