大數據時代，企業對于DBA也提出更高的需求。同時，NoSQL作為近幾年新崛起的一門技術，也受到越來越多的關注。本文將基于個推SRA孟顯耀先生所負責的DBA工作，和大數據運維相關經驗，分享兩大方向內容：一、公司在KV存儲上的架構演進以及運維需要解決的問題；二、對NoSQL如何選型以及未來發展的一些思考。

據官方統計，截止目前（2018年4月20日）NoSQL有225個解決方案，具體到每個公司，使用的都是其中很小的一個子集，下圖中藍色標注的產品是當前個推正在使用的。

NoSQL的由來

1946年，第一臺通用計算機誕生。但一直到1970年RDMBS的出現，大家才找到通用的數據存儲方案。到21世紀，DT時代讓數據容量成為最棘手的問題，對此谷歌和亞馬遜分別提出了自己的NoSQL解決方案，比如谷歌于2006年提出了Bigtable。2009年的一次技術大會上，NoSQL一詞被正式提出，到現在共有225種解決方案。

NoSQL與RDMBS的區別主要在兩點：第一，它提供了無模式的靈活性，支持很靈活的模式變更；第二，可伸縮性，原生的RDBMS只適用于單機和小集群。而NoSQL一開始就是分布式的，解決了讀寫和容量擴展性問題。以上兩點，也是NoSQL產生的根本原因。

實現分布式主要有兩種手段：副本（Replication）和分片（Sharding）。Replication能解決讀的擴展性問題和HA（高可用），但是無法解決讀和容量的擴展性。而Sharding可以解決讀寫和容量的擴展性。一般NoSQL解決方案都是將二者組合起來。

Sharding主要解決數據的劃分問題，主要有基于區間劃分（如Hbase的Rowkey劃分）和基于哈希的劃分。為了解決哈希分布式的單調性和平衡性問題，目前業內主要使用虛擬節點。后文所述的Codis也是用虛擬節點。虛擬節點相當于在數據分片和托管服務器之間建立了一層虛擬映射的關系。

目前，大家主要根據數據模型和訪問方式進行NoSQL分類。

個推常用的幾種NoSQL解決方案

個推Redis系統規模如下圖。下面介紹一下運維過程遇到的幾個問題。

首先是技術架構演進過程。個推以面向APP開發者提供消息推送服務起家，在2012年之前，個推的業務量相對較小，當時我們用Redis做緩存，用MySQL做持久化。在2012-2016年，隨著個推業務的高速發展，單節點已經無法解決問題。在MySQL無法解決高QPS、TPS的情況下，我們自研了Redis分片方案。此外，我們還自研了Redis客戶端，用它來實現基本的集群功能，支持自定義讀寫比例，同時對故障節點的監測和隔離、慢監控以及每個節點健康性進行檢查。但這種架構沒有過多考慮運維效率的問題，缺少運維工具。

當我們計劃完善運維工具的時候，發現豌豆莢團隊將Codis開源，給我們提供了一個不錯的選項。

個推Codis+的優勢

Codis是proxy-based架構，支持原生客戶端，支持基于web的集群操作和監控，并且也集成了Redis Sentinel。可以提高我們運維的工作效率，且HA也更容易落地。

但是在使用過程中，我們也發現一些局限。因此我們提出了Codis+，即對Codis做一些功能增強。

第一、 采用2N+1副本方案，解決故障期間Master單點的問題。

第二、Redis準半同步。設置一個閾值，比如slave僅在5秒鐘之內可讀。

第三、資源池化。能通過類似HBase增加RegionServer的方式去進行資源擴容。

此外，還有機架感知功能和跨IDC的功能。Redis本身是為了單機房而設置的，沒有考慮到這些問題。

那么，為什么我們不用原生的rRedis cluster？這里有三個原因：一、原生的集群，它把路由轉發的功能和實際上的數據管理功能耦合在一個功能里，如果一個功能出問題就會導致數據有問題；二、在大集群時，P2P的架構達到一致性狀態的過程比較耗時，codis是樹型架構，不存在這個問題。三、集群沒有經過大平臺的背書。

此外，關于Redis，我們最近還在看一個新的NoSQL方案Aerospike，我們對它的定位是替換部分集群Redis。Redis的問題在于數據常駐內存，成本很高。我們期望利用Aerospike減少TCO成本。Aerospike有如下特性：

一、Aerospike數據可以放內存，也可以放SSD，并對SSD做了優化。

二、資源池化，運維成本繼續降低。

三、支持機架感知和跨IDC的同步，但這屬于企業級版本功能。

目前我們內部現在有兩個業務在使用Aerospike，實測下來，發現單臺物理機搭載單塊Inter SSD 4600，可以達到接近10w的QPS。對于容量較大，但QPS要求不高的業務，可以選擇Aerospike方案節省TCO。

在NoSQL演進的過程中，我們也遇到一些運維方面的問題。

標準化安裝

我們共分了三個部分：OS標準化、Redis文件和目錄標準、Redis參數標準化，全部用saltstack + cmdb實現；

擴容和縮容

在技術架構不斷演進過程中，擴容和縮容的難度也在變低，原因之一在于codis緩解了一部分問題。當然，如果選擇Aerospike，相關操作就會非常輕松。

做好監控，降低運維成本

大部分的運維同學都應該認真閱讀《SRE：Google運維揭秘》，它在理論層面和實踐層面提出了很多非常有價值的方法論，強烈推薦。

個推Redis監控復雜性

三種集群架構：自研、codis2和codis3，這三種架構采集數據的方式并不相同。

三類監控對象：集群、實例、主機，需要有元數據維護邏輯關系，并在全局做聚合。

三種個性化配置：個推的Redis集群，有的集群需要有多副本，有的不需要。有的節點允許滿做緩存，有的節點不允許滿。還有持久化策略，有的不做持久化，有的做持久化，有的做持久化+異地備份，這些業務特點對我們監控靈活性提出很高的要求。

Zabbix是一個非常完備的監控系統，約三年多的時間里，我都把它作為主要的監控系統平臺。但是它有兩個缺陷：一是它使用MySQL作為后端存儲，TPS有上限；二是不夠靈活。比如：一個集群放在一百臺機器上，要做聚合指標，就很困難。

小米的open-falcon解決了這個問題，但是也會產生一些新問題。比如告警函數很少，不支持字符串，有時候會增加手工的操作等等。后來我們對它進行功能性補充，便沒有遇到大的問題。

下圖是個推運維平臺。

第一個是IT硬件資源平臺，主要維護主機維度的物理信息。比如說主機在哪個機架上接的哪個交換機，在哪個機房的哪一個樓層等等，這是做機架感知和跨IDC等等的基礎。

第二個是CMDB，這個是維護主機上的軟件信息，主機上裝了哪些實例，實例屬于哪些集群，我們用了哪些端口，這些集群有什么個性化的參數配置，包括告警機制不一樣，全是通過CMDB實現。CMDB的數據消費方包含grafana監控系統和監控采集程序，采集程序由我們自己開發。這樣CMDB數據會活起來。如果只是一個靜態數據沒有消費方，數據就會不一致。

grafana監控系統聚合了多個IDC數據，我們運維每天只需看一下大屏就夠了。

Slatstack，用于實現自動化發布，實現標準化并提高工作效率。

采集程序是我們自行研發的，針對公司的業務特點定制化程度很高。還有ELK（不用logstach，用filebeat）做日志中心。

通過以上這些，我們搭建出個推整個監控體系。

下面講一下搭建過程中遇到的幾個坑。

一、主從重置，會導致主機節點壓力爆增，主節點無法提供服務。

主從重置有很多原因。

Redis版本低，主從重置的概率很高。Redis3主從重置的概率比Redis2大大減少，Redis4支持節點重啟以后也能增量同步，這是Redis本身進行了很多改進。

我們現在主要使用的是2.8.20,屬于比較容易能產生主從重置。

Redis的主從重置一般是觸發了如下條件中的一個。

1、repl-backlog-size太小，默認是1M，如果你有大量的寫入，很容易擊穿這個緩沖區；2、repl-timeout，Redis主從默認每十秒鐘ping一次，60秒鐘ping不推就會主從重置，原因可能是網絡抖動、總節點壓力過大，無法響應這個包等；3、tcp-baklog，默認是511。操作系統的默認是限制到128，這個可以適度提高，我們提高到2048，這個能對網絡丟包現象進行一定容錯。

以上都是導致主從重置的原因，主從重置的后果很嚴重。Master壓力爆增無法提供服務，業務就把這個節點定為不可用。響應時間變長 Master所在所有主機的節點都會受到影響。

二、節點過大，部分是人為原因造成的。第一是拆分節點的效率較低，遠遠慢于公司業務量的增長。此外，分片太少。我們的分片是500個，codis是1024，codis原生是16384個，分片太少也是個問題。如果做自研的分布式方案，大家一定要把分片數量，稍微設大一點，避免業務發展超過你預期的情況。節點過大之后，會導致持久化的時間增長。我們30G的節點要持久化，主機剩余內存要大于30G，如果沒有，你用Swap導致主機持久化時間大幅增長。一個30G的節點持久化可能要4個小時。負載過高也會導致主從重置，引起連鎖反應。

關于我們遇到的坑，接下來分享幾個實際的案例。

第一個案例是一次主從重置。這個情況是在春節前兩天出現的，春節前屬于消息推送業務高峰期。我們簡單還原一下故障場景。首先是大規模的消息下發導致負載增加；然后，Redis Master壓力增大，TCP包積壓，OS產生丟包現象，丟包把Redis主從ping的包給丟了，觸發了repl-timeout 60秒的閾值，主從就重置了。同時由于節點過大，導致Swap和IO飽和度接近100%。解決的方法很簡單，我們先把主從斷開。故障原因首先是參數不合理，大都是默認值，其次是節點過大讓故障效果進行放大。

第二個案例是codis最近遇到的一個問題。這是一個典型的故障場景。一臺主機掛掉后，codis開啟了主從切換，主從切換后業務沒有受影響，但是我們去重新接主從時發現接不上，接不上就報了錯。這個錯也不難查，其實就是參數設置過小，也是由于默認值導致。Slave從主節點拉數據的過程中，新增數據留在Master緩沖區，如果Slave還沒拉完，Master緩沖區就超過上限，就會導致主從重置，進入一個死循環。

基于這些案例，我們整理了一份最佳實踐。

一、配置CPU親和。Redis是單機點的結構，不親和會影響CPU的效率。

二、節點大小控制在10G。

三、主機剩余內存最好大于最大節點大小+10G。主從重置需要有同等大小的內存，這個一定要留夠，如果不留夠，用了Swap，就很難重置成功。

四、盡量不要用Swap。500毫秒響應一個請求還不如掛掉。

五、tcp-backlog、repl-backlog-size、repl-timeout適度增大。

六、Master不做持久化，Slave做AOF+定時重置。

最后是個人的一些思考和建議。選擇適合自己的NoSQL，選擇原則有五點：

1、業務邏輯。首先要了解自身業務特點，比如是KV型就在KV里面找；如果是圖型就在圖型里找，這樣范圍一下會減少70%-80%。

2、負載特點，QPS、TPS和響應時間。在選擇NoSQL方案時，可以從這些指標去衡量，單機在一定配置下的性能指標能達到多少？Redis在主機足夠剩余情況下，單臺的QPS40-50萬是完全OK的。

3、數據規模。數據規模越大，需要考慮的問題就越多，選擇性就越小。到了幾百個TB或者PB級別，幾乎沒太多選擇，就是Hadoop體系。

4、運維成本和可不可監控，能否方便地進行擴容、縮容。

5、其它。比如有沒有成功案例，有沒有完善的文檔和社區，有沒有官方或者企業支持。可以讓別人把坑踩過之后我們平滑過去，畢竟自己踩坑的成本還是蠻高的。

結語：關于NoSQL的釋義，網絡上曾有一個段子：從1980年的know SQL，到2005年的Not only SQL，再到今日的No SQL！互聯網的發展伴隨著技術概念的更新與相關功能的完善。而技術進步的背后，則是每一位技術人的持續的學習、周密的思考與不懈的嘗試。