面試官:Redis 這些我必問
分散式快取
快取好處：高效能 + 高併發
高效能（常用）
高併發
快取不良後果
- 快取與資料庫雙寫不一致
- 快取雪崩
- 快取穿透
- 快取併發競爭
Redis 執行緒模型
redis 單執行緒 ，memcached 多執行緒redis 是單執行緒 nio 非同步執行緒模型
Redis 和 Memcached 區別
- Redis 支援伺服器端的資料操作：Redis比Memcached來說，擁有更多的資料結構和並支援更豐富的資料操作，通常在Memcached裡，你需要將資料拿到客戶端來進行類似的修改再set回去。這大大增加了網路 IO 的次數和資料體積。在Redis中，這些複雜的操作通常和一般的GET/SET一樣高效。所以，如果需要快取能支援更復雜的結構和操作，那麼Redis會是不錯的選擇
- 叢集模式：memcached 沒有原生的叢集模式，需要依靠客戶端來實現往叢集中分片寫入資料，但是 Redis 目前是原生支援 cluster模式的
Redis 單執行緒模型
一個執行緒+一個佇列
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 多路複用可以同時監聽AEREABLE和 AEWRITABLE ，如果同時達到則優先處理 AE_REABLE 時間檔案事件處理器：連線應答處理器 對應 客戶端要連線 redis命令請求處理器 對應 客戶端寫資料到 redis命令回覆處理器 對應 客戶端從 redis 讀資料
流程：
- redis 初始化時，會將連線應答處理器跟 AE_READABLE事件關聯
- 客戶端對 redis 發起連線，產生一個 AE_READABLE 事件
- 連線應答處理器處理客戶端 AEREADABLE 事件，建立客戶端對應的 socket，同時將這個 socket的 AEREADABLE 事件和命令請求處理器關聯
- 客戶端對 redis 發起讀請求，會在 socket上產生一個 AE_READABLE 事件
- 繫結 AEREADABLE 事件的命令請求處理器會從 socket 中讀取請求相關資料，執行對應操作，當執行完畢後，將 socket的 AEWRITABLE 事件跟命令回覆處理器關聯
- 當客戶端這邊準備好讀取響應時，會在 socket上產生一個AE_WRITABLE事件
- 繫結 AE_WRITABLE 事件的命令回覆處理器將準備好的響應資料寫入 socket，供客戶端來讀取
- 命令回覆處理器寫完後，刪掉 socket的 AE_WRITABLE 事件和命令回覆處理器的繫結關係
Redis 單執行緒模型效率高
一秒鐘可以處理幾萬個請求
- 非阻塞 I/O 多路複用機制（不處理事件，只輪詢請求壓入佇列）
- 純記憶體操作（操作只有幾微秒）
- 單執行緒反而 避免了多執行緒頻繁上下文切換的問題
Redis 資料型別
- string
普通的 set,get kv快取 - hash
型別 map結構，比如一個物件（沒有巢狀物件）快取到 redis裡面，然後讀寫快取的時候，可以直接操作hash的欄位（比如把 age 改成 21，其他的不變）
key=150
value = {
"id":150,
"name":"zhangsan",
"age":20
} - list
有序列表 ，元素可以重複
可以通過 list 儲存一些列表型資料結構，類似粉絲列表，文章評論列表。
例如：微信大 V的粉絲，可以以 list 的格式放在 redis 裡去快取
key=某大 V value=[zhangsan,lisi,wangwu]
比如 lrange 可以從某個元素開始讀取多少個元素，可以基於 list 實現分頁查詢功能，基於 redis實現高效能分頁，類似微博下來不斷分頁東西。
可以搞個簡單的訊息佇列，從 list頭懟進去（lpush），list尾巴出來 (brpop) - set
無序集合，自動去重
需要對一些資料快速全域性去重，（當然也可以基於 HashSet，但是單機）
基於 set 玩差集、並集、交集的操作。比如：2 個人的粉絲列表整一個交集，看看 2 個人的共同好友是誰？
把 2 個大 V 的粉絲都放在 2 個 set中，對 2 個 set做交集（sinter） - sorted set
排序的 set，去重但是可以排序，寫進去的時候給一個分數，自動根據分數排序
排行榜：
- 將每個使用者以及其對應的分數寫入進去
zadd board score username - zrevrange board 0 99 可以獲取排名前 100 的使用者
- zrank board username 可以看到使用者在排行榜裡的排名
例如：
zadd board 85 zhangsan
zadd board 72 wangwu
zadd board 96 lis
zadd board 62 zhaoliu
自動排序為：96 lisi85 zhangsan72 wangwu62 zhaoliu
獲取排名前 3 的使用者 ： zrevrange board 0 396 lisi85 zhangsan72 wangwu
檢視zhaoliu的排行 ：zrank board zhaoliu 返回 4
Redis 過期策略
記憶體是寶貴的，磁碟是廉價的給key設定過期時間後，redis對這批key是定期刪除+惰性刪除定期刪除：redis 預設每隔 100ms隨機抽取一些設定了過期時間的 key，檢查其是否過期了，如果過期就刪除。注意：redis是每隔100ms隨機抽取一些 key來檢查和刪除，而不是遍歷所有的設定過期時間的key（否則CPU 負載會很高，消耗在檢查過期 key 上）惰性刪除：獲取某個key的時候， redis 會檢查一下，這個key如果設定了過期時間那麼是否過期，如果過期了則刪除。如果定期刪除漏掉了許多過期key，然後你也沒及時去查，也沒走惰性刪除，如果大量過期的key堆積在記憶體裡，導致 redis 記憶體塊耗盡，則走記憶體淘汰機制。
記憶體淘汰策略：
- noeviction:當記憶體不足以容納新寫入資料時，新寫入操作直接報錯（沒人用）
- allkeys-lru: 當記憶體不足以容納新寫入資料時，在鍵空間中，移除最近最少使用的key（最常用）
- allkeys-random: 當記憶體不足以容納新寫入資料時，在鍵空間中，隨機移除某個 key，(沒人用)
- volatile-lru:當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，移除最近最少使用的key(不合適)
- volatile-ttl:當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，有更早過期時間的 key 優先移除(不合適)
LRU 演演算法：
package com.mousycoder.mycode;
import java.util.LinkedHashMap;
import java.util.Map;
/**
* @version 1.0
* @author: mousycoder
* @date: 2019/10/31 17:55
*/
public class LRUCache<K,V> extends LinkedHashMap<K,V> {
private final int CACHE_SIZE;
public LRUCache( int cacheSize) {
super((int)Math.ceil(cacheSize / 0.75) + 1,0.75f,true);
this.CACHE_SIZE = cacheSize;
}
@Override
protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
return size() > CACHE_SIZE;
}
public static void main(String[] args) {
LRUCache<Integer,Integer> lruCache = new LRUCache<>(10);
for (int i = 0; i < 15; i++) {
lruCache.put(i,i);
}
Integer integer1 = lruCache.get(0);
for (Integer integer : lruCache.keySet()) {
System.out.println(integer);
}
}
}
複製程式碼Redis 高併發和高可用
快取架構（多級快取架構、熱點快取）redis 高併發瓶頸在單機，讀寫分離，一般是支撐讀高併發，寫請求少，也就 一秒一兩千，大量請求讀，一秒鐘二十萬次。
主從架構
Redis Replication
核心機制：
- redis 採用非同步方式複製資料到 slave 節點
- 一個 master node是可以配置多個 slave node的
- slave node也可以連線其他的 slave node
- slave node 做複製的時候，是不會 block master node的正常工作
- slave node 在做複製的時候，也不會 block對自己的查詢操作，它會用舊的資料集來提供服務。但是複製完成時，需要刪除舊資料集，載入新的資料集，這個時候就會暫停對外服務了。
- slave node 主要用來進行橫向擴容，做讀寫分離，擴容 slave node 可以提高讀的吞吐量
master持久化對主從架構的意義：如果開啟了主從架構，一定要開啟 master node的持久化，不然 master宕機重啟資料是空的，一經複製，slave的資料也丟了
主從複製原理：
- 當啟動一個 slave node的時候，它會傳送一個 PSYNC 命令給 master node
- master 會觸發一次 full resynchronization （如果不是第一次連線，master 只會複製給 slave 部分缺少的資料，從backlog裡找）
- master會啟動一個後臺執行緒，開始生成一份 RDB 快照（ bgsave,也可以直接在記憶體中建立），同時將從客戶端收到的所有寫命令快取在記憶體中。RDB 檔案生成完畢之後，master會將這個RDB傳送給slave，slave會先寫入本地磁碟，然後再從本地磁碟載入到記憶體中。然後 master會將記憶體中快取的寫命令傳送給 slave,slave也會同步這些資料（slave如果跟 master網路故障，斷開連線，會自動重連，master如果發現有多個 slave 來重新連線，僅僅只會啟動一個 RDB save 操作，用一份資料服務所有 slave node）
正常情況下：
master 來一條資料，就非同步給 slave
Redis高可用性
全年 99.99%的時間，都是出於可用的狀態，那麼就可以稱為高可用性redis 高可用架構叫故障轉移，failover，也可以叫做主備切換，切換的時間不可用，但是整體高可用。sentinal node(哨兵)
Sentinal
作用：
- 叢集監控，負責監控 redis master 和 slave程式是否正常
- 訊息通知，如果某個 redis 例項有故障，那麼哨兵負責傳送訊息作為報警通知給管理員
- 故障轉移，如果 master 掛掉，會自動轉移到 slave
- 配置中心，如果故障轉移了，通知 client 客戶端新的 master地址
兩節點哨兵叢集
三節點哨兵叢集（經典）
Redis 主從 + 哨兵
丟資料：
- master記憶體中資料非同步同步到 slave master 就掛掉了,丟掉了 master 記憶體中的資料
- 腦裂，某個 master 所在機器突然脫離了正常的網路，其他 slave機器不能連線，但是實際上 master還在執行，哨兵認為 master 宕機，選舉 slave為master，此時叢集裡有 2 個 master,client還沒來得及切換到新的master，還繼續寫在舊的 master上，資料丟了，此時舊的 master再次恢復，被被作為一個 slave 掛到新的 master 上，自己的資料被清空 （腦裂，大腦一分為 2，同時指揮同一個人）
解決方案：
- min-slaves-max-lag 10 （至少一個 slave同步的延遲不能超過 10s） 減少非同步複製的資料丟失，發現slave複製資料和 ack延時過長，拒絕寫入，減少同步資料損失。讓client做降級寫到本地磁碟裡和限流，或者先暫存到訊息佇列，然後重新發回 master
- min-slaves-to-write 1 減少腦裂帶來的資料丟失，最多損失 10 s資料，假設master 不能繼續給 slave傳送資料，並且 slave 10s沒給自己的 ack訊息，直接拒絕客戶端寫請求，同時 client做降寫到本地磁碟、限流，或者先暫存到訊息佇列，然後重新發回 master
哨兵
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）選舉演演算法：
- 如果slave跟master斷開連線已經超過 down-after-milliseconds * 10 + master宕機時間，則放棄
- 按 slave 優先順序排序 ，slave-priority 越小越靠前
- replica offset ，哪個slave複製越多的資料，越靠前
- runid 越小，越靠前
quorum 數量哨兵認為odown->選舉一個哨兵切換->獲得 majority哨兵的授權（quorum = majority 需要 quorum 哨兵授權）第一個選舉出來的哨兵切換失敗了，其他哨兵等待 failover-time之後，重新拿confiuration epoch做為新的version 切換，保證拿到最新配置，用於 configuration傳播（通過 pu/sub訊息機制，其他哨兵對比 version 新舊更新 master配置）
Redis 優化方案
高併發：主從架構高容量：Redis叢集，支援每秒幾十萬的讀寫併發高可用：主從+哨兵
Redis 持久化
持久化的意義在於故障恢復資料備份（到其他伺服器）+故障恢復（遇到災難，機房斷電，電纜被切）
- RDB 對 Redis 中的資料執行週期性的持久化。
- AOF 機制，每條寫命令作為日誌，以 append-only模式寫入一個日誌檔案總，在 redis重啟的時候，可以通過回放AOF日誌中的寫入指令來重新構建整個資料集
AOF 只有一個，Redis 中的資料是有一定限量的，記憶體大小是一定的,AOF 是存放寫命令的，當大到一定的時候，AOF 做 rewrite 操作，就會基於當時 redis 記憶體中的資料，來重新構造一個更小的 AOF 檔案，然後將舊的膨脹很大的檔案給刪掉，AOF 檔案一直會被限制在和Redis記憶體中一樣的資料。AOF同步間隔比 RDB 小，資料更完整
RDB
優點：
- RDB 會生成多個資料檔案，每個資料檔案都代表了某一個時刻中 redis 的資料，這種多個資料檔案的方式，非常適合做冷備，可以將這種完整的資料檔案傳送到一些遠端的安全儲存上去，RDB 做冷備，生成多個檔案，每個檔案都代表某一個時刻的完整的資料快照，AOF 也可以做冷備，只有一個檔案，每隔一定時間去 copy一份這個檔案出來。 RDB 做冷備，由Redis控制固定時長去生成快照檔案，比較方便。AOF，需要自己寫指令碼定時控制。
- RDB 對 redis對外提供的讀寫服務，影響非常小，可以讓 redis 保持高效能，因為 redis 主程式只需要 fork一個子程式，讓子程式執行磁碟 IO 操作來進行 RDB 持久化
- 相對於 AOF 持久化機制來說，直接基於 RDB 資料檔案來重啟和恢復 redis 程式，更加快速
缺點： - 如果想要在 redis故障時，儘可能少丟資料，那麼 RDB 沒有 AOF 好，一般 RDB 資料快照，都是間隔 5 分鐘，或者更長的時候生成一次，這個時候就得接受一旦 redis 程式宕機，那麼會丟失最近 5 分鐘資料
- RDB 每次在 fork子程式來執行 RDB 快早資料檔案生成的時候，如果資料檔案特別大，可能會導致對客戶端提供的服務暫停數毫秒，甚至數秒（RDB 生成間隔不要太長）
AOF 存放的指令日誌，資料恢復的時候，需要回放執行所有指令日誌，RDB 就是一份資料檔案，直接載入到記憶體中。
AOF
優點：
- 更好保護資料不丟失，後臺執行緒 fsync 操作，最多丟失一秒鐘資料，保證 os cache中的資料寫入磁碟中
- AOF 用 append-only 模式，沒有磁碟定址開銷，寫入效能非常高，檔案不容易損壞。
- AOF 日誌過大的時候，後臺 rewrite log時候，老的日誌檔案照常寫入，新的merge後的日誌檔案 ready的時候，再交換新老日誌檔案
- 適合災難性恢復，某人不小心 flushall清空所有資料，只要後臺 rewrite還沒發生，那麼可以立刻拷貝 AOF 檔案，將最後一條 flushall命令給刪了，然後再將該 AOF 檔案放回去，可以通過恢復機制，自動恢復所有資料
缺點：
- AOF 日誌檔案比 RDB 資料快照檔案大
- 降低 Redis的寫 QPS
- AOF 複雜，Bug多
- 資料恢復比較慢
最佳方案
AOF 來保證資料不丟失，RDB 做不同時間的冷備
Redis Cluster
資料量很少，高併發 -> replication + sentinal 叢集海量資料 + 高併發 + 高可用 -> redis cluster
分散式演演算法
hash演演算法->一致性 hash 演演算法-> redis cluster->hash slot演演算法
redis cluster :自動對資料進行分片，每個 master 上放一部分資料，提供內建的高可用支援，部分master不可用時，還是可以繼續工作cluster bus 通過 16379進行通訊，故障檢測，配置更新，故障轉移授權，另外一種二進位制協議，主要用於節點間進行高效資料交換，佔用更少的網路頻寬和處理時間
hash演演算法
key進行hash，然後對節點數量取模，最大問題只有任意一個 master 宕機，大量資料就要根據新的節點數取模，會導致大量快取失效。
一致性 hash 演演算法
Hash Slot演演算法
redis cluster 有固定 16384 個 hash slot,對每個key計算 CRC16 值，然後對16384取模，可以獲取 key對應的 hash slotredis cluster 中每個 master 都會持有部分 slot,當一臺 master 宕機時候，會最快速度遷移 hash slot到可用的機器上（只會短暫的訪問不到）走同一個 hash slot 通過 hash tag實現
Redis Cluster 核心
- 基礎通訊
通過 gossip 協議通訊（小道留言，所有節點都持有一份元資料，不同的節點如果出現了元資料的變更，就不斷將元資料傳送給其他節點，讓其他節點也進行元資料的變更）
叢集元資料：包括 hashslot->node之間的對映表關係，master->slave之間的關係，故障的資訊
叢集元資料集中式儲存（storm），底層基於zookeeper（分散式協調中介軟體）叢集所有元資料的維護。好處：元資料的更新和讀取，時效性好，一旦變更，其他節點立刻可以感知。缺點：所有元資料的更新壓力全部集中在一個地方，可能會導致元資料的儲存有壓力。
goosip: 好處：元資料的更新比較分散，有一定的延時，降低了壓力。缺點：更新有延時，叢集的一些操作會滯後。（reshared操作時configuration error） - 10000 埠
自己提供服務的埠號+ 10000 ，每隔一段時間就會往另外幾個節點傳送ping訊息，同時其他幾點接收到ping之後返回pong - 交換的資訊
故障資訊，節點的增加和移除， hash slot 資訊 - gossip協議
meet:某個節點傳送 meet給新加入的節點，讓新節點加入叢集中，然後新節點就會開始於其他節點進行通訊
ping:每個節點都會頻繁給其他節點傳送ping，其中包含自己的狀態還有自己維護的叢集元資料，互相通過ping交換元資料
ping:返回ping和meet，包含自己的狀態和其他資訊
fail:某個節點判斷另一個節點fail之後，就傳送 fail 給其他節點，通知其他節點，指定的節點宕機了 - ping訊息
ping 很頻繁，且攜帶元資料，會加重網路負擔
每個節點每秒會執行 10 次 ping，每次選擇 5 個最久沒有通訊的其他節點
當如果發現某個節點通訊延遲達到了 clusternodetimeout /2 ，那麼立即傳送 ping， 避免資料交換延遲過長，落後時間太長（2 個節點之間 10 分鐘沒有交換資料，整個叢集處於嚴重的元資料不一致的情況）。
每次ping，一個是帶上自己的節點資訊，還有就是帶上1/10其他節點的資訊，傳送出去，進行資料交換
至少包含 3 個其他節點資訊，最多包含總節點-2 個其他節點的資訊 - JRedis原理
- 請求重定向
客戶端傳送到任意一個redis例項傳送命令，每個redis例項接受到命令後，都會計算key對應的hash slot，如果在本地就本地處理，否則返回moved給客戶端，讓客戶端進行重定向 （redis-cli -c） - hash slot
通過tag指定key對應的slot,同一個 tag 下的 key，都會在一個 hash slot中，比如 set key1:{100} 和 set key2:{100} - smart jedis
本地維護一份hashslot->node的對映表。
JedisCluster 初始化的時候，隨機選擇一個 node，初始化 hashslot->node 對映表，同時為每個節點建立一個JedisPool連線池，每次基於JedisCluster執行操作，首先JedisCluster都會在本地計算key的hashslot，然後再本地對映表中找到對應的節點，如果發現對應的節點返回moved，那麼利用該節點的元資料，更新 hashslot->node對映表（重試超過 5 次報錯） - hashslot遷移和ask重定向
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 個請求走降級，返回一些預設 的值，或者友情提示好處 ：
- 資料庫絕對不會死，確保了每秒只會過去 2000 個請求
- 只要資料庫不死，對於使用者來說 2/5的請求可以被處理
- 系統沒死，使用者多點幾次可能就刷出來了
快取穿透
快取與資料庫雙寫一致性
- cache aside pattern
讀的時候，先讀快取，快取沒有，就讀資料庫，然後取出資料後放入快取，同時返回響應
更新的時候，刪除快取，更新資料庫
為什麼不更新快取：
更新快取代價太高（更新 20 次，只讀 1 次），lazy思想，需要的時候再計算，不需要的時候不計算 - 修改資料庫成功，刪除快取失敗，導致資料庫是新的資料，快取中是舊的資料
方案：先刪除快取，再修改資料庫 - 修改資料庫還沒修改完，同時又有查詢請求，把舊的資料放到快取中（高併發，每秒併發讀幾萬，每秒只要有資料更新請求，就可能出現資料庫+快取不一致情況）
方案：寫，讀路由到相同的一個記憶體佇列（唯一標識，hash，取模）裡，更新和讀操作進行序列化（後臺執行緒非同步執行佇列序列化操作），（佇列裡只放一個更新查詢操作即可，多餘的過濾掉，記憶體佇列裡沒有該資料更新操作，直接返回 ）有該資料更新操作則輪詢取快取值，超時取不到快取值，直接取一次資料庫的舊值
TP 99 意思是99%的請求可以在200ms內返回
注意點：多個商品的更新操作都積壓在一個佇列裡面（太多操作積壓只能增加機器），導致讀請求發生大量的超時，導致大量的讀請求走資料庫
一秒 500 寫操作，每200ms，100 個寫操作，20 個記憶體佇列，每個佇列積壓 5 個寫操作，一般在20ms完成
Redis 併發競爭問題
Redis 叢集部署架構
10臺機器，5 主 5 從，每個節點QPS 5W ，一共 25W QPS（Redis cluster 32G + 8 核 ，Redis 程式不超過 10G）總記憶體 50g，每條資料10kb，10W 條資料1g，200W 條資料 20G，佔用總記憶體不到50%，目前高峰期 3500 QPS
本文由部落格一文多發平臺 OpenWrite 釋出！