个推常用的几种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。

关于我们遇到的坑，接下来分享几个实际的案例。

第一个案例是一次主从重置。首先是大规模的消息下发导致负载增加；然后，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、其它。比如有没有成功案例，有没有完善的文档和社区，有没有官方或者企业支持。