應用實戰：從Redis到Aerospike，咱們踩了這些坑

       個推專一爲開發者們提供消息推送服務多年。經過個推SDK，手機終端與服務器創建長鏈接，維持在線狀態。然而在網絡異常等狀況下，消息沒法實時送達到終端用戶，於是推送服務器創建了一份離線消息列表，以待用戶從新登陸時，進行消息的下發。這部分數據存儲在個推Redis集羣，整個集羣包括主從共百餘個實例，key的數量在10億級別，存儲空間在T級別，帶來了必定的維護成本和運維挑戰。做爲個推的後端開發工程師，咱們也一直在尋找高性價比的方案。

       個推整個集羣的QPS在百萬級別，若選擇使用Aerospike，對比實測下來，咱們發現單臺搭載單塊Inter SSD 4600的物理機，能夠達到接近10w的QPS，即幾十臺機器就能夠知足現有的需求，並可以支撐將來較長一段時間的業務需求。

Aerospike的優點

       Aerospike是一個高性能、可擴展、可靠性強的NoSQL解決方案，支持RAM和SSD做爲存儲介質，並專門針對SSD特殊優化，普遍應用於實時競價等實時計算領域。官方保證99%的操做在1ms內完成，並提供集羣數據自動Rebalance、集羣感知客戶端等功能，且支持超大規模數據集(100T級別)的存儲。

       做爲KV存儲，Aerospike提供多種數據類型，其操做方式和Redis比較相似。除基礎功能以外，Aerospike還支持AMC控制檯、API等多種監控方式，有集羣QPS、健康度、負載等多項監控指標，對運維比較友好。支持集羣內數據的自動Rebalance，和Redis集羣方案相比，維護成本降低很多。

 

       本文主要作一些Aerospike灰度部署、使用方面的經驗分享，但願對正在調研或者已經準備使用Aerospike的讀者提供一些參考。此外，灰度的理念並不限於Aerospike自己，對其餘基礎組件的遷移和規劃，也可以帶來必定的借鑑意義。

數據模型說明

Aerospike	RDBMS
namespace	相似於數據庫，最多可設置32個。一個namespace可關聯多塊SSD，一塊SSD只關聯一個namespace，每一個namespace下包含4096個分片
set	相似於數據庫表，一個namespace最多1023個set
bin	相似於數據庫字段，支持Java基本數據類型：List、Map、Blob, 一個namespace下最多32767個bin
record	相似數據庫中的一條記錄， 採用Schema-Less的方式

 

pika等支持Redis協議的磁盤存儲，總體計算下來，Aerospike的性價比最高。

 

前期咱們結合線上場景模擬實際讀寫比例(分析線上業務，咱們發現寫Aerospike採用無模式存儲，數據模型相似RDBMS，於是在理解與使用上相對親切:

每一個namespace包含多個set，每一個set包含多條record，每一個record包含多個bin(數據庫列)，可經過索引key來查詢record。不一樣的業務可使用同一個集羣的不一樣namespace來做作資源隔離，從而實現資源池化、最大化利用資源的目的。

灰度上線流程

和讀大體比例在1:1 ~ 1:2之間)進行壓測，對可行性進行評估和驗證，而後進行投產規劃。

線上業務比較龐雜，直接全量切到Aerospike不太現實，風險也比較大。測試網模擬驗證難以暴露出生產環境下可能出現的問題，所以咱們將整個上線流程劃分爲觀察階段和灰度階段。觀察階段顧名思義，原Redis集羣仍然承擔線上讀寫業務，只是將一樣的流量複製一份導入Aerospike，來進行真實壓力驗證; 灰度階段將線上業務逐步切到Aerospike集羣，擴大灰度保證集羣穩定運行至業務徹底切到Aerospike。兩個階段具體操做以下:

觀察階段: Redis操做成功後，對Redis的讀寫操做以異步方式同步到Aerospike，Aerospike不承擔具體業務。下一步是數據雙寫Redis和Aerospike。該階段主要觀察兩邊數據是否一致，Aerospike壓力等。同時觀察階段能夠進行節點重啓、集羣擴容等運維操做，評估運維成本，優化配置等。這裏可以使用AMC頁面控制檯、監控API來監控集羣狀態，客戶端調用部分記錄必要日誌和監控信息。

灰度階段: Aerospike開始承擔部分應用和任務的離線消息列表存儲。灰度階段Redis和Aerospike數據雙寫雙清，保持熱備狀態，直至Redis數據徹底切換到Aerospike並穩定運行一段時間。

觀察階段很是重要，基本上是對整個方案可行性進行線上評估。這個階段觀察點分爲客戶端(AS-Client)和服務端(AS-Server)兩部分。客戶端主要觀察:

1.使用metrics監控客戶端請求響應耗時，利用一段時間內的請求耗時百分比分佈(50%, 90%, 99%, 99.9%)，評估系統SLA。

2.監控讀寫成功、失敗等狀況的計數。

3.將慢日誌閾值設定爲50ms，統計高峯期和日常時段的慢日誌狀況。

4.異步寫Aerospike隊列監控，合理調整隊列大小。

服務端主要觀察:

1.集羣的健康度。

2.磁盤和內存佔用狀況，內存空間/磁盤空間比例。

3.機器IO負載、CPU負載、磁盤碎片化程度等信息。

4.集羣吞吐量，讀寫TPS是否能與線上Redis集羣至關。

5.數據一致性檢查。如何檢查觀察階段和灰度階段兩份數據的一致狀況？逐key比對差別在性能上難以知足要求。考慮數據徹底一致狀況下Redis查出的數據應該和Aerospike查出來的數據徹底相同，因此抽樣記錄Redis和Aerospike的數據查詢結果記錄到日誌，對比分析1分鐘、5分鐘、30分鐘、1小時內不一致數據佔比。若是線上Key的數量在10億級別，即使只檢查出萬分之一的差別，那麼不一致的狀況也很顯著了。這種狀況下，就須要排查引起不一致狀況的緣由並解決。

維護性方面主要考慮到集羣數據自動Rebalance會帶來必定的性能降低，可能對用戶體驗有較大影響，結合咱們的經驗，模擬了一些典型的運維場景:

1.模擬單節點故障致使的集羣Rebalance對系統性能的影響。

2.模擬集羣擴容致使的集羣Rebalance對系統性能的影響。

3.根據對線上業務的影響，計算白天和晚上集羣的Rebalance速度，同時支持cron job更新。

4.節點重啓。

5.增長SSD掛載。

6.相關配置的優化等。

 

總結一下，完整的上線流程分爲如下幾步:

0.模擬線上環境壓測，進行可行性驗證。

1.將Aerospike客戶端封裝成類Redis的接口，添加必要日誌、監控項，對Bin的有效性檢查等。

2.消息服務集成Aerospike客戶端，須要的功能包括: Aerospike異步讀寫，業務數據源切換，流量過濾等。

3.QA功能驗證。

4.申請資源，線上部署Aerospike集羣。

5.集成Aerospike功能的消息服務上線。

6.觀察階段驗證經過後，進入灰度階段，直至最終上線或中途撤回。

經驗總結

在Aerospike使用過程當中，咱們遇到了一些問題和挑戰，總結爲下面幾點:

1. Aerospike開啓single-bin的模式會節省佔用空間。
2. Aerospike不會存儲原始key，實際索引的是原始key的一個20字節hash值，若是業務須要使用原始key則必須另外設置bin存儲。即使key和value值的字節數較少，但key自己佔據20個字節，於是實際佔用的空間會比較大。
3. Aerospike在節點宕機或是增減節點時會Rebalance數據，這個過程會影響對外服務質量。但Rebalance速度能夠控制，於是須要在保證服務質量和集羣快速恢復兩者間作權衡。
4. 社區版本集羣每次重啓都要重建索引，而後加載到內存，這會致使速度比較慢。namespace須要在配置文件中指定，於是最好能按業務劃分，預先分配好未來可能用到的namespace，減小沒必要要的重啓。
5. 由於SSD自己存在碎片和寫入放大的問題，實際使用中，咱們發現若磁盤空間使用量在50%左右，性能降低會比較嚴重。故能夠結合實際業務優化碎片整理相關參數。
6. Aerospike對HotKey有限制，於是頻繁對一個key讀寫時，會返回HotKey錯誤(errorcode 14) 。服務端能夠經過增大 transaction-pending-limit配置來提升對同一個key操做的併發量，它的默認爲20，值爲0時表示不限。增大該配置可能會下降必定性能。客戶端可能須要對該異常增長重試處理，但重試可能會進一步增大HotKey的風險。
7. 這種基礎組件的更迭必定要儘量使用線上流量作壓力檢驗，從而儘早暴露潛在問題。
8. 觀察階段也要評估運維成本，避免從一個坑跳進另外一個坑。
9. 使用過程當中還須要注意Aerospike的一些固有限制，如一個namespace最多有1023個set 、bin名字長度最多14個單字節字符 、一個namespace最多支持64塊SSD 等等，具體可參考:aerospike_known_limitations。

結語

Aerospike做爲一個大容量的NoSql解決方案，並未在國內廠中普遍商使用。它適合對容量要求比較大，QPS相對低一些的場景，必定程度上能夠節省TCO。支持命令上，Aerospike和Redis比較相像，業務遷移過來也比較容易。它自然地支持集羣部署，對監控和運維支持比較友好。儘管擁有這麼多優良特性，但技術選型時仍是要持審慎態度，預先評估是否符合本身的業務場景，性能和成本是否可以知足要求等。在官方的某些測試場景下，它的性能比Redis還要高，實際上由於SSD自己的限制，大部分狀況下，它在QPS方面與Redis差距較大。最後，上線前務必通過線上流量驗證，用灰度方式處理實際線上業務，最小化影響用戶體驗。