一、常見使用方式

Redis 的幾種常見使用方式包括：

1、Redis 單副本

Redis 單副本，采用單個(gè) Redis 節(jié)點(diǎn)部署架構(gòu)，沒有備用節(jié)點(diǎn)實(shí)時(shí)同步數(shù)據(jù)，不提供數(shù)據(jù)持久化和備份策略，適用于數(shù)據(jù)可靠性要求不高的純緩存業(yè)務(wù)場景。

優(yōu)點(diǎn)：

架構(gòu)簡單，部署方便；

高性價(jià)比：緩存使用時(shí)無需備用節(jié)點(diǎn)（單實(shí)例可用性可以用 supervisor 或 crontab 保證），當(dāng)然為了滿足業(yè)務(wù)的高可用性，也可以犧牲一個(gè)備用節(jié)點(diǎn)，但同時(shí)刻只有一個(gè)實(shí)例對外提供服務(wù)；

高性能。

缺點(diǎn)：

不保證數(shù)據(jù)的可靠性；

在緩存使用，進(jìn)程重啟后，數(shù)據(jù)丟失，即使有備用的節(jié)點(diǎn)解決高可用性，但是仍然不能解決緩存預(yù)熱問題，因此不適用于數(shù)據(jù)可靠性要求高的業(yè)務(wù)；

高性能受限于單核 CPU 的處理能力（Redis 是單線程機(jī)制），CPU 為主要瓶頸，所以適合操作命令簡單，排序、計(jì)算較少的場景。也可以考慮用 Memcached 替代。

2、Redis 多副本（主從）

Redis 多副本，采用主從（replication）部署結(jié)構(gòu)，相較于單副本而言最大的特點(diǎn)就是主從實(shí)例間數(shù)據(jù)實(shí)時(shí)同步，并且提供數(shù)據(jù)持久化和備份策略。主從實(shí)例部署在不同的物理服務(wù)器上，根據(jù)公司的基礎(chǔ)環(huán)境配置，可以實(shí)現(xiàn)同時(shí)對外提供服務(wù)和讀寫分離策略。

優(yōu)點(diǎn)：

高可靠性：一方面，采用雙機(jī)主備架構(gòu)，能夠在主庫出現(xiàn)故障時(shí)自動(dòng)進(jìn)行主備切換，從庫提升為主庫提供服務(wù)，保證服務(wù)平穩(wěn)運(yùn)行；另一方面，開啟數(shù)據(jù)持久化功能和配置合理的備份策略，能有效的解決數(shù)據(jù)誤操作和數(shù)據(jù)異常丟失的問題；

讀寫分離策略：從節(jié)點(diǎn)可以擴(kuò)展主庫節(jié)點(diǎn)的讀能力，有效應(yīng)對大并發(fā)量的讀操作。

缺點(diǎn)：

故障恢復(fù)復(fù)雜，如果沒有 RedisHA 系統(tǒng)（需要開發(fā)），當(dāng)主庫節(jié)點(diǎn)出現(xiàn)故障時(shí)，需要手動(dòng)將一個(gè)從節(jié)點(diǎn)晉升為主節(jié)點(diǎn)，同時(shí)需要通知業(yè)務(wù)方變更配置，并且需要讓其它從庫節(jié)點(diǎn)去復(fù)制新主庫節(jié)點(diǎn)，整個(gè)過程需要人為干預(yù)，比較繁瑣；

主庫的寫能力受到單機(jī)的限制，可以考慮分片；

主庫的存儲(chǔ)能力受到單機(jī)的限制，可以考慮 Pika；

原生復(fù)制的弊端在早期的版本中也會(huì)比較突出，如：Redis 復(fù)制中斷后，Slave 會(huì)發(fā)起 psync，此時(shí)如果同步不成功，則會(huì)進(jìn)行全量同步，主庫執(zhí)行全量備份的同時(shí)可能會(huì)造成毫秒或秒級的卡頓；又由于 COW 機(jī)制，導(dǎo)致極端情況下的主庫內(nèi)存溢出，程序異常退出或宕機(jī)；主庫節(jié)點(diǎn)生成備份文件導(dǎo)致服務(wù)器磁盤 IO 和 CPU（壓縮）資源消耗；發(fā)送數(shù) GB 大小的備份文件導(dǎo)致服務(wù)器出口帶寬暴增，阻塞請求，建議升級到最新版本。

3、Redis Sentinel（哨兵）

Redis Sentinel 是社區(qū)版本推出的原生高可用解決方案，其部署架構(gòu)主要包括兩部分：Redis Sentinel 集群和 Redis 數(shù)據(jù)集群。

其中 Redis Sentinel 集群是由若干 Sentinel 節(jié)點(diǎn)組成的分布式集群，可以實(shí)現(xiàn)故障發(fā)現(xiàn)、故障自動(dòng)轉(zhuǎn)移、配置中心和客戶端通知。Redis Sentinel 的節(jié)點(diǎn)數(shù)量要滿足 2n+1（n>=1）的奇數(shù)個(gè)。

優(yōu)點(diǎn)：

Redis Sentinel 集群部署簡單；

能夠解決 Redis 主從模式下的高可用切換問題；

很方便實(shí)現(xiàn) Redis 數(shù)據(jù)節(jié)點(diǎn)的線形擴(kuò)展，輕松突破 Redis 自身單線程瓶頸，可極大滿足 Redis 大容量或高性能的業(yè)務(wù)需求；

可以實(shí)現(xiàn)一套 Sentinel 監(jiān)控一組 Redis 數(shù)據(jù)節(jié)點(diǎn)或多組數(shù)據(jù)節(jié)點(diǎn)。

缺點(diǎn)：

部署相對 Redis 主從模式要復(fù)雜一些，原理理解更繁瑣；

資源浪費(fèi)，Redis 數(shù)據(jù)節(jié)點(diǎn)中 slave 節(jié)點(diǎn)作為備份節(jié)點(diǎn)不提供服務(wù)；

Redis Sentinel 主要是針對 Redis 數(shù)據(jù)節(jié)點(diǎn)中的主節(jié)點(diǎn)的高可用切換，對 Redis 的數(shù)據(jù)節(jié)點(diǎn)做失敗判定分為主觀下線和客觀下線兩種，對于 Redis 的從節(jié)點(diǎn)有對節(jié)點(diǎn)做主觀下線操作，并不執(zhí)行故障轉(zhuǎn)移。

不能解決讀寫分離問題，實(shí)現(xiàn)起來相對復(fù)雜。

建議：

如果監(jiān)控同一業(yè)務(wù)，VPS租用 國內(nèi)服務(wù)器，可以選擇一套 Sentinel 集群監(jiān)控多組 Redis 數(shù)據(jù)節(jié)點(diǎn)的方案，反之選擇一套 Sentinel 監(jiān)控一組 Redis 數(shù)據(jù)節(jié)點(diǎn)的方案。

sentinel monitor

配置中的建議設(shè)置成 Sentinel 節(jié)點(diǎn)的一半加 1，當(dāng) Sentinel 部署在多個(gè) IDC 的時(shí)候，單個(gè) IDC 部署的 Sentinel 數(shù)量不建議超過（Sentinel 數(shù)量 – quorum）。

合理設(shè)置參數(shù)，防止誤切，控制切換靈敏度控制：

a. quorum

b. down-after-milliseconds 30000

c. failover-timeout 180000

d. maxclient

e. timeout

部署的各個(gè)節(jié)點(diǎn)服務(wù)器時(shí)間盡量要同步，否則日志的時(shí)序性會(huì)混亂。

Redis 建議使用 pipeline 和 multi-keys 操作，減少 RTT 次數(shù)，云主機(jī)，提高請求效率。

自行搞定配置中心（zookeeper），方便客戶端對實(shí)例的鏈接訪問。

4、Redis Cluster