Ⅰ redis的分片能存在相同的key嗎
不能。redis的分片採用的是一致性哈希演算法，對於相同的key肯定是能唯一分配到同一個redis-server，而同一個redis-server是不允許有相同key的。
Ⅱ redis使用什麼演算法來解決hash沖突
因為Memcached的哈希策略是在其客戶端實現的，因此不同的客戶端實現也有區別，以Spymemcache、Xmemcache為例，都是使用了KETAMA作為其實現。
因此，我們也可以使用一致性hash演算法來解決Redis分布式這個問題。在介紹一致性hash演算法之前，先介紹一下我之前想的一個方法，怎麼把Key均勻的映射到多台Redis Server上。
Ⅲ redis | 七、redis之Hash
Redis hash 是一個 string 類型的 field（欄位） 和 value（值） 的映射表，hash 特別適合用於存儲對象。
Redis 中每個 hash 可以存儲 232 - 1 鍵值對（40多億）。
hash類型可以理解為map集合，{key1:value1,key2:value2}
實例
Hash 的應用場景：
將一個用戶作為一個 hash ，然後其屬性和值就作為內部的 k-v 集合進行存儲
例如
user:1 代表第 1 個用戶，然後這個用戶具有 name，age，job 這些欄位，因為 redis 效率很高，因此適合將屬性值經常變動的對象作為 hash 存儲
個人理解和便於學習，進行了簡單分類！
分為以下幾類：
下表列出了 redis hash 基本的相關命令：
更多命令請參考： https://redis.io/commands
Ⅳ Redis分布式緩存搭建
花了兩天時間整理了之前記錄的Redis單體與哨兵模式的搭建與使用，又補齊了集群模式的使用和搭建經驗，並對集群的一些個原理做了理解。
筆者安裝中遇到的一些問題：
如果make報錯，可能是沒裝gcc或者gcc++編輯器，安裝之 yum -y install gcc gcc-c++ kernel-devel ，有可能還是提示一些個c文件編譯不過，gcc -v查看下版本，如果不到5.3那麼升級一下gcc：
在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable
scl enable devtoolset-9 bash
重新make clean, make
這回編譯通過了，提示讓你最好make test一下/
執行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test
那就升級tcl， yum install tcl
重新make test，如果還有error就刪了目錄，重新tar包解壓重新make , make test
o/ All tests passed without errors! ，表示編譯成功。
然後make install即可。
直接運行命令： ./redis-server /usr/redis-6.0.3/redis.conf &
redis.conf 配置文件里 bind 0.0.0.0 設置外部訪問， requirepass xxxx 設置密碼。
redis高可用方案有兩種：
常用搭建方案為1主1從或1主2從+3哨兵監控主節點， 以及3主3從6節點集群。
（1）sentinel哨兵
/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &
sentinel2.conf配置：
坑1：master節點也會在故障轉移後成為從節點，也需要配置masterauth
當kill master進程之後，經過sentinel選舉，slave成為了新的master，再次啟動原master，提示如下錯誤：
原因是此時的master再次啟動已經是slave了，需要向現在的新master輸入密碼，所以需要在master.conf
中配置：
坑2：哨兵配置文件要暴露客戶端可以訪問到的master地址
在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置該哨兵對應的master名字、master地址和埠，以及達到多少個哨兵選舉通過認為master掛掉。其中master地址要站在redis訪問者（也就是客戶端）的角度、配置訪問者能訪問的地址，例如sentinel與master在一台伺服器（122.xx.xxx.xxx）上，那麼相對sentinel其master在本機也就是127.0.0.1上，這樣 sentinel monitor mymaster 127.0.0.1 6379 2 邏輯上沒有問題，但是如果另外伺服器上的springboot通過lettuce訪問這個redis哨兵，則得到的master地址為127.0.0.1，也就是springboot所在伺服器本機，這顯然就有問題了。
附springboot2.1 redis哨兵配置：
坑3：要注意配置文件.conf會被哨兵修改
redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。
曾經遇到過這樣一個問題，大致的信息如下
slaves莫名其妙多了一個，master的地址也明明改了真實對外的地址，這里又變成127.0.0.1 !
最後，把5個redis進程都停掉，逐個檢查配置文件，發現redis的配置文件在主從哨兵模式會被修改，master的配置文件最後邊莫名其妙多了一行replicaof 127.0.0.1 7001， 懷疑應該是之前配置錯誤的時候（見坑2）被哨兵動態加上去的！ 總之，實踐中一定要多注意配置文件的變化。
（2）集群
當數據量大到一定程度，比如幾十上百G，哨兵模式不夠用了需要做水平拆分，早些年是使用codis，twemproxy這些第三方中間件來做分片的，即 客戶端 -> 中間件 -> Redis server 這樣的模式，中間件使用一致性Hash演算法來確定key在哪個分片上。後來Redis官方提供了方案，大家就都採用官方的Redis Cluster方案了。
Redis Cluster從邏輯上分16384個hash slot，分片演算法是 CRC16(key) mod 16384 得到key應該對應哪個slot，據此判斷這個slot屬於哪個節點。
每個節點可以設置1或多個從節點，常用的是3主節點3從節點的方案。
reshard，重新分片，可以指定從哪幾個節點移動一些hash槽到另一個節點去。重新分片的過程對客戶端透明，不影響線上業務。
搭建Redis cluster
redis.conf文件關鍵的幾個配置：
啟動6個集群節點
[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]
這時候這6個節點還是獨立的，要把他們配置成集群：
說明： -a xxxx 是因為筆者在redis.conf中配置了requirepass xxxx密碼，然後 --cluster-replicas 1 中的1表示每個master節點有1個從節點。
上述命令執行完以後會有一個詢問： Can I set the above configuration? yes同意自動做好的分片即可。
最後 All 16384 slots covered. 表示集群中16384個slot中的每一個都有至少有1個master節點在處理，集群啟動成功。
查看集群狀態：
坑1：暴露給客戶端的節點地址不對
使用lettuce連接發現連不上，查看日誌 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里邊配置master地址犯的錯誤一樣，集群啟動的時候帶的地址應該是提供給客戶端訪問的地址。
我們要重建集群：先把6個redis進程停掉，然後刪除 nodes-7001.conf 這些節點配置文件，刪除持久化文件 mp.rdb 、 appendonly.aof ，重新啟動6個進程，在重新建立集群：
然後，還是連不上，這次報錯 connection timed out: /172.xx.0.xx:7004 ，發現連到企鵝雲伺服器的內網地址上了！
解決辦法，修改每個節點的redis.conf配置文件，找到如下說明：
所以增加配置：
然後再重新構建集群，停進程、改配置、刪除節點文件和持久化文件、啟動進程、配置集群。。。再來一套（累死了）
重新使用Lettuce測試，這次終於連上了！
坑2：Lettuce客戶端在master節點故障時沒有自動切換到從節點
name這個key在7002上，kill這個進程模擬master下線，然後Lettuce一直重連。我們期望的是應該能自動切換到其slave 7006上去，如下圖：
重新啟動7002進程，
7006已成為新master，7002成為它的slave，然後Lettuce也能連接上了。
解決辦法，修改Lettuce的配置：
筆者用的是springboot 2.1 spring-boot-starter-data-redis 默認的Lettuce客戶端，當使用Redis cluster集群模式時，需要配置一下 RedisConnectionFactory 開啟自適應刷新來做故障轉移時的自動切換從節點進行連接。
重新測試：停掉master 7006，這次Lettuce可以正常切換連到7002slave上去了。（仍然會不斷的在日誌里報連接錯誤，因為需要一直嘗試重連7006，但因為有7002從節點頂上了、所以應用是可以正常使用的）
Redis不保證數據的強一致性
Redis並不保證數據的強一致性，也就是取CAP定理中的AP
關於一致性Hash演算法，可以參考 一致性Hash演算法 - (jianshu.com)
Redis cluster使用的是hash slot演算法，跟一致性Hash演算法不太一樣，固定16384個hash槽，然後計算key落在哪個slot里邊（計算key的CRC16值再對16384取模），key找的是slot而不是節點，而slot與節點的對應關系可以通過reshard改變並通過gossip協議擴散到集群中的每一個節點、進而可以為客戶端獲知，這樣key的節點定址就跟具體的節點個數沒關系了。也同樣解決了普通hash取模演算法當節點個數發生變化時，大量key對應的定址都發生改動導致緩存失效的問題。
比如集群增加了1個節點，這時候如果不做任何操作，那麼新增加的這個節點上是沒有slot的，所有slot都在原來的節點上且對應關系不變、所以沒有因為節點個數變動而緩存失效，當reshard一部分slot到新節點後，客戶端獲取到新遷移的這部分slot與新節點的對應關系、定址到新節點，而沒遷移的slot仍然定址到原來的節點。
關於熱遷移，猜想，內部應該是先做復制遷移，等遷移完了，再切換slot與節點的對應關系，復制沒有完成之前仍按照原來的slot與節點對應關系去原節點訪問。復制結束之後，再刪除原節點上已經遷移的slot所對應的key。
與哨兵模式比較類似，當1個節點發現某個master節點故障了、會對這個故障節點進行pfail主觀宕機，然後會通過gossip協議通知到集群中的其他節點、其他節點也執行判斷pfail並gossip擴散廣播這一過程，當超過半數節點pfail時那麼故障節點就是fail客觀宕機。接下來所有的master節點會在故障節點的從節點中選出一個新的主節點，此時所有的master節點中超過半數的都投票選舉了故障節點的某個從節點，那麼這個從節點當選新的master節點。
所有節點都持有元數據，節點之間通過gossip這種二進制協議進行通信、發送自己的元數據信息給其他節點、故障檢測、集群配置更新、故障轉移授權等等。
這種去中心化的分布式節點之間內部協調，包括故障識別、故障轉移、選主等等，核心在於gossip擴散協議，能夠支撐這樣的廣播協議在於所有的節點都持有一份完整的集群元數據，即所有的節點都知悉當前集群全局的情況。
Redis高可用方案 - (jianshu.com)
面試題:Redis 集群模式的工作原理能說一下么 - 雲+社區 - 騰訊雲 (tencent.com)
深度圖解Redis Cluster原理 - detectiveHLH - 博客園 (cnblogs.com)
Redis學習筆記之集群重啟和遇到的坑-阿里雲開發者社區 (aliyun.com)
雲伺服器Redis集群部署及客戶端通過公網IP連接問題
Ⅳ redis 哈希
redis 哈希的結構為key field value,key和field都不能重復,value可以重復。類似如下結構:
1.獲取、設置、刪除 key
2.判斷field是否存在
3.獲取key field 的數量
4.批量獲取hash key的一批field的對應值
5.批量設置hash key的一批field value
6.hash key的field的value的加法
7.返回hash key 中 對應所有的field和value
8.返回hash key對應所有field的value
9.返回hash key對應所有field
10.設置hash key對應field的value,如果已經存在則失敗
11.hash key的field的value的加法（浮點數）
Ⅵ 演算法簡述：一致性hash環，與redis 槽道原理
1.哈希演算法 對伺服器個數進行模餘存儲，
（下圖）
傳統新增節點 （下圖）
2、哈希環，應用於數據的分布式存儲，在增刪節點之間，能夠盡可能少的遷移數據，保證多數數據的一致性。（下圖）每個節點代表一個數據存儲伺服器。伺服器在通過哈希演算法過後，得到一個固定長度數值a, 由a/65535 模余 得0~65535之間正整數，散列分布在hash環上（下圖）
藍色代表數據，綠色代表數據存儲庫，每個數據存儲庫 管理順時針 ，上個節點之間的區域。（下圖）圖中數字 因該是對65536取余數
在新增節點4 後，只有數據a需要遷移（下圖）
3，槽道原理，綜上所述 ，哈希環減少了 數據在存儲節點增刪 過程中對數據產生的影響。redis 提出的hash槽道，則讓數據遷移變得更為靈活
Ⅶ Redis - 集群Hash槽分配
常見的Redis集群架構是三主三從的結構，為了保證數據分片，redis採用了Hash槽的概念，即:
常見的三主三從結構，將solt平均分到三個節點上
如果存入一個值，按照redis cluster哈希槽的 演算法 ： CRC16('key')384 = 6782。 那麼就會把這個key 的存儲分配到 B 上了。同樣，當我連接(A,B,C)任何一個節點想獲取'key'這個key時，也會這樣的演算法，然後內部跳轉到B節點上獲取數據
新增一個節點D，redis cluster的這種做法是從各個節點的前面各拿取一部分slot到D上，會變成這樣：
同樣刪除一個節點也是類似，移動完成後就可以刪除這個節點了。
Redis的Hash槽分配不是 一致性Hash ，一致性Hash是成一個hash環，當節點加入或者失效的時候，在環上順時針找到對應節點。而Redis集群屬於手動分配 線性Hash槽 ，需要手動指定，並且盡量做到各個節點solt平均分配。
而至於為什麼Redis沒有採用一致性Hash，因為如果一個節點失效，把數據轉移到下一個節點，容易造成緩存雪崩，而採用hash槽+副本節點失效的時候從節點自動接替，不易造成雪崩。
Ⅷ Redis hash槽分配
Redis 集群中內置了 16384 個哈希槽，當需要在 Redis 集群中放置一個 key-value
時，redis 先對 key 使用 crc16 演算法算出一個結果，然後把結果對 16384 求余數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，redis 會根據節點數量大致均等的將哈希槽映射到不同的節點。Redis 集群沒有使用一致性hash, 而是引入了哈希槽的概念。
Redis 集群有16384個哈希槽,每個key通過CRC16校驗後對16384取模來決定放置哪個槽.集群的每個節點負責一部分hash槽。這種結構很容易添加或者刪除節點，並且無論是添加刪除或者修改某一個節點，都不會造成集群不可用的狀態。使用哈希槽的好處就在於可以方便的添加或移除節點。當需要增加節點時，只需要把其他節點的某些哈希槽挪到新節點就可以了；當需要移除節點時，只需要把移除節點上的哈希槽挪到其他節點就行了；在這一點上，我們以後新增或移除節點的時候不用先停掉所有的 redis 服務。
"用了哈希槽的概念，而沒有用一致性哈希演算法，不都是哈希么？這樣做的原因是為什麼呢？
"Redis Cluster是自己做的crc16的簡單hash演算法，沒有用一致性hash。Redis的作者認為它的crc16(key) mod 16384的效果已經不錯了，雖然沒有一致性hash靈活，但實現很簡單，節點增刪時處理起來也很方便。"為了動態增刪節點的時候，不至於丟失數據么？"節點增刪時不丟失數據和hash演算法沒什麼關系，不丟失數據要求的是一份數據有多個副本。「還有集群總共有2的14次方，16384個哈希槽，那麼每一個哈希槽中存的key 和 value是什麼？」當你往Redis Cluster中加入一個Key時，會根據crc16(key) mod 16384計算這個key應該分布到哪個hash slot中，一個hash slot中會有很多key和value。你可以理解成表的分區，使用單節點時的redis時只有一個表，所有的key都放在這個表裡；改用Redis Cluster以後會自動為你生成16384個分區表，你insert數據時會根據上面的簡單演算法來決定你的key應該存在哪個分區，每個分區里有很多key。
Ⅸ 京東面試官：Redis 這些我必問
緩存好處：高性能 + 高並發
資料庫查詢耗費了800ms，其他用戶對同一個數據再次查詢 ，假設該數據在10分鍾以內沒有變化過，並且 10 分鍾之內有 1000 個用戶 都查詢了同一數據，10 分鍾之內，那 1000 每個用戶，每個人查詢這個數據都感覺很慢 800ms
比如 ：某個商品信息，在 一天之內都不會改變，但是這個商品每次查詢一次都要耗費2s，一天之內被瀏覽 100W次
mysql 單機也就 2000qps,緩存單機輕松幾萬幾十萬qps,單機 承載並發量是 mysql 單機的幾十倍。
在中午高峰期，有 100W 個用戶訪問系統 A，每秒有 4000 個請求去查詢資料庫，資料庫承載每秒 4000 個請求會宕機，加上緩存後，可以 3000 個請求走緩存 ，1000 個請求走資料庫。
緩存是走內存的，內存天然可以支撐4w/s的請求，資料庫（基於磁碟）一般建議並發請求不要超過 2000/s
redis 單線程 ，memcached 多線程
redis 是單線程 nio 非同步線程模型
一個線程+一個隊列
redis 基於 reactor 模式開發了網路事件處理器，這個處理器叫做文件事件處理器，file event handler，這個文件事件處理器是單線程的，所以redis 是單線程的模型，採用 io多路復用機制同時監聽多個 socket,根據socket上的事件來選擇對應的事件處理器來處理這個事件。
文件事件處理器包含：多個 socket,io多路復用程序，文件事件分派器，事件處理器（命令請求處理器、命令恢復處理器、連接應答處理器）
文件事件處理器是單線程的，通過 io 多路復用機制監聽多個 socket，實現高性能和線程模型簡單性
被監聽的 socket 准備好執行 accept,read,write,close等操作的時候，會產生對應的文件事件，調用之前關聯好的時間處理器處理
多個 socket並發操作，產生不同的文件事件，i/o多路復用會監聽多個socket，將這些 socket放入一個隊列中排隊。事件分派器從隊列中取出socket給對應事件處理器。
一個socket時間處理完後，事件分派器才能從隊列中拿到下一個socket，給對應事件處理器來處理。
文件事件：
AE_READABLE 對應 socket變得可讀（客戶端對redis執行 write操作）
AE_WRITABLE 對應 socket 變得可寫（客戶端對 redis執行 read操作）
I/O 多路復用可以同時監聽AE_REABLE和 AE_WRITABLE ，如果同時達到則優先處理 AE_REABLE 時間
文件事件處理器：
連接應答處理器 對應 客戶端要連接 redis
命令請求處理器 對應 客戶端寫數據到 redis
命令回復處理器 對應 客戶端從 redis 讀數據
流程：
一秒鍾可以處理幾萬個請求
普通的 set,get kv緩存
類型 map結構，比如一個對象（沒有嵌套對象）緩存到 redis裡面，然後讀寫緩存的時候，可以直接操作hash的欄位（比如把 age 改成 21，其他的不變）
key=150
value = {
}
有序列表 ，元素可以重復
可以通過 list 存儲一些列表型數據結構，類似粉絲列表，文章評論列表。
例如：微信大 V的粉絲，可以以 list 的格式放在 redis 里去緩存
key=某大 V value=[zhangsan,lisi,wangwu]
比如 lrange 可以從某個元素開始讀取多少個元素，可以基於 list 實現分頁查詢功能，基於 redis實現高性能分頁，類似微博下來不斷分頁東西。
可以搞個簡單的消息隊列，從 list頭懟進去（lpush），list尾巴出來 (brpop)
無序集合，自動去重
需要對一些數據快速全局去重，（當然也可以基於 HashSet，但是單機）
基於 set 玩差集、並集、交集的操作。比如：2 個人的粉絲列表整一個交集，看看 2 個人的共同好友是誰？
把 2 個大 V 的粉絲都放在 2 個 set中，對 2 個 set做交集（sinter）
排序的 set，去重但是可以排序，寫進去的時候給一個分數，自動根據分數排序
排行榜：
zadd board score username
例如：
zadd board 85 zhangsan
zadd board 72 wangwu
zadd board 96 lis
zadd board 62 zhaoliu
自動排序為：
96 lisi
85 zhangsan
72 wangwu
62 zhaoliu
獲取排名前 3 的用戶 ： zrevrange board 0 3
96 lisi
85 zhangsan
72 wangwu
查看zhaoliu的排行 ：zrank board zhaoliu 返回 4
內存是寶貴的，磁碟是廉價的
給key設置過期時間後，redis對這批key是定期刪除+惰性刪除
定期刪除：
redis 默認每隔 100ms隨機抽取一些設置了過期時間的 key，檢查其是否過期了，如果過期就刪除。
注意：redis是每隔100ms隨機抽取一些 key來檢查和刪除，而不是遍歷所有的設置過期時間的key（否則CPU 負載會很高，消耗在檢查過期 key 上）
惰性刪除：
獲取某個key的時候， redis 會檢查一下，這個key如果設置了過期時間那麼是否過期，如果過期了則刪除。
如果定期刪除漏掉了許多過期key，然後你也沒及時去查，也沒走惰性刪除，如果大量過期的key堆積在內存里，導致 redis 內存塊耗盡，則走內存淘汰機制。
內存淘汰策略：
LRU 演算法：
緩存架構（多級緩存架構、熱點緩存）
redis 高並發瓶頸在單機，讀寫分離，一般是支撐讀高並發，寫請求少，也就 一秒一兩千，大量請求讀，一秒鍾二十萬次。
一主多從，主負責寫，將數據同步復制到其他 slave節點，從節點負責讀，所有讀的請求全部走從節點。主要是解決讀高並發。、
主從架構->讀寫分離->支撐10W+讀QPS架構
master->slave 復制，是非同步的
核心機制：
master持久化對主從架構的意義：
如果開啟了主從架構，一定要開啟 master node的持久化，不然 master宕機重啟數據是空的，一經復制，slave的數據也丟了
主從復制原理：
第一次啟動或者斷開重連情況：
正常情況下：
master 來一條數據，就非同步給 slave
全年 99.99%的時間，都是出於可用的狀態，那麼就可以稱為高可用性
redis 高可用架構叫故障轉移，failover，也可以叫做主備切換，切換的時間不可用，但是整體高可用。
sentinal node(哨兵)
作用：
quorum = 1 （代表哨兵最低個數可以嘗試故障轉移，選舉執行的哨兵）
master 宕機，只有 S2 存活，因為 quorum =1 可以嘗試故障轉移，但是沒達到 majority =2 （最低允許執行故障轉移的哨兵存活數）的標准，無法執行故障轉移
如果 M1 宕機了，S2,S3 認為 master宕機，選舉一個執行故障轉移，因為 3 個哨兵的 majority = 2，所以可以執行故障轉移
丟數據：
解決方案：
sdown 主觀宕機，哨兵覺得一個 master 宕機（ping 超過了 is-master-down-after-milliseconds毫秒數）
odown 客觀宕機，quorum數量的哨兵都覺得 master宕機
哨兵互相感知通過 redis的 pub/sub系統，每隔 2 秒往同一個 channel里發消息（自己的 host,ip,runid），其他哨兵可以消費這個消息
以及同步交換master的監控信息。
哨兵確保其他slave修改master信息為新選舉的master
當一個 master被認為 odown && marjority哨兵都同意，那麼某個哨兵會執行主備切換，選舉一個slave成為master（考慮 1. 跟master斷開連接的時長 2. slave 優先順序 3.復制 offset 4. runid）
選舉演算法：
quorum 數量哨兵認為odown->選舉一個哨兵切換->獲得 majority哨兵的授權（quorum majority 需要 majority個哨兵授權，quorum >= majority 需要 quorum 哨兵授權）
第一個選舉出來的哨兵切換失敗了，其他哨兵等待 failover-time之後，重新拿confiuration epoch做為新的version 切換，保證拿到最新配置，用於 configuration傳播（通過 pu/sub消息機制，其他哨兵對比 version 新舊更新 master配置）
高並發：主從架構
高容量：Redis集群，支持每秒幾十萬的讀寫並發
高可用：主從+哨兵
持久化的意義在於故障恢復數據備份（到其他伺服器）+故障恢復（遇到災難，機房斷電，電纜被切）
AOF 只有一個，Redis 中的數據是有一定限量的，內存大小是一定的,AOF 是存放寫命令的，當大到一定的時候，AOF 做 rewrite 操作，就會基於當時 redis 內存中的數據，來重新構造一個更小的 AOF 文件，然後將舊的膨脹很大的文件給刪掉，AOF 文件一直會被限制在和Redis內存中一樣的數據。AOF同步間隔比 RDB 小，數據更完整
優點：
缺點：
AOF 存放的指令日誌，數據恢復的時候，需要回放執行所有指令日誌，RDB 就是一份數據文件，直接載入到內存中。
優點：
缺點：
AOF 來保證數據不丟失，RDB 做不同時間的冷備
支持 N 個 Redis master node,每個 master node掛載多個 slave node
多master + 讀寫分離 + 高可用
數據量很少，高並發 -> replication + sentinal 集群
海量數據 + 高並發 + 高可用 -> redis cluster
hash演算法->一致性 hash 演算法-> redis cluster->hash slot演算法
redis cluster :自動對數據進行分片，每個 master 上放一部分數據，提供內置的高可用支持，部分master不可用時，還是可以繼續工作
cluster bus 通過 16379進行通信，故障檢測，配置更新，故障轉移授權，另外一種二進制協議，主要用於節點間進行高效數據交換，佔用更少的網路帶寬和處理時間
key進行hash，然後對節點數量取模，最大問題只有任意一個 master 宕機，大量數據就要根據新的節點數取模，會導致大量緩存失效。
key進行hash，對應圓環上一個點，順時針尋找距離最近的一個點。保證任何一個 master 宕機，只受 master 宕機那台影響，其他節點不受影響，此時會瞬間去查資料庫。
緩存熱點問題：
可能集中在某個 hash區間內的值特別多，那麼會導致大量的數據都湧入同一個 master 內，造成 master的熱點問題，性能出現瓶頸。
解決方法：
給每個 master 都做了均勻分布的虛擬節點，這樣每個區間內大量數據都會均勻的分布到不同節點內，而不是順時針全部湧入到同一個節點中。
redis cluster 有固定 16384 個 hash slot,對每個key計算 CRC16 值，然後對16384取模，可以獲取 key對應的 hash slot
redis cluster 中每個 master 都會持有部分 slot ,當一台 master 宕機時候，會最快速度遷移 hash slot到可用的機器上（只會短暫的訪問不到）
走同一個 hash slot 通過 hash tag實現
集群元數據：包括 hashslot->node之間的映射表關系，master->slave之間的關系，故障的信息
集群元數據集中式存儲（storm），底層基於zookeeper（分布式協調中間件）集群所有元數據的維護。好處：元數據的更新和讀取，時效性好，一旦變更，其他節點立刻可以感知。缺點：所有元數據的更新壓力全部集中在一個地方，可能會導致元數據的存儲有壓力。
goosip: 好處：元數據的更新比較分散，有一定的延時，降低了壓力。缺點：更新有延時，集群的一些操作會滯後。（reshared操作時configuration error）
自己提供服務的埠號+ 10000 ，每隔一段時間就會往另外幾個節點發送ping消息，同時其他幾點接收到ping之後返回pong
故障信息，節點的增加和移除， hash slot 信息
meet:某個節點發送 meet給新加入的節點，讓新節點加入集群中，然後新節點就會開始於其他節點進行通信
ping:每個節點都會頻繁給其他節點發送ping，其中包含自己的狀態還有自己維護的集群元數據，互相通過ping交換元數據
ping:返回ping和meet，包含自己的狀態和其他信息
fail:某個節點判斷另一個節點fail之後，就發送 fail 給其他節點，通知其他節點，指定的節點宕機了
ping 很頻繁，且攜帶元數據，會加重網路負擔
每個節點每秒會執行 10 次 ping，每次選擇 5 個最久沒有通信的其他節點
當如果發現某個節點通信延遲達到了 cluster_node_timeout /2 ，那麼立即發送 ping， 避免數據交換延遲過長，落後時間太長（2 個節點之間 10 分鍾沒有交換數據，整個集群處於嚴重的元數據不一致的情況）。
每次ping，一個是帶上自己的節點信息，還有就是帶上1/10其他節點的信息，發送出去，進行數據交換
至少包含 3 個其他節點信息，最多包含總節點-2 個其他節點的信息
客戶端發送到任意一個redis實例發送命令，每個redis實例接受到命令後，都會計算key對應的hash slot，如果在本地就本地處理，否則返回moved給客戶端，讓客戶端進行重定向 （redis-cli -c）
通過tag指定key對應的slot,同一個 tag 下的 key，都會在一個 hash slot中，比如 set key1:{100} 和 set key2:{100}
本地維護一份hashslot->node的映射表。
JedisCluster 初始化的時候，隨機選擇一個 node，初始化 hashslot->node 映射表，同時為每個節點創建一個JedisPool連接池，每次基於JedisCluster執行操作，首先JedisCluster都會在本地計算key的hashslot，然後再本地映射表中找到對應的節點，如果發現對應的節點返回moved，那麼利用該節點的元數據，更新 hashslot->node映射表（重試超過 5 次報錯）
hash slot正在遷移，那麼會返回ask 重定向給jedis,jedis 接受到ask重定向之後，，會重定向到目標節點去執行
判斷節點宕機：
如果一個節點認為另外一個節點宕機了， 就是pfail,主觀宕機
如果多個節點都認為另外一個節點宕機了，那麼就是fail，客觀宕機（跟哨兵原理一樣）
在cluster-node-timeout內，某個節點一直沒有返回 pong,那麼就被認為是 pfail
如果一個節點認為某個節點pfail了，那麼會在gossip消息中，ping給其他節點，如果超過半數的節點認為pfail了，那麼就會變成fail。
從節點過濾：
對宕機的 mster node ，從其所有的 slave node中，選擇一個切換成 master node
檢查每個 slave node與master node斷開連接的時間，如果超過了cluster-node-timeout * cluster-slave-validity-factor，那麼就沒資格切換成 master（和哨兵一致）
從節點選舉：
每個從節點，根據自己對 master 復制數據的 offset，設置一個選舉時間，offset越大（復制數據越多）的從節點，選舉時間越靠前，所有的 master node 開始投票，給要進行選舉的 slave進行投票，如果大部分 master node(N/2 +1) 都投票給某個從節點，那麼選舉通過，從節點執行主備切換，從節點切換成主節點
總結：和哨兵很像，直接集成了 replication 和 sentinal
方案：
事前：保證 redis 集群高可用性 （主從+哨兵或 redis cluster），避免全盤崩潰
事中：本地 ehcache 緩存 + hystrix 限流（保護資料庫） & 降級，避免 MySQL被打死
事後： redis持久化，快速恢復緩存數據，繼續分流高並發請求
限制組件每秒就 2000 個請求通過限流組件進入資料庫，剩餘的 3000 個請求走降級，返回一些默認 的值，或者友情提示
好處 ：
4000 個請求黑客攻擊請求資料庫里沒有的數據
解決方案：把黑客查資料庫中不存在的數據的值，寫到緩存中，比如： set -999 UNKNOWN
讀的時候，先讀緩存，緩存沒有，就讀資料庫，然後取出數據後放入緩存，同時返回響應
更新的時候，刪除緩存，更新資料庫
為什麼不更新緩存：
更新緩存代價太高（更新 20 次，只讀 1 次），lazy思想，需要的時候再計算，不需要的時候不計算
方案：先刪除緩存，再修改資料庫
方案：寫，讀路由到相同的一個內存隊列（唯一標識，hash，取模）里，更新和讀操作進行串列化（後台線程非同步執行隊列串列化操作），（隊列里只放一個更新查詢操作即可，多餘的過濾掉，內存隊列里沒有該數據更新操作，直接返回 ）有該數據更新操作則輪詢取緩存值，超時取不到緩存值，直接取一次資料庫的舊值
TP 99 意思是99%的請求可以在200ms內返回
注意點：多個商品的更新操作都積壓在一個隊列裡面（太多操作積壓只能增加機器），導致讀請求發生大量的超時，導致大量的讀請求走資料庫
一秒 500 寫操作，每200ms，100 個寫操作，20 個內存隊列，每個隊列積壓 5 個寫操作，一般在20ms完成
方案：分布式鎖 + 時間戳比較
10台機器，5 主 5 從，每個節點QPS 5W ，一共 25W QPS（Redis cluster 32G + 8 核 ，Redis 進程不超過 10G）總內存 50g，每條數據10kb，10W 條數據1g，200W 條數據 20G，佔用總內存不到50%，目前高峰期 3500 QPS
作者： mousycoder