用戶福利

阿里雲最新發布業界首款雲原生多模數據庫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保障，並有專家團隊的免費技術支持，使客戶能全力以赴聚焦業務側發展