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

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

NoSQL的由來

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

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

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

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

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

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

個推Redis系統(tǒng)規(guī)模如下圖。下面介紹一下運維過程遇到的幾個問題。

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

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

個推Codis+的優(yōu)勢

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

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

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

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

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

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

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

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

一、Aerospike數(shù)據(jù)可以放內(nèi)存，也可以放SSD，并對SSD做了優(yōu)化。

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

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

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

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

標準化安裝

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

擴容和縮容

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

做好監(jiān)控，降低運維成本

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

個推Redis監(jiān)控復雜性

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

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

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

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

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

下圖是個推運維平臺。

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

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

grafana監(jiān)控系統(tǒng)聚合了多個IDC數(shù)據(jù)，我們運維每天只需看一下大屏就夠了。

Slatstack，用于實現(xiàn)自動化發(fā)布，實現(xiàn)標準化并提高工作效率。

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

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

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

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

主從重置有很多原因。

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

我們現(xiàn)在主要使用的是2.8.20,屬于比較容易能產(chǎn)生主從重置。

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

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

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

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

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

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

第二個案例是codis最近遇到的一個問題。這是一個典型的故障場景。一臺主機掛掉后，codis開啟了主從切換，主從切換后業(yè)務沒有受影響，但是我們?nèi)ブ匦陆又鲝臅r發(fā)現(xiàn)接不上，接不上就報了錯。這個錯也不難查，其實就是參數(shù)設置過小，也是由于默認值導致。Slave從主節(jié)點拉數(shù)據(jù)的過程中，新增數(shù)據(jù)留在Master緩沖區(qū)，如果Slave還沒拉完，Master緩沖區(qū)就超過上限，就會導致主從重置，進入一個死循環(huán)。

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

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

二、節(jié)點大小控制在10G。

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

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

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

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

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

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

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

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

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

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

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