基于Lindorm的網際網路賬單解決方案

使用者福利

阿裡雲最新釋出業界首款雲原生多模資料庫Lindorm，新使用者可享9.9元/3個月優惠，技術交流釘釘群：35977898，更多内容請

參考連結

一、背景

不管是對于傳統行業還是對于網際網路行業，交易訂單資料的存儲需求由來已久，比如筆者最初所處的民航業，其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正是這樣一個合适的資料庫選型。

3、基于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等，滿足海量資料下的高效檢索需求。

4、Lindorm核心能力概述

Lindorm通過全方位多角度的能力提升，充分滿足了賬單場景的高可用、高吞吐、低延遲、低成本、多元度及可能的突發熱點請求等等一系列的需求。

當然，Lindorm的能力還遠不止于此，Lindorm具備了大資料背景下，面向海量資料的存儲系統應該具備的一系列的能力：

• 是一款支援寬表、時序、搜尋、檔案的多模資料庫
• 是一款基于存儲計算分離架構的資料庫，提供極緻的計算、存儲彈性伸縮能力，并将全新提供Serverless服務，實作按需即時彈性、按使用量付費的能力
• 是一款支援冷熱分離、、追求更優壓縮優化方案的極具成本效益的資料庫
• 是一款具備全局二級索引、多元檢索、時序索引等功能的資料庫
• 提供具備智能化服務能力的LDInsight工具，白屏化完成系統管理、資料通路及故障診斷
• 提供LTS(Lindorm Tunnel Service，原BDS)，支援簡單易用的資料交換、處理、訂閱等能力，滿足使用者的資料遷移、實時訂閱、數湖轉存、數倉回流、單元化多活、備份恢複等需求

5、賬單場景客戶案例

第三方支付賬單

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

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

收錢吧

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

收錢吧使用Lindorm作為其訂單解決方案，成功實作了：

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

咨詢交流

歡迎加入Lindorm技術交流群