個推專注為開發(fā)者們提供消息推送服務多年。通過個推SDK，手機終端與服務器建立長連接，維持在線狀態(tài)。然而在網(wǎng)絡異常等情況下，消息無法實時送達到終端用戶，因而推送服務器建立了一份離線消息列表，以待用戶重新登錄時，進行消息的下發(fā)。這部分數(shù)據(jù)存儲在個推Redis集群，整個集群包括主從共百余個實例，key的數(shù)量在10億級別，存儲空間在T級別，帶來了一定的維護成本和運維挑戰(zhàn)。作為個推的后端開發(fā)工程師，我們也一直在尋找高性價比的方案。
個推整個集群的QPS在百萬級別，若選擇使用Aerospike，對比實測下來，我們發(fā)現(xiàn)單臺搭載單塊Inter SSD 4600的物理機，可以達到接近10w的QPS，即幾十臺機器就可以滿足現(xiàn)有的需求，并能夠支撐未來較長一段時間的業(yè)務需求。
Aerospike的優(yōu)勢
Aerospike是一個高性能、可擴展、可靠性強的NoSQL解決方案，支持RAM和SSD作為存儲介質(zhì)，并專門針對SSD特殊優(yōu)化，廣泛應用于實時競價等實時計算領(lǐng)域。官方保證99%的操作在1ms內(nèi)完成，并提供集群數(shù)據(jù)自動Rebalance、集群感知客戶端等功能，且支持超大規(guī)模數(shù)據(jù)集(100T級別)的存儲。
作為KV存儲，Aerospike提供多種數(shù)據(jù)類型，其操作方式和Redis比較類似。除基礎功能之外，Aerospike還支持AMC控制臺、API等多種監(jiān)控方式，有集群QPS、健康度、負載等多項監(jiān)控指標，對運維比較友好。支持集群內(nèi)數(shù)據(jù)的自動Rebalance，和Redis集群方案相比，維護成本下降不少。
本文主要做一些Aerospike灰度部署、使用方面的經(jīng)驗分享，希望對正在調(diào)研或者已經(jīng)準備使用Aerospike的讀者提供一些參考。此外，灰度的理念并不限于Aerospike本身，對其他基礎組件的遷移和規(guī)劃，也能夠帶來一定的借鑒意義。
數(shù)據(jù)模型說明
Aerospike采用無模式存儲，數(shù)據(jù)模型類似RDBMS，因而在理解與使用上相對親切:
每個namespace包含多個set，每個set包含多條record，每個record包含多個bin(數(shù)據(jù)庫列)，可通過索引key來查詢record。不同的業(yè)務可以使用同一個集群的不同namespace來作做資源隔離，從而實現(xiàn)資源池化、最大化利用資源的目的。
灰度上線流程
個推在離線消息列表存儲這項業(yè)務中使用了較大規(guī)模的Redis集群。我們先后調(diào)研了ssdb、pika等支持Redis協(xié)議的磁盤存儲，整體計算下來，Aerospike的性價比最高。
前期我們結(jié)合線上場景模擬實際讀寫比例(分析線上業(yè)務，我們發(fā)現(xiàn)寫和讀大致比例在1:1 ~ 1:2之間)進行壓測，對可行性進行評估和驗證，然后進行投產(chǎn)規(guī)劃。
線上業(yè)務比較龐雜，直接全量切到Aerospike不太現(xiàn)實，風險也比較大。測試網(wǎng)模擬驗證難以暴露出生產(chǎn)環(huán)境下可能出現(xiàn)的問題，因此我們將整個上線流程劃分為觀察階段和灰度階段。觀察階段顧名思義，原Redis集群仍然承擔線上讀寫業(yè)務，只是將同樣的流量復制一份導入Aerospike，來進行真實壓力驗證; 灰度階段將線上業(yè)務逐步切到Aerospike集群，擴大灰度保證集群穩(wěn)定運行至業(yè)務完全切到Aerospike。兩個階段具體操作如下:
觀察階段: Redis操作成功后，對Redis的讀寫操作以異步方式同步到Aerospike，Aerospike不承擔具體業(yè)務。下一步是數(shù)據(jù)雙寫Redis和Aerospike。該階段主要觀察兩邊數(shù)據(jù)是否一致，Aerospike壓力等。同時觀察階段可以進行節(jié)點重啟、集群擴容等運維操作，評估運維成本，優(yōu)化配置等。這里可使用AMC頁面控制臺、監(jiān)控API來監(jiān)控集群狀態(tài)，客戶端調(diào)用部分記錄必要日志和監(jiān)控信息。
灰度階段: Aerospike開始承擔部分應用和任務的離線消息列表存儲。灰度階段Redis和Aerospike數(shù)據(jù)雙寫雙清，保持熱備狀態(tài)，直至Redis數(shù)據(jù)完全切換到Aerospike并穩(wěn)定運行一段時間。
觀察階段非常重要，基本上是對整個方案可行性進行線上評估。這個階段觀察點分為客戶端(AS-Client)和服務端(AS-Server)兩部分?？蛻舳酥饕^察:
1.使用metrics監(jiān)控客戶端請求響應耗時，利用一段時間內(nèi)的請求耗時百分比分布(50%, 90%, 99%, 99.9%)，評估系統(tǒng)SLA。
2.監(jiān)控讀寫成功、失敗等情況的計數(shù)。
3.將慢日志閾值設定為50ms，統(tǒng)計高峰期和平常時段的慢日志情況。
4.異步寫Aerospike隊列監(jiān)控，合理調(diào)整隊列大小。
服務端主要觀察:
1.集群的健康度。
2.磁盤和內(nèi)存占用情況，內(nèi)存空間/磁盤空間比例。
3.機器IO負載、CPU負載、磁盤碎片化程度等信息。
4.集群吞吐量，讀寫TPS是否能與線上Redis集群相當。
5.數(shù)據(jù)一致性檢查。如何檢查觀察階段和灰度階段兩份數(shù)據(jù)的一致情況？逐key比對差異在性能上難以滿足要求?？紤]數(shù)據(jù)完全一致情況下Redis查出的數(shù)據(jù)應該和Aerospike查出來的數(shù)據(jù)完全相同，所以抽樣記錄Redis和Aerospike的數(shù)據(jù)查詢結(jié)果記錄到日志，對比分析1分鐘、5分鐘、30分鐘、1小時內(nèi)不一致數(shù)據(jù)占比。如果線上Key的數(shù)量在10億級別，即便只檢查出萬分之一的差異，那么不一致的情況也很顯著了。這種情況下，就需要排查引發(fā)不一致情況的原因并解決。
維護性方面主要考慮到集群數(shù)據(jù)自動Rebalance會帶來一定的性能下降，可能對用戶體驗有較大影響，結(jié)合我們的經(jīng)驗，模擬了一些典型的運維場景:
1.模擬單節(jié)點故障導致的集群Rebalance對系統(tǒng)性能的影響。
2.模擬集群擴容導致的集群Rebalance對系統(tǒng)性能的影響。
3.根據(jù)對線上業(yè)務的影響，計算白天和晚上集群的Rebalance速度，同時支持cron job更新。
4.節(jié)點重啟。
5.增加SSD掛載。
6.相關(guān)配置的優(yōu)化等。
總結(jié)一下，完整的上線流程分為以下幾步:
0.模擬線上環(huán)境壓測，進行可行性驗證。
1.將Aerospike客戶端封裝成類Redis的接口，添加必要日志、監(jiān)控項，對Bin的有效性檢查等。
2.消息服務集成Aerospike客戶端，需要的功能包括: Aerospike異步讀寫，業(yè)務數(shù)據(jù)源切換，流量過濾等。
3.QA功能驗證。
4.申請資源，線上部署Aerospike集群。
5.集成Aerospike功能的消息服務上線。
6.觀察階段驗證通過后，進入灰度階段，直至最終上線或中途撤回。
經(jīng)驗總結(jié)
在Aerospike使用過程中，我們遇到了一些問題和挑戰(zhàn)，總結(jié)為下面幾點:
1.Aerospike開啟single-bin的模式會節(jié)省占用空間。
2.Aerospike不會存儲原始key，實際索引的是原始key的一個20字節(jié)hash值，如果業(yè)務需要使用原始key則必須另外設置bin存儲。即便key和value值的字節(jié)數(shù)較少，但key本身占據(jù)20個字節(jié)，因而實際占用的空間會比較大。
3.Aerospike在節(jié)點宕機或是增減節(jié)點時會Rebalance數(shù)據(jù)，這個過程會影響對外服務質(zhì)量。但Rebalance速度可以控制，因而需要在保證服務質(zhì)量和集群快速恢復二者間做權(quán)衡。
4.社區(qū)版本集群每次重啟都要重建索引，然后加載到內(nèi)存，這會導致速度比較慢。namespace需要在配置文件中指定，因而最好能按業(yè)務劃分，預先分配好將來可能用到的namespace，減少不必要的重啟。
5.因為SSD本身存在碎片和寫入放大的問題，實際使用中，我們發(fā)現(xiàn)若磁盤空間使用量在50%左右，性能下降會比較嚴重。故可以結(jié)合實際業(yè)務優(yōu)化碎片整理相關(guān)參數(shù)。
6.Aerospike對HotKey有限制，因而頻繁對一個key讀寫時，會返回HotKey錯誤(errorcode 14) 。服務端可以通過增大 transaction-pending-limit配置來提高對同一個key操作的并發(fā)量，它的默認為20，值為0時表示不限。增大該配置可能會降低一定性能?？蛻舳丝赡苄枰獙υ摦惓Ｔ黾又卦囂幚恚卦嚳赡軙M一步增大HotKey的風險。
7.這種基礎組件的更迭一定要盡可能使用線上流量做壓力檢驗，從而盡早暴露潛在問題。
8.觀察階段也要評估運維成本，避免從一個坑跳進另一個坑。
9.使用過程中還需要注意Aerospike的一些固有限制，如一個namespace最多有1023個set 、bin名字長度最多14個單字節(jié)字符 、一個namespace最多支持64塊SSD 等等，具體可參考:aerospike_known_limitations。
結(jié)語
Aerospike作為一個大容量的NoSql解決方案，并未在國內(nèi)廠中廣泛商使用。它適合對容量要求比較大，QPS相對低一些的場景，一定程度上可以節(jié)省TCO。支持命令上，Aerospike和Redis比較相像，業(yè)務遷移過來也比較容易。它天然地支持集群部署，對監(jiān)控和運維支持比較友好。盡管擁有這么多優(yōu)良特性，但技術(shù)選型時還是要持審慎態(tài)度，預先評估是否符合自己的業(yè)務場景，性能和成本是否能夠滿足要求等。在官方的某些測試場景下，它的性能比Redis還要高，實際上因為SSD本身的限制，大部分情況下，它在QPS方面與Redis差距較大。最后，上線前務必經(jīng)過線上流量驗證，用灰度方式處理實際線上業(yè)務，最小化影響用戶體驗。
