【ArchSummit】小红书缓存服务多云建设之路

作者简介:小明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、数据排序、推荐特征存储、分布式锁……

【ArchSummit】小红书缓存服务多云建设之路_第1张图片

二、Redis编排(Kubernetes 编排)

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

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

【ArchSummit】小红书缓存服务多云建设之路_第2张图片

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

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

三、Redis内核优化

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

Gossip分治

【ArchSummit】小红书缓存服务多云建设之路_第3张图片

Cluster功能裁剪

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

实时大Key检测

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

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

【ArchSummit】小红书缓存服务多云建设之路_第4张图片

四、多云架构演进

1、为什么使用多云架构

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

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

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

4、上海机房资源受限

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

6、避免地域级故障

2、多云架构演进路线

2.1 同城双活

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

【ArchSummit】小红书缓存服务多云建设之路_第5张图片

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

2.2 跨云多活1.0

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

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

【ArchSummit】小红书缓存服务多云建设之路_第6张图片

2.3 跨云多活2.0

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

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

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

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

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

【ArchSummit】小红书缓存服务多云建设之路_第7张图片

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

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

总结

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

你可能感兴趣的:(#,《企业系统架构分析实践与落地》,互联网架构分析与实战[更新中],云原生,微服务,架构,redis,多云架构)