自總結知識點：
一、什麼是分佈式系統？與集羣系統的區別
答：分佈式和集羣是不得不聯繫在一起的兩個概念，如果多臺服務器共同處理一件事情，叫集羣；如果多臺服務器各自處理不同的事情，彼此之間協調合作，共同完成整個系統的工作，就叫做分佈式系統。
二、Redis-Cloud是集羣，還是分佈式緩存系統？
答：既是集羣，也是分佈式系統。這要看從哪個角度來看。
假如從存儲數據是否相同來看，Redis-Cloud中每個結點存儲的數據是不一樣的，它共有16384個槽（0~16383），假如Redis-Cloud中有3個結點，那麼這16384個槽是根據各個節點的性能分佈在不同結點上的。第一個結點負責0~5000個槽，第二個結點負責5001~10000個槽，第三個結點負責10001~16383個槽，三個結點分別負責不同範圍的數據存儲，最終完整對整個數據範圍的存儲，很顯然，這是一個分佈式系統。
但如果從Redis-Cloud中所提供的緩存功能來看，每個結點都是用來做緩存的，各個節點提供的功能都是一樣的，當內存不夠用時，還可以不斷橫向添加結點來擴大內存容量，很顯然，這是一個集羣。
所以，我們會說，Redis集羣是一個分佈式集羣系統。
三、Redis-Cloud分佈式緩存如何維持數據的完整性？
答：Redis-Cloud分佈式緩存原理：
①集羣中有那麼多個結點，結點中保存的數據不一樣，所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬，客戶端想要連接集羣，只需要連接到集羣中的任意一個節點即可，客戶端與節點直連，不需要中間proxy層；
②每一個節點都有一個備份機（猜測：1每個節點最少一個備份，可有多個？2主節點不能作爲其他節點的備份節點），如果這個結點掛了，必須要有備份結點頂上來，來保證集羣可以繼續提供服務。
③集羣中最少有幾個結點呢？3個！3個結點就可以搭建起一個Redis集羣，在實際開發中，因爲還要保證每個結點都有一個備份機，所以，最小的集羣會搭建6個結點
四、Redis-Cloud高可用性原理？故障轉移機制
答：
①判斷節點故障的機制
Redis集羣中有一個投票：容錯機制，我們前面說集羣中一般都會有一個集羣管理工具，但在Redis集羣中並沒有，那麼，我們怎麼才能知道集羣中哪一個結點掛了呢？Redis集羣中有一個投票機制。大家都知道，在選舉的時候，是少數服從多數的原則，要判斷Redis集羣中的某個結點是否掛掉了，需要我們集羣中超過半數的節點進行投票，半數以上的節點認爲它掛了，它就掛了。假如集羣中有5個結點，有三個認爲某個結點已經掛了，那麼集羣就認爲這個結點真掛了。這個時候就要看有沒有備份結點，如果沒有備份結點頂上來，那麼集羣就會宕機。如果有備份結點，備份結點頂上來，繼續維持整個集羣的工作，然後管理人員就需要趕快把那個掛掉的節點修理好。
領着選舉過程是集羣中所有master參與,如果半數以上master節點與故障節點通信超過(cluster-node-timeout),認爲該節點故障，自動觸發故障轉移操作.
②確定節點故障後的處理
如果有備份節點，則故障轉移機制啓動，備份節點頂上，且等待報警等待管理人員修理；
如果沒有備份節點，則宕機。
什麼時候整個集羣不可用(cluster_state:fail)?
a:如果集羣任意master掛掉,且當前master沒有slave.集羣進入fail狀態,也可以理解成集羣的slot映射[0-16383]不完成時進入fail狀態. ps : redis-3.0.0.rc1加入cluster-require-full-coverage參數,默認關閉,打開集羣兼容部分失敗.
b:如果集羣超過半數以上master掛掉，無論是否有slave集羣進入fail狀態.
===================================================================
參考文章一：
什麼是分佈式系統？
答：分佈式和集羣是不得不聯繫在一起的兩個概念，如果多臺服務器共同處理一件事情，叫集羣；如果多臺服務器各自處理不同的事情，彼此之間協調合作，共同完成整個系統的工作，就叫做分佈式系統。
Redis-Cloud是集羣，還是分佈式緩存系統？
答：既是集羣，也是分佈式系統。這要看從哪個角度來看。
假如從存儲數據是否相同來看，Redis-Cloud中每個結點存儲的數據是不一樣的，它共有16384個槽（0~16383），假如Redis-Cloud中有3個結點，那麼這16384個槽是根據各個節點的性能分佈在不同結點上的。第一個結點負責0~5000個槽，第二個結點負責5001~10000個槽，第三個結點負責10001~16383個槽，三個結點分別負責不同範圍的數據存儲，最終完整對整個數據範圍的存儲，很顯然，這是一個分佈式系統。
但如果從Redis-Cloud中所提供的緩存功能來看，每個結點都是用來做緩存的，各個節點提供的功能都是一樣的，當內存不夠用時，還可以不斷橫向添加結點來擴大內存容量，很顯然，這是一個集羣。
所以，我們會說，Redis集羣是一個分佈式集羣系統。
（面試題）你知道哪些分佈式緩存，如果要你設計一個分佈式緩存，你會怎麼去設計？
答：主要有Memcached和Redis。我使用Redis來做分佈式緩存。
剛開始對Redis的操作都是單機版，雖然Redis的速度很快，但是在特別高的併發下，Redis也有性能瓶頸。Redis中的數據都放在內存裏面，內存能有多大呢？64個G，已經很大了，64G都放滿了呢？還能放嗎？可以，內存放滿了會放在硬盤中的虛擬內存中，一旦用到虛擬內存了，性能就很低了，所以我們儘可能的不要超出內存的容量。如果存不下了，但是數據還是很多，還需要往緩存中放，那怎麼辦呢？通過搭Redis集羣來擴展內存空間。官方給出的Redis集羣名稱爲Redis-Cluster。
Redis-Cluster架構圖如下：
集羣一般都會有一個入口，有一個集羣管理工具，但Redis集羣沒有入口，即沒有代理層，集羣中的節點都是相互連接的，通過PING-PONG機制來實現各個節點之間的通信，以及判斷各個節點的狀態，客戶端想要連接集羣，只需要連接到集羣中的任意一個節點即可。
集羣中有那麼多個結點，結點中保存的數據一樣嗎？不一樣。如果是一樣的，那叫主備。既然是集羣，就應該是可以擴容的，如果存儲空間不足了，可以加結點，加一個服務器進行，存儲空間就會變大。所有結點的內存容量加起來纔是整個集羣內存的總容量，如果每個結點存儲的數據都一樣，那總容量就只是一個Redis的內存容量了。
Redis集羣中，每個結點保存的數據是不一樣的。如果不一樣，那麼當一個結點掛了，那整個集羣就不完整了，不完整了就不能用了，所以，要想保證Redis集羣的高可用（長時間可使用，而不會宕機），每一個節點都需要加一個備份機，如果這個結點掛了，必須要有備份結點頂上來，來保證集羣可以繼續提供服務。
Redis集羣中有一個投票：容錯機制，我們前面說集羣中一般都會有一個集羣管理工具，但在Redis集羣中並沒有，那麼，我們怎麼才能知道集羣中哪一個結點掛了呢？Redis集羣中有一個投票機制。大家都知道，在選舉的時候，是少數服從多數的原則，要判斷Redis集羣中的某個結點是否掛掉了，需要我們集羣中超過半數的節點進行投票，半數以上的節點認爲它掛了，它就掛了。假如集羣中有5個結點，有三個認爲某個結點已經掛了，那麼集羣就認爲這個結點真掛了。這個時候就要看有沒有備份結點，如果沒有備份結點頂上來，那麼集羣就會宕機。如果有備份結點，備份結點頂上來，繼續維持整個集羣的工作，然後管理人員就需要趕快把那個掛掉的節點修理好。那麼，集羣中最少有幾個結點呢？3個！3個結點就可以搭建起一個Redis集羣，在實際開發中，因爲還要保證每個結點都有一個備份機，所以，最小的集羣會搭建6個結點。
只需要連接上Redis集羣中的任意一個結點，就能連接上整個集羣。
Redis集羣中，每個結點保存的數據是不一樣的，那就會有一個問題，如何把數據分散到不同的節點進行存儲呢？爲解決這個問題，Redis集羣中引入了一個概念，叫slot（槽，哈希槽）。Redis集羣中一共有16384個槽（0~16383），這是固定的。這些槽有什麼作用呢？
當要在Redis集羣中放置一個key-value對時，先要對key使用crc16算法得出一個數，然後再用這個數對16384求餘數，肯定會得到一個0~16383之間的數，這樣每一個key值都會對應一個0~16383之間的哈希槽，然後將key-value鍵值對放在這個槽對應的Redis結點上就可以了。
槽如何進行分配呢？
要看Redis集羣中有幾個結點，還要看每個結點的性能怎麼樣。假如有3個結點，每個結點的性能都是完全一樣的，那麼我們就可以把這16384個槽平均分到3個結點上。
0~5000個槽分到第一個結點上
5001~10000個槽分到第二個結點上
10001~16383個槽分到第三個結點上（爲了好計算，這樣劃分）
有個問題，Redis集羣中最少有幾個結點？Redis集羣中最多有多少個結點？
答：最少有3個，最多有16384個結點。這裏不考慮備份機的問題。
架構細節:
(1)所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬.
(2)節點的fail是通過集羣中超過半數的節點檢測失效時才生效.
(3)客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連接集羣所有節點,連接集羣中任何一個可用節點即可
(4)redis-cluster把所有的物理節點映射到[0-16383]slot上,cluster 負責維護node<->slot<->value
Redis 集羣中內置了 16384 個哈希槽，當需要在 Redis 集羣中放置一個 key-value 時，redis 先對 key 使用 crc16 算法算出一個結果，然後把結果對 16384 求餘數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，redis 會根據節點數量大致均等的將哈希槽映射到不同的節點
==========================================================================
參考文章二：
一:關於redis cluster
1:redis cluster的現狀
reids-cluster計劃在redis3.0中推出，可以看作者antirez的聲明:http://antirez.com/news/49 (ps:跳票了好久，今年貌似加快速度了),目前的最新版本見:https://raw.githubusercontent.com/antirez/redis/3.0/00-RELEASENOTES
作者的目標:Redis Cluster will support up to ~1000 nodes. 贊...
目前redis支持的cluster特性(已測試):
1):節點自動發現
2):slave->master 選舉,集羣容錯
3):Hot resharding:在線分片
4):集羣管理:cluster xxx
5):基於配置(nodes-port.conf)的集羣管理
6):ASK 轉向/MOVED 轉向機制.
2:redis cluster 架構
1)redis-cluster架構圖
架構細節:
(1)所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬.
(2)節點的fail是通過集羣中超過半數的master節點檢測失效時才生效.
(3)客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連接集羣所有節點,連接集羣中任何一個可用節點即可
(4)redis-cluster把所有的物理節點映射到[0-16383]slot上,cluster 負責維護node<->slot<->key
2) redis-cluster選舉:容錯
(1)領着選舉過程是集羣中所有master參與,如果半數以上master節點與故障節點通信超過(cluster-node-timeout),認爲該節點故障，自動觸發故障轉移操作.
(2):什麼時候整個集羣不可用(cluster_state:fail)?
a:如果集羣任意master掛掉,且當前master沒有slave.集羣進入fail狀態,也可以理解成集羣的slot映射[0-16383]不完成時進入fail狀態. ps : redis-3.0.0.rc1加入cluster-require-full-coverage參數,默認關閉,打開集羣兼容部分失敗.
b:如果集羣超過半數以上master掛掉，無論是否有slave集羣進入fail狀態.
ps:當集羣不可用時,所有對集羣的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)錯誤