应用实战：从Redis到Aerospike，我们踩了这些坑

个推专注为开发者们提供消息推送服务多年。通过个推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本身，对其他基础组件的迁移和规划，也能够带来一定的借鉴意义。

数据模型说明

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

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

灰度上线流程

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

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

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

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

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

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

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

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

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

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

服务端主要观察:

1.集群的健康度。

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

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

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

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.相关配置的优化等。

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

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差距较大。最后，上线前务必经过线上流量验证，用灰度方式处理实际线上业务，最小化影响用户体验。

巴特西

应用实战：从Redis到Aerospike，我们踩了这些坑

最新文章

热门文章