小红书自研KV存储架构如何实现万亿量级存储与跨云多活

摘要：

RedKV是小红书自研的一款基于NVMeSSD的分布式NoSQL KV存储系统，支持无中心和有中心的两种管控架构，旨在解决公司内实时落盘的KV存储需求。RedKV1.0基于Gossip协议做节点管理，在全公司已经大规模使用，实时QPS接近1亿/秒，存储量在数PB级别。RedKV2.0采用中心Shard管理架构，支持全球多云多副本在线弹性伸缩，异地容灾和服务秒级切换。

通过分层优化，RedKV对比开源同类产品，聚合写吞吐能力平均提升3倍，读1.5倍；对标HBase，成本优化近40%。RedKV部分兼容Redis协议，string/hash/zset等主要数据类型很好的的支持了公司的绝大部分在线存储业务，优化了早期Redis集群部署产生的成本问题以及HBase带来的性能及稳定性问题。RedKV和Hive数仓的数据互通能力为离线数据业务提供了一种解决方案。

1.小红书存储发展历史

小红书是年轻人的生活记录、分享平台，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式。在当前的业务模型下，用户的画像数据和笔记数据用来做风险控制和内容推荐。存储数据具有对象-属性的特征、维度多，画像数据量已经达到数十TB， 在线业务对画像和笔记数据的访问P99 时延要求非常高。

2020年之前公司选择的NoSQL存储产品主要有：Redis、HBase，随着公司DAU的高速增长，早期的存储方案遇到如下挑战：

• Redis集群主要适用于缓存场景，开启AOF数据实时落盘对性能有比较大的影响，同时每个节点需要额外挂载云盘用于存储AOF。在集群节点和存储容量受限的情况下，单节点的数据量设置过大会导致故障后节点数据的failover时间太长，单节点数据量设置小会导致gossip协议在稳定性高要求下节点个数受限，同时考虑突发流量的压力，Redis集群在部署上需要做一些空间预留，带来成本高的问题。
• HBase作为一款生态完善的NoSQL存储系统，在高QPS下也产生了诸多的性能和稳定性问题，如：Zookeeper压力大时稳定性难以保障（节点探活，服务注册等都依赖 Zookeeper）；HBase的数据文件和WAL日志文件直接写HDFS，节点故障后，重放HDFS上的WAL速度慢；Java GC会导致Zookeeper误杀RegionServer，同时产生毛刺；Major Compaction 会导致I/O飙升，产生长尾效应；受限HDFS的复杂性，黑盒运维对工程师来说比较困难；在小红书的业务实战中，百万QPS下HBase延时不太理想，核心数据用大内存机型兜住，也引发成本高的问题。

随着业务的持续增长，开源存储产品已经不能很好的满足公司的业务发展需求, 公司需要一款稳定的高性能KV系统支撑内部业务，一方面要满足业务对功能和性能的需求，另一方面要优化成本。

2.小红书业务需求

2.1. 高QPS和低延时读取特性

特征数据存储场景：

• 写入带宽达到数十GB/s，要求实时写入性能和读取性能都很高。

图片缓存的场景：

• 数据量很大，要求读取时延低。可以接受故障场景下少量数据丢失。

高性能（P99 < 10ms）：

• 模型数据存储服务。记录过去一段时间用户训练模型数据，对P99时延要求非常高，数据量在几十TB。
• 去重存储服务。数据量在几十TB，P99<10ms, P999<20ms。
• 风控数据存储服务。QPS目前达到千万级别，P999 < 30ms。

2.2. 低成本的缓存特性

对标Redis：

• 兼容Redis协议，性能比Redis慢一些，但资源成本降低50%+。

典型场景：

• 广告的关键词存储和反作弊业务，解决大数据量、低QPS的存储模型。

2.3. NoSQL存储特性

对标HBase：

• 支持数据多版本，列存行取等特性，比HBase成本减少30%+，P99时延提升6倍。
• 支持KKV级别的TTL。
• 强一致：目前RedKV1.0采用的主从双副本，数据写入成功，可以通过配置同步模式来保障2副本写成功，读主写主保障强一致。对于写性能要求高的场景，可以打开异步写，写主成功则返回，依赖增量同步从节点数据。

典型场景：

• 风控服务。实时查询对P999要求极高，千万QPS下HBase已经不能满足性能需求，时延抖动比较大。
• 画像存储服务。数据的维度多，字段读取的业务方多，对时延要求敏感。