大數(shù)據(jù)時代，企業(yè)對于DBA也提出更高的需求。同時瓜饥，NoSQL作為近幾年新崛起的一門技術(shù)，也受到越來越多的關(guān)注浴骂。本文將基于個推SRA孟顯耀先生所負責(zé)的DBA工作乓土，和大數(shù)據(jù)運維相關(guān)經(jīng)驗，分享兩大方向內(nèi)容：一、公司在KV存儲上的架構(gòu)演進以及運維需要解決的問題趣苏；二狡相、對NoSQL如何選型以及未來發(fā)展的一些思考。
據(jù)官方統(tǒng)計食磕，截止目前（2018年4月20日）NoSQL有225個解決方案尽棕，具體到每個公司，使用的都是其中很小的一個子集彬伦，下圖中藍色標(biāo)注的產(chǎn)品是當(dāng)前個推正在使用的滔悉。
NoSQL的由來
1946年，第一臺通用計算機誕生单绑。但一直到1970年RDMBS的出現(xiàn)回官，大家才找到通用的數(shù)據(jù)存儲方案。到21世紀(jì)搂橙，DT時代讓數(shù)據(jù)容量成為最棘手的問題歉提，對此谷歌和亞馬遜分別提出了自己的NoSQL解決方案，比如谷歌于2006年提出了Bigtable区转。2009年的一次技術(shù)大會上苔巨，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é)點相當(dāng)于在數(shù)據(jù)分片和托管服務(wù)器之間建立了一層虛擬映射的關(guān)系旦事。
目前魁巩，大家主要根據(jù)數(shù)據(jù)模型和訪問方式進行NoSQL分類。
個推常用的幾種NoSQL解決方案
個推Redis系統(tǒng)規(guī)模如下圖姐浮。下面介紹一下運維過程遇到的幾個問題谷遂。
首先是技術(shù)架構(gòu)演進過程。個推以面向APP開發(fā)者提供消息推送服務(wù)起家卖鲤，在2012年之前肾扰，個推的業(yè)務(wù)量相對較小，當(dāng)時我們用Redis做緩存蛋逾，用MySQL做持久化集晚。在2012-2016年，隨著個推業(yè)務(wù)的高速發(fā)展换怖，單節(jié)點已經(jīng)無法解決問題甩恼。在MySQL無法解決高QPS、TPS的情況下沉颂，我們自研了Redis分片方案条摸。此外，我們還自研了Redis客戶端铸屉，用它來實現(xiàn)基本的集群功能钉蒲，支持自定義讀寫比例，同時對故障節(jié)點的監(jiān)測和隔離彻坛、慢監(jiān)控以及每個節(jié)點健康性進行檢查顷啼。但這種架構(gòu)沒有過多考慮運維效率的問題，缺少運維工具昌屉。
當(dāng)我們計劃完善運維工具的時候钙蒙，發(fā)現(xiàn)豌豆莢團隊將Codis開源，給我們提供了一個不錯的選項间驮。
個推Codis+的優(yōu)勢
Codis是proxy-based架構(gòu)躬厌，支持原生客戶端，支持基于web的集群操作和監(jiān)控竞帽，并且也集成了Redis Sentinel扛施。可以提高我們運維的工作效率屹篓，且HA也更容易落地疙渣。
但是在使用過程中，我們也發(fā)現(xiàn)一些局限堆巧。因此我們提出了Codis+妄荔，即對Codis做一些功能增強泼菌。
第一、 采用2N+1副本方案懦冰，解決故障期間Master單點的問題灶轰。
第二、Redis準(zhǔn)半同步刷钢。設(shè)置一個閾值笋颤，比如slave僅在5秒鐘之內(nèi)可讀。
第三内地、資源池化伴澄。能通過類似HBase增加RegionServer的方式去進行資源擴容。
此外阱缓，還有機架感知功能和跨IDC的功能非凌。Redis本身是為了單機房而設(shè)置的，沒有考慮到這些問題荆针。
那么敞嗡，為什么我們不用原生的rRedis cluster？這里有三個原因：一航背、原生的集群喉悴，它把路由轉(zhuǎn)發(fā)的功能和實際上的數(shù)據(jù)管理功能耦合在一個功能里，如果一個功能出問題就會導(dǎo)致數(shù)據(jù)有問題玖媚；二箕肃、在大集群時，P2P的架構(gòu)達到一致性狀態(tài)的過程比較耗時今魔，codis是樹型架構(gòu)勺像，不存在這個問題。三错森、集群沒有經(jīng)過大平臺的背書吟宦。
此外，關(guān)于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è)務(wù)在使用Aerospike蚕泽，實測下來，發(fā)現(xiàn)單臺物理機搭載單塊Inter SSD 4600桥嗤，可以達到接近10w的QPS须妻。對于容量較大，但QPS要求不高的業(yè)務(wù)泛领，可以選擇Aerospike方案節(jié)省TCO荒吏。
在NoSQL演進的過程中，我們也遇到一些運維方面的問題渊鞋。
標(biāo)準(zhǔn)化安裝
我們共分了三個部分：OS標(biāo)準(zhǔn)化绰更、Redis文件和目錄標(biāo)準(zhǔn)、Redis參數(shù)標(biāo)準(zhǔn)化锡宋，全部用saltstack + cmdb實現(xiàn)儡湾；
擴容和縮容
在技術(shù)架構(gòu)不斷演進過程中，擴容和縮容的難度也在變低员辩，原因之一在于codis緩解了一部分問題盒粮。當(dāng)然，如果選擇Aerospike奠滑，相關(guān)操作就會非常輕松丹皱。
做好監(jiān)控，降低運維成本
大部分的運維同學(xué)都應(yīng)該認真閱讀《SRE：Google運維揭秘》宋税，它在理論層面和實踐層面提出了很多非常有價值的方法論摊崭，強烈推薦。
個推Redis監(jiān)控復(fù)雜性
三種集群架構(gòu)：自研杰赛、codis2和codis3呢簸，這三種架構(gòu)采集數(shù)據(jù)的方式并不相同。
三類監(jiān)控對象：集群乏屯、實例根时、主機，需要有元數(shù)據(jù)維護邏輯關(guān)系辰晕，并在全局做聚合蛤迎。
三種個性化配置：個推的Redis集群，有的集群需要有多副本含友，有的不需要替裆。有的節(jié)點允許滿做緩存校辩，有的節(jié)點不允許滿。還有持久化策略辆童，有的不做持久化宜咒，有的做持久化，有的做持久化+異地備份把鉴，這些業(yè)務(wù)特點對我們監(jiān)控靈活性提出很高的要求故黑。
Zabbix是一個非常完備的監(jiān)控系統(tǒng)，約三年多的時間里纸镊，我都把它作為主要的監(jiān)控系統(tǒng)平臺倍阐。但是它有兩個缺陷：一是它使用MySQL作為后端存儲，TPS有上限逗威；二是不夠靈活峰搪。比如：一個集群放在一百臺機器上，要做聚合指標(biāo)凯旭，就很困難概耻。
小米的open-falcon解決了這個問題，但是也會產(chǎn)生一些新問題罐呼。比如告警函數(shù)很少鞠柄，不支持字符串，有時候會增加手工的操作等等嫉柴。后來我們對它進行功能性補充厌杜，便沒有遇到大的問題。
下圖是個推運維平臺计螺。
第一個是IT硬件資源平臺夯尽，主要維護主機維度的物理信息。比如說主機在哪個機架上接的哪個交換機登馒，在哪個機房的哪一個樓層等等匙握，這是做機架感知和跨IDC等等的基礎(chǔ)。
第二個是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)標(biāo)準(zhǔn)化并提高工作效率。
采集程序是我們自行研發(fā)的谜悟，針對公司的業(yè)務(wù)特點定制化程度很高话肖。還有ELK（不用logstach，用filebeat）做日志中心葡幸。
通過以上這些最筒，我們搭建出個推整個監(jiān)控體系。
下面講一下搭建過程中遇到的幾個坑蔚叨。
一床蜘、主從重置，會導(dǎo)致主機節(jié)點壓力爆增蔑水，主節(jié)點無法提供服務(wù)邢锯。
主從重置有很多原因。
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)絡(luò)抖動么伯、總節(jié)點壓力過大，無法響應(yīng)這個包等卡儒；3田柔、tcp-baklog俐巴，默認是511。操作系統(tǒng)的默認是限制到128硬爆，這個可以適度提高欣舵，我們提高到2048，這個能對網(wǎng)絡(luò)丟包現(xiàn)象進行一定容錯缀磕。
以上都是導(dǎo)致主從重置的原因缘圈，主從重置的后果很嚴重。Master壓力爆增無法提供服務(wù)袜蚕，業(yè)務(wù)就把這個節(jié)點定為不可用糟把。響應(yīng)時間變長 Master所在所有主機的節(jié)點都會受到影響。
二牲剃、節(jié)點過大遣疯，部分是人為原因造成的。第一是拆分節(jié)點的效率較低凿傅，遠遠慢于公司業(yè)務(wù)量的增長另锋。此外，分片太少狭归。我們的分片是500個夭坪，codis是1024，codis原生是16384個过椎，分片太少也是個問題室梅。如果做自研的分布式方案，大家一定要把分片數(shù)量疚宇，稍微設(shè)大一點亡鼠，避免業(yè)務(wù)發(fā)展超過你預(yù)期的情況。節(jié)點過大之后敷待，會導(dǎo)致持久化的時間增長间涵。我們30G的節(jié)點要持久化，主機剩余內(nèi)存要大于30G榜揖，如果沒有勾哩，你用Swap導(dǎo)致主機持久化時間大幅增長。一個30G的節(jié)點持久化可能要4個小時举哟。負載過高也會導(dǎo)致主從重置思劳，引起連鎖反應(yīng)。
關(guān)于我們遇到的坑妨猩，接下來分享幾個實際的案例潜叛。
第一個案例是一次主從重置。這個情況是在春節(jié)前兩天出現(xiàn)的，春節(jié)前屬于消息推送業(yè)務(wù)高峰期威兜。我們簡單還原一下故障場景销斟。首先是大規(guī)模的消息下發(fā)導(dǎo)致負載增加；然后椒舵，Redis Master壓力增大票堵，TCP包積壓，OS產(chǎn)生丟包現(xiàn)象逮栅，丟包把Redis主從ping的包給丟了，觸發(fā)了repl-timeout 60秒的閾值窗宇，主從就重置了措伐。同時由于節(jié)點過大，導(dǎo)致Swap和IO飽和度接近100%军俊。解決的方法很簡單侥加，我們先把主從斷開。故障原因首先是參數(shù)不合理粪躬，大都是默認值担败，其次是節(jié)點過大讓故障效果進行放大。
第二個案例是codis最近遇到的一個問題镰官。這是一個典型的故障場景提前。一臺主機掛掉后，codis開啟了主從切換泳唠，主從切換后業(yè)務(wù)沒有受影響狈网，但是我們?nèi)ブ匦陆又鲝臅r發(fā)現(xiàn)接不上，接不上就報了錯笨腥。這個錯也不難查拓哺，其實就是參數(shù)設(shè)置過小，也是由于默認值導(dǎo)致脖母。Slave從主節(jié)點拉數(shù)據(jù)的過程中士鸥，新增數(shù)據(jù)留在Master緩沖區(qū)，如果Slave還沒拉完谆级，Master緩沖區(qū)就超過上限烤礁，就會導(dǎo)致主從重置，進入一個死循環(huán)肥照。
基于這些案例鸽凶，我們整理了一份最佳實踐。
一建峭、配置CPU親和玻侥。Redis是單機點的結(jié)構(gòu)，不親和會影響CPU的效率亿蒸。
二凑兰、節(jié)點大小控制在10G掌桩。
三、主機剩余內(nèi)存最好大于最大節(jié)點大小+10G姑食。主從重置需要有同等大小的內(nèi)存波岛，這個一定要留夠，如果不留夠音半，用了Swap则拷，就很難重置成功。
四曹鸠、盡量不要用Swap煌茬。500毫秒響應(yīng)一個請求還不如掛掉。
五彻桃、tcp-backlog坛善、repl-backlog-size、repl-timeout適度增大邻眷。
六眠屎、Master不做持久化，Slave做AOF+定時重置肆饶。
最后是個人的一些思考和建議改衩。選擇適合自己的NoSQL，選擇原則有五點：
1驯镊、業(yè)務(wù)邏輯燎字。首先要了解自身業(yè)務(wù)特點，比如是KV型就在KV里面找阿宅；如果是圖型就在圖型里找候衍，這樣范圍一下會減少70%-80%。
2洒放、負載特點蛉鹿，QPS、TPS和響應(yīng)時間往湿。在選擇NoSQL方案時妖异，可以從這些指標(biāo)去衡量，單機在一定配置下的性能指標(biāo)能達到多少领追？Redis在主機足夠剩余情況下他膳，單臺的QPS40-50萬是完全OK的。
3绒窑、數(shù)據(jù)規(guī)模棕孙。數(shù)據(jù)規(guī)模越大，需要考慮的問題就越多，選擇性就越小蟀俊。到了幾百個TB或者PB級別钦铺，幾乎沒太多選擇，就是Hadoop體系肢预。
4矛洞、運維成本和可不可監(jiān)控，能否方便地進行擴容烫映、縮容沼本。
5、其它锭沟。比如有沒有成功案例抽兆，有沒有完善的文檔和社區(qū)，有沒有官方或者企業(yè)支持冈钦。可以讓別人把坑踩過之后我們平滑過去李请，畢竟自己踩坑的成本還是蠻高的瞧筛。
結(jié)語：關(guān)于NoSQL的釋義，網(wǎng)絡(luò)上曾有一個段子：從1980年的know SQL导盅，到2005年的Not only SQL较幌，再到今日的No SQL！互聯(lián)網(wǎng)的發(fā)展伴隨著技術(shù)概念的更新與相關(guān)功能的完善白翻。而技術(shù)進步的背后乍炉，則是每一位技術(shù)人的持續(xù)的學(xué)習(xí)、周密的思考與不懈的嘗試滤馍。
歡迎工作一到五年的Java工程師朋友們加入Java高并發(fā)： 957734884岛琼，群內(nèi)提供免費的Java架構(gòu)學(xué)習(xí)資料（里面有高可用、高并發(fā)巢株、高性能及分布式槐瑞、Jvm性能調(diào)優(yōu)、Spring源碼阁苞，MyBatis困檩，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構(gòu)資料）合理利用自己每一分每一秒的時間來學(xué)習(xí)提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰那槽！趁年輕悼沿，使勁拼，給未來的自己一個交代骚灸！
