干干人人,夜夜骚av,www.亚洲精品

Redis集群架構模式概述，引領我們穿越在數據存儲的未知之旅

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

一、主從模式

1、簡介

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

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

2、工作機制

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

缺點： 主節點唯一，主節點宕機導致Redis無法提供寫服務。

二、哨兵模式

1、簡介

哨兵模式解決主從模式的單點故障問題，通過監控Redis集群狀態實現高可用性：

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

2、工作機制

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

3、注意

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

三、Cluster模式

1、簡介

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

2、工作機制

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

3、cluster集群優點

多個Redis節點網絡互聯，數據共享
所有節點一主一從，支持在線增加、刪除節點

4、cluster集群缺點

不支持同時處理多個key（如MSET/MGET），因為redis需要把key均勻分布在各個節點上，
并發量很高的情況下同時創建key-value會降低性能并導致不可預測的行為

四、代理模式

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

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

對比：

Redis集群架構模式概述，引領我們穿越在數據存儲的未知之旅

1、Twemproxy

（1）工作機制

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

Redis集群架構模式概述，引領我們穿越在數據存儲的未知之旅

（2）缺點

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

（3）不支持的命令

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

2、Codis

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

（1）工作機制

Codis包含如下組件

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

Redis集群架構模式概述，引領我們穿越在數據存儲的未知之旅

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

（2）優點

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

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

（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之前，代理層是實現Redis集群的首選方案。其中，Twemproxy和Codis是兩個常見的代理工具。然而，Twemproxy存在一些限制，如不支持阻塞命令、事務、發布訂閱等，且沒有直接支持Redis高可用。之后有了 redis cluster后，Predixy是比較靠譜的代理方案。