人生不過如此，且行且珍惜。自己永遠是自己的主角，不要總在別人的戲劇里充當著配角。

我以林語堂的《人生不過如此》中一句話來開篇。

背景

在互聯網高速發展、快速演化的時代，想必在你的系統架構設計中，緩存服務是不是已經成為必不可少的一層，豐富的數據結構、高性能的讀寫、簡單的協議，讓緩存數據庫很好的承擔起關系型數據庫的上層。暢途網為了解決節假日或高峰期的車次查詢、搶票等大數據量的訪問請求，很早以前就引進了 Redis，來作為數據庫的上游緩存層，緩解底層數據庫的讀寫壓力。

REDIS HA 架構

世界上唯一可以不勞而獲的就是貧窮，唯一可以無中生有的是夢想。沒有哪件事，不動手就可以實現。世界雖然殘酷，但只要你愿意走，總會有路；看不到美好，是因為你沒有堅持走下去。人生貴在行動，遲疑不決時，不妨先邁出小小一步。前進不必遺憾，若是美好，叫做精彩；若是糟糕，叫做經歷。**——林語堂《人生不過如此》

2014 年 10 月，為了避免單點故障，我們嘗試在生產環境的 Redis 主從架構中，引入了 Redis Sentinel，實現了 Redis 服務的 failover。當 Redis-Master 主機異常宕機或 Redis-Master 服務異常崩潰時，原有的 Redis-Slave 自動升級為 master 角色，當原有 Redis-Master 恢復后，自動恢復為 slave 角色。

由于 Redis Sentinel 只能做到 Redis 服務級別的切換，無法做到 IP 地址的切換，無法完全滿足現網系統架構的需要，我們又嘗試在 HA 架構中加入了負載均衡器設備，引用了浮動 IP，所有應用程序訪問浮動 IP，IP 地址的切換操作由負載均衡器設備來實現。

Redis Sentinel 配置文件

測試小結：

主 Redis 服務器：redis-sent-0-17

從 Redis 服務器：redis-sent-0-18

域名：

redis-sent.cache.changtu.pvt

• 重啟 redis-sent-0-17 節點，60 秒后，redis-sent-0-18 節點成為 master，用戶訪問 redis-sent.cache.changtu.pvt 域名 redis 服務恢復正常，2 分鐘后，redis-sent-0-17 節點重啟完成，自動成為 slave；
• 重啟 redis-sent-0-18 節點，60 秒后，redis-sent-0-17 節點成為 master，用戶訪問 redis-sent.cache.changtu.pvt 域名 redis 服務恢復正常，2 分鐘后，redis-sent-0-18 節點重啟完成，自動成為 slave。

對應用程序的要求

• 緩存應用服務統一通過域名訪問。
• 緩存應用服務對 Redis 域名的訪問有斷點重連的功能。

2015 年新增 2 臺 Redis Sentinel 服務器，負責平臺所有 Redis 服務器集群管理。并對平臺現有 Redis 服務進行改造，逐步升級為 Redis HA 架構。

CODIS 分布式集群

你可以一輩子不登山，但你心中一定要有座山。它使你總往高處爬，它使你總有個奮斗的方向，它使你任何一刻抬起頭，都能看到自己的希望。——林語堂《人生不過如此》

隨著暢途網業務量上漲，數據量猛增，單點的 Redis 容量受限于服務器的內存，Redis 主從架構已經力不從心了。在業務系統對性能要求逐漸提高情況下，我們更希望將數據能存在內存中，本地持久化，而不希望寫入數據庫中。雖然當時用 SSD 將內存換成磁盤，以獲取更大的容量，但是我們更想如何將 redis 變成一個可以水平擴展的分布式緩存服務？

在 Codis 發布之前，業界只有 Twemproxy，Twemproxy 本身是一個靜態的分布式 Redis 方案，進行擴容、縮容對運維要求非常高，而且很難做到平滑的擴縮容。Codis 的目標就是盡量兼容 Twemproxy，并且加上數據遷移的功能以實現擴容和縮容，最終替換 Twemproxy。本文省略了對 Twemproxy 的介紹。

REDIS-CLUSTER

與 Codis 同時期發布的官方 redis-cluster，采用 P2P 的模式，完全去中心化架構， 其實我們花了大精力研究測試過，由于當時對 failover 判斷方式提出懷疑，高耦合的模塊設計思想、客戶端問題、不太友好的維護等方面， 我司目前沒有投入生產，沒有了實際的生產維護經驗，我先不發表看法。抱拳，我知道在緩存數據庫里最不應該缺少的就是 Redis-cluster 了，以后有機會單獨介紹吧！

容我感嘆一下，別指望所有的人都能懂你，因為蘿卜白菜，各有所愛。你做了蘿卜，自然就做不成青菜。

好了，回歸正題，先簡單介紹一下 Codis，由豌豆莢于 2014 年 11 月開源，基于 Go 和 C 開發，引用作者的一段原話， Codis 采用一層無狀態的 proxy 層，將分布式邏輯寫在 proxy 上，底層的存儲引擎是 Redis，數據的分布狀態存儲于 zookeeper(etcd) 中，底層的數據存儲變成了可插拔的部件。各個部件是可以動態水平擴展的，尤其無狀態的 proxy 對于動態的負載均衡，對業務而言完全是透明的。*

核心組件說明

1. ZooKeeper：

用來存放數據路由表和 Codis-proxy 節點的元信息，Codis-config 發起的命令都會通過 ZooKeeper 同步到各個存活的 Codis-proxy 中。

2. Codis-Proxy :

是客戶端連接的 Redis 代理服務，本身是沒狀態的，Codis-proxy 實現了 Redis 協議，對于一個業務來說，可以部署多個 Codis-proxy， 提供連接集群 Redis 服務的入口。

3. Codis-Config ：

是 Codis 的集成管理工具，支持添加 / 刪除 Redis 節點、添加 / 刪除 Proxy 節點、以及發起數據遷移等操作，Codis-config 還自帶了 http server，會啟動 dashboard，用戶可以在 WEB 上監控 Codis 集群的狀態。

4. Codis-Server：

是 Codis 項目維護的一個 Redis 分支，基于 redis-2.8.21 分支開發，增加了額外的數據結構，以支持 slot 有關的操作以及數據遷移指令。

5.Pre-Sharding 技術

Codis 采用 Pre-Sharding 的技術來實現數據的分片, 默認分成 1024 個 slots (0-1023), 對于每個 key 來說, 通過以下公式確定所屬的 Slot Id : SlotId = crc32(key) % 1024，每一個 slot 都會有一個特定的 server group id 來表示這個 slot 的數據由哪個 server group 來提供。

在 2016 年 6 月左右，我們引進了 Codis（當時版本是 3.0，并沒有 Redis-Sentinel、Codis-fe 等組件，1 年后，才升級到 3.2 的，文章主要以 3.0 版本為背景），首先介紹一下基礎環境。

系統架構

在公司硬件資源有限條件下，我們計劃用 6 臺服務器部署 Codis，簡單分了兩層，Codis-Proxy 層和 Codis-Server 層。

1. Codis-Proxy 層用了三臺配置相對較低服務器，部署了 ZooKeeper、Codis-Proxy、Keepalived、LVS 等 ，3 個節點都做了負載均衡。
2. Codis-Server 層用來三臺配置相對較高的服務器，并用 SSD，3 個 Codis-group，每個 group 有一主一從，交叉部署，每個主從分配 30G 內存。

我們分別通過 jredis 編寫測試程序和使用 redis-benchmark 工具模擬壓力測試（請求量：1000 萬~1 億，并發數：1000~50000，長度：固定 / 可變）：

• 在性能方面：基本上能達到我們的預期，理想情況 Codis 性能值能達到 50~60K OP/S，各個 codis-group 中 master-slave 實例數據能實時同步，詳情可以參考《Codis 高可用集群性能測試報告 _20160315》。
• 數據一致性問題：一方面，Codis 的 HA 并不能保證數據完全不丟失，由于 M-S 是異步復制，當 master 節點異常或崩潰，將 slave 切換成 master 后，剛剛沒來得及同步的數據就會丟失。另一方面，Codis 支持的 mget/mset 命令是無法保證單點時的原子語義的，如果 mset 指定 KEY 分布在不同 slot 上，從而導致 KEY 在不同機器上，造成要不一起成功，不要一起失敗。所以對于分布式事務的問題，這是一個痛點。在實際場景中，也有人使用了 lua 腳本以擴展 Redis 的功能，雖然 Codis 支持，但是并不保證你的腳本操作的數據是否在正確的節點執行，僅僅起到一個轉發功能。如果你并不能保證 lua 操作的 KEY 是否在同一個機器上，Codis 只能將這個腳本分配到參數列表中的第一個 key 的機器上執行。
• 不支持命令列表，參考
• https://github.com/CodisLabs/codis/blob/release3.2/doc/unsupported_cmds.md
• Redis 修改部分（增加若干指令），參考
• https://github.com/CodisLabs/codis/blob/release3.2/doc/redis_change_zh.md

倔強的青銅

于是組織研發同事進行多次分析討論，并提出了對緩存服務進行接口改造，經過 2 個多月的辛勞，取得了很大進展，讓我們 Codis 項目順利上線邁開了重要一步，打斷一下，容我在此特別感謝一下同事王慧，在他的主導下，完成公司絕大部分緩存服務接口改造工作。

幾點改造思路

1. 緩存服務分類。

• 針對業務緩存服務不容許數據丟失，在現有的邏輯中，Codis 和數據庫都會保留，優先從 Codis 讀取，如讀取不到時，會從后端數據庫里讀取。
• 針對車次、合作方緩存服務，由于數據量大，拉取頻率高的數據，只會從 Codis 里讀取。

2. 對緩存服務進行接口改造，新增基礎緩存服務層，將生產的 Redis/Codis 相關的服務納入基礎緩存服務進行統一管理。

• 制定一套標準 KEY 命名、管理規范，包括數據類型的選擇、長度、過期時間等。我們會統一在后臺管理系統公示，限定新數據的規則，限制一切不合規范的行為。
• 在基礎緩存服務層，對部分 Codis 不支持的命令進行改寫，規范 Redis/Codis 日常操作。
• 統計熱點數據，維護熱點數據，在基礎緩存服務層上假設二級緩存，作為熱點數據的快速通道。

3.SLOT 的分配

哈希算法

Codis 采用 Pre-sharding 的技術來實現數據的分片, 默認分成 1024 個 slots (0-1023), 對于每個 key 來說, 通過以下公式確定所屬的 Slot Id : SlotId = crc32(key) % 1024。例如 pub_cty_ct018 根據算法得出的值是 997。

key 值重定向分配

比如你有一個腳本是操作某個用戶的多個信息，如 uid1age，uid1sex，uid1name 形如此類的 key，如果你不用 hashtag 的話，這些 key 可能會分散在不同的機器上，如果使用了 hashtag(用花括號擴住計算 hash 的區域)：{uid1}age，{uid1}sex，{uid1}name，這樣就保證這些 key 分布在同一個機器上。這個是 twemproxy 引入的一個語法，我們這邊也支持了。

以 pub_cty 為例，通過 crc32hash 算法得出，key 存放在 237 slot 中，類似測試了{pub_cty}_ct01，{pub_cty}_ct02…{pub_cty}_ctnn 都存放在 237 slot 中。第一，有了 hashtag 算法支持，我們可以對特定需求的 key 做一些特需的規劃，將這些特殊的 key 有序的存放在 codis slot 中，保證 mget/mset, 以及 lua 腳本正常執行。我們目前大概管理 200 多個 redis 鍵，統一鎖定到一個 codis-server（slot）中。第二，在某些極端情況（不希望發生），如某 codis-group 中的 master 異常或崩潰時，我們從程序設計角度，盡可能對出現的無法進行操作 KEY 的行為做一些 " 某種意義上 " 保護。譬如，當某 codis-group 的 maser 宕機時，對 codis 進行寫操作，如果對應的 key 落到宕機的主機上，會得到異常或者錯誤，可以通過捕獲異常信息，將異常的 key 通過改變 key 名的規則將其存放到其他 codis-group 上。同理，如果是讀取宕機主機上的 key 數據時，將其引導到調整后的 key 上，在一定程度上保障 codis 的完整性（不保障數據不丟失，只保證業務系統操作緩存數據完整性）。

有點意思的整改

在長達幾年的迭代演變過程中，維護團隊推動多次緩存服務架構的升級與優化，緩存服務逐漸完善和穩定。 記下了一些“有點意思”的整改，提供大家參考。

熱點數據

統計緩存熱點數據，在基礎緩存服務層上假設二級緩存，作為熱點數據的快速通道，具備可動態獲取，最快訪問，少變化的特點 。

根據緩存服務各主、子鍵關系，使用 index_{主鍵}的方式來作為管理主子鍵關系的 SortedSet 集合，統計數據的使用頻率，抽取 Top100 的數據，作為熱點數據。對這批數據進行分析，結合數據的改動頻率，制定這批數據緩存在內存中的時長。

二級緩存設計

緩存數據列表生成與維護

內存緩存數據的 key 列表由緩存服務生成和維護，Key 列表包括后臺手動配置（如，10 個）和系統根據使用熱度生成（如，20 個）共同組成，其中 cache-manager 的 jar 包只負責對該數據使用，通過定時任務獲取 codis 中的前 20 位和后臺手動配置的相關數據，期間要保證獲取到數據的有效性。

維護本地內存中的數據

自然統計內存緩存：用 sortedSet 集合，統計各主鍵下的所有鍵 Get 的次數，匯總成 score_{主鍵}方式的集合。利用 ZIncrby 命令統計對應的子鍵的次數，最終匯總每個主鍵，統計出 Top100 的 key，利用 zunionstore 命令將信息統計匯總作為內存緩存的基礎，此集合內數據均從內存中獲取。

管理類內存緩存：分析和統計項目主流程的關鍵的基礎緩存數據保存到內存中, 保障對應區域的數據獲取與緩存時間，在離開數據源后能夠最大程度的展現暢途網的功能。

在發生手動更新時，對內存中對應的主鍵進行更新

在發生更新時，由后臺發起，在緩存服務向 codis 中置入標志位，各客戶端在定時任務中獲取標志位，如果標志位（cache_memory_update_flag）為 Y，則清空內存和 Key 規則表，等到下一個更新周期來臨重新獲取數據。

總結

多年后，再回想年少時的迷茫和執著，或許原因都記不得了。青春就是讓你張揚的笑，也給你莫名的痛。——林語堂《人生不過如此》

經過大半年的時間測試、緩存服務接口改造，在 2016 年 9 月份，趕在國慶前，我們的 Codis3.0 上線了，在車次查詢等方面，有了質的飛越，尤其節假日或高峰期期間，平滑的擴縮容、數據遷移、高可用等方面展示出巨大優勢。

三個 codis_proxy 節點的均衡情況：

1 年后，2018 年 8~9 月份，我們將 Codis 升級到 3.2 的，由之前 6 臺服務器，擴展到 7 臺，實際上多一臺 Codis-web 節點，獨立承擔 Codis-fe、Codis-dashboard 等組件。對于 Redis-Sentinel、Codis-fe 等組件的引進，解決了運維人員很多問題，在此不再描述，有興趣的可以參考。

https://github.com/CodisLabs/codis/blob/3.2.2/doc/tutorial_zh.md

目前 Codis 作為暢途網最為核心的緩存層，一如既往的穩定輸出，肩負起它的神圣使命！