阿里妹導讀：Lindorm，就是云操作系統飛天中面向大數據存儲處理的重要組成部分。Lindorm是基于HBase研發的、面向大數據領域的分布式NoSQL數據庫，集大規模、高吞吐、快速靈活、實時混合能力于一身，面向海量數據場景提供世界領先的高性能、可跨域、多一致、多模型的混合存儲處理能力。目前，Lindorm已經全面服務于阿里經濟體中的大數據結構化、半結構化存儲場景。

注：Lindorm是阿里內部HBase分支的別稱，在阿里云上對外售賣的版本叫做HBase增強版，之后文中出現的HBase增強版和Lindorm都指同一個產品。

2019年以來，Lindorm已經服務了包括淘寶、天貓、螞蟻、菜鳥、媽媽、優酷、高德、大文娛等數十個BU，在今年的雙十一中，Lindorm峰值請求達到了7.5億次每秒，天吞吐22.9萬億次，平均響應時間低于3ms，整體存儲的數據量達到了數百PB。這些數字的背后，凝聚了HBase&Lindorm團隊多年以來的汗水和心血。Lindorm脫胎于HBase，是團隊多年以來承載數百PB數據，億級請求量，上千個業務后，在面對規模成本壓力，以及HBase自身缺陷下，全面重構和引擎升級的全新產品。相比HBase，Lindorm無論是性能，功能還是可用性上，都有了巨大飛躍。本文將從功能、可用性、性能成本、服務生態等維度介紹Lindorm的核心能力與業務表現，最后分享部分我們正在進行中的一些項目。

極致優化，超強性能

Lindorm比HBase在RPC、內存管理，緩存、日志寫入等方面做了深度的優化，引入了眾多新技術，大幅提升了讀寫性能，在相同硬件的情況下，吞吐可達到HBase的5倍以上，毛刺更是可以達到HBase的1/10。這些性能數據，并不是在實驗室條件下產生的，而是在不改動任何參數的前提下，使用開源測試工具YCSB跑出來的成績。我們把測試的工具和場景都公布在阿里云的幫助文件中，任何人都可以依照指南自己跑出一樣的結果。

取得這么優異的性能的背后，是Lindorm中積攢多年的“黑科技”，下面，我們簡單介紹下Lindorm內核中使用到的部分“黑科技”。

Trie Index

Lindorm 的文件LDFile（類似HBase中的HFile）是只讀 B+ 樹結構，其中文件索引是至關重要的數據結構。在 block cache 中有高優先級，需要盡量常駐內存。如果能降低文件索引所占空間大小，我們可以節省 block cache 中索引所需要的寶貴內存空間?；蛘咴谒饕臻g不變的情況下，增加索引密度，降低 data block 的大小，從而提高性能。而HBase中的索引block中存的是全量的Rowkey，而在一個已經排序好的文件中，很多Rowkey都是有共同前綴的。

數據結構中的Trie (前綴樹) 結構能夠讓共同前綴只存一份，避免重復存儲帶來的浪費。但是傳統前綴樹結構中，從一個節點到下一個節點的指針占用空間太多，整體而言得不償失。這一情況有望用 Succinct Prefix Tree 來解決。SIGMOD2018年的最佳論文 Surf 中提出了一種用 Succinct Prefix Tree 來取代 bloom filter，并同時提供 range filtering 的功能。我們從這篇文章得到啟發，用 Succinct Trie 來做 file block index。

我們在線上的多個業務中使用了Trie index實現的索引結構。結果發現，各個場景中，Trie index可以大大縮小索引的體積，最多可以壓縮12倍的索引空間！節省的這些寶貴空間讓內存Cache中能夠存放更多的索引和數據文件，大大提高了請求的性能。

ZGC加持，百GB堆平均5ms暫停

ZGC(Powerd by Dragonwell JDK)是下一代Pauseless GC算法的代表之一，其核心思想是Mutator利用內存讀屏障(Read Barrier)識別指針變化，使得大部分的標記(Mark)與合并(Relocate)工作可以放在并發階段執行。 這樣一項實驗性技術，在Lindorm團隊與AJDK團隊的緊密合作下，進行了大量的改進與改造工作。使得ZGC在Lindorm這個場景上實現了生產級可用，主要工作包括：

Lindorm內存自管理技術，數量級減少對象數與內存分配速率。(比如說阿里HBase團隊貢獻給社區的CCSMap)。

AJDK ZGC Page緩存機制優化(鎖、Page緩存策略)。

AJDK ZGC 觸發時機優化，ZGC無并發失敗。AJDK ZGC在Lindorm上穩定運行兩個月，并順利通過雙十一大考。其JVM暫停時間穩定在5ms左右，最大暫停時間不超過8ms。ZGC大大改善了線上運行集群的RT與毛刺指標，平均RT優化15%～20%，P999 RT減少一倍。在今年雙十一螞蟻風控集群中，在ZGC的加持下，P999時間從12ms降低到了5ms。

注：圖中的單位應該為us，平均GC在5ms

LindormBlockingQueue

上圖是HBase中的RegionServer從網絡上讀取RPC請求并分發到各個Handler上執行的流程。HBase中的RPC Reader從Socket上讀取RPC請求放入BlockingQueue，Handler訂閱這個Queue并執行請求。而這個BlockingQueue，HBase使用的是Java原生的JDK自帶的LinkedBlockingQueue。

LinkedBlockingQueue利用Lock與Condition保證線程安全與線程之間的同步，雖然經典易懂，但當吞吐增大時，這個queue會造成嚴重的性能瓶頸。因此在Lindorm中全新設計了LindormBlockingQueue，將元素維護在Slot數組中。維護head與tail指針，通過CAS操作對進隊列進行讀寫操作，消除了臨界區。并使用Cache Line Padding與臟讀緩存加速，同時可定制多種等待策略(Spin/Yield/Block)，避免隊列為空或為滿時，頻繁進入Park狀態。LindormBlockingQueue的性能非常突出，相比于原先的LinkedBlockingQueue性能提升4倍以上。

VersionBasedSynchronizer

LDLog是Lindorm中用于系統failover時進行數據恢復時的日志，以保障數據的原子性和可靠性。在每次數據寫入時，都必須先寫入LDLog。LDLog寫入成功之后，才可以進行后續的寫入memstore等操作。因此Lindorm中的Handler都必須等待WAL寫入完成后再被喚醒以進行下一步操作，在高壓條件下，無用喚醒會造成大量的CPU Context Switch造成性能下降。針對這個問題，Lindorm研發了基于版本的高并發多路線程同步機制(VersionBasedSynchronizer)來大幅優化上下文切換。

VersionBasedSynchronizer的主要思路是讓Handler的等待條件被Notifier感知，減少Notifier的喚醒壓力。經過模塊測試VersionBasedSynchronizer的效率是JDK自帶的ObjectMonitor和J.U.C(java util concurrent包)的兩倍以上。

全面無鎖化

HBase內核在關鍵路徑上有大量的鎖，在高并發場景下，這些鎖都會造成線程爭搶和性能下降。Lindorm內核對關鍵鏈路上的鎖都做了無鎖化處理，如MVCC，WAL模塊中的鎖。另外，HBase在運行過程中會產生的各種指標，如qps，rt，cache命中率等等。而在記錄這些Metrics的“不起眼”操作中，也會有大量的鎖。面對這樣的問題，Lindorm借鑒了tcmalloc的思想，開發了LindormThreadCacheCounter，來解決Metrics的性能問題。

Handler協程化

在高并發應用中，一個RPC請求的實現往往包含多個子模塊，涉及到若干次IO。這些子模塊的相互協作，系統的ContextSwitch相當頻繁。ContextSwitch的優化是高并發系統繞不開的話題，各位高手都各顯神通，業界有非常多的思想與實踐。其中coroutine(協程)和SEDA(分階段事件驅動)方案是我們著重考察的方案?；诠こ檀鷥r，可維護性，代碼可讀性三個角度考慮，Lindorm選擇了協程的方式進行異步化優化。我們利用了阿里JVM團隊提供的Dragonwell JDK內置的Wisp2.0功能實現了HBase Handler的協程化，Wisp2.0開箱即用，有效地減少了系統的資源消耗，優化效果比較客觀。

全新Encoding算法

從性能角度考慮，HBase通常需要將Meta信息裝載進block cache。如果將block大小較小，Meta信息較多，會出現Meta無法完全裝入Cache的情況, 性能下降。如果block大小較大，經過Encoding的block的順序查詢的性能會成為隨機讀的性能瓶頸。針對這一情況，Lindorm全新開發了Indexable Delta Encoding，在block內部也可以通過索引進行快速查詢，seek性能有了較大提高。Indexable Delta Encoding原理如圖所示：

通過Indexable Delta Encoding， HFile的隨機seek性能相對于使用之前翻了一倍，以64K block為例，隨機seek性能基本與不做encoding相近（其他encoding算法會有一定性能損失）。在全cache命中的隨機Get場景下，相對于Diff encoding RT下降50%

其他

相比社區版HBase，Lindorm還有多達幾十項的性能優化和重構，引入了眾多新技術，由于篇幅有限，這里只能列舉一部分，其他的核心技術，比如：

• CCSMap
• 自動規避故障節點的并發三副本日志協議 (Quorum-based write)
• 高效的批量組提交(Group Commit)
• 無碎片的高性能緩存—Shared BucketCache
• Memstore Bloomfilter
• 面向讀寫的高效數據結構
• GC-Invisible內存管理
• 在線計算與離線作業架構分離
• JDK/操作系統深度優化
• FPGA offloading Compaction
• 用戶態TCP加速
• ……

豐富的查詢模型，降低開發門檻

原生的HBase只支持KV結構的查詢，雖然簡單，但是在面對各項業務的復雜需求時，顯的有點力不從心。因此，在Lindorm中，我們針對不同業務的特點，研發了多種查詢模型，通過更靠近場景的API和索引設計，降低開發門檻。

WideColumn 模型（原生HBase API）

WideColumn是一種與HBase完全一致的訪問模型和數據結構，從而使得Lindrom能100%兼容HBase的API。用戶可以通過Lindorm提供的高性能原生客戶端中的WideColumn API訪問Lindorm，也可以通過alihbase-connector這個插件，使用HBase客戶端及API(無需任何代碼改造)直接訪問Lindorm。同時，Lindorm使用了輕客戶端的設計，將大量數據路由、批量分發、超時、重試等邏輯下沉到服務端，并在網絡傳輸層做了大量的優化，使得應用端的CPU消耗可以大大節省。像下表中，相比于HBase，使用Lindorm后的應用側CPU使用效率提升60%，網絡帶寬效率提升25%。

注：表中的客戶端CPU代表HBase/Lindorm客戶端消耗的CPU資源，越小越好。

在HBase原生API上，我們還獨家支持了高性能二級索引，用戶可以使用HBase原生API寫入數據過程中，索引數據透明地寫入索引表。在查詢過程中，把可能全表掃的Scan + Filter大查詢，變成可以先去查詢索引表，大大提高了查詢性能。

TableService模型(SQL、二級索引)

HBase中只支持Rowkey這一種索引方式，對于多字段查詢時，通常效率低下。為此，用戶需要維護多個表來滿足不同場景的查詢需求，這在一定程度上既增加了應用的開發復雜性，也不能很完美地保證數據一致性和寫入效率。并且HBase中只提供了KV API，只能做Put、Get、Scan等簡單API操作，也沒有數據類型，所有的數據都必須用戶自己轉換和儲存。對于習慣了SQL語言的開發者來說，入門的門檻非常高，而且容易出錯。

為了解決這一痛點，降低用戶使用門檻，提高開發效率，在Lindorm中我們增加了TableService模型，其提供豐富的數據類型、結構化查詢表達API，并原生支持SQL訪問和全局二級索引，解決了眾多的技術挑戰，大幅降低普通用戶的開發門檻。通過SQL和SQL like的API，用戶可以方便地像使用關系數據庫那樣使用Lindorm。下面是一個Lindorm SQL的簡單示例。

-- 主表和索引DDL create table shop_item_relation (shop_id varchar,item_id varchar,status varchar constraint primary key(shop_id, item_id)) ; create index idx1 on shop_item_relation (item_id) include (ALL); -- 對第二列主鍵建索引，冗余所有列 create index idx2 on shop_item_relation (shop_id, status) include (ALL); -- 多列索引，冗余所有列 -- 寫入數據，會同步更新2個索引 upsert into shop_item_relation values('shop1', 'item1', 'active'); upsert into shop_item_relation values('shop1', 'item2', 'invalid'); -- 根據WHERE子句自動選擇合適的索引執行查詢 select * from shop_item_relation where item_id = 'item2'; -- 命中idx1 select * from shop_item_relation where shop_id = 'shop1' and status = 'invalid'; -- 命中idx2

相比于關系數據庫的SQL，Lindorm不具備多行事務和復雜分析(如Join、Groupby)的能力，這也是兩者之間的定位差異。相比于HBase上Phoenix組件提供的二級索引，Lindorm的二級索引在功能、性能、穩定性上遠遠超過Phoenix，下圖是一個簡單的性能對比。

注：該模型已經在阿里云HBase增強版上內測，感興趣的用戶可以聯系云HBase答疑釘釘號或者在阿里云上發起工單咨詢。

FeedStream模型

現代互聯網架構中，消息隊列承擔了非常重要的職責，可以極大的提升核心系統的性能和穩定性。其典型的應用場景有包括系統解耦，削峰限流，日志采集，最終一致保證，分發推送等等。常見的消息隊列包括RabbitMq，Kafka以及RocketMq等等。這些數據庫盡管從架構和使用方式和性能上略有不同，但其基本使用場景都相對接近。然而，傳統的消息隊列并非完美，其在消息推送，feed流等場景存在以下問題：

• 存儲：不適合長期保存數據，通常過期時間都在天級
• 刪除能力：不支持刪除指定數據entry
• 查詢能力：不支持較為復雜的查詢和過濾條件
• 一致性和性能難以同時保證：類似于Kafka之類的數據庫更重吞吐，為了提高性能存在了某些狀況下丟數據的可能，而事務處理能力較好的消息隊列吞吐又較為受限。
• Partition快速拓展能力：通常一個Topc下的partition數目都是固定，不支持快速擴展。
• 物理隊列/邏輯隊列：通常只支持少量物理隊列(如每個partition可以看成一個隊列)，而業務需要的在物理隊列的基礎上模擬出邏輯隊列，如IM系統中為每個用戶維護一個邏輯上的消息隊列，用戶往往需要很多額外的開發工作。

針對上述需求，Lindorm推出了隊列模型FeedStreamService，能夠解決海量用戶下的消息同步，設備通知，自增ID分配等問題。

FeedStream模型在今年手機淘寶消息系統中扮演了重要角色，解決了手機淘寶消息推送保序，冪等等難題。在今年雙十一中，手淘的蓋樓和回血大紅包推送都有Lindorm的身影。手淘消息的推送中，峰值超過了100w/s，做到了分鐘級推送全網用戶。

注：該模型已經在阿里云HBase增強版上內測，感興趣的用戶可以聯系云HBase答疑釘釘號或者在阿里云上發起工單咨詢。

全文索引模型

雖然Lindorm中的TableService模型提供了數據類型和二級索引。但是，在面對各種復雜條件查詢和全文索引的需求下，還是顯得力不從心，而Solr和ES是優秀的全文搜索引擎。使用Lindorm+Solr/ES，可以最大限度發揮Lindorm和Solr/ES各自的優點，從而使得我們可以構建復雜的大數據存儲和檢索服務。Lindorm內置了外部索引同步組件，能夠自動地將寫入Lindorm的數據同步到外部索引組件如Solr或者ES中。這種模型非常適合需要保存大量數據，而查詢條件的字段數據僅占原數據的一小部分，并且需要各種條件組合查詢的業務，例如：

• 常見物流業務場景，需要存儲大量軌跡物流信息，并需根據多個字段任意組合查詢條件
• 交通監控業務場景，保存大量過車記錄，同時會根據車輛信息任意條件組合檢索出感興趣的記錄
• 各種網站會員、商品信息檢索場景，一般保存大量的商品/會員信息，并需要根據少量條件進行復雜且任意的查詢，以滿足網站用戶任意搜索需求等。

全文索引模型已經在阿里云上線，支持Solr/ES外部索引。目前，索引的查詢用戶還需要直接查詢Solr/ES再來反查Lindorm，后續我們會用TableService的語法把查詢外部索引的過程包裝起來，用戶全程只需要和Lindorm交互，即可獲得全文索引的能力。

更多模型在路上

除了上述這些模型，我們還會根據業務的需求和痛點，開發更多簡單易用的模型，方便用戶使用，降低使用門檻。像時序模型，圖模型等，都已經在路上，敬請期待。

零干預、秒恢復的高可用能力

從一個嬰兒成長為青年，阿里HBase摔過很多次，甚至頭破血流，我們在客戶的信任之下幸運的成長。在9年的阿里應用過程中，我們積累了大量的高可用技術，而這些技術，都應用到了HBase增強版中。

MTTR優化

HBase是參照Gooogle著名論文BigTable的開源實現，其中最核心特點是數據持久化存儲于底層的分布式文件系統HDFS，通過HDFS對數據的多副本維護來保障整個系統的高可靠性，而HBase自身不需要去關心數據的多副本及其一致性，這有助于整體工程的簡化，但也引入了"服務單點"的缺陷，即對于確定的數據的讀寫服務只有發生固定的某個節點服務器，這意味著當一個節點宕機后，數據需要通過重放Log恢復內存狀態，并且重新派發給新的節點加載后，才能恢復服務。

當集群規模較大時，HBase單點故障后恢復時間可能會達到10-20分鐘，大規模集群宕機的恢復時間可能需要好幾個小時！而在Lindorm內核中，我們對MTTR（平均故障恢復時間）做了一系列的優化，包括故障恢復時先上線region、并行replay、減少小文件產生等眾多技術。將故障恢復速度提升10倍以上！基本上接近了HBase設計的理論值。

可調的多一致性

在原來的HBase架構中，每個region只能在一個RegionServer中上線，如果這個region server宕機，region需要經歷Re-assgin，WAL按region切分，WAL數據回放等步驟后，才能恢復讀寫。這個恢復時間可能需要數分鐘，對于某些高要求的業務來說，這是一個無法解決的痛點。另外，雖然HBase中有主備同步，但故障下只能集群粒度的手動切換，并且主和備的數據只能做到最終一致性，而有一些業務只能接受強一致，HBase在這點上望塵莫及。

Lindorm內部實現了一種基于Shared Log的一致性協議，通過分區多副本機制達到故障下的服務自動快速恢復的能力，完美適配了存儲分離的架構, 利用同一套體系即可支持強一致語義，又可以選擇在犧牲一致性的前提換取更佳的性能和可用性，實現多活，高可用等多種能力。

在這套架構下，Lindorm擁有了以下幾個一致性級別，用戶可以根據自己的業務自由選擇一致性級別：

注：該功能暫時未在阿里云HBase增強版上對外開放

客戶端高可用切換

雖然說目前HBase可以組成主備，但是目前市面上沒有一個高效地客戶端切換訪問方案。HBase的客戶端只能訪問固定地址的HBase集群。如果主集群發生故障，用戶需要停止HBase客戶端，修改HBase的配置后重啟，才能連接備集群訪問?；蛘哂脩粼跇I務側必須設計一套復雜地訪問邏輯來實現主備集群的訪問。阿里HBase改造了HBase客戶端，流量的切換發生在客戶端內部，通過高可用的通道將切換命令發送給客戶端，客戶端會關閉舊的鏈接，打開與備集群的鏈接，然后重試請求。

?

云原生，更低使用成本

Lindorm從立項之初就考慮到上云，各種設計也能盡量復用云上基礎設施，為云的環境專門優化。比如在云上，我們除了支持云盤之外，我們還支持將數據存儲在OSS這種低成本的對象存儲中減少成本。我們還針對ECS部署做了不少優化，適配小內存規格機型，加強部署彈性，一切為了云原生，為了節省客戶成本。

ECS+云盤的極致彈性

目前Lindorm在云上的版本HBase增強版均采用ECS+云盤部署（部分大客戶可能采用本地盤），ECS+云盤部署的形態給Lindorm帶來了極致的彈性。

最開始的時候，HBase在集團的部署均采用物理機的形式。每個業務上線前，都必須先規劃好機器數量和磁盤大小。在物理機部署下，往往會遇到幾個難以解決的問題：

• 業務彈性難以滿足：當遇到業務突發流量高峰或者異常請求時，很難在短時間內找到新的物理機擴容。
• 存儲和計算綁定，靈活性差：物理機上CPU和磁盤的比例都是一定的，但是每個業務的特點都不一樣，采用一樣的物理機，有一些業務計算資源不夠，但存儲過剩，而有些業務計算資源過剩，而存儲瓶頸。特別是在HBase引入混合存儲后，HDD和SSD的比例非常難確定，有些高要求的業務常常會把SSD用滿而HDD有剩余，而一些海量的離線型業務SSD盤又無法利用上。
• 運維壓力大：使用物理機時，運維需要時刻注意物理機是否過保，是否有磁盤壞，網卡壞等硬件故障需要處理，物理機的報修是一個漫長的過程，同時需要停機，運維壓力巨大。對于HBase這種海量存儲業務來說，每天壞幾塊磁盤是非常正常的事情。而當Lindorm采用了ECS+云盤部署后，這些問題都迎刃而解。

ECS提供了一個近似無限的資源池。當面對業務的緊急擴容時，我們只需在資源池中申請新的ECS拉起后，即可加入集群，時間在分鐘級別之內，無懼業務流量高峰。配合云盤這樣的存儲計算分離架構。我們可以靈活地為各種業務分配不同的磁盤空間。當空間不夠時，可以直接在線擴縮容磁盤。同時，運維再也不用考慮硬件故障，當ECS有故障時，ECS可以在另外一臺宿主機上拉起，而云盤完全對上層屏蔽了壞盤的處理。極致的彈性同樣帶來了成本的優化。我們不需要為業務預留太多的資源，同時當業務的大促結束后，能夠快速地縮容降低成本。

一體化冷熱分離

在海量大數據場景下，一張表中的部分業務數據隨著時間的推移僅作為歸檔數據或者訪問頻率很低，同時這部分歷史數據體量非常大，比如訂單數據或者監控數據，降低這部分數據的存儲成本將會極大的節省企業的成本。如何以極簡的運維配置成本就能為企業極大降低存儲成本，Lindorm冷熱分離功能應運而生。Lindorm為冷數據提供新的存儲介質，新的存儲介質存儲成本僅為高效云盤的1/3。

Lindorm在同一張表里實現了數據的冷熱分離，系統會自動根據用戶設置的冷熱分界線自動將表中的冷數據歸檔到冷存儲中。在用戶的訪問方式上和普通表幾乎沒有任何差異，在查詢的過程中，用戶只需配置查詢Hint或者TimeRange，系統根據條件自動地判斷查詢應該落在熱數據區還是冷數據區。對用戶而言始終是一張表，對用戶幾乎做到完全的透明。

ZSTD-V2，壓縮比再提升100%

早在兩年前，我們就把集團內的存儲壓縮算法替換成了ZSTD，相比原來的SNAPPY算法，獲得了額外25%的壓縮收益。今年我們對此進一步優化，開發實現了新的ZSTD-v2算法，其對于小塊數據的壓縮，提出了使用預先采樣數據進行訓練字典，然后用字典進行加速的方法。我們利用了這一新的功能，在Lindorm構建LDFile的時候，先對數據進行采樣訓練，構建字典，然后在進行壓縮。在不同業務的數據測試中，我們最高獲得了超過原生ZSTD算法100%的壓縮比，這意味著我們可以為客戶再節省50%的存儲費用。

HBase Serverless版，入門首選

阿里云HBase Serverless 版是基于Lindorm內核，使用Serverless架構構建的一套新型的HBase 服務。阿里云HBase Serverless版真正把HBase變成了一個服務，用戶無需提前規劃資源，選擇CPU，內存資源數量，購買集群。在應對業務高峰，業務空間增長時，也無需進行擴容等復雜運維操作，在業務低谷時，也無需浪費閑置資源。

在使用過程中，用戶可以完全根據當前業務量，按需購買請求量和空間資源即可。使用阿里云HBase Serverless版本，用戶就好像在使用一個無限資源的HBase集群，隨時滿足業務流量突然的變化，而同時只需要支付自己真正使用的那一部分資源的錢。

面向大客戶的安全和多租戶能力

Lindorm引擎內置了完整的用戶名密碼體系，提供多種級別的權限控制，并對每一次請求鑒權，防止未授權的數據訪問，確保用戶數據的訪問安全。同時，針對企業級大客戶的訴求，Lindorm內置了Group，Quota限制等多租戶隔離功能，保證企業中各個業務在使用同一個HBase集群時不會被相互影響，安全高效地共享同一個大數據平臺。

用戶和ACL體系

Lindorm內核提供一套簡單易用的用戶認證和ACL體系。用戶的認證只需要在配置中簡單的填寫用戶名密碼即可。用戶的密碼在服務器端非明文存儲，并且在認證過程中不會明文傳輸密碼，即使驗證過程的密文被攔截，用以認證的通信內容不可重復使用，無法被偽造。

Lindorm中有三個權限層級。Global，Namespace和Table。這三者是相互覆蓋的關系。比如給user1賦予了Global的讀寫權限，則他就擁有了所有namespace下所有Table的讀寫權限。如果給user2賦予了Namespace1的讀寫權限，那么他會自動擁有Namespace1中所有表的讀寫權限。

Group隔離

當多個用戶或者業務在使用同一個HBase集群時，往往會存在資源爭搶的問題。一些重要的在線業務的讀寫，可能會被離線業務批量讀寫所影響。而Group功能，則是HBase增強版（Lindorm）提供的用來解決多租戶隔離問題的功能。 通過把RegionServer劃分到不同的Group分組，每個分組上host不同的表，從而達到資源隔離的目的。

例如，在上圖中，我們創建了一個Group1，把RegionServer1和RegionServer2劃分到Group1中，創建了一個Group2，把RegionServer3和RegionServer4劃分到Group2。同時，我們把Table1和Table2也移動到Group1分組。這樣的話，Table1和Table2的所有region，都只會分配到Group1中的RegionServer1和RegionServer2這兩臺機器上。

同樣，屬于Group2的Table3和Table4的Region在分配和balance過程中，也只會落在RegionServer3和RegionServer4上。因此，用戶在請求這些表時，發往Table1、Table2的請求，只會由RegionServer1和RegionServer2服務，而發往Table3和Table4的請求，只會由RegionServer3和RegionServer4服務，從而達到資源隔離的目的。

Quota限流

Lindorm內核中內置了一套完整的Quota體系，來對各個用戶的資源使用做限制。對于每一個請求，Lindorm內核都有精確的計算所消耗的CU（Capacity Unit），CU會以實際消耗的資源來計算。比如用戶一個Scan請求，由于filter的存在，雖然返回的數據很少，但可能已經在RegionServer已經消耗大量的CPU和IO資源來過濾數據，這些真實資源的消耗，都會計算在CU里。在把Lindorm當做一個大數據平臺使用時，企業管理員可以先給不同業務分配不同的用戶，然后通過Quota系統限制某個用戶每秒的讀CU不能超過多少，或者總的CU不能超過多少，從而限制用戶占用過多的資源，影響其他用戶。同時，Quota限流也支持Namesapce級別和表級別限制。

最后

全新一代NoSQL數據庫Lindorm是阿里巴巴HBase&Lindorm團隊9年以來技術積累的結晶，Lindorm在面向海量數據場景提供世界領先的高性能、可跨域、多一致、多模型的混合存儲處理能力。對焦于同時解決大數據(無限擴展、高吞吐)、在線服務(低延時、高可用)、多功能查詢的訴求，為用戶提供無縫擴展、高吞吐、持續可用、毫秒級穩定響應、強弱一致可調、低存儲成本、豐富索引的數據實時混合存取能力。Lindorm已經成為了阿里巴巴大數據體系中的核心產品之一，成功支持了集團各個BU上千個業務，也多次在天貓雙十一“技術大團建”中經受住了考驗。阿里CTO行癲說過，阿里的技術都應該通過阿里云輸出，去普惠各行各業數百萬客戶。

雙12來襲！500元淘寶紅包、iPhone11等你拿。
https://www.aliyun.com/1212/2019/home?utm_content=g_1000092611

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

?

?

總結

以上是生活随笔為你收集整理的每秒7亿次请求，阿里新一代数据库如何支撑？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。