一、往期回顧

上篇文章《??億流量大考（2）：開發一套高容錯分布式系統??》，主要聊了一下將單塊系統重構為分布式系統，以此來避免單臺機器的負載過高。同時引申出來了彈性資源調度、分布式容錯機制等相關的東西。

這篇文章我們繼續來聊聊這個系統后續的重構演進過程，先來看下目前的系統架構圖，一起來回顧一下。

二、百億流量的高并發技術挑戰

上篇文章說到，如果僅僅只是每天億級流量的話，其實基本上目前的系統架構就足夠支撐了，但是呢，我們面臨的可不僅僅是億級流量那么簡單。我們面對的是日益增多和復雜的各種業務系統，我們面對的是不斷增加的系統用戶，我們面對的是即將迎來每天百億級的高并發流量。

給大家先說下當時的系統部署情況，數據庫那塊一共部署了8主8從，也就是16臺數據庫服務器，每個庫都是部署在獨立的數據庫服務器上的，而且全部用的是物理機，機器的配置，如果沒記錯的話，應該是32核+128G+SSD固態硬盤。

為啥要搞這么多物理機，而且全部都是高配置呢？不知道大家發現沒有，目前為止，我們最大的依賴就是MySQL！

之前給大家解釋過，在當時的背景下，我們要對涌入的億級海量數據，實時的運行數百個復雜度為幾百行到上千行的大SQL，幾秒鐘就要出分析結果。

這個是沒有任何一個開源系統可以做到的，Storm不行，Spark Streaming也不行，因此必須得基于MySQL純自研一套數據平臺架構出來，支撐這個需求場景。

所以，只有MySQL是可以支撐如此復雜的SQL語句完美運行的，因此我們在早期必須嚴重依賴于MySQL作為數據的存儲和計算，將源源不斷涌入的數據放在MySQL中進行存儲，接著基于數據分片計算的架構來高性能的運行復雜大SQL基于MySQL來進行計算。

所以大家就知道了，MySQL目前為止是這套系統的命脈。在當時的場景下，每臺數據庫服務器都要抗住每秒2000左右的并發請求，高峰期的CPU負載、IO負載其實都非常高，而且主庫和從庫的延遲在高峰期已經有點嚴重，會達到秒級了。

在我們的生產系統的實際線上運行情況下，單臺MySQL數據庫服務器，我們一般是不會讓他的高峰期并發請求超過2000/s的，因為一旦達到每秒幾千的請求，根據當時線上的資源負載情況來看，很可能MySQL服務器負載過高會宕機。

所以此時就有一個很尷尬的問題了，假如說每天億級流量的場景下，需要用8主8從這么多高配置的數據庫服務器來抗，那如果是幾十億流量呢？甚至如果是百億流量呢？難道不停的增加更多的高配置機器嗎？

要知道，這種高配置的數據庫服務器，如果是物理機的話，是非常昂貴的！

之前給大家簡單介紹過項目背景，這整套大型系統組成的商業級平臺，涉及到N多個系統，這個數據產品只是一個子產品而已，不可能為了這么一個產品，投入大量的預算通過不停的砸高配置的機器來撐住更高的并發寫入。

我們必須用技術的手段來重構系統架構，盡量用有限的機器資源，通過最優秀的架構來抗住超高的并發寫入壓力！

三、計算與存儲分離的架構

這個架構里的致命問題之一，就是數據的存儲和計算混在了一個地方，都在同一個MySQL庫里！

大家想想，在一個單表里放上千萬數據，然后你每次運行一個復雜SQL的時候，SQL里都是通過索引定位到表中他要計算的那個數據分片。這樣搞合適嗎？

答案顯然是否定的！因為表里的數據量很大，但是你每次實際SQL運算只要對其中很小很小的一部分數據計算就可以了，實際上我們在生產環境中實踐過后發現，如果你在一個大表運行一個復雜SQL，哪怕通過各種索引保證定位到的數據量很少，因為表數據量過大，也是會導致性能直線下降的。

因此第一件事情，先將數據的存儲和計算這兩件事情拆開。

• 我們當時的思路如下：
• 數據直接寫入一個存儲，僅僅只是簡單的寫入即可
• 然后在計算的時候從數據存儲中提取你需要的那個數據分片里的可能就一兩千條數據，寫入另外一個專用于計算的臨時表中，那個臨時表內就這一兩千條數據

然后運行你的各種復雜SQL即可。

bingo！一旦將數據存儲和計算兩個事情拆開，架構里可以發揮的空間就大多了。

首先你的數據存儲只要支撐高并發的寫入，日百億流量的話，高峰每秒并發會達到幾十萬，撐住這就可以了。然后支持計算引擎通過簡單的操作從數據存儲里提取少量數據就OK。

太好了，這個數據存儲就可以PASS掉MySQL了，就這點兒需求，你還用MySQL干什么？兄弟！

當時我們經過充分的技術調研和選型之后，選擇了公司自研的分布式KV存儲系統，這套KV存儲系統是完全分布式的，高可用，高性能，輕量級，支持海量數據，而且之前經歷過公司線上流量的百億級請求量的考驗，絕對沒問題。主要支持高并發的寫入數據以及簡單的查詢操作，完全符合我們的需求。

這里給大家提一句，其實業內很多類似場景會選擇hbase，所以大家如果沒有公司自研的優秀kv存儲的話，可以用選用hbase也是沒問題的，只不過hbase有可能生產環境會有點坑，需要大家對hbase非常精通，合理避坑和優化。

輕量級的分布式kv系統，一般設計理念都是支持一些簡單的kv操作，大量的依托于內存緩存熱數據來支持高并發的寫入和讀取，因為不需要支持MySQL里的那些事務啊、復雜SQL啊之類的重量級的機制。

因此在同等的機器資源條件下，kv存儲對高并發的支撐能力至少是MySQL的數倍甚至數十倍。

就好比說，大家應該都用過Redis，Redis普通配置的單機器撐個每秒幾萬并發都是ok的，其實就是這個道理，他非常的輕量級，轉為高并發而生。

然后，我們還是可以基于MySQL中的一些臨時表來存放kv存儲中提取出來的數據分片，利用MySQL對復雜SQL語法的支持來進行計算就可以了。也就是說，我們在這個架構里，把kv系統作為存儲，把MySQL用做少量數據的計算。

此時我們在系統架構中引入了分布式kv系統來作為我們的數據存儲，每天的海量數據都存放在這里就可以了，然后我們的Slave計算引擎每次計算，都是根據那個數據分片從kv存儲中提取對應的數據出來放入MySQL內的一個臨時表，接著就是對那個臨時表內的一兩千條數據分片運行各種復雜SQL進行計算即可。

大家看上面的圖，此時通過這一步計算與存儲架構的分離，我們選用了適合支撐高并發的kv集群來抗住每天百億級的流量寫入。然后基于MySQL作為臨時表放入少量數據來進行運算。這一個步驟就直接把高并發請求可以妥妥的抗住了。

而且分布式kv存儲本來就可以按需擴容，如果并發越來越高，只要擴容增加機器就可以了。此時，就完成了架構的一個關鍵的重構步驟。

四、自研純內存SQL計算引擎

下一步，我們就要對架構追求極致！因為此時我們面臨的一個痛點就在于說，其實僅僅只是將MySQL作為一個臨時表來計算了，主要就是用他的復雜SQL語法的支持。

但是問題是，對MySQL的并發量雖然大幅度降低了，可是還并不算太低。因為大量的數據分片要計算，還是需要頻繁的讀寫MySQL。

此外，每次從kv存儲里提取出來了數據，還得放到MySQL的臨時表里，還得發送SQL去MySQL里運算，這還是多了幾個步驟的時間開銷。

因為當時面臨的另外一個問題是，每天請求量大，意味著數據量大，數據量大意味著時間分片的計算任務負載還是較重。

總是這么依賴MySQL，還要額外維護一大堆的各種臨時表，可能多達幾百個臨時表，你要維護，要注意他的表結構的修改，還有分庫分表的一些運維操作，這一切都讓依賴MySQL這個事兒顯得那么的多余和麻煩。

因此，我們做出決定，為了讓架構的維護性更高，而且將性能優化到極致，我們要自己研發純內存的SQL計算引擎。

其實如果你要自研一個可以支持MySQL那么復雜SQL語法的內存SQL計算引擎，還是有點難度和麻煩的。但是在我們仔細研究了業務需要的那幾百個SQL之后，發現其實問題沒那么的復雜。

因為其實一般的數據分析類的SQL，主要就是一些常見的功能，沒有那么多的怪、難、偏的SQL語法。

因此我們將線上的SQL都分析過一遍之后，就針對性的研發出了僅僅支持特定少數語法的SQL引擎，包括了嵌套查詢組件、多表關聯組件、分組聚合組件、多字段排序組件、少數幾個常用函數，等等。

接著就將系統徹底重構為不再依賴MySQL，每次從kv存儲中提取一個數據分片之后，直接放入內存中，然后用我們自研的SQL計算引擎來在純內存里針對一個數據分片執行各種復雜的SQL。

這個純內存操作的性能，那就不用多說了，大家應該都能想象到了，基本上純內存的SQL執行，都是毫秒級的，基本上一個時間分片的運算全部降低到毫秒級了。性能進一步得到了大幅度的提升，而且從此不再依賴MySQL了，不需要維護復雜的分庫分表等等東西。

這套架構上線之后，徹底消除了對MySQL的依賴，理論上，無論多大的流量過來，都可以通過立馬擴容kv集群以及擴容Slave計算集群來解決，不需要依賴MySQL的分庫分表、幾百張臨時表等比較耗費人力、麻煩而且坑爹的方案了。而且這種純內存的計算架構直接把計算性能提升到了毫秒級。

而且消除對MySQL的依賴有另外一個好處，數據庫的機器總是要高配置的，但是Slave機器主要4核8G的普通虛擬機就夠了，分布式系統的本質就是盡量利用大量的廉價普通機器就可以完成高效的存儲和計算。

因此在百億流量的負載之下，我們Slave機器部署了幾十臺機器就足夠了，那總比你部署幾十臺昂貴的高配置MySQL物理機來的劃算多了！

五、MQ削峰以及流量控制

其實如果對高并發架構稍微了解點的同學都會發現，這個系統的架構中，針對高并發的寫入這塊，還有一個比較關鍵的組件要加入，就是MQ。

因為我們如果應對的是高并發的非實時響應的寫入請求的話，完全可以使用MQ中間件先抗住海量的請求，接著做一個中間的流量分發系統，將流量異步轉發到kv存儲中去，同時這個流量分發系統可以對高并發流量進行控制。

比如說如果瞬時高并發的寫入真的導致后臺系統壓力過大，那么就可以由流量分發系統自動根據我們設定的閾值進行流量控制，避免高并發的壓力打垮后臺系統。

而且在這個流控系統中，我們其實還做了很多的細節性的優化，比如說數據校驗、過濾無效數據、切分數據分片、數據同步的冪等機制、100%保證數據落地到kv集群的機制保障，等等。

公司的MQ集群天然都支撐過大流量寫入以及高并發請求，因此MQ集群那個層面抗住高并發并不是什么問題，再高的并發按需擴容就可以了，然后我們自己的流控系統也是集群部署的，線上采用的是4核8G的虛擬機，因為這個機器不需要太高的配置。

流控系統，基本線上我們一般保持在每臺機器承載每秒小三千左右的并發請求，百億流量場景下，高峰每秒并發在每秒小幾十萬的級別，因此這個流控集群部署到幾十臺機器就足夠了。

而公司的kv集群也是天然支撐過大流量高并發寫入的，因此kv集群按需擴容，抗住高并發帶流量的寫入也不是什么問題，而且這里其實我們因為在自身架構層面做了大量的優化（存儲與計算分離的關鍵點），因此kv集群的定位基本就是online storage，一個在線存儲罷了。

通過合理、巧妙的設計key以及value的數據類型，使得我們對kv集群的讀寫請求都是優化成最最簡單的key-value的讀寫操作，天然保證高并發讀寫是沒問題的。

另外稍微給大家一點點的劇透，后面講到全鏈路99.99%高可用架構的時候，這個流控集群會發揮巨大的作用，他是承上啟下的一個效果，前置的MQ集群故障的高可用保障，以及后置的KV集群故障的高可用保障，都是依靠流控集群來實現的。

六、數據的動靜分離架構

在完成上述重構之后，我們又對核心的自研內存SQL計算引擎做了進一步的優化。因為在實際生產環境運行過程中，我們發現了一個問題：就是每次如果Slave節點都是對一個數據分片提取相關聯的各種數據出來然后進行計算，其實是沒必要的！

給大家舉個例子，如果你的SQL要對一些表進行關聯計算，里面涉及到了一些大部分時候靜態不變的數據，那些表的數據一般很少改變，因此沒必要每次都走網絡請求從kv存儲里提取那部分數據。

我們其實完全可以在Slave節點對這種靜態數據做個輕量級的cache，然后只有數據分片里對應的動態改變的數據才從kv存儲來提取數據。

通過這個數據的動靜分離架構，我們基本上把Slave節點對kv集群的網絡請求降低到了最少，性能提升到了最高。大家看下面的圖。

七、階段性總結

這套架構到此為止，基本上就演進得比較不錯了，因為超高并發寫入、極速高性能計算、按需任意擴容，等各種特性都可以支持到了，基本上從寫入到計算，這兩個步驟，是沒什么太大的瓶頸了。

而且通過自研內存SQL計算引擎的方案，將我們的實時計算性能提升到了毫秒級的標準，基本已經達到極致。

八、下一步展望

下一步，我們就要看看這個架構中的左側，還有一個MySQL呢！

首先是實時計算鏈路和離線計算鏈路，都會導入大量的計算結果到那個MySQL中。

其次面向數十萬甚至上百萬的B端商家時，如果是實時展示數據分析結果的話，一般頁面上會有定時的JS腳本，每隔幾秒鐘就會發送請求過來加載最新的數據計算結果。

因此實際上那個專門面向終端用戶的MySQL也會承受極大的數據量的壓力，高并發寫入的壓力以及高并發查詢的壓力。?