大容量NoSQL解决方案：Aerospike实战

Posted 2021-05-01 个推技术学院

个推为企业和开发者提供推送技术服务多年。通过个推SDK，手机终端与服务器可以建立长连接，维持在线状态。然而在网络异常等情况下，推送消息无法实时送达终端用户，所以个推的推送服务器建立了离线消息列表，以待用户重新登录之后，进行消息的推送。

这些离线数据存储在个推Redis集群中，整个集群包括主、从共百余个实例，key的数量在10亿级别，存储空间在T级别，带来了一定的维护成本和运维挑战。个推的后端开发团队在经过了调研与对比实测后，选择了使用Aerospike作为存储集群。我们发现，在单台搭载单块Inter SSD 4600的物理机，使用Aerospike可以达到接近10w的QPS，而个推整个集群的QPS在百万级别，即几十台机器就可以满足现有的需求，并能够支撑未来较长一段时间的业务需求。

01

Aerospike的优势

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

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

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

02

数据模型说明

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

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

03

灰度上线流程

个推在离线消息列表存储这项业务中，使用了较大规模的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、相关配置的优化等。

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

模拟线上环境压测，进行可行性验证。

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

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

3、QA功能验证。

4、申请资源，线上部署Aerospike集群。

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

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

04

经验总结

在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。

05

结语

Aerospike作为一个大容量的NoSql解决方案，并未在国内厂中广泛商使用。它适合对容量要求较大，QPS相对较低一些的场景，在一定程度上可以节省TCO。而在支持命令上，Aerospike和Redis比较相似，业务迁移也比较容易。Aerospike天然地支持集群部署，对监控和运维支持比较友好。尽管拥有这么多的优良特性，开发人员在进行技术选型时，还是需要持审慎态度，预先评估Aerospike是否适合自己的业务场景，其性能和成本能否满足要求等。

在官方的某些测试场景下，Aerospike的性能比Redis要高，但实际上，由于SSD本身的限制，在大部分情况下，它在QPS方面与Redis的差距较大。最后，项目上线前务必要经过线上流量验证，用灰度方式处理实际的线上业务，使对用户体验影响降到最低。