摘要：什么是一個分布式解決方案，多個節(jié)點構成的集群上層應用可以像使用單機的一樣使用，底層會處理請求的轉發(fā)，不停機的數(shù)據(jù)遷移等工作實例的計算能力匯集到一起，從而完成關于大數(shù)據(jù)和高并發(fā)量的的讀寫操作組成部分，處理客戶端請求，支持協(xié)議，因此客戶端訪問

一個分布式 Redis 解決方案，多個 Redis 節(jié)點構成的集群

上層應用可以像使用單機的 Redis 一樣使用，Codis 底層會處理請求的轉發(fā)，不停機的數(shù)據(jù)遷移等工作

Redis 實例的CPU計算能力匯集到一起，從而完成關于大數(shù)據(jù)和高并發(fā)量的的讀寫操作

Codis Proxy (codis-proxy)，處理客戶端請求，支持Redis協(xié)議，因此客戶端訪問Codis Proxy跟訪問原生Redis沒有什么區(qū)別；

Codis Dashboard (codis-config)，Codis 的管理工具，支持添加/刪除 Redis 節(jié)點、添加/刪除 Proxy 節(jié)點，發(fā)起數(shù)據(jù)遷移等操作。codis-config 本身還自帶了一個 http server，會啟動一個 dashboard，用戶可以直接在瀏覽器上觀察 Codis 集群的運行狀態(tài)；

Codis Redis (codis-server)，Codis 項目維護的一個 Redis 分支，基于 2.8.21 開發(fā)，加入了 slot 的支持和原子的數(shù)據(jù)遷移指令；

ZooKeeper/Etcd，Codis 依賴 ZooKeeper 來存放數(shù)據(jù)路由表和 codis-proxy 節(jié)點的元信息，codis-config 發(fā)起的命令都會通過 ZooKeeper 同步到各個存活的 codis-proxy；

codis-ha，通過codis開放的api實現(xiàn)自動切換主從的工具。該工具會在檢測到master掛掉的時候將其下線并選擇其中一個slave提升為master繼續(xù)提供服務

生產環(huán)境部署：

1024個slot，落到64個group，每臺服務器包含8個group

一個codis集群 = 8臺物理機 = 8臺物理機 （每臺：8個group）= 64個group (每個group：16個slot) = 1024個slot

一臺物理機運行16個Redis實例，2個Redis一個Group，一臺master，一臺slave

一個Master可以有多個Slaves，主流是一主二仆

默認配置下，master節(jié)點可以進行讀和寫，slave節(jié)點只能進行讀操作，寫操作被禁止

不要修改配置讓slave節(jié)點支持寫操作，沒有意義，原因一，寫入的數(shù)據(jù)不會被同步到其他節(jié)點；原因二，當master節(jié)點修改同一條數(shù)據(jù)后，slave節(jié)點的數(shù)據(jù)會被覆蓋掉

slave節(jié)點掛了不影響其他slave節(jié)點的讀和master節(jié)點的讀和寫，重新啟動后會將數(shù)據(jù)從master節(jié)點同步過來

master節(jié)點掛了以后，不影響slave節(jié)點的讀，Redis將不再提供寫服務，master節(jié)點啟動后Redis將重新對外提供寫服務。

master節(jié)點掛了以后，不會slave節(jié)點重新選一個master（缺點）

sentinel模式是建立在主從模式的基礎上，如果只有一個Redis節(jié)點，sentinel就沒有任何意義

當master節(jié)點掛了以后，sentinel會在slave中選擇一個做為master，并修改它們的配置文件，其他slave的配置文件也會被修改，比如slaveof屬性會指向新的master

當master節(jié)點重新啟動后，它將不再是master而是做為slave接收新的master節(jié)點的同步數(shù)據(jù)

sentinel因為也是一個進程有掛掉的可能，所以sentinel也會啟動多個形成一個sentinel集群

當主從模式配置密碼時，sentinel也會同步將配置信息修改到配置文件中，不許要擔心

一個sentinel或sentinel集群可以管理多個主從Redis

sentinel最好不要和Redis部署在同一臺機器，不然Redis的服務器掛了以后，sentinel也掛了

sentinel監(jiān)控的Redis集群都會定義一個master名字，這個名字代表Redis集群的master Redis

缺點：

主從服務器的數(shù)據(jù)要經常進行主從復制，這樣造成性能下降

當主服務器宕機后，從服務器切換成主服務器的那段時間，服務是不能用的

Codis會把所有的key分成1024個槽，這1024個槽對應著的就是Redis的集群，這個在Codis中是會在內存中維護著這1024個槽與Redis實例的映射關系。這個槽是可以配置，可以設置成 2048 或者是4096個

key的分配算法，先是把key進行CRC32 后，得到一個32位的數(shù)字，然后再hash%1024后得到一個余數(shù)，這個值就是這個key對應著的槽，這槽后面對應著的就是redis的實例

//Codis中Key的算法
    hash = crc32(command.key)
    slot_index = hash % 1024
    redis = slots[slot_index].redis
    redis.do(command)

擴容Redis實例步驟：新增Redis配置 => 啟動新的Redis => 新建Group，將reids添加進來 => 數(shù)據(jù)遷移

數(shù)據(jù)遷移步驟：

1、服務slot_1的group原為group 1，codis-config 現(xiàn)發(fā)起遷移指令 pre_migrate slot_1 to group 2，將slot_1狀態(tài)標記為”pre_migrate”；
2、等待所有的proxy回復收到遷移指令；
3、將slot_1狀態(tài)標記為”migrating”，服務slot_1的server group改為group2
4、codis-config不斷發(fā)送SLOTSMGRT命令給group1的redis ，直到slot_1所有的key遷移完成；
5、遷移過程中, 如果請求 slot_1 的 key 數(shù)據(jù), proxy 會將請求轉發(fā)到group2上, proxy會先在group1上強行執(zhí)行一次 MIGRATE key 將這個鍵值提前遷移過來. 然后再到group2上正常讀取
6、將slot_1狀態(tài)標記為”online”

slot_index = crc32(command.key) % 1024
if slot_index in migrating_slots:
    do_migrate_key(command.key)  # 強制執(zhí)行遷移
    redis = slots[slot_index].new_redis
else:
    redis = slots[slot_index].redis
redis.do(command)

自動均衡策略：Codis 會在機器空閑的時候，觀察Redis中的實例對應著的slot數(shù)，如果不平衡的話就會自動進行遷移

pipeline通過減少客戶端與redis的通信次數(shù)來實現(xiàn)降低往返延時時間，而且Pipeline 實現(xiàn)的原理是隊列，而隊列的原理是時先進先出，這樣就保證數(shù)據(jù)的順序性

原生批量命令(例如mget,mset等)是原子性,Pipeline是非原子性的

原生批量命令是一個命令對應多個key,Pipeline支持多個命令

原生批量命令是Redis服務端支持實現(xiàn)的,而Pipeline需要服務端與客戶端的共同實現(xiàn)