A. 京東面試題：ElasticSearch深度分頁解決方案
Elasticsearch 是一個實時的分布式搜索與分析引擎，在使用過程中，有一些典型的使用場景，比如分頁、遍歷等。
在使用關系型資料庫中，我們被告知要注意甚至被明確禁止使用深度分頁，同理，在 Elasticsearch 中，也應該盡量避免使用深度分頁。
這篇文章主要介紹 Elasticsearch 中分頁相關內容！
在ES中，分頁查詢默認返回最頂端的10條匹配hits。
如果需要分頁，需要使用from和size參數。
一個基本的ES查詢語句是這樣的：
上面的查詢表示從搜索結果中取第100條開始的10條數據。
「那麼，這個查詢語句在ES集群內部是怎麼執行的呢？」
在ES中，搜索一般包括兩個階段，query 和 fetch 階段，可以簡單的理解，query 階段確定要取哪些doc，fetch 階段取出具體的 doc。
如上圖所示，描述了一次搜索請求的 query 階段：·
在上面的例子中，coordinating node 拿到 (from + size) * 6 條數據，然後合並並排序後選擇前面的 from + size 條數據存到優先順序隊列，以便 fetch 階段使用。
另外，各個分片返回給 coordinating node 的數據用於選出前 from + size 條數據，所以，只需要返回唯一標記 doc 的 _id 以及用於排序的 _score 即可，這樣也可以保證返回的數據量足夠小。
coordinating node 計算好自己的優先順序隊列後，query 階段結束，進入 fetch 階段。
query 階段知道了要取哪些數據，但是並沒有取具體的數據，這就是 fetch 階段要做的。
上圖展示了 fetch 過程：
coordinating node 的優先順序隊列里有 from + size 個 _doc _id ，但是，在 fetch 階段，並不需要取回所有數據，在上面的例子中，前100條數據是不需要取的，只需要取優先順序隊列里的第101到110條數據即可。
需要取的數據可能在不同分片，也可能在同一分片，coordinating node 使用 「multi-get」 來避免多次去同一分片取數據，從而提高性能。
「這種方式請求深度分頁是有問題的：」
我們可以假設在一個有 5 個主分片的索引中搜索。當我們請求結果的第一頁（結果從 1 到 10 ），每一個分片產生前 10 的結果，並且返回給 協調節點 ，協調節點對 50 個結果排序得到全部結果的前 10 個。
現在假設我們請求第 1000 頁—結果從 10001 到 10010 。所有都以相同的方式工作除了每個分片不得不產生前10010個結果以外。然後協調節點對全部 50050 個結果排序最後丟棄掉這些結果中的 50040 個結果。
「對結果排序的成本隨分頁的深度成指數上升。」
「注意1：」
size的大小不能超過 index.max_result_window 這個參數的設置，默認為10000。
如果搜索size大於10000，需要設置 index.max_result_window 參數
「注意2：」
_doc 將在未來的版本移除，詳見：
Elasticsearch 的From/Size方式提供了分頁的功能，同時，也有相應的限制。
舉個例子，一個索引，有10億數據，分10個 shards，然後，一個搜索請求，from=1000000，size=100，這時候，會帶來嚴重的性能問題：CPU，內存，IO，網路帶寬。
在 query 階段，每個shards需要返回 1000100 條數據給 coordinating node，而 coordinating node 需要接收 10 * 1000 ，100 條數據，即使每條數據只有 _doc _id 和 _score ，這數據量也很大了？
「在另一方面，我們意識到，這種深度分頁的請求並不合理，因為我們是很少人為的看很後面的請求的，在很多的業務場景中，都直接限制分頁，比如只能看前100頁。」
比如，有1千萬粉絲的微信大V，要給所有粉絲群發消息，或者給某省粉絲群發，這時候就需要取得所有符合條件的粉絲，而最容易想到的就是利用 from + size 來實現，不過，這個是不現實的，這時，可以採用 Elasticsearch 提供的其他方式來實現遍歷。
深度分頁問題大致可以分為兩類：
「下面介紹幾個官方提供的深度分頁方法」
我們可以把scroll理解為關系型資料庫里的cursor，因此，scroll並不適合用來做實時搜索，而更適合用於後台批處理任務，比如群發。
這個分頁的用法， 「不是為了實時查詢數據」 ，而是為了 「一次性查詢大量的數據（甚至是全部的數據」 ）。
因為這個scroll相當於維護了一份當前索引段的快照信息，這個快照信息是你執行這個scroll查詢時的快照。在這個查詢後的任何新索引進來的數據，都不會在這個快照中查詢到。
但是它相對於from和size，不是查詢所有數據然後剔除不要的部分，而是記錄一個讀取的位置，保證下一次快速繼續讀取。
不考慮排序的時候，可以結合 SearchType.SCAN 使用。
scroll可以分為初始化和遍歷兩部，初始化時將 「所有符合搜索條件的搜索結果緩存起來（注意，這里只是緩存的doc_id，而並不是真的緩存了所有的文檔數據，取數據是在fetch階段完成的）」 ，可以想像成快照。
在遍歷時，從這個快照里取數據，也就是說，在初始化後，對索引插入、刪除、更新數據都不會影響遍歷結果。
「基本使用」
初始化指明 index 和 type，然後，加上參數 scroll，表示暫存搜索結果的時間，其它就像一個普通的search請求一樣。
會返回一個 _scroll_id ， _scroll_id 用來下次取數據用。
「遍歷」
這里的 scroll_id 即 上一次遍歷取回的 _scroll_id 或者是初始化返回的 _scroll_id ，同樣的，需要帶 scroll 參數。
重復這一步驟，直到返回的數據為空，即遍歷完成。
「注意，每次都要傳參數 scroll，刷新搜索結果的緩存時間」 。另外， 「不需要指定 index 和 type」 。
設置scroll的時候，需要使搜索結果緩存到下一次遍歷完成， 「同時，也不能太長，畢竟空間有限。」
「優缺點」
缺點：
「優點：」
適用於非實時處理大量數據的情況，比如要進行數據遷移或者索引變更之類的。
ES提供了scroll scan方式進一步提高遍歷性能，但是scroll scan不支持排序，因此scroll scan適合不需要排序的場景
「基本使用」
Scroll Scan 的遍歷與普通 Scroll 一樣，初始化存在一點差別。
需要指明參數：
「Scroll Scan與Scroll的區別」
如果你數據量很大，用Scroll遍歷數據那確實是接受不了，現在Scroll介面可以並發來進行數據遍歷了。
每個Scroll請求，可以分成多個Slice請求，可以理解為切片，各Slice獨立並行，比用Scroll遍歷要快很多倍。
上邊的示例可以單獨請求兩塊數據，最終五塊數據合並的結果與直接scroll scan相同。
其中max是分塊數，id是第幾塊。
Search_after 是 ES 5 新引入的一種分頁查詢機制，其原理幾乎就是和scroll一樣，因此代碼也幾乎是一樣的。
「基本使用：」
第一步：
返回出的結果信息 ：
上面的請求會為每一個文檔返回一個包含sort排序值的數組。
這些sort排序值可以被用於 search_after 參數里以便抓取下一頁的數據。
比如，我們可以使用最後的一個文檔的sort排序值，將它傳遞給 search_after 參數：
若我們想接著上次讀取的結果進行讀取下一頁數據，第二次查詢在第一次查詢時的語句基礎上添加 search_after ，並指明從哪個數據後開始讀取。
「基本原理」
es維護一個實時游標，它以上一次查詢的最後一條記錄為游標，方便對下一頁的查詢，它是一個無狀態的查詢，因此每次查詢的都是最新的數據。
由於它採用記錄作為游標，因此 「SearchAfter要求doc中至少有一條全局唯一變數（每個文檔具有一個唯一值的欄位應該用作排序規范）」
「優缺點」
「優點：」
「缺點：」
SEARCH_AFTER 不是自由跳轉到任意頁面的解決方案，而是並行滾動多個查詢的解決方案。
分頁方式性能優點缺點場景 from + size低靈活性好，實現簡單深度分頁問題數據量比較小，能容忍深度分頁問題 scroll中解決了深度分頁問題無法反應數據的實時性（快照版本）維護成本高，需要維護一個 scroll_id海量數據的導出需要查詢海量結果集的數據 search_after高性能最好不存在深度分頁問題能夠反映數據的實時變更實現復雜，需要有一個全局唯一的欄位連續分頁的實現會比較復雜，因為每一次查詢都需要上次查詢的結果，它不適用於大幅度跳頁查詢海量數據的分頁
參照：https://www.elastic.co/guide/en/elasticsearch/reference/master/paginate-search-results.html#scroll-search-results
在 7.* 版本中，ES官方不再推薦使用Scroll方法來進行深分頁，而是推薦使用帶PIT的 search_after 來進行查詢；
從 7.* 版本開始，您可以使用 SEARCH_AFTER 參數通過上一頁中的一組排序值檢索下一頁命中。
使用 SEARCH_AFTER 需要多個具有相同查詢和排序值的搜索請求。
如果這些請求之間發生刷新，則結果的順序可能會更改，從而導致頁面之間的結果不一致。
為防止出現這種情況，您可以創建一個時間點(PIT)來在搜索過程中保留當前索引狀態。
在搜索請求中指定PIT：
分別分頁獲取 1 - 10 ， 49000 - 49010 ， 99000 - 99010 范圍各10條數據（前提10w條），性能大致是這樣：
對於向前翻頁，ES中沒有相應API，但是根據官方說法（https://github.com/elastic/elasticsearch/issues/29449），ES中的向前翻頁問題可以通過翻轉排序方式來實現即：
Scroll和 search_after 原理基本相同，他們都採用了游標的方式來進行深分頁。
這種方式雖然能夠一定程度上解決深分頁問題。但是，它們並不是深分頁問題的終極解決方案，深分頁問題 「必須避免！!」 。
對於Scroll，無可避免的要維護 scroll_id 和 歷史 快照，並且，還必須保證 scroll_id 的存活時間，這對伺服器是一個巨大的負荷。
對於 Search_After ，如果允許用戶大幅度跳轉頁面，會導致短時間內頻繁的搜索動作，這樣的效率非常低下，這也會增加伺服器的負荷，同時，在查詢過程中，索引的增刪改會導致查詢數據不一致或者排序變化，造成結果不準確。
Search_After 本身就是一種業務折中方案，它不允許指定跳轉到頁面，而只提供下一頁的功能。
Scroll默認你會在後續將所有符合條件的數據都取出來，所以，它只是搜索到了所有的符合條件的 doc_id (這也是為什麼官方推薦用 doc_id 進行排序，因為本身緩存的就是 doc_id ，如果用其他欄位排序會增加查詢量)，並將它們排序後保存在協調節點(coordinate node)，但是並沒有將所有數據進行fetch，而是每次scroll，讀取size個文檔，並返回此次讀取的最後一個文檔以及上下文狀態，用以告知下一次需要從哪個shard的哪個文檔之後開始讀取。
這也是為什麼官方不推薦scroll用來給用戶進行實時的分頁查詢，而是適合於大批量的拉取數據，因為它從設計上就不是為了實時讀取數據而設計的。
B. 京東面試官：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