小红书自研 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 数仓的数据互通能力为离线数据业务提供了一种解决方案。

小红书是年轻人的生活记录、分享平台，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式。在当前的业务模型下，用户的画像数据和笔记数据用来做风险控制和内容推荐。存储数据具有对象-属性的特征、维度多，画像数据量已经达到数十 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.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 已经不能满足性能需求，时延抖动比较大。

• 画像存储服务。数据的维度多，字段读取的业务方多，对时延要求敏感。

RedKV 整体架构分 3 层，接入层兼容 Redis 协议，支持各种语言的社区版 SDK 和公司定制的中间件版；接入代理层支持千万 QPS 的读写能力，无状态扩展；存储层提供高可靠读写服务。RedKV1.0 架构如下图 1，下面我们详细的展开 3 层组件的介绍。

图 1. RedKV1.0 整体架构

3.1. Client 接入层

RedKV 集群部署完成后，通过公司内部提供的 Service Mesh 组件做服务发现，对 Client 提供服务。

3.2. Proxy

Proxy 层由一个无状态 CorvusPlus 进程组成。它兼容老的 Redis Client，扩缩容、升级对无 Client 和后端集群无感，支持多线程、IO 多路复用和端口复用特性。对比开源版本，CorvusPlus 增强了自我防护和可观测特性，实现了可在线配置的功能特性：

• Proxy 限流

• 数据在线压缩

• 线程模型优化

• backup-read 优化长尾

• 大 key 检测

3.2.1. Proxy 限流

小红书当前的业务模型比较多，客户端行为无法预期，可能出现的发版错误、系统问题及网络抖动引发客户端重试，突发的 qps 会影响服务稳定性。在高 QPS 压力下，Proxy 处理客户端读写超时，大量重试会导致雪崩，业务高峰期单个 Proxy 带宽可能超过机器的出入带宽限制，而存储集群只能保证在有限的资源内提供稳定可靠的服务。针对这类场景，我们需要保证流量过载时，Proxy 和 RedKV 服务不被打崩，能保障高可用。

基于以上问题和目标，对比原生的 Redis Cluster 模式，RedKV 基于令牌桶的流控算法支持了对连接数、带宽和 QPS 多维度限流。在高 QPS 下，我们的 Proxy 限流防止了雪崩，如图 2；在大带宽场景下，我们优化了时延，如图 3。

图 2. 雪崩场景下的限流

图 3. 大带宽场景下的限流

3.2.2. 数据在线压缩

Proxy 层本身只做路由转发，对 CPU 的消耗非常低。在大带宽的场景下，我们可以充分利用 Proxy 的 CPU 资源优化带宽和毛刺。在解析 Redis 协议时，使用 LZ4 算法对写入数据进行在线压缩，读取时在线解压。在推荐缓存的使用场景中网络带宽和存储空间压缩 40%以上（如图 4），总体时延并没有明显的下降。因为网络带宽和写入读取数据的减少，时延毛刺也变小了。

图 4. Proxy 开压缩后的带宽优化

3.2.3. 线程模型的优化

Proxy 采用 IO 多路复用技术，每个连接维护一个请求处理队列和响应队列，保序的返回给客户端。Proxy 在收到 RedKV Server 的回应之后，如果没有收到所有发送的 cmd 的返回，则会一直等待所有 cmd 的返回后再发送给 client，对于读的场景这种模式非常不友好。经过改造，如果某个 cmd 之前的 cmd 都已经正常响应，则可以马上响应给 client，不需要再等后面的所有 cmd 请求完成。

3.2.4. backup-read 优化长尾

在公网环境下，一个 CVM 虚拟机和其他多个虚拟机共享一台物理机。当某个客户的 CVM 占用大量资源时，很容易影响到其他 CVM 的 P99 时延（由于 QOS 和隔离性做的不够好，SMI 中断和内存 CE）。在网络吞吐较大的情况下，某云的 DPDK 容易被打爆，出现母机 OOB。而在 RedKV 的内部实现中，如果 Server 请求比较大，某些 key 的查询时延比较高的时候，容易产生排队堆积，或者 compaction 之后的 block cache 失效，很容易造成 IO 长尾。因此，RedKV 的 P99 读时延的毛刺很难避免，但毛刺是偶尔发生的，当前我们的主从节点一定是离散部署在不同的母机上，同时出现 P99 毛刺的可能很小。基于这点，我们在 Proxy 层做了 backup read 功能，优化了 RedKV 的 p99 时延问题。

针对以上模型，我们的优化思路：

• 检查节点的状态和过去的延时

• 选择 2 个节点中状态好的那个节点发送请求

• 计算 P99 时延，超过 P95 时延则向另外一个节点发送一定数目的 backup read 请求数

• 两个请求中任意一个请求返回成功则成功，如果超时则继续重试

图 5. Backup-read 消峰

因为 backup read 转发不需要复制内存，通过索引来保证生命周期，而且只有超过 P95 时延的报文会被检查是否能发送 backup read，因此，只要 5%的报文会发送两次，对集群基本不会增加压力。图 6 为一个集群中 P999 从 35ms 降低到 4ms 左右，效果非常明显。对比 HBase 同样的业务场景，客户端在同样的 timeout 的配置下，我们的方案提高了客户端的成功率。

图 6. Backup-read P999 优化对比

3.2.5. 大 Key 检测

我们线上很多集群在业务使用过程中会偶发的产生一些毛刺，通过抓包发现，这里毛刺有很大一部分原因是因为大 Key 造成的。为了甄别这类问题，我们在 Proxy 层支持的大 Key 的可观测指标。Proxy 在解析 Redis 的 cmd 可以附带统计 KV 的大小。对于 string 读类型的 command，读到的 val 值大于 big-string-size 判定为大 key；对于写类型的 command， 请求值大于 big-string-size 判定为大 key；对于 hash/zset 则为一次读取的 kv 总数大小。通过增加 read_size（所有读请求总共读到的字节数） 和 write_size （所有写请求总共写入的字节数）监控，rate(read_size) / rate(total_req_amount) 可以计算出平均请求值大小。大 Key 和热 Key 是 KV 系统不可避免的 2 个场景，针对大 Key，我们提供了 Proxy 层的数据压缩能力；对于热 Key， 我们在 Server 层基于 HeavyKeeper^[3]算法做了 topK 统计和处理。

3.3. RedKV Cluster

公司的存储需求场景比较多，如广告业务存储的标签和数据模型很多，同时是非常核心的业务，业务需要做资源隔离。为了减少节点故障缩小数据的爆炸半径 ，这里业务我们采用无中心管控的架构，即 RedKV1.0 架构，它能在部署和运维上能大大简化。无中心的集群架构采用的是 Gossip 协议，存储节点采用多进程多实例部署，如图 7。

图 7. Gossip 管控的 KV Cluster

推荐模型训练的数据量非常大，上下游业务很多，承载的 QPS 高，对应集群的节点也比较多，在故障处理和扩缩容方面会触发 gossip 抖动。针对大集群的节点管理，我们采用有中心管控的架构，即 RedKV2.0 架构。基于 Shard 管理的中心架构能更好的支持数据迁移和集群扩缩容，存储节点采用单进程多实例部署，在多活场景中可以支持副本数弹性扩展，如图 8。RedKV2.0 的相关组件会在后续的技术文章中详细介绍。

图 8. 基于中心管控的 KV Cluster

3.3.1. Gossip 优化

RedKV1.0 采用 Gossip 协议通信，节点故障时主从节点的切换，最长影响时间为 30s。一个节点出现故障时，集群中正常节点将故障节点标记为 fail 状态需要经过一段收敛时间。在这段时间内，Proxy 层有可能将用户请求转发给已经 fail 的节点，导致请求失败。减小集群收敛时间能有效减少 Proxy 层错误请求数量，提高集群的稳定性和可用性。

RedKV1.0 通过如下三个步骤加快视图收敛：

• 探测时间优化：Redis Gossip 协议正常情况下会每隔 100ms 随机选取一个节点发送 ping 包，并更新节点的 ping_sent 值为发送 ping 包时间。如果集群很大，节点数很多，那么故障节点被 ping 到的概率就会变小，最多超过 node_timeout/2 时间给故障节点发送 ping 包。这样就会导致节点发生故障时，集群中正常节点不能第一时间 ping 到故障节点，从而无法立刻感知到故障节点发生了故障。为了减少这部分时间，当集群中有节点超过 2s 没有收到故障节点发送的 pong 报文时，就立马通知其他节点去 ping 故障节点。这样可以把节点故障到正常节点给故障节点发送 ping 的时间控制在 2s 左右。

• 判定 PFAIL 时间优化：Gossip 协议现有实现方式是超过 node_timeout（通常为 15s）时间没有收到 pong 报文，就将节点状态置为 pfail。本次优化将这个时间设置为 3s（可配置），如果 24 小时内（可配置）首次超过 3s 没有收到 pong 报文，就将节点置为 pfail 状态。如果 24 小时内频繁出现，那可能是网络抖动造成，还走原来的路径等待 node_timeout。

• 减少 PFAIL 到 FAIL 的判定时间：只有一个节点收到集群 1/2 的节点的 PFAIL 信息的时候，才会将故障节点判定为 FAIL 状态。而 PFAIL 这个信息是通过 Gossip 协议交互的，最久需要 1/2 node_timeout 才会通知到其他节点。因此为了加速 PFAIL 到 FAIL 的状态，所有的节点按照统一的规则选出一个种子节点，PFAIL 信息除了随机发送一个节点意外，还会通知这个种子节点。这样种子节点能在最快的时间学习到集群所有节点的 PFAIL 信息，从而将故障节点标记为 FAIL 状态广播到集群。

3.3.2. RedKV Server

RedKV Server 配置多个 IO 线程同时监听一个端口来接受连接请求，每个线程上的连接数目会随机均衡。每个线程只解析自己连接上的请求，并将解析出的报文通过 key 挂到对应的请求队列上，每个队列由一个 Worker 线程处理。这样同一个 key/同一个 slot 上的请求都会落到同一根 Worker 线程上处理，避免了对 key 进行加锁，减少锁冲突和线程切换。Worker 线程中会对数据进行重编码，存储到 Rocksdb 本地存储引擎。

RedKV 内部的线程模型如下图 9：

图 9. RedKV Server 无锁线程模型

3.3.3. 数据存储

RedKV 当前支持的数据类型有 string、hash 和 zset，数据节点选择 RocksDB^[2]作为本地存储引擎，集群创建时支持配置多副本，主从节点离散部署。采用 hash 打散的方式存储连续 slot 分片的数据，能比较好的避免热点 key 问题。不同的数据类型包含(MetaKey,MetaValue) 和（DataKey, DataValue）,设计格式如下：

MetaKey：

MetaValue：

DataKey：

DataValue：

在如上的编码方式下，key 的设计中保留的 slot 信息，可以在扩缩容的场景中通过 slot 灵活的做数据迁移。

4.1. 数据复制

与传统解决方案引入同步组件的方式不同，我们快速实现了单向数据同步以及集群扩容需求，整体架构去除了对第三方组件的依赖，通过扩展 Redis 复制协议实现了 RedKV 数据节点的直接复制，如图 10。单向复制的限制是扩容需要基于$2^n$做节点同步，扩容完成后后台任务根据 3.3.3 中定义的 key 的分片删除不是本节点的数据。 

在多活的部署形态下，多云集群的一对多的数据复制采用单向复制对主集群性能侵入较大，因此我们实现了基于中心管控的数据复制策略。该策略支持多个集群的分片异构部署，通过 Checkpoint 方式定向同步数据，不再需要额外的后台任务去做数据淘汰，能很好的支持多对多的多云集群数据复制、数据破环和扩缩容。

图 10. RedKV 的数据复制

4.2. 数据批量导入

小红书大量的离线业务数据存储在 S3 Hive 中，每天会有部分数据需要增量更新，其他的数据会被淘汰。这类场景有几个挑战：

• 批量导入：如小红书的笔记数据，一般需要小时级别甚至天级别的更新，所以业务需要有快捷的批量导入功能。

• 快速更新：特征数据的特点就是数据量特别大，以笔记为例，全量笔记在 TB 级别数据量。如果通过 Jedis SDK 写入，那么存储集群需要支持百万 QPS 的机器资源。当下小红书数据平台支持业务把数据从 hive 通过工作流直接导入 RedKV，一般是每天凌晨开始写数据，等到晚高峰时大量读取。这种方法实践下来，经常导致 RedKV 集群的集群内存 OOM，影响稳定性。

• 性能及稳定：数据在导入的过程中不能影响读的性能

实现方案如图 11：

• 自定义获取集群视图和数据编码的 UDTF，支持 RedKV1.0 的数据格式

• 将原先的抽数据，编码，分片和排序整合成一个 HiveOperator，执行完成后按指定的 OutputFormat 输出 SST 文件到一个指定 S3 目录

• 通过 Hadoop distcp 工具做数据的跨云传输，走离线带宽不影响线上的读写业务

• RedKV 集群的节点 SiderCar 作为对象存储的一个 Client，RedKV 节点加载本节点的 SST 并 ingest

图 11. 离线数据 BulkLoad

4.3. 数据批量导出

小红书的业务模型训练数据通过 Hash 存储在 RedKV 集群中，业务下游需要对训练结果进行离线分析，希望 RedKV 具有和 Hive 数据流通的能力。RedKV 本身是不支持 Schema 的，如果要将 KV 数据导入 Hive 表，则需要将 Hash 的 KKV 数据转化为一个 Table。

RedKV 的内部数据按 hash 打散，导入 Hive 表则需要提供 table 关键字，先按前缀扫描的方式扫描存储节点，再生成 Hive 识别的文件，最后通过 Hive Load 进行加载。为了更好的兼容其他 spark 任务，我们选择 Hive 支持的标准 parquet 列式存储文件，整个 I/O 链路如下图 12：

图 12. RedKV2Hive I/O

示例：RedKV 里面的 Key 写入规定以 {tablename}_ 开始，比如一个 artical 表

RedKV 中的数据采用 hmset 写入：

hmset {person}_1 name John quantity 20 price 200.23hmset {person}_2 name Henry quantity 30 price 3000.45

通过以上的写入方式，可以通过配置 RedKV2Hive 将 KV 里面的数据导入到 Hive 里面的 Person 表 如果单表的数据量很大，可以采用分表写入，比如把 person 表分成 16 份

hmset {person:1}_1 name John quantity 20 price 200.23hmset {person:1}_2 name Henry quantity 30 price 3000.45...hmset {person:16}_100000 name Tom quantity 43 price 234.56

4.4. 数据的备份和恢复

小红书的广告数据存储在自研的分布式 KV 系统中，数据安全主要面临如下挑战：

• 基于 LSM 结构的 KV 系统，数据 compaction 导致的空间放大会翻倍，数据量大后，数据备份需要大容量的磁盘

• 单集群故障后，集群恢复的时间不可控

• 备份数据依赖第三方系统

• 广告系统对数据的及时恢复能力有比较高的要求，通常要求在分钟级。为了解决上述几个问题，我们提出了一种中心管控的主备集群容灾策略，通过 Proxy 接入层的秒级切换能快速切流到一个特定的版本

实现方案如图 13：

• 先部署一个容灾集群，主集群对外提供读写服务，灾备集群保存特定数量的快照数据

• 低峰期，中心管控根据配置的版本数和任务时间会定时的向主集群发送打快照的服务

• 快照完成后通过发生远程 rsync 命令将快照目录传送到容灾集群，主集群低峰期数据压缩后数据量可控，这样灾备集群可以备份指定数量的版本信息

• 故障发生后，中心管控可以在灾备集群通过 RPC 指令指定恢复到一个特定的版本

• Proxy 接入层通过服务注册与发现主键配置 2 组服务，通过动态的秒级切换可以将流量打向特定版本的集群，完成服务访问的秒级切换

图 13. 集群备份

4.5. 跨云多活

为了应对高速增长的业务需求，公司对云厂商的服务稳定性要求越来越高，单机房云服务难以满足公司稳定性的需求，跨云多活可以提高服务的稳定性，双写双读可以实现主备数据中心均对外提供读写服务, 这样既不会造成数据中心的资源浪费又可以实现跨地域容灾。我们对业界常用的方案做了一些对比分析：

我们综合调研其他厂商的架构经验，提出了 RedKV 双活设计( Replicator as Sidecar Service 同机部署) 方案，如图 14。

• 同机部署，网络开销小；

• Sidecar Service 对主服务侵入性小；

• 单独部署，易于升级

架构灵活，适合日志类存储系统双活架构。Redis 以及图数据库的多云方案都可以改造适用，具体的功能组件和实战场景会在后续技术文章详细介绍。

图 14. 跨云多活架构

正如第 2 节描述的小红书业务需求场景，本节通过一个典型的业务场景来展示 RedKV 在 noSQL 存储下的收益。

早期在没有 zprofile 中台的场景下，zprofile 用户和笔记信息都存储在 HBase。为了保证集群的数据安全和服务稳定性，HBase 采用了双集群部署，写入和读取方通过 HBase Client API 做数据存储。HBase 的用户数据在数十 TB，在百万 QPS 下，P99 时延已经在 70ms 左右，随着 QPS 的快速增长，时延越来越高，集群扩容带来的存储成本也越来越高，稳定性保障也面临极大的挑战。

RedKV1.0 上线后，经过半年多的打磨，开始慢慢承接公司的核心业务。推荐平台架构组也开始着手打造 zprofile 中台服务，收敛上下游的业务，提供标准统一的读写方式。在存储方案上，平台架构组同学和存储组经过多次的业务沟通，最终选择使用 RedKV 作为底层存储，主要对接两类业务方：分别是数据生产者 producer 以及数据消费方 consumer。zprofile 最终的中台架构如下图 15：

• zprofile-write service 对上游提供统一的数据写入接口服务，提供用户和比较的 Meta 管理，用户数据写入 redkv-zprofile-user 集群，笔记及其他数据写入 redkv-zprofile-other 集群。

• zprofile-service 对下游提供统一的数据消费服务，对应时延要求不高的离线服务，RedKV 本身支持单向数据复制的能力通过 2 个 offline 小集群提供数据 scan 业务。

整体架构改造完成后，使用 RedKV 对接同样 QPS 的业务能力，成本节省了 36%, P99 性能提升了约 5 倍。

图 15. zprofile 中台

[1] Pinterest 数据复制：

https://medium.com/pinterest-engineering/open-sourcing-rocksplicator-a-real-time-rocksdb-data-replicator-558cd3847a9d

[2] Rocskdb: 

https://github.com/facebook/rocksdb/wiki

[3] HeavyKeeper:

 HeavyKeeper: An Accurate Algorithm for Finding Top-k Elephant Flows | USENIX

云哲

小红书基础架构存储组，目前主要负责 RedKV1.0 架构下的功能开发和稳定性建设，研究方向为分布式 KV、持久化内存 KV 存储和表格存储。

久美

小红书基础架构存储组，目前主要负责 RedKV2.0 架构下的功能开发和存储中间件建设，研究研究方向为分布式 KV 和存储中间件。

文书

小红书基础架构存储组，目前主要负责 RedKV1.0 架构下的功能开发和跨云多活建设，研究方向为分布式 KV 和存储中间件。

基础架构-存储组是给小红书的业务部门提供稳定可靠的存储解决方案，满足公司内部对于存储产品的功能、性能、成本和稳定性要求。

目前负责自研分布式 KV、图数据库、时序数据库和持久化内存存储。已上线的存储产品包括：

• RedKV : 分布式高性能 KV

• RedTao：满足一跳查询的高性能图存储数据库

• RedTable：提供 Schema 支持的表格存储

• RedGraph：提供两跳及以上的图语义查询数据库

基础架构-存储和中间件岗位

工作职责：

1. 打造优秀的分布式 KV 存储系统、图数据库、表格存储和时序数据库, 为公司海量数据和大规模业务系统提供可靠的基础设施

2. 解决线上系统的疑难问题， 能从业务问题中抽象出通用的解决方案， 并落地实现

3. 团队密切配合， 共同研究和使用业内各方向最新技术，共同推动公司技术演进

任职资格：

1. 有 C/C++开发经验，精通多线程编程，有高并发场景下的产品设计和实战经验

2. 掌握分布式系统基本原理，了解 Paxos、Raft 等一致性协议原理及应用，熟悉 RocksDB 等单机存储引擎的使用及优化

3. 熟悉算法和数据结构，解决问题思路清晰, 对问题有深入钻研的兴趣.

4. 对系统设计有完美追求， 对编码保持热情

加分项：

1. 有 rocksdb、tidb、nebula、Lindom 等 KV/图/表格数据库使用和优化经验优先

2. 有持久化内存产品的研发经验优先

3. 对开源项目有深入学习或参与的优先

欢迎感兴趣的朋友发送简历至: 

REDtech@xiaohongshu.com；

并抄送至: 

liubei@xiaohongshu.com, ft_storage_team@xiaohongshu.com