Redis，不僅是數(shù)據(jù)存儲，更是架構(gòu)的藝術(shù)。從主從到哨兵、再到Cluster，每個模式都有著獨特的優(yōu)勢。而代理模式，則是應(yīng)對大規(guī)模場景的得力助手。這是一場探險，Redis引領(lǐng)我們穿越在數(shù)據(jù)存儲的未知之旅。本文先簡略介紹Redis的幾種架構(gòu)模式，后續(xù)合集再逐一進行詳細介紹部署、使用及原理。

一、主從模式

1、簡介

主從模式是Redis架構(gòu)中最簡單的模式之一，分為主數(shù)據(jù)庫master和從數(shù)據(jù)庫slave兩類,主要特點如下：

• 主數(shù)據(jù)庫支持讀寫操作，數(shù)據(jù)變化時自動同步給從數(shù)據(jù)庫。
• 從數(shù)據(jù)庫通常為只讀，接收主數(shù)據(jù)庫同步的數(shù)據(jù)。
• 一個主數(shù)據(jù)庫可以擁有多個從數(shù)據(jù)庫，但一個從數(shù)據(jù)庫只能對應(yīng)一個主數(shù)據(jù)庫。
• 從數(shù)據(jù)庫宕機不影響其他從數(shù)據(jù)庫和主數(shù)據(jù)庫的讀操作，重新啟動后同步數(shù)據(jù)。
• 主數(shù)據(jù)庫宕機不影響從數(shù)據(jù)庫的讀，但Redis不再提供寫服務(wù)，重啟后重新提供寫服務(wù)。
• 主數(shù)據(jù)庫宕機后，不會在從數(shù)據(jù)庫中重新選取主數(shù)據(jù)庫。

2、工作機制

當(dāng)從數(shù)據(jù)庫啟動時，主動向主數(shù)據(jù)庫發(fā)送SYNC命令。主數(shù)據(jù)庫接收SYNC命令后，在后臺保存快照（RDB持久化）和緩存保存快照期間的命令，然后將保存的快照文件和緩存的命令發(fā)送給從數(shù)據(jù)庫。從數(shù)據(jù)庫收到后加載快照文件和執(zhí)行緩存的命令。復(fù)制初始化后，主數(shù)據(jù)庫每次收到寫命令都會同步發(fā)送給從數(shù)據(jù)庫，確保主從數(shù)據(jù)一致性。

缺點： 主節(jié)點唯一，主節(jié)點宕機導(dǎo)致Redis無法提供寫服務(wù)。

二、哨兵模式

1、簡介

哨兵模式解決主從模式的單點故障問題，通過監(jiān)控Redis集群狀態(tài)實現(xiàn)高可用性：

• Sentinel模式建立在主從模式基礎(chǔ)上。
• 當(dāng)主節(jié)點宕機，Sentinel選擇一個從節(jié)點作為新主節(jié)點，修改配置文件。
• 主節(jié)點重新啟動后成為從節(jié)點。
• Sentinel形成集群，相互監(jiān)控，防止單點故障。
• Sentinel不與Redis部署在同一臺機器，以防Redis服務(wù)器宕機導(dǎo)致Sentinel也宕機。

2、工作機制

• 每個Sentinel每秒向所知的主、從和其他Sentinel實例發(fā)送PING命令。
• 如果實例距離上次有效回復(fù)PING超過設(shè)定時間，則被標(biāo)記為主觀下線。
• 當(dāng)主觀下線后，所有Sentinel每秒確認一次，滿足條件則標(biāo)記為客觀下線。
• Sentinel以10秒一次的頻率向已知的所有主、從發(fā)送INFO命令。
• 主被標(biāo)記為客觀下線后，向下線主的從發(fā)送INFO命令頻率提高。
• 若沒有足夠Sentinel同意主已下線，客觀下線狀態(tài)移除。
• 若主重新響應(yīng)PING，主觀下線狀態(tài)移除。

3、注意

客戶端不直接連接Redis，連接Sentinel的IP和端口，由Sentinel提供可用Redis實例。避免主節(jié)點宕機時Sentinel感知并提供新主節(jié)點。

三、Cluster模式

1、簡介

哨兵模式基本可以滿足一般生產(chǎn)的需求，具備高可用性。但是當(dāng)數(shù)據(jù)量過大到一臺服務(wù)器存不下的情況時，主從模式或sentinel模式就不能滿足需求了，這個時候需要對存儲的數(shù)據(jù)進行分片，將數(shù)據(jù)存儲到多個Redis實力中，cluster模式的出現(xiàn)就是為了解決單機Redis容量有限的問題，將Redis的數(shù)據(jù)根據(jù)一定的規(guī)則分配到多臺機器。

2、工作機制

cluster可以說是sentinal和主從模式的結(jié)合體，通過cluster可以實現(xiàn)主從和master重選功能，所以如果配置兩個副本三個分片的話，就需要六個Redis實例。因為Redis的數(shù)據(jù)是根據(jù)一定規(guī)則分配到cluster的不同機器的，當(dāng)數(shù)據(jù)量過大時，可以新增機器進行擴容。
使用集群，只要將redis配置文件中的cluster-enable配置打開即可。每個集群中至少需要3個主數(shù)據(jù)庫才能正常運行，新增節(jié)點非常方便。

3、cluster集群優(yōu)點

• 多個Redis節(jié)點網(wǎng)絡(luò)互聯(lián)，數(shù)據(jù)共享
• 所有節(jié)點一主一從，支持在線增加、刪除節(jié)點

4、cluster集群缺點

• 不支持同時處理多個key（如MSET/MGET），因為redis需要把key均勻分布在各個節(jié)點上，
• 并發(fā)量很高的情況下同時創(chuàng)建key-value會降低性能并導(dǎo)致不可預(yù)測的行為

四、代理模式

目前比較流行的代理框架如下 ：

• twemproxy：快速、輕量級memcached和redis代理，Twitter推特公司開發(fā)
• codis：redis集群代理解決方案，豌豆莢公司開發(fā)，需要修改redis源碼
• predixy：高性能全特征redis代理，支持Redis Sentinel和Redis Cluster
• Redis-cerberus: Redis Cluster代理

對比：

1、Twemproxy

（1）工作機制

Twemproxy是一種代理分片機制，由Twitter開源。Twemproxy作為代理，可接受來自多個程序的訪問，按照路由規(guī)則，轉(zhuǎn)發(fā)給后臺的各個Redis服務(wù)器，再原路返回。該方案很好的解決了單個Redis實例承載能力的問題。通過Twemproxy可以使用多臺服務(wù)器來水平擴張redis服務(wù)，可以有效的避免單點故障問題。

（2）缺點

• Twemproxy本身也是單點（需要用Keepalived做高可用方案）
• 使用Twemproxy需要更多的硬件資源和在redis性能有一定的損失（twitter測試約20%）

（3）不支持的命令

見https://github.com/twitter/twemproxy/blob/master/notes/redis.md。

2、Codis

Codis 是一個分布式 Redis 解決方案, 對于上層的應(yīng)用來說，連接到 Codis Proxy 和連接原生的 RedisServer 沒有明顯的區(qū)別 (部分命令不支持），上層應(yīng)用可以像使用單機的 Redis 一樣使用，Codis 底層會處理請求的轉(zhuǎn)發(fā)，不停機的數(shù)據(jù)遷移等工作，所有后邊的一切事情，對于前面的客戶端來說是透明的，可以簡單的認為后邊連接的是一個內(nèi)存無限大的 Redis 服務(wù)。

（1）工作機制

Codis包含如下組件

• Codis Proxy (codis-proxy)
• Codis Manager (codis-config)
• Codis Redis (codis-server)
• ZooKeeper

• codis-proxy：無縫連接的Redis代理服務(wù)
  客戶端連接的Redis代理服務(wù)，實現(xiàn)了Redis協(xié)議，表現(xiàn)與原生Redis幾乎無差異（類似Twemproxy）。
  業(yè)務(wù)可部署多個codis-proxy，這些代理是無狀態(tài)的。
• codis-config：Codis的智能管理工具
  作為Codis的管理工具，支持諸如添加/刪除Redis節(jié)點、添加/刪除Proxy節(jié)點、發(fā)起數(shù)據(jù)遷移等操作。
  內(nèi)置HTTP服務(wù)器，啟動一個Dashboard，用戶可通過瀏覽器實時觀察Codis集群的運行狀態(tài)。
• codis-server：Codis項目的特制Redis分支
  基于Redis 2.8.13開發(fā)，加入了對slot的支持和原子的數(shù)據(jù)遷移指令。
  Codis的上層組件codis-proxy和codis-config只能與這個特定版本的Redis交互才能正常運行。
• Codis項目依賴ZooKeeper存儲數(shù)據(jù)路由表和codis-proxy節(jié)點的元信息。通過ZooKeeper，codis-config發(fā)起的命令能夠同步到所有存活的codis-proxy，確保集群的協(xié)同工作。
• Codis不僅僅是一個擴展，更是智能的擴展。它支持按照Namespace區(qū)分不同的產(chǎn)品，每個產(chǎn)品擁有獨特的product name，配置互不沖突。Codis讓Redis的擴展變得輕松而智能

（2）優(yōu)點

Codis項目為Redis提供了智能而強大的擴展功能，其顯著特點如下：

• 自動平衡：Codis自動平衡數(shù)據(jù)，確保每個節(jié)點負載均衡，提升系統(tǒng)性能。
• 簡單易用：使用起來非常簡單，無需繁瑣的配置，即可享受Codis的強大功能。
• 圖形化面板和管理工具：Codis提供直觀的圖形化面板和管理工具，使集群管理變得輕松而高效。
• 支持絕大多數(shù)Redis命令：完全兼容twemproxy，支持Redis豐富的命令集，確保平滑遷移。
• Redis原生客戶端支持：與Redis原生客戶端完美兼容，保障業(yè)務(wù)的穩(wěn)定連接。
• 安全透明的數(shù)據(jù)移植：數(shù)據(jù)移植安全可靠，輕松添加或刪除節(jié)點，保持?jǐn)?shù)據(jù)的穩(wěn)定遷移。
• 命令行接口：提供命令行接口，方便開發(fā)人員進行更精細的操作和管理。
• RESTful API：強大的RESTful API，使開發(fā)者能夠靈活地進行集群管理，提升整體運維效率。

（3）不支持的命令

KEYS, MOVE, OBJECT, RENAME, RENAMENX, SORT, SCAN, BITOP,MSETNX, BLPOP, BRPOP,
 BRPOPLPUSH, PSUBSCRIBE，PUBLISH, PUNSUBSCRIBE, SUBSCRIBE, UNSUBSCRIBE, 
DISCARD, EXEC, MULTI, UNWATCH, WATCH, SCRIPT EXISTS, SCRIPT FLUSH, 
SCRIPT KILL, SCRIPT LOAD, AUTH, ECHO, SELECT, BGREWRITEAOF, BGSAVE, 
CLIENT KILL, CLIENT LIST, CONFIG GET, CONFIG SET, CONFIG RESETSTAT, 
DBSIZE, DEBUG OBJECT, DEBUG SEGFAULT, FLUSHALL, FLUSHDB, INFO, LASTSAVE,
 MONITOR, SAVE, SHUTDOWN, SLAVEOF, SLOWLOG, SYNC, TIME

詳情請參考：https://github.com/CodisLabs/codis
https://github.com/CodisLabs/codis/blob/master/doc/tutorial_zh.md。

3、predixy

在Redis3.0版本引入RedisCluster之前，代理層是實現(xiàn)Redis集群的首選方案。其中，Twemproxy和Codis是兩個常見的代理工具。然而，Twemproxy存在一些限制，如不支持阻塞命令、事務(wù)、發(fā)布訂閱等，且沒有直接支持Redis高可用。之后有了 redis cluster后，Predixy是比較靠譜的代理方案。

（1）Predixy工作機制

Predixy是一個強大的代理工具，同時支持Redis Sentinel和Redis Cluster：

• 后端為Redis Sentinel監(jiān)控的一組Redis，功能與原始Redis完全相同。
• 后端為Redis Sentinel監(jiān)控的多組Redis，部分功能受限。
• 后端為Redis Cluster，功能與Redis Cluster相同。

（2）Predixy特點

Predixy擁有多項特點，使其成為強大而靈活的代理工具，主要特點如下：

• 高性能且輕量級。
• 支持多線程。
• 跨平臺支持：Linux、OSX、BSD、Windows。
• 兼容Redis Sentinel，可配置一組或多組Redis。
• 兼容Redis Cluster。
• 支持阻塞型命令（blpop、brpop、brpoplpush）。
• 支持scan命令，無論是單個Redis還是多個Redis實例。
• 多key命令支持：mset/msetnx/mget/del/unlink/touch/exists。
• 支持Redis的多數(shù)據(jù)庫，即可以使用select命令。
• 事務(wù)支持，目前僅限于Redis Sentinel下單一Redis組可用。
• 腳本支持，包括命令：script load、eval、evalsha。
• 支持發(fā)布訂閱機制，即Pub/Sub系列命令。
• 多數(shù)據(jù)中心支持，讀寫分離。
• 擴展的AUTH命令，強大的權(quán)限控制和鍵空間限制。
• 日志可按級別采樣輸出，異步日志記錄避免線程被io阻塞
• 日志文件可以按時間、大小自動切分。
• 豐富的統(tǒng)計信息，包括CPU、內(nèi)存、請求、響應(yīng)等。
• 延遲監(jiān)控信息，可查看整體延遲以及后端Redis實例的延遲。
• Predixy的全面特性使其成為一個強大的選擇，為Redis集群提供了廣泛的支持和靈活的管理

五、小結(jié)

本期為概述內(nèi)容，參考多個文檔并修改其中錯誤內(nèi)容，后續(xù)具體各架構(gòu)詳情將在合集中詳細演示。