个推专注为开发者们提供消息推送服务多年。通过个推SDK,手机终端与服务器建立长连接,维持在线状态。然而在网络异常等情况下,消息无法实时送达到终端用户,因而推送服务器建立了一份离线消息列表,以待用户重新登录时,进行消息的下发。这部分数据存储在个推Redis集群,整个集群包括主从共百余个实例,key的数量在10亿级别,存储空间在T级别,带来了一定的维护成本和运维挑战。作为个推的后端开发工程师,我们也一直在寻找高性价比的方案。

个推整个集群的QPS在百万级别,若选择使用Aerospike,对比实测下来,我们发现单台搭载单块Inter SSD 4600的物理机,可以达到接近10w的QPS,即几十台机器就可以满足现有的需求,并能够支撑未来较长一段时间的业务需求。

Aerospike的优势

Aerospike是一个高性能、可扩展、可靠性强的NoSQL解决方案,支持RAM和SSD作为存储介质,并专门针对SSD特殊优化,广泛应用于实时竞价等实时计算领域。官方保证99%的操作在1ms内完成,并提供集群数据自动Rebalance、集群感知客户端等功能,且支持超大规模数据集(100T级别)的存储。

作为KV存储,Aerospike提供多种数据类型,其操作方式和Redis比较类似。除基础功能之外,Aerospike还支持AMC控制台、API等多种监控方式,有集群QPS、健康度、负载等多项监控指标,对运维比较友好。支持集群内数据的自动Rebalance,和Redis集群方案相比,维护成本下降不少。

本文主要做一些Aerospike灰度部署、使用方面的经验分享,希望对正在调研或者已经准备使用Aerospike的读者提供一些参考。此外,灰度的理念并不限于Aerospike本身,对其他基础组件的迁移和规划,也能够带来一定的借鉴意义。

数据模型说明

img

Aerospike采用无模式存储,数据模型类似RDBMS,因而在理解与使用上相对亲切:

每个namespace包含多个set,每个set包含多条record,每个record包含多个bin(数据库列),可通过索引key来查询record。不同的业务可以使用同一个集群的不同namespace来作做资源隔离,从而实现资源池化、最大化利用资源的目的。

img

灰度上线流程

个推在离线消息列表存储这项业务中使用了较大规模的Redis集群。我们先后调研了ssdb、pika等支持Redis协议的磁盘存储,整体计算下来,Aerospike的性价比最高。

前期我们结合线上场景模拟实际读写比例(分析线上业务,我们发现写和读大致比例在1:1 ~ 1:2之间)进行压测,对可行性进行评估和验证,然后进行投产规划。

线上业务比较庞杂,直接全量切到Aerospike不太现实,风险也比较大。测试网模拟验证难以暴露出生产环境下可能出现的问题,因此我们将整个上线流程划分为观察阶段和灰度阶段。观察阶段顾名思义,原Redis集群仍然承担线上读写业务,只是将同样的流量复制一份导入Aerospike,来进行真实压力验证; 灰度阶段将线上业务逐步切到Aerospike集群,扩大灰度保证集群稳定运行至业务完全切到Aerospike。两个阶段具体操作如下:

观察阶段: Redis操作成功后,对Redis的读写操作以异步方式同步到Aerospike,Aerospike不承担具体业务。下一步是数据双写Redis和Aerospike。该阶段主要观察两边数据是否一致,Aerospike压力等。同时观察阶段可以进行节点重启、集群扩容等运维操作,评估运维成本,优化配置等。这里可使用AMC页面控制台、监控API来监控集群状态,客户端调用部分记录必要日志和监控信息。

img

灰度阶段: Aerospike开始承担部分应用和任务的离线消息列表存储。灰度阶段Redis和Aerospike数据双写双清,保持热备状态,直至Redis数据完全切换到Aerospike并稳定运行一段时间。

img

观察阶段非常重要,基本上是对整个方案可行性进行线上评估。这个阶段观察点分为客户端(AS-Client)和服务端(AS-Server)两部分。客户端主要观察:

1.使用metrics监控客户端请求响应耗时,利用一段时间内的请求耗时百分比分布(50%, 90%, 99%, 99.9%),评估系统SLA。

2.监控读写成功、失败等情况的计数。

3.将慢日志阈值设定为50ms,统计高峰期和平常时段的慢日志情况。

4.异步写Aerospike队列监控,合理调整队列大小。

服务端主要观察:

1.集群的健康度。

2.磁盘和内存占用情况,内存空间/磁盘空间比例。

img

3.机器IO负载、CPU负载、磁盘碎片化程度等信息。

4.集群吞吐量,读写TPS是否能与线上Redis集群相当。

img

5.数据一致性检查。如何检查观察阶段和灰度阶段两份数据的一致情况?逐key比对差异在性能上难以满足要求。考虑数据完全一致情况下Redis查出的数据应该和Aerospike查出来的数据完全相同,所以抽样记录Redis和Aerospike的数据查询结果记录到日志,对比分析1分钟、5分钟、30分钟、1小时内不一致数据占比。如果线上Key的数量在10亿级别,即便只检查出万分之一的差异,那么不一致的情况也很显著了。这种情况下,就需要排查引发不一致情况的原因并解决。

维护性方面主要考虑到集群数据自动Rebalance会带来一定的性能下降,可能对用户体验有较大影响,结合我们的经验,模拟了一些典型的运维场景:

1.模拟单节点故障导致的集群Rebalance对系统性能的影响。

2.模拟集群扩容导致的集群Rebalance对系统性能的影响。

3.根据对线上业务的影响,计算白天和晚上集群的Rebalance速度,同时支持cron job更新。

4.节点重启。

5.增加SSD挂载。

6.相关配置的优化等。

总结一下,完整的上线流程分为以下几步:

img

0.模拟线上环境压测,进行可行性验证。

1.将Aerospike客户端封装成类Redis的接口,添加必要日志、监控项,对Bin的有效性检查等。

2.消息服务集成Aerospike客户端,需要的功能包括: Aerospike异步读写,业务数据源切换,流量过滤等。

3.QA功能验证。

4.申请资源,线上部署Aerospike集群。

5.集成Aerospike功能的消息服务上线。

6.观察阶段验证通过后,进入灰度阶段,直至最终上线或中途撤回。

经验总结

在Aerospike使用过程中,我们遇到了一些问题和挑战,总结为下面几点:

1.Aerospike开启single-bin的模式会节省占用空间。

2.Aerospike不会存储原始key,实际索引的是原始key的一个20字节hash值,如果业务需要使用原始key则必须另外设置bin存储。即便key和value值的字节数较少,但key本身占据20个字节,因而实际占用的空间会比较大。

3.Aerospike在节点宕机或是增减节点时会Rebalance数据,这个过程会影响对外服务质量。但Rebalance速度可以控制,因而需要在保证服务质量和集群快速恢复二者间做权衡。

4.社区版本集群每次重启都要重建索引,然后加载到内存,这会导致速度比较慢。namespace需要在配置文件中指定,因而最好能按业务划分,预先分配好将来可能用到的namespace,减少不必要的重启。

5.因为SSD本身存在碎片和写入放大的问题,实际使用中,我们发现若磁盘空间使用量在50%左右,性能下降会比较严重。故可以结合实际业务优化碎片整理相关参数。

6.Aerospike对HotKey有限制,因而频繁对一个key读写时,会返回HotKey错误(errorcode 14) 。服务端可以通过增大 transaction-pending-limit配置来提高对同一个key操作的并发量,它的默认为20,值为0时表示不限。增大该配置可能会降低一定性能。客户端可能需要对该异常增加重试处理,但重试可能会进一步增大HotKey的风险。

7.这种基础组件的更迭一定要尽可能使用线上流量做压力检验,从而尽早暴露潜在问题。

8.观察阶段也要评估运维成本,避免从一个坑跳进另一个坑。

9.使用过程中还需要注意Aerospike的一些固有限制,如一个namespace最多有1023个set 、bin名字长度最多14个单字节字符 、一个namespace最多支持64块SSD 等等,具体可参考:aerospike_known_limitations

结语

Aerospike作为一个大容量的NoSql解决方案,并未在国内厂中广泛商使用。它适合对容量要求比较大,QPS相对低一些的场景,一定程度上可以节省TCO。支持命令上,Aerospike和Redis比较相像,业务迁移过来也比较容易。它天然地支持集群部署,对监控和运维支持比较友好。尽管拥有这么多优良特性,但技术选型时还是要持审慎态度,预先评估是否符合自己的业务场景,性能和成本是否能够满足要求等。在官方的某些测试场景下,它的性能比Redis还要高,实际上因为SSD本身的限制,大部分情况下,它在QPS方面与Redis差距较大。最后,上线前务必经过线上流量验证,用灰度方式处理实际线上业务,最小化影响用户体验。