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

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

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

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

文章目录

前言

本文导读

一、Redis集群现状

二、Redis编排（Kubernetes 编排）

三、Redis内核优化

四、多云架构演进

1、为什么使用多云架构

2、多云架构演进路线

2.1 同城双活

2.2 跨云多活1.0

2.3 跨云多活2.0

总结

前言

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全同步、单机房/专线故障时的处理预案、三活的成本等等

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

总结

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