小红书KV存储架构：万亿级数据与跨云多活不在话下 RedKV是小红书自研的一款基于

RedKV是小红书自研的一款基于NVMeSSD的分布式NoSQLKV存储系统，支持无中心和有中心的两种管控架构，旨在解决公司内实时落盘的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数仓的数据互通能力为离线数据业务提供了一种解决方案。
一、小红书存储发展历史
小红书是年轻人的生活记录、分享平台，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式。在当前的业务模型下，用户的画像数据和笔记数据用来做风险控制和内容推荐。存储数据具有对象-属性的特征、维度多，画像数据量已经达到数十TB ，在线业务对画像和笔记数据的访问P99时延要求非常高。
2020年之前公司选择的NoSQL存储产品主要有：Redis、HBase ，随着公司DAU的高速增长，早期的存储方案遇到如下挑战：Redis集群主要适用于缓存场景，开启AOF数据实时落盘对性能有比较大的影响，同时每个节点需要额外挂载云盘用于存储AOF 。在集群节点和存储容量受限的情况下，单节点的数据量设置过大会导致故障后节点数据的failover时间太长，单节点数据量设置小会导致gossip协议在稳定性高要求下节点个数受限，同时考虑突发流量的压力， Redis集群在部署上需要做一些空间预留，带来成本高的问题。 HBase作为一款生态完善的NoSQL存储系统，在高QPS下也产生了诸多的性能和稳定性问题，如：Zookeeper压力大时稳定性难以保障（节点探活，服务注册等都依赖Zookeeper）；HBase的数据文件和WAL日志文件直接写HDFS ，节点故障后，重放HDFS上的WAL速度慢；JavaGC会导致Zookeeper误杀RegionServer ，同时产生毛刺；MajorCompaction会导致I/O飙升，产生长尾效应；受限HDFS的复杂性，黑盒运维对工程师来说比较困难；在小红书的业务实战中，百万QPS下HBase延时不太理想，核心数据用大内存机型兜住，也引发成本高的问题。
随着业务的持续增长，开源存储产品已经不能很好地满足公司的业务发展需求,公司需要一款稳定的高性能KV系统支撑内部业务，一方面要满足业务对功能和性能的需求，另一方面要优化成本。
二、小红书业务需求
1、高QPS和低延时读取特性
1）特征数据存储场景
写入带宽达到数十GB/s ，要求实时写入性能和读取性能都很高。
2）图片缓存的场景
数据量很大，要求读取时延低。可以接受故障场景下少量数据丢失。
3）高性能（P99<10ms）模型数据存储服务。记录过去一段时间用户训练模型数据，对P99时延要求非常高，数据量在几十TB 。去重存储服务。数据量在几十TB ， P99<10ms,P999<20ms 。风控数据存储服务。 QPS目前达到千万级别， P999<30ms 。
2、低成本的缓存特性
1）对标Redis
兼容Redis协议，性能比Redis慢一些，但资源成本降低50%+ 。
2）典型场景
广告的关键词存储和反作弊业务，解决大数据量、低QPS的存储模型。
3、NoSQL存储特性
1）对标HBase支持数据多版本，列存行取等特性，比HBase成本减少30%+ ， P99时延提升6倍。支持KKV级别的TTL 。强一致：目前RedKV1.0采用的主从双副本，数据写入成功，可以通过配置同步模式来保障2副本写成功，读主写主保障强一致。对于写性能要求高的场景，可以打开异步写，写主成功则返回，依赖增量同步从节点数据。