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

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

文章图片
我们综合调研其他厂商的架构经验，提出了RedKV双活设计(ReplicatorasSidecarService同机部署)方案，如图14 。同机部署，网络开销小；SidecarService对主服务侵入性小；单独部署，易于升级。
架构灵活，适合日志类存储系统双活架构。 Redis以及图数据库的多云方案都可以改造适用，具体的功能组件和实战场景会在后续技术文章详细介绍。

文章图片
图14跨云多活架构
五、实践案例
正如第2节描述的小红书业务需求场景，本节通过一个典型的业务场景来展示RedKV在NoSQL存储下的收益。
早期在没有zprofile中台的场景下， zprofile用户和笔记信息都存储在HBase 。为了保证集群的数据安全和服务稳定性， HBase采用了双集群部署，写入和读取方通过HBaseClientAPI做数据存储。 HBase的用户数据在数十TB ，在百万QPS下， P99时延已经在70ms左右，随着QPS的快速增长，时延越来越高，集群扩容带来的存储成本也越来越高，稳定性保障也面临极大的挑战。
RedKV1.0上线后，经过半年多的打磨，开始慢慢承接公司的核心业务。推荐平台架构组也开始着手打造zprofile中台服务，收敛上下游的业务，提供标准统一的读写方式。在存储方案上，平台架构组同学和存储组经过多次的业务沟通，最终选择使用RedKV作为底层存储，主要对接两类业务方：分别是数据生产者producer以及数据消费方consumer 。 zprofile最终的中台架构如下图15：zprofile-writeservice对上游提供统一的数据写入接口服务，提供用户和比较的Meta管理，用户数据写入redkv-zprofile-user集群，笔记及其他数据写入redkv-zprofile-other集群。 zprofile-service对下游提供统一的数据消费服务，对应时延要求不高的离线服务， RedKV本身支持单向数据复制的能力通过2个offline小集群提供数据scan业务。
整体架构改造完成后，使用RedKV对接同样QPS的业务能力，成本节省了36%,P99性能提升了约5倍。

文章图片
图15zprofile中台
>>>>参考资料Pinterest数据复制https://medium.com/pinterest-engineering/open-sourcing-rocksplicator-a-real-time-rocksdb-data-replicator-558cd3847a9dRocskdbhttps://github.com/facebook/rocksdb/wikiHeavyKeeperHeavyKeeper:AnAccurateAlgorithmforFindingTop-kElephantFlows|USENIX
作者丨云哲、久美、文书
来源丨公众号：小红书技术REDtech（ID：gh_f510929429e3）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
关于我们
dbaplus社群是围绕Database、BigData、AIOps的企业级专业社群。资深大咖、技术干货，每天精品原创文章推送，每周线上技术分享，每月线下技术沙龙，每季度Gdevops&DAMS行业大会。
关注公众号【dbaplus社群】，获取更多原创技术文章和精选工具下载返回搜狐，查看更多
责任编辑：