📫 作者簡介：小明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全同步、單機房/專線故障時的處理預案、三活的成本等等

多云可以更加靈活地支撐更大的業務規模。不同的云技術特點不同，小紅書可以根據不同云廠商的特點部署不一樣的技術，如離線和在線的混布等。另外，多云對資源的冗余要求也更低一些，在容災上有一定的效率優勢。

總結

對于未來，小紅書隨著業務的增長，多云架構必將發展的更加高效、節流、多元化，探索出一條緩存服務多云部署之路，從而顯著提升系統可靠性和降低成本。

總結

以上是生活随笔為你收集整理的【ArchSummit】小红书缓存服务多云建设之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。