出處:https://mp.weixin.qq.com/s?__biz=MzU5OTQ1MDEzMA==&mid=2247488375&idx=1&sn=9f3264de8bf91325cab75bf924d1c46e

一.背景

不管是對於傳統行業還是對於網際網路行業，交易訂單資料的儲存需求由來已久，比如筆者最初所處的民航業，其CRS系統（代理人機票售票系統）儲存了旅客的訂座記錄；又如各類銀行需要儲存廣大儲戶在其系統內的支取和存入的流水記錄；再如電子商務/第三方支付平臺，廣大網民的網購、繳費、理財、充值等交易行為的記錄也需要儲存。交易性質的資料往往有較強的事務需求，比如電商系統中交易資料的儲存會有多張表，表與表之間的資料需要保證強一致性。基於這樣的要求，CRS系統最初選擇了專業性較強的Unisys大型機系統及其資料庫；銀行的選擇則是大家較為熟悉的IBM DB2；而淘寶/支付寶這樣的電子商務的領頭羊，最初的選擇則是Oracle，在Oracle時代往往是一個業務一套資料庫，不同業務做垂直隔離，其架構如下圖所示：

如前所述，對於第三方支付場景，交易系統主要面向接單，操作以寫入為主。但是，隨著其業務場景的不斷豐富，從最初只有網上購物，之後湧現出轉賬、公共事業繳費、話費充值等等越來越多的場景，而這些系統因其業務特徵的不同，往往是相互垂直，相對獨立的交易系統。這樣一來，對於一個普通網民而言產生了一個樸素而基本的需求，有一個統一的賬單查詢入口，畢竟普通老百姓的錢不是大風颳來的。因此，賬單系統應運而生。

二.網際網路賬單系統的架構演進

網際網路賬單系統，從誕生的第一天起附帶了一些天然的屬性。

只讀性： 賬單的資料來自於上游各個交易系統，透過可靠訊息進行資料同步，提供統一的查詢入口給終端使用者。高增長： 網際網路的一個非常典型的特徵就是超乎想象的高速增長，特別是處於風口的豬，是真的會被吹起來的。低成本： 賬單系統不像交易系統，不直接產生經濟效益，總有一種庶出的感覺。因此，期望重金投入那是絕對不可能的。高可用： 賬單系統是面向客戶，對交易系統的延伸，是客戶對交易資料的查詢入口，對C端客戶而言，其實並存在交易系統和賬單系統的區分。因此，這兩個系統的可用性要求是一致的。多維度查詢： 對於C端使用者而言，往往會從不同角度對賬單進行分類、標記以及檢視和過濾自己的賬單。2.1一代架構2.1.1 基於MySQL的分庫分表

基於上述的特徵，在IOE還處於統治地位的時代，支付賬單系統最初擁抱的並不是交易系統使用的、成本高昂的Oracle資料庫，而是開源世界裡最流行的、基於PC伺服器的MySQL資料庫，並且因為規模的原因，往往需要引入相對更加複雜的分表、分庫方案，其架構如下圖所示(圖中省略了MySQL Slave叢集及Master、Slave間的複製關係)：

然而，如前所述，業務的快速增長帶來資料的極速膨脹，需要不斷的增加分表、分庫的數量，否則就會達到MySQL單例項的瓶頸，而拆分為更大規模的分表、分庫的運維代價是極其巨大的。基於此原因，賬單系統的儲存演變到了下一代架構。

2.2 二代架構

上文描述到，隨著業務的不斷增長，由於MySQL自身容量的天花板，第一代架構面臨的問題無法解決，單純依賴MySQL的架構已經不再是賬單業務的合適選擇。因此，不同的使用者做出了不同的選擇。

2.2.1 MySQL熱資料+HBase全量的混布架構

做為架構演進的一種選擇，有一部分使用者的選擇是仍然依賴MySQL，但會將透過訊息系統過來的資料同時寫入到MySQL的分表和HBase叢集中的單表。MySQL做為主儲存，承擔“熱”資料的讀請求，而HBase做為備儲存，僅承擔歷史資料的讀請求。這種架構下MySQL僅需要儲存業務定義的指定週期內的熱資料，因此，在演變到該架構的初期，極大的緩解了資料增長帶來的壓力。但是，隨著時間的推移，業務的飛速發展，熱資料的量不斷變大，因此仍然面臨繼續做拆分的需求；而且需要每天起定時任務進行歷史資料的刪除，大規模的資料刪除引起了叢集負載的升高，對叢集穩定性產生了嚴重的隱患；另一方面，業務形態也在發生變化，比如：出現了最典型的“雙十一”，這樣超級的業務大熱點，這就迫使需要對MySQL做更細粒度的拆分，並且每年大促前要大量擴容節點，大促後還原到原有規模，這對於儲存系統提出了極致的彈性擴縮容需求，而這樣的要求對於儲存計算一體化的架構而言是非常大的挑戰。同時，雙十一帶來的不僅僅是業務量上的一個巨大尖刺，也帶來了一些其他的不穩定因素，比如：會隨時奔出來一個大賣家，這樣的大熱點往往導致單個MySQL例項容量不足，在計算儲存一體化的架構下，應對這樣的問題總是顯得有點力不從心。

2.2.2 基於Share Nothing架構的分散式關係型資料庫

做為架構演進的另一種選擇，其他一部分使用者則拋棄了MySQL，選擇新的市面上比較流行的分散式關係型資料庫。分散式關係型資料庫透過其內建的資料分片的能力，很好的避免了業務增長、新業務場景(雙十一)帶來的分庫、分表的需求；透過其自動化的擴容/縮容能力，相比MySQL架構下的運維成本也有大幅度的降低。但是，這種架構下也面臨著一些問題：

儲存成本高無法按需擴縮容： 單臺服務內的CPU、記憶體、磁碟資源的配比是固定的，在Share Nothing架構下，不管是計算還是儲存資源不足，都只能進行整體擴容，這樣就導致了不必要的資源投入，從而提高了執行成本。冷熱分離： 在Share Nothing架構下，即便不考慮是否已經實現了冷熱分離，在實踐層面也會有一些問題。比如：賬單資料有永久儲存的需求，意味著冷資料佔比會越來越高，而機型是固定的，因此叢集會因為冷儲存不能滿足需求，而進行擴容，從而導致不必要的資源投入；或者採用非固定/非標準化機型，則意味著運維複雜度的提升。效能問題： 關係型資料庫主要面向的業務場景是有強事務需求的交易、支付、賬務類業務，需要強事務保證，往往會導致部分操作的序列化，從而降低了效能。另一方相關係型資料庫不像NoSQL，需要經過SQL層的解析並生成執行計劃後才能執行，這個過程也不可避免的產生了一定的資源開銷，從而降低了效能。效能的下降意味著單機吞吐量的下降，進而需要更多的伺服器資源的投入，即意味著成本的增加彈效能力差儲存計算一體的Share Nothing架構，導致擴容節點的過程需要伴隨著資料的搬遷，從而導致節點擴容的代價和耗時都是比較大的，導致面對雙十一這樣的需要極致彈性擴縮容能力的場景，顯得力不從心。更長的擴縮容時間意味著更長的資源保有周期，從而提升了大促執行成本熱點問題：應急效率低： Share Nothing架構下，應對隨時可能出現的熱點問題也是非常低效的,導致有較高的穩定性風險。比如：雙十一突然湧現出來的一個大賣家，熱點賣家和該節點的其他賣家共享伺服器資源，由於歷史資料的存在，並不能立即隔離識別出來的熱點，而是需要等待歷史資料同步完成後，才能切流到獨立的空閒節點。這樣的應急速度在雙十一這樣的大促下顯然是非常低效，難以滿足穩定性需求的。儲存不均衡： Share Nothing架構下，有熱點賬號的情況下，資料量往往也會比較大，導致節點間資料量的不均衡，從而需要人工去幹預對大賬號所在節點做拆分，導致運維成本上升。2.3 三代架構

因此，勢必需要有一種新的更完善的資料庫產品來滿足賬單場景的需求。首先，我們簡單回顧一下一、二代架構下面臨的最核心的業務痛點，也是三代架構下必須要著重面對並且解決的問題。

儲存成本高彈效能力差熱點問題

那麼，市面上是否存在這樣的一款資料庫產品“恰好” 能解決賬單場景在一、二代架構下遇到的問題，同時又能很好的滿足賬單系統對可用性，對多維度查詢的要求？答案是肯定的。Lindorm正是這樣一個合適的資料庫選型。

三.基於Lindorm的架構

Lindorm是誕生於大資料時代的一款NoSQL資料庫，低成本解決海量大資料的高效存、取是根植於其體內的基因。Lindorm在阿里內部歷經十年的技術積澱，目前是阿里內部使用最為廣泛的、資料體量最大的核心資料庫產品。這一切歸功於Lindorm擁有眾多的核心技術和功能特性。那麼，面向賬單場景的業務痛點，Lindorm有哪些重要的抓手呢？

3.1 低成本

對於賬單這樣的海量資料場景，資料有著非常典型的訪問特徵，近期資料訪問頻率較高，請求的響應延遲要求也較高，隨著時間的推移訪問頻率會逐步降低，甚至僅作為歷史資料存在，而只有極少量的訪問，但另一方面業務要求資料永久保留的特性，導致其線上資料體量非常大。Lindorm的冷熱分離和壓縮最佳化則可以非常有效的解決這個問題。

3.1.1 冷熱分離

Lindorm具備在單一個儲存架構下的“一張表”內實現資料的冷熱分離，系統會自動根據使用者設定的冷熱分界線，自動將表中的冷資料歸檔到冷儲存中。在使用者的訪問方式上和普通表幾乎沒有任何差異，在查詢的過程中，使用者只需配置查詢Hint或者Time Range，系統根據條件自動地判斷查詢應該落在熱資料區還是冷資料區。對使用者而言始終是一張表，對使用者幾乎做到完全的透明。

3.1.2 壓縮最佳化

儲存成本最低的系統是沒有資料需要儲存的系統，但這點顯然是不現實的，現實可行的方案是將需要儲存的資料降到合理的最低點。為了降低儲存開銷，Lindorm引入了一種新的無失真壓縮演算法，旨在提供快速壓縮，並實現高壓縮比。它既不像LZMA和ZPAQ那樣追求儘可能高的壓縮比，也不像LZ4那樣追求極致的壓縮速度。這種演算法的壓縮速度超過200MB/s, 解壓速度超過400MB/s（實驗室資料），很好的滿足Lindorm對吞吐量的需求。經實際場景驗證，新的壓縮最佳化下，壓縮比相對於LZO有非常顯著的提高，儲存節省可以達到50%～100%，對於儲存型業務，這就意味著最高可以達到50%的成本減少。

3.2 極致彈性

網際網路世界總是以超乎想象的速度在飛速增長。賬單的峰值讀&寫請求量、需要儲存資料量會伴隨著業務飛速的增長，每年都會是上一年的翻倍甚至數倍，因此需要儲存系統具備良好的擴充套件能力。

雙十一這樣的業務場景，則會瞬間帶來數十倍甚至百倍的峰值讀寫量，為了滿足這樣的場景，就需要儲存系統具備更加極致的彈性擴、縮容的能力。

如前所述，低成本解決海量大資料的高效存、取是根植於Lindorm體內的基因。因此，Lindorm天然就具備了良好的線性擴充套件能力，可以很好的支撐每秒億級別請求，PB級資料量，而且在大資料量、高併發下仍然能提供穩定的毫秒級的平均響應。

Lindorm原生支援儲存計算分離架構( 其架構如下圖)，這樣的架構設計使得叢集擴容、縮容都變得非常的輕量，說簡單一點就是“起個程序+資料分片balance”這點事，新節點接收業務請求並不需要等待歷史資料的搬遷，而縮容剛剛好是逆向的過程。因此，對於Lindorm而言彈性擴縮容當然是分分鐘搞定咯！

3.3 熱點問題3.3.1 高效熱點響應

交易分為買家和賣家兩個對手方，賬單資料也往往會按照這兩個使用者維度進行組織。從單個買家角度看往往交易量較低，不至於形成熱點。但是賣家卻可能是一個大的焦點，特別是在雙十一這樣的大壓力下，單個UID的交易量尖刺往往會更高。熱點對於任何一個儲存系統而言都是災難性的，但Lindorm天然的讀寫分離架構在應對熱點方面會有更大的優勢。Lindorm分為儲存和計算兩層，LDserver負責資料分片的組織和讀寫訪問，Lindorm Store負責檔案的儲存和訪問。資料分片在不同LDserver之間的移動並不需要考慮Lindorm Store層儲存位置。因此，當讀寫出現熱點時，Lindorm可以透過快速移動資料分片到空閒節點，即可秒級完成熱點資料分片的隔離，達到提升抗熱點的能力。

3.3.2 儲存水位不均問題

如前所述，Lindorm採用儲存計算分離的架構，資料按region進行分片，其大小在GB級別，通常指定為8G，16G，超過閾值會自動進行split，資料分片會自動在不同節點間進行balance。因此，這樣的架構設計使得Lindorm可以很好的保持不同節點間資料量的均衡。從而很好的避免了Share Nothing架構下熱點賬號帶來的“不必要”的運維工作。

3.4 其他必要特性

Lindorm的上述幾個特性很好的解決了賬單系統在一、二代架構中難於解決的問題，但是賬單場景對儲存系統基本要求：可用性、多維度查詢，在三代架構下也是必須要滿足的，否則就是顧此失彼，甚至得不償失了。

3.4.1 高可用

Lindorm的表資料透過自動balance策略分散到叢集中的多臺伺服器上，每一個數據分片可以擁有1至N個副本，這N個副本擁有主、從兩種角色，主從副本可以載入在不同的Zone，從而保障叢集的高可用和強一致。針對不同的一致性模式，主從副本之間的資料同步和讀寫模式如下：

強一致模式： 只有主副本提供讀寫，資料會非同步回放到從副本,主副本所在節點故障，從副本晉升為主(晉升之前會保障資料同步完成，從副本擁有所有最新資料，整體過程由Master協調負責)最終一致模式： 主從副本都提供讀寫，資料會相互同步，保證副本之間的資料最終一致。

透過這樣的高可用機制，Lindorm可以很好的保障賬單這樣的對資料強一致性和可用性需求都非常高的業務。

3.4.2 多維度查詢

為了解決業務基於非主鍵列的查詢問題，Lindorm內建原生的全域性二級索引功能，對於列較少且有固定查詢模式的場景來說，高效能二級索引方案能夠完美解決此類問題，同時仍保持強大的吞吐與效能。

當面對更加複雜的查詢，比如模糊查詢、隨機條件組合查詢等等，二級索引方案會顯得力不從心，這時候Lindorm搜尋引擎LSearch就有其用武之地。LSearch是面向海量資料設計的分散式搜尋引擎，相容開源Solr標準介面，同時可無縫作為寬表、時序引擎的索引儲存，加速檢索查詢。其整體架構與寬表引擎一致，基於資料自動分割槽+分割槽多副本+Lucene的結構設計，具備全文檢索、聚合計算、複雜多維查詢等能力，支援水平擴充套件、一寫多讀、跨機房容災、TTL等，滿足海量資料下的高效檢索需求。

四.Lindorm核心能力概述

Lindorm透過全方位多角度的能力提升，充分滿足了賬單場景的高可用、高吞吐、低延遲、低成本、多維度及可能的突發熱點請求等等一系列的需求。當然，Lindorm的能力還遠不止於此，Lindorm具備了大資料背景下，面向海量資料的儲存系統應該具備的一系列的能力：

是一款支援寬表、時序、搜尋、檔案的多模資料庫是一款基於儲存計算分離架構的資料庫，提供極致的計算、儲存彈性伸縮能力，並將全新提供Serverless服務，實現按需即時彈性、按使用量付費的能力是一款支援冷熱分離、、追求更優壓縮最佳化方案的極具價效比的資料庫是一款具備全域性二級索引、多維檢索、時序索引等功能的資料庫提供具備智慧化服務能力的LDInsight工具，白屏化完成系統管理、資料訪問及故障診斷提供LTS(Lindorm Tunnel Service，原BDS)，支援簡單易用的資料交換、處理、訂閱等能力，滿足使用者的資料遷移、實時訂閱、數湖轉存、數倉迴流、單元化多活、備份恢復等需求5、賬單場景客戶案例第三方支付賬單

某國內領先的第三方支付平臺，致力於提供“簡單、安全、快速”的支付解決方案。自2014年第二季度開始成為當前全球最大的移動支付廠商。

自從2013年起，該第三方支付平臺已經將其全量的線上交易、線下交易、繳費、轉賬等等各類交易資料全量儲存在Lindorm內，提供實時、線上查詢，可以獲取賬單詳情以及透過各類篩選條件滿足C端使用者的賬單篩選需求。

收錢吧

隸屬於上海喔噻網際網路科技有限公司，是中國移動支付服務商領軍者，致力於用網路和資料的力量服務線下實體商家。收錢吧不僅為商家提供專業移動支付收款工具，同時也是為商家提供金融、廣告、營銷管理、供應鏈等多種服務的生意幫手。2014年12月，收錢吧正式上線，開創了中國移動支付市場“一站式收款”時代，併成功研發了“收錢吧掃碼王”等全場景智慧收款裝置，產品獲得多項國家專利。目前收錢吧服務超過330萬商家，日服務3000萬人次。收錢吧使用Lindorm作為其訂單解決方案，成功實現了：

全文索引方案，使得業務高效能實現高維度&隨機組合場景下的訂單搜尋資料壓縮最佳化及叢集內冷熱分離，使得業務低成本實現資料永久保留相比最佳化前的架構，成本下降77.42%全託管、免運維及SLA保障，並有專家團隊的免費技術支援，使客戶能全力以赴聚焦業務側發展

作者:吳起

出處:https://mp.weixin.qq.com/s?__biz=MzU5OTQ1MDEzMA==&mid=2247488375&idx=1&sn=9f3264de8bf91325cab75bf924d1c46e