作者 | 硬核云頂宮
責編 | 伍杏玲
出品 | CSDN（ID:CSDNnews）
上周，螞蟻集團迎來IPO，其發行價格將達到68.8元，總市值將突破2萬億元，市場對螞蟻的成長性有著充分的信心，為了申購螞蟻的股票，10月27日多家券商的交易系統熱情的股民們擁擠而產生癱瘓，
據螞蟻集團招股書資訊顯示，截至 2020 年 9 月 30 日，經濟受益權激勵計劃項下的經濟利益所對應發行人股份合計 30.79 億股，授予螞蟻集團的員工及顧問的比例約為 65%，如果以 68.8 元人民幣的發行價計算，螞蟻集團的員工及顧問共計可獲得約 1376.9 億元人民幣的經濟收益，截止6月30日，螞蟻員工總計16660人，如果照此計算，螞蟻集團人均可攤到 826.47 萬元人民幣，以筆者對于阿里及螞蟻的了解，其研發人員占比80%以上，這樣的激勵計劃主要惠及程式員群體，看到這樣的訊息不少碼農們紛紛表示羨慕，也有人質疑阿里的程式員到底能否配得上這樣的身價，
與阿里云的廣為人知的原創技術飛天作業系統和神龍服務器不同，筆者認為螞蟻對于IT界最大的貢獻在于創造一套秒殺系統的技術體系，而目前一個能提供良好客戶體驗的秒殺系統已經逐漸成為了互聯網企業的必備神器了，不過秒殺系統不是一天煉成的，其背后的黑科技值得我們深入探尋，
秒殺系統 IOE 所不能隨之重
十幾年前隨著淘寶和支付寶的誕生，網路購物對于線下零售排隊是降維打擊，網路時代的“搶購”，再也不用早起排隊，在這樣的這種場景下，任何毫秒級的延誤，都會造成物體驗的惡化，如何讓用戶愉快地剁手，是阿里、騰訊這樣的互聯網公司必須要解決的問題，
自此，我國互聯網企業普遍迎來了第一波流量爆發，淘寶雙十一的交易額從2005年的80億直線升到2012年的破千億，這種爆炸式增長成了阿里、騰訊“甜蜜”的負擔，大家發現其用戶的增長速度已超出系統處理能力的提升速度，原有一直沿用的IOE中心化系統與這種高用戶并發的場景幾乎格格不入，不無說達到如此性能的IOE系統成本會有多驚人，問題的關鍵在于即使是當時最強大的科技公司IOE，也沒有經歷過上億用戶同時在線的業務場景，時任阿里CTO的王堅院士率先提出“去IOE”的目標，通過打造阿里自己的技術來解決用戶爆發式增長的問題，
“去IOE”是上云的另一種表述方式，在IOE架構的系統中提升算力的思路是讓服務器越來越強，云計算的分布式思路是只需要增加服務器節點的數量，就能處理更多的并發服務請求，云系統業務的連續性并不是靠高可用性來保證，而是靠整個服務體系的容錯能力造就的，正是在不斷探索中，阿里人摸索出了新的云計算分布式架構，通過發揮云計算的威力，使得看似普通的虛擬機集群，能為億萬用戶同時提供優質的服務，
秒殺系統技術堆疊的演進路徑
考慮到雙十一需要在短時間內處理上億并發量，即便是世界最強超算可能也力不從心，因此建設這樣的系統須進行分布式架構的改造，分布式系統包含多個相連的處理資源，這些資源能在系統的控制下，對單一問題進行合作，最少依賴集中程序、資料或硬體，快速構建應對高并發和復雜業務場景的能力，分布式系統有一個重要的原則CAP定理，
CAP定理：是指在一個分布式系統（Distributed System）中，一致性（Consistency）、可用性（Availability）、磁區容錯性（Partition tolerance），呈不可能三角關系，既三個目標只能同時做到兩點，不可能三者兼顧，
CAP定理并不難理解，如果滿足一致性、高可用性，那么一旦集群內有節點故障，為保證資料一致，必將使系統整體陷入中斷，如果既滿足可用性、又滿足磁區容錯性，那么必然存在某個節點在系統對外提供服務時出現宕機，而這時各節點的資料一致性，又無法完全保證，
結合秒殺系統的需求分析，系統可用性肯定是要首先保證的，正如上文所述，當代的消費者無法接受排隊等待，如果活動當天頁面無法訪問，那恐怕營銷不成，讓用戶路轉黑了，在大流量的沖擊下，可能會發生節點故障，因此磁區容錯性需要保證，這樣看來，能稍微放一放的只有資料一致性，因此從這個角度上講，交易的總額必然會圍繞期望值上下浮動，
雙十一秒殺系統，一般會將以哈希分配與平均預分布兩種方案結合，首先根據歷史經驗，將交易量相量的地區結合，分為一組，比如北京、天津和遼寧、長春分為一組、上海、蘇州、南京分為二組等等以此類推，與之對應的云集群，都有自己獨立的商品額度，也只處理發給自己的請求，這樣既能避免入口的瓶頸，也盡量平均分配了請求的處理量，
每個集群也會將額度分配給內部的服務器，然后每個服務器會將自己庫存范圍內的請求，直接標志為成功，并在自己庫存范圍的基礎上，還會多預留一定比例的需求為待定，待統一減庫存后再確定能否待請求能否成功，
從分布式的角度來看，磁區域與分庫存是系統設計的基礎環節，而接下來要做的就是解決分布式一致性的問題了，只要分布式一致性的問題解決了，那么無論會么形式的搶購都可以迎刃而解，
分布式事務一致性，“秒殺系統”的核心
秒殺系統對技術要求非常高，其中最關鍵的鑰匙，在于解決分布式事務一致性的難題，無論是購買余額寶、信用卡還款還是相互保，都是典型的分布式場景，在分布式場景下銀行、基金、保險與支付寶對于一筆交易的記錄必須同時成功，或者同時失敗，以保證事務的原子性，
一般來講解決事務一致性問題，有兩種解決方案：
一是類似于阿里的Oceanbase分布式資料庫所使用的方式，他們將事務分為Prepare和Commit兩個階段來進行提交：
1.請求發起：首先由應用程式（client）發起一個事務開始請求到TC（事務協調器）；
2.TC發起prepare流程：TC先將prepare訊息寫到本地日志，之后向所有的Si發起prepare訊息，還是以以支付寶向信用卡還款為例，TC給A的prepare訊息是通知支付寶資料庫相應賬目扣款1千，TC給B的prepare訊息是通知余額寶資料庫相應賬目增加1千，為什么在執行任務前需要先寫本地日志，主要是為了故障后恢復用，本地日志起到現實生活中憑證的效果，如果沒有本地日志（憑證），出問題容易死無對證；
3.節點處理prepare流程：在各分布式節點收到prepare訊息后，執行具體本機事務，但不會進行commit，如果成功回傳yes，不成功回傳no，同理，回傳前都應把要回傳的訊息寫到日志里，當作憑證，
4.流程投票：TC收集所有節點回傳的訊息，如果所有執行器都回傳yes，那么給所有執行器發生送commit訊息，執行器收到commit后執行本地事務的commit操作；如果有任一個執行器回傳no，那么給所有執行器發送abort訊息，執行器收到abort訊息后執行事務abort操作，
以支付寶信用卡還款操作以下“銀行處理中”界面恰恰從側面印證了這個資訊同步的程序，
而分布式事務一致性就是要保證不同的兩個節點間資訊是完全同步的，帶有“**處理中”字樣的交易往往是非實時性的交易，這說明要保證分布式事務一致性的系統，其付出的時間同步成本一般也會是比較高昂的，
這方面OceanBase的使用策略是通過Paxos分布式協議在各節點中進行投票的，在性能優化方面Oceanbase在今年6月再次刷榜拿下TPC冠軍的OcceanBase，處理峰值也達到7億次/秒，將自己去年創造的6100萬次/秒，提高了11倍，
另一種是基于事務型訊息佇列來保證分布式一致性的：目前在主流的訊息佇列產品中，RabbitMQ和Kafka都是不支持事務訊息的，目前只有阿里研發并開源的RocketMQ支持事務功能，其事務訊息功能既保證操作DB操作雙方的最終一致性；并且在consumer端支持tag過濾，減少不必要的網路傳輸，
未來各行各業若要保證良好的客戶體驗，又要從容面對隨時可能到來的流量高峰，就必須仿照微博、淘寶的方式將核心系統全面遷移到分布式資料庫上去，這樣才能使自身服務體系保持足夠的彈性，迅速回應各種營銷熱點，如果不對核心換代升級，繼續死守傳統的物理架構，不論存在技術斷供的風險，單從業務發展來說，未來的空間將十分狹小，
在這方面，阿里云正在將螞蟻乃至整個阿里的服務能力SaaS化，他們提供覆寫底層基礎架構一直到上層應用開發的全鏈路分布式技術產品和輕型解決方案，通過異地多活、單元化、微服務、中臺等創新技術改造，秒殺類核心系統安全、高效和穩定地應對未來業務場景，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/203734.html
標籤：其他