📫 作者简介：小明Java问道之路，专注于研究 Java/ Liunx 内核/ C++及汇编/计算机底层原理/源码，就职于大型金融公司后端高级工程师，擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。

📫 热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。

🏆 InfoQ 签约作者、CSDN 专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO 专家 🏆

🔥 如果此文还不错的话，还请👍关注 、点赞 、收藏三连支持👍一下博主~

前言

2022 年 9 月 26 -27 日，有幸参加极客邦科技旗下 InfoQ 中国举办的 ArchSummit 全球架构师峰会（杭州站）。

本专栏是以“基础设施技术”为主题，关注数据中心、分布式系统、容器等基础设施技术，也可以从存储 + 计算 + 研发体系这三个角度来分享话题，分享架构与业务的融合。

大会内容涵盖人工智能、云计算、微服务、元宇宙、智能运维、大数据等主题，为企业管理者、架构师与开发人员提供了行业前沿视角与参考，帮助企业在数字化时代赢得先机，把握竞争优势。

本次大会官网ArchSummit 全球架构师峰会（杭州站），感兴趣的同学可以自行了解，错过杭州站的同学可以去了解一下北京站 。

本文导读

随着小红书业务体量迅速上涨，缓存系统（Redis）规模也在不断扩张，目前整体 QPS 高达 2 亿 +，内存 300TB+。 如何保证大规模缓存系统的高性能、高可靠、低成本是一件非常有挑战的事情。

目前小红书在 Redis 的中间件、内核、服务编排等多方面进行优化，探索出一条缓存服务多云部署之路，从而显著提升系统可靠性和降低成本。

本次议题我将为你分享小红书缓存服务多云建设之路，希望对你有所启发。

一、Redis 集群现状

整体规模与

小红书的 Redis 集群基本信息：488 内存/TB、412QPS/M、90Pod/K、100%k8s

面临挑战与跨云多活背景

需要 Redis 提供的能力：标准缓存、内存 DB、数据排序、推荐特征存储、分布式锁……

二、Redis 编排（Kubernetes 编排）

小红书 Redis 集群是用 Kubernetes 进行容器管理和编排。Kubernetes 编排分为三大模块：整体部署架构（单 Zone、单 Region、跨云等多种方式）、集群构建（组件构成、反亲和、多租户隔离等）、运维操作（故障自愈、大规模迁移等）

为什么使用 Kubernetes？主要有几点好处一、运维简单、自动化程度高，二、屏蔽多云机器差异，三、复用 K8S 丰富的调度能力；四、方便资源拆借、混部（混合部署）。

那么是不是使用 Kubernetes 就万无一失了呢？Kubernetes 存在资源碎片问题，由于小红书业务原因，缓存的内存会很多，单 k8s 规模过大(>4000 node)，宿主机快速重启导致数据丢失、IP 漂移、磁盘满导致节点被驱逐等等问题。

所以小红书对 Redis 内核优化进行一系列优化。

三、Redis 内核优化

小红书对 Redis 内核优化主要有，异地多活（支持 Binlog 改造、复制回环、冲突解决等），Gossip 优化（节点规模突破 1000，解决 Redis Cluster 规模受限的业界难题）全局 Scan、Rax Tree 裁剪、实时大 Key 统计等等，我们重点看几种优化设计的思路。

Gossip 分治

Cluster 功能裁剪

一个 Redis Cluster 由多个 Redis 节点构成，不同节点组服务的数据没有交集，也就是每个一节点组对应数据 sharding 的一个分片。

实时大 Key 检测

记录 Key 搜索事件：zincryby twrank:search-key camping 1

获取 Key 搜索频率 Top 100：zrevrange twrank:search-key 0 100 withscores

四、多云架构演进

1、为什么使用多云架构

1、避免单机房故障导致服务不可用

2、单云入口层异常导致服务不可用

3、需要更强大的灰度和容量管理能力

4、上海机房资源受限

5、单供应商议价能力差（从降本增效的层面考虑）

6、避免地域级故障

2、多云架构演进路线

2.1 同城双活

同城双活的基本信息：上海同城双机房（Ping<2ms, 带宽几乎无限制），核心业务场景（标准缓存用法），单机房异常/专线异常时核心用户体验不受影响。

同城双活的的一些问题：Full Sync Without RDB、Slot 同步延迟校验、数据致性校验。

2.2 跨云多活 1.0

跨云多活 1.0 的基本信息：华东跨省多机房( Ping:10ms, 带宽受限)，业务侧场景复杂（Redis As Cache & DB），业务层做单元化改造，单机房异常/专线异常时核心用户体验不受影响。

改造的方面主要有：自定义 ReplCmd,引入 Clsuter ID 避免循环复制，不做冲突处理，复制位点存储 Redis，无中心存储依赖，默认关闭全同步由人工触发，外部组件检查 &调整复制链路

2.3 跨云多活 2.0

当前小红书对整体架构的目标有三点：

第一，架构可以很好地支撑业务快速发展带来的规模的持续扩张，比如能够稳定支撑亿级 DAU 的规模；

第二，能够做到较高的可靠性和可用性，这主要表现在跨地域容灾能力和跨云基础设施的容灾设计等方面；

第三，架构必须是高效率的，这包括相对低廉的成本和较高的资源利用率。

这三个目标也是小红书做多云架构转型的动力。

但是多云也有一些问题需要解决，强一致性、强写后读场景的不满足、专线带宽管理、异步 RDB 全同步、单机房/专线故障时的处理预案、三活的成本等等

多云可以更加灵活地支撑更大的业务规模。不同的云技术特点不同，小红书可以根据不同云厂商的特点部署不一样的技术，如离线和在线的混布等。另外，多云对资源的冗余要求也更低一些，在容灾上有一定的效率优势。

总结

对于未来，小红书随着业务的增长，多云架构必将发展的更加高效、节流、多元化，探索出一条缓存服务多云部署之路，从而显著提升系统可靠性和降低成本。