王曉波?

同程旅行 機票事業群 CTO

讀完需要

4

分鐘

速讀僅需 2 分鐘

本章和大家分享一下同程鳳凰緩存系統在基于 Redis 方面的設計與實踐。如何改變 Redis 不好用的誤區

? 本文節選自中生代技術社區出品圖書《深入分布式緩存》

接上文《同程旅行王曉波：同程鳳凰緩存系統在基于 Redis 方面的設計與實踐（上篇）》

這樣的亂象一定是不可能繼續了，最少同程這樣的使用方式不可以再繼續了，使用者也開始從喜歡到痛苦了。怎么辦？

這是一個很沉重的事：“一個被人用亂的系統就像一桌燒壞的菜，讓你重新回爐，還讓人叫好，是很困難的?！?/p>

關鍵是已經用成這樣了，總不可能讓所有系統都停下來，等待新系統上線并瞬間切換吧？這是個什么活？高速公路上換輪胎！

但問題出現了總是要解決的，想了再想，論了再論，總結了以下幾點：

必須搭建完善的監控系統，在這之前要先預警，不能等到發生了，我們才發現問題。

控制和引導 Redis 的使用，我們需要有自己研發的 Redis 客戶端，在使用時就開始控制和引導。

Redis 的部分角色要改，將 Redis 由 storage 角色降低為 cache 角色。

Redis 的持久化方案要重新做，需要自己研發一個基于 Redis 協議的持久化方案，讓使用者可以把 Redis 當 DB 用。

Redis 的高可用要按照場景分開，根據不同的場景決定采用不同的高可用方案。

留給開發同學的時間并不多，必須兩個月的時間來完成這些事情。這其實還是很有挑戰的，考驗開發同學這個輪胎到底能不換下來的時候到了。同學們開始研發我們自己的 Redis 緩存系統，下面我們來看一下這個代號為鳳凰的緩存系統的第一版方案。

首先是監控系統

原有的開源 Redis 監控從大面上講只一些監控工具，不能算作一個完整的監控系統。當然這個監控是全方位從客戶端開始一直到返回數據的全鏈路的監控。

其次是改造 Redis 客戶端

廣泛使用的 Redis 客戶端有的太簡單有的太重，總之不是我們想要的東西，比如，.Net 下的 BookSleeve 和 servicestack.Redis （同程還有一點老的.Net 開發的應用)，前者已經好久沒人維護了，后者直接收費了。好吧，我們就開發一個客戶端，然后督促全公司的研發用它來替換目前正在使用的客戶端。在這個客戶端里面，我們植入了日志記錄，記錄了代碼對 Redis 的所有操作事件，例如耗時、key、value 大小、網絡斷開等，我們將這些有問題的事件在后臺進行收集，由一個收集程序進行分析和處理，同時取消了直接的 IP 端口連接方式，通過一個配置中心分配 IP 地址和端口。當 Redis 發生問題并需要切換時，直接在配置中心修改，由配置中心推送新的配置到客戶端，這樣就免去了 Redis 切換時需要運維人員修改配置文件的麻煩。另外，把 Redis 的命令操作分拆成兩部分：安全的命令和不安全的命令。對于安全的命令可以直接使用，對于不安全的命令需要分析和審批后才能打開，這也是由配置中心控制的，這樣就解決了研發人員使用 Redis 時的規范問題，并且將 Redis 定位為緩存角色，除非有特殊需求，否則一律以緩存角色對待。

最后，對 Redis 的部署方式也進行了修改

以前是 Keepalived 的方式，現在換成了主從+哨兵的模式。另外，我們自己實現了 Redis 的分片，如果業務需要申請大容量的 Redis 數據庫，就會把 Redis 拆分成多片，通過 Hash 算法均衡每片的大小，這樣的分片對應用層也是無感知的。

當然重客戶端方式不好，并且我們要做的緩存不僅僅是單純的 Redis，我們還會做一個 Redis 的 Proxy，提供統一的人口點，Proxy 可以多份部署，客戶端無論連接的是哪個 Proxy，都能取得完整的集群數據，這樣就基本完成了按場景選擇不同的部署方式的問題。

這樣的一個 Proxy 也解決了多種開發語言的問題，例如，運維系統是使用 Python 開發的，也需要用到 Redis，就可以直接連 Proxy，然后接到統一的 Redis 體系中來。做客戶端也好，做 Proxy 也好，不只是為代理請求而是為了統一治理 Redis 緩存的使用，不讓亂象出現。讓緩存在一個可管可控的場景下穩定的運維，讓開發者可以安全并肆無忌憚繼續亂用 Redis，但這個“亂”是被虛擬化的亂，因為它的底層是可以治理的。系統架構如圖 15-1 所示

圖 15-1 系統架構圖

當然以上這些改造都需要在不影響業務的情況下進行。實現這個其實還是有不小的挑戰，特別是分片，將一個 Redis 拆分成多個，還能讓客戶端正確找到所需要的 key，這需要非常小心，因為稍有不慎，內存的數據就全部消失了。在這段時間里，我們開發了多種同步工具，幾乎把 Redis 的主從協議整個實現了一遍，終于可以將 Redis 平滑過度到新的模式上了。（未完待續）

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

阿里技術精彩文章推薦

往期推薦

深度：揭秘阿里巴巴的客群畫像

多隆：從工程師到阿里巴巴合伙人

阿里技術專家楚衡：架構制圖的工具與方法論

螞蟻集團技術專家山丘：性能優化常見壓測模型及優缺點

阿里文娛技術專家戰獒: 領域驅動設計詳解之What, Why, How?

阿里專家馬飛翔：一文讀懂架構整潔之道

阿里專家常昊：新人如何上手項目管理？

螞蟻集團沈凋墨：Kubernetes-微內核的分布式操作系統

阿里合伙人范禹：常掛在阿里技術人嘴邊的四句土話

阿里技術專家都鐸：一文搞懂技術債

支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路

阿里技術專家麒燁：修煉測試基本功

阿里計算平臺掌門人賈揚清：我對人工智能方向的一點淺見

螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護隱私的共享智能？

阿里高級技術專家簫逸：如何畫好一張架構圖？

阿里高級技術專家張建飛：應用架構分離業務邏輯和技術細節之道

螞蟻科技 Service Mesh 落地實踐與挑戰 | GIAC 實錄

阿里6年，我的技術蛻變之路！

螞蟻集團涵暢：再啟程，Service Mesh 前路雖長，尤可期許

阿里P9專家右軍：大話軟件質量穩定性

阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽

阿里高工流生 | 云原生時代的 DevOps 之道

阿里高級技術專家邱小俠：微服務架構的理論基礎 - 康威定律

阿里P9專家右軍：以終為始的架構設計

阿里P8架構師：淘寶技術架構從1.0到4.0的架構變遷！12頁PPT詳解

阿里技術：如何畫出一張合格的技術架構圖？

螞蟻資深技術專家王旭：開源項目是如何讓這個世界更安全的？

阿里資深技術專家崮德：8 個影響我職業生涯的重要技能

儒梟：我看技術人的成長路徑

阿里高級技術專家宋意：平凡人在阿里十年的成長之旅

阿里技術專家甘盤：淺談雙十一背后的支付寶LDC架構和其CAP分析

阿里技術專家光錐：億級長連網關的云原生演進之路

阿里云原生張羽辰：服務發現技術選型那點事兒

螞蟻研究員玉伯：做一個簡單自由有愛的技術人

阿里高級技術專家至簡: Service Mesh 在超大規模場景下的落地挑戰

阿里巴巴山獵：手把手教你玩轉全鏈路監控

阿里涉江：你真的會學習嗎？從結構化思維說起

螞蟻金服資深技術專家經國：云原生時代微服務的高可用架構設計

深入分布式緩存之EVCache探秘開局篇

? ?END ? ?? #架構師必備#點分享點點贊點在看

總結

以上是生活随笔為你收集整理的同程旅行王晓波：如何改变 Redis 用不好的误区的全部內容，希望文章能夠幫你解決所遇到的問題。

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