java编程——高并发大容量NoSQL解决方案探索

日期:2018-08-22 17:08:30 / 人气:1851

个推常用的几种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、其它。比如有没有成功案例,有没有完善的文档和社区,有没有官方或者企业支持。

作者:admin


现在致电 0371-69506331 OR 查看更多联系方式 →

COPYRIGHT © 2017 版权所有 豫ICP备12024037号-1