（1）緩存剛好失效 （2）請求A查詢資料庫，得一個舊值 （3）請求B將新值寫入資料庫 （4）請求B刪除緩存 （5）請求A將查到的舊值寫入快取

但是只有2,3中 3比2 快, B才會發生先刪除快取,A 用舊值寫緩存

實際上 寫庫操作遠低於讀取操作,所以避免慢 SQL.

（1）先淘汰緩存 （2）再寫資料庫（這兩步和原來一樣） （3）休眠1秒，再次淘汰緩存

使用非同步雙刪除

查看個數,長度

是否存在,包含,追加,對該key 或key下的某一域增減

刪除,刪除指定位置,刪除並取得

自由主題

Key

Set

List

有序集合

Transaction

Hash

自由主題

當字串大小需要擴容時,小於1M,都是擴大一倍.大於1M,每次只擴容1M. 最大長度512 M

自增值超過最大值,會報錯

對於容器型資料結構,如果容器不存在就建立,如果元素沒有了,就刪除容器

取得鎖

解鎖

a) 一旦redis發生主從切換，可能會遺失一些鎖，

Zookeeper實現的分散式鎖其實有一個缺點，那就是效能上可能並沒有快取服務那麼高。因為每次在建立鎖定和釋放鎖定的過程中，都要動態建立、銷毀瞬時節點來實現鎖定功能。 ZK中建立和刪除節點只能透過Leader伺服器來執行，然後將資料同不到所有的Follower機器上。 並發問題，可能有網路抖動，客戶端和ZK叢集的session連線斷了，zk叢集以為客戶端掛了，就會刪除臨時節點，這時候其他客戶端就可以取得到分散式鎖了

Redis很難實現公平性

在演算法的分散式版本中，我們假設我們有N個Redis主機。這些節點完全獨立，因此我們不使用複製或任何其他隱式協調系統。我們已經描述瞭如何在單一實例中安全地取得和釋放鎖。我們理所當然地認為演算法將使用此方法在單一實例中獲取和釋放鎖。在我們的範例中，我們設定N = 5，這是一個合理的值，因此我們需要在不同的電腦或虛擬機器上執行5個Redis主伺服器，以確保它們以大多數獨立的方式失敗。 為了取得鎖，客戶端執行以下操作： 1. 它以毫秒為單位取得當前時間。 2. 它嘗試依序取得所有N個實例中的鎖，在所有實例中使用相同的鍵名和隨機值。在步驟2期間，當在每個實例中設定鎖定時，用戶端使用與總鎖定自動釋放時間相比較小的逾時以取得它。例如，如果自動釋放時間是10秒，則超時可以在~5-50毫秒範圍內。這可以防止客戶端長時間保持阻塞狀態，試圖與Redis節點通話失敗：如果執行個體不可用，我們應該盡快嘗試與下一個執行個體通話。 3. 客戶端透過從目前時間中減去在步驟1中獲得的時間戳記來計算獲取鎖定所需的時間。當且僅當客戶端能夠在大多數實例中獲取鎖定時（至少3個）並且獲取鎖定所經過的總時間小於鎖定有效時間，認為鎖定被獲取。 4. 如果獲得了鎖，則其有效時間被認為是初始有效時間減去經過的時間，如步驟3中計算的。 5. 如果客戶端因某種原因（無法鎖定N / 2 1實例或有效時間為負）未能取得鎖定，它將嘗試解鎖所有實例（即使它認為不是能夠鎖定）。

當掛掉一個節點後,不會導致鎖被搶佔的風險

失效時間設定隨機值,避免集體失效

記錄用戶帖子id 列表.快速顯示

記錄熱榜帖子 ID列表.總熱榜,分類熱榜

用於記錄一對多,且多的一方嚴格不能重複

記錄某個集合,該集合可能是和使用者相關,也可能是與總的系統相關

記錄貼文按讚數,留言數,點擊數.

記錄貼文標題,摘要,作者,封面資訊等.

快取近期的熱貼內容.(貼文內容非常大,不適合從db取)

記錄帖子的相關文章清單.根據內容推薦相關帖子

用於作為bool數組,或自訂位數組,主要是為了節省內存

用於粗略計算去重之後的統計值.

只能新增和取得總數,不能取得某個值是否存在,或全部元素

用於去重.取得某個元素是否存在於清單中

專案不大的，維護成本不高的話，可以採用 直接使用 redsi-cell ，否則可以考慮細粒度的控製到每個服務節點去限流，配合相應的負載平衡策略去實現

利用zset，score圈出時間窗口，統計時間窗口內同一個用戶同一個行為出現的次數,如果限流次數太大.可能不適用,例如1s 1000次

CL.THROTTLE test 100 400 60 3

1： 是否成功，0：成功，1：拒絕 2： 令牌桶的容量，大小為初始值 1 3： 目前令牌桶中可用的令牌 4： 若請求被拒絕，這個值表示多久後才漏斗桶中會重新添加令牌，單位：秒，可以作為重試時間 5： 表示多久後令牌桶中的令牌會存滿

漏斗演算法

由一個個壓縮鍊錶即數組組成,為了避免普通鍊錶的額外記憶體開銷.

為了盡可能節省記憶體設計出來的雙向鍊錶

儲存字串或整數

在細節上節省內存，對於值的存儲採用了變長的編碼方式

hash、list、zset底層資料結構實現

特點

1）針對效能要求較高的場景使用ziplist，建議長度不要超過1000，每個元素大小控制在512位元組以內

跳表平均支援 O(logN)，最壞O(N)複雜度的查找

為什麼不用樹,平衡樹代替跳躍表?

壓縮鍊錶使用 指標連結起來,變成一個linkedlist

每一個ziplist 預設是8k.(可配)

2）指令平均耗時使用info Commandstats指令獲取，包含每個指令呼叫次數 ，總耗時，平均耗時，單位微秒。

Redis的複製功能分為同步（sync）和命令傳播（command propagate）兩個操作：

讀寫分離適合大訪問（大到單一redis感覺很慢了），而且寫入操作遠小於讀取操作的情況。

如果讀取請求數量遠超寫請求，導致叢集資料copy成本遠小於讀取請求成本。 同時能一定程度上接受數據的不一致性，那可以做讀寫分離的。

1、所有的redis節點彼此互聯(PING-PONG機制),內部使用二進位協定優化傳輸速度和頻寬。

2.節點的fail是透過叢集中超過半數的節點偵測失效時才生效。

3.客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連接叢集所有節點,連接叢集中任何一個可用節點即可。

4.redis-cluster把所有的實體節點映射到[0-16383]slot（不一定是平均分配）,cluster 負責維護node<->slot<->value。

5.Redis集群預分好16384個桶，當需要在 Redis 集群中放置一個 key-value 時，根據 CRC16(key) mod 16384的值，決定將一個key放到哪個桶中。

每個Redis實例都知道其他節點的存在

1.你的客戶端寫給主伺服器節點 B 2.主伺服器節點B向您的客戶端回覆確認。 3.主伺服器節點B將寫入傳播到它的從伺服器B1，B2和B3。

如果在 2步驟之後, 沒有發送從伺服器,此時B 掛掉了,那麼key將丟失(故障期間一定會有key 丟失)

選舉過程是叢集中所有master參與,如果半數以上master節點與故障節點通訊超過(cluster-node-timeout),認為該節點故障，自動觸發故障轉移操作.

(2):何時整個叢集不可用(cluster_state:fail)? a:如果集群任意master掛掉,且當前master沒有slave.集群進入fail狀態,也可以理解成集群的slot映射[0-16383]不完成時進入fail狀態. b:如果群集超過半數以上master掛掉，無論是否有slave群集進入fail狀態.

當叢集不可用時,所有對叢集的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)錯誤

1. 下線的主節點的所有從節點裡面，會進行選舉，選出一個新的主節點。 2. 被選取的從節點會執行 slave no one指令，成為新的主節點。 3. 新的主節點會撤銷所有對已下線主節點的槽指派，並將這些槽指派給自己。 4. 新的主節點向叢集廣播一條pong訊息，這條pong訊息可以讓叢集中的其他節點立即知道這個節點已經由從節點變成了主節點，並且這個主節點已經接管了原本由已下線節點處理的槽。 5.新的主節點開始接受和自己負責處理的槽有關的命令請求，故障轉移操作完成。

1. 當從節點發現自己複製的主節點進入已下線時，從節點（這裡發出請求的從節點可能會有多個）會向集群廣播一條cluster_type_failover_auth_request的訊息，要求有投票權（負責處理槽）的主節點向這個節點進行投票。 2.收到cluster_type_failover_auth_request訊息的主節點，根據自身條件（發起投票節點的current epoch不低於投票節點的current epoch）判斷是否贊成該從節點成為新的主節點，若贊成則傳回一條cluster_type_failover_auth_ack訊息。 3. 從節點接收到cluster_type_failover_auth_ack訊息，會將選票數加1。 4.如果某個從節點的選票大於等於叢集中主節點的一半時（大於等於N/2 1），這個節點就會變成新的主節點。 如果在一個配置週期內，沒有一個從節點獲得足夠的選票，那麼叢集中會進入新的配置週期，並在此進行選舉，知道選出新的主節點為止。

所有從節點都可能徵求意見,自己是否可以成為主(投票的人只投給自己大的節點),超過半數即可(n 1)/2

可能選不出來

1.目前只支援同一個槽上的key的批次操作； 2.目前只支援同一個槽上的key事務； 3.只能使用資料庫0(每個redis實例有16個資料庫，可透過select {index}指令來切換)； 4.不能將一個大的key(如hash、list)映射到不同的節點上； 5.目前集群主從複製只支援一層，不支援嵌套樹狀架構；

步驟

每個節點都知道每個槽對應的 cluster node .

節點在接到命令請求時,查詢是否自己處理,如果是則處理,如果不是,返回move 錯誤, moved錯誤攜帶正確的節點ip和端口號返回給客戶端指引其轉向執行，而且客戶端以後的每一次關於該key都會去moved錯誤提供的節點去執行。

當Codis的Codis Dashbord 改變槽位的訊息的時候，其他的Codis節點會監聽到ZooKeeper的槽位變化，會及時同步過來。如圖：

zk負責同步槽位資訊.

使用多個佇列實作.優先權佇列.不同的優先權任務進入到不同的佇列

同時消費者從隊列中取資料時,支援從多個隊列中取資料,其中有優先順序.

啟動多個消費者就是啟動多個 client取數據

使用

風險

1、當給定清單內沒有任何元素可供彈出的時候，連線將被 BRPOP 指令阻塞，直到等待逾時或發現可彈出元素為止。 2.當給定多個key參數時，依參數 key 的先後順序依序檢查各個列表，彈出第一個非空列表的尾端元素。 另外，BRPOP 除了彈出元素的位置和 BLPOP 不同之外，其他表現一致。

如果list中沒有任務時， 該連線將會被阻塞 連接的阻塞有一個逾時時間 ， 當逾時時間設定為0 ， 即可無線等待， 直到彈出訊息

適用於 A-B 之間兩個業務之間的訂閱發佈等,當多個業務線意味著不同的消費者時,比較困難

ack實現