大数据年代，企业关于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！互联网的开展伴跟着技能概念的更新与相关功用的完善。而技能进步的背面，则是每一位技能人的继续的学习、缜密的考虑与不懈的测验。
