Redis，就是這么樸實無華
Redis是2009年發布的，到今天已經超過10歲了。作為必備技能之一，關于它也有聊不完的話題。本文中的任何一個點，都可以展開，完成一篇中等規模的文章。
交流和面試時，你需要用最精準的語言進行描述，那么本文比較適合你。
redis能力：
- 1 0W/s QPS (redis-benchmark)
- 1w+ 長鏈接 (netstat / ss)
- 最復雜的Zset 6kw數據 寫入1k/s 讀取5k/s 平均耗時5ms
- 持久化 (rdb)
1. 基本概覽
學習一門新語言，重要的是掌握它的基本數據結構，以及這些數據結構的API。redis的這些數據結構，就類似一門語言。
Redis數據結構
常用5種，一共10種。面試時一般回答5種即可，但其他5種是加分項。
- String字符串
- Hash 字典
- List 列表
- Set集合
- ZSet 有序集合。性能參考：《redis的zset有多牛?請把耳朵遞過來》
- Pubsub 發布訂閱 (不推薦使用，坑很多)
- Bitmap 位圖
- GEO 地理位置 (有限使用，附近的人)
- Stream 流(5.0) (與Kafka非常像)
- Hyperloglog 基數統計
Redis的協議
Redis是文本協議
- RESP 以CRLF結尾(\r\n)
- RESP3 (redis6啟用，增加客戶端緩存)
Redis底層數據結構
數據量較小和大數據量的時候，往往不同，關注大數據量的主要結構。
- String-sds
- Hash-(ziplist , dict)
- Set-(intset,dict)
- List-(ziplist,quicklist)
- ZSet-(ziplist+skiptable 跳表)
- Stream-(radix-tree 基數數)
跳表的關注度比較大，在Java中，可以參考類似ConcurrentSkipListMap實現。
另：Java中有序Set叫做TreeSet，但是用紅黑樹實現的，注意區別。
Redis持久化方式
生產環境，一般僅采用RDB模式。
- RDB
- AOF (類似Binglog row模式)
- 混合模式：RDB+AOF
O(n)指令
- keys *
- hgetall
- smembers
- sunion
- ...
建議在集合大小不確定的時候，使用scan hscan sscan zscan 替代。另外，像keys這種危險命令，最好使用RENAME指令給屏蔽掉。
性能優化
- unlink刪除key -> 異步避免阻塞
- pipeline批量傳輸，減少網絡RTT ->減少頻繁網絡交互
- 多值指令(mset，hmset)-> 減少頻繁網絡交互
- 關掉aof -> 避免io_wait
擴展方式
- lua
- redis-module
module模式知道的人比較少，屬于比較底層的開發。
2. 問題排查
- monitor指令 回顯所有執行的指令。可以使用grep配合過濾
- keyspace-events 訂閱某些Key的事件。比如，刪除某條數據的事件，底層實現基于pubsub
- slow log 顧名思義，滿查詢，非常有用
- --bigkeys啟動參數 Redis大Key健康檢查。使用的是scan的方式執行， 不用擔心阻塞
- memory usage key、memory stats 指令
- info指令，關注instantaneous_ops_per_sec、used_memory_human、connected_clients
- redis-rdb-tools rdb線下分析
3. 淘汰策略
如果你應聘的是redis dba，這道題答不出來，直接淘汰。
- 被動刪除 (只有被get到的時候，刪除并返回NIL 屬于惰性刪除)
- 主動刪除 (100ms運行一次，隨機刪除持續25ms，類似Cron)
- ->內存使用超過maxmemory，觸發主動清理策略
針對于第三種情況，有8種策略。注意，redis已經有LFU了。
- 默認volatile-lru 從設置過期數據集里查找最近最少使用
- volatile-ttl 從設置過期的數據集里面優先刪除剩余時間短的Key
- volatile-random 從設置過期的數據集里面任意選擇數據淘汰
- volatile-lfu 從過期的數據集里刪除 最近不常使用 的數據淘汰
- allkeys-lru
- allkeys-lfu
- allkeys-random 數據被使用頻次最少的,優先被淘汰
- no-enviction
如果不設置maxmemory,Redis將一直使用內存，直到觸發操作系統的OOM-KILLER。
4. 集群模式
- 單機
- 單機多實例
- 主從(1+n)
- 主從(1+n)& 哨兵(3或者基數個)
- Redis Cluster (推薦，但使用有限制)。參考：《與親生的Redis Cluster，來一次親密接觸》
互聯網建議使用Redis Cluster，外包、項目隨意。
大規模
- twemproxy
- codis
- 基于Netty Redis協議自研
- 管理平臺：CacheCloud
5. Redis常見問題
Redis使用場景
- 緩存 (緩存一致性 緩存穿透 緩存擊穿 緩存雪崩)
- 分布式鎖 (redlock)
- 分布式限流
- Session
API舉例：
- zset 排行榜，排序
- bitmap 用戶簽到，在線狀態
- geo 地理位置，附近的人
- stream 類似kafka的消息流
- hyperloglog 每日訪問ip數統計
緩存一致性
為什么有一致性問題?
- 寫入。緩存和數據庫是兩個不同的組件，只要涉及到雙寫，就存在只有一個寫成功的可能性，造成數據不一致。
- 更新。更新的情況類似，需要更新兩個不同的組件。
- 讀取。讀取要保證從緩存中讀到的信息是最新的，是和數據庫中的是一致的。
- 刪除。當刪除數據庫記錄的時候，如何把緩存中的數據也刪掉?
建議使用：Cache Aside Pattern
讀請求：
- 先讀cache，再讀db
變更操作：
- 先操作數據庫，再 淘汰 緩存
涉及到復雜的事務和回滾操作，可以把淘汰放在finally里。
問題：緩存淘汰失敗!(概率很低 ，定時補償)
緩存擊穿
影響，輕微。
高流量下 大量請求讀取一個失效的Key -> Redis Miss -> 穿透到DB
解決方式：采用分布式鎖，只有拿到鎖的第一個線程去請求數據庫，然后插入緩存
緩存穿透
影響，一般。
訪問一個不存在的Key(惡意攻擊)-> Redis Miss -> 穿透到DB
解決方式：
- 給相應的Key設置一個Null值，放在緩存中
- BloomFilter預先判斷
緩存雪崩
影響：嚴重。
大量Key同時失效 | 2.Redis當機 -> Redis Miss -> 壓力打到DB
解決方式：
- 給失效時間加上相對的隨機數
- 保證Redis的高可用
分布式鎖
redis的分布式鎖，并不是那么簡單。建議使用redisson的redlock。最基礎的指令是setnx。
- setnx-> SET key value [EX seconds|PX milliseconds|KEEPTTL] [NX|XX] [GET]
分布式鎖 關鍵點：
- 原子性
- 鎖超時
- 死鎖
- 讀寫鎖
- 故障轉移
最簡單的Redis分布式鎖代碼(不嚴謹)。
java端代碼模擬lock和unlock。
- public String lock(String key, int timeOutSecond) {
- for (; ; ) {
- String stamp = String.valueOf(System.nanoTime());
- boolean exist = redisTemplate.opsForValue().setIfAbsent(key, stamp, timeOutSecond, TimeUnit.SECONDS);
- if (exist) {
- return stamp;
- }
- }
- }
- public void unlock(String key, String stamp) {
- redisTemplate.execute(script, Arrays.asList(key), stamp);
- }
lua腳本unlock。
- local stamp = ARGV[1]
- local key = KEYS[1]
- local current = redis.call("GET",key)
- if stamp == current then
- redis.call("DEL",key)
- return "OK"
- end
6. Redis使用
常用Java客戶端
- lettuce SpringBoot默認,基于Netty的事件驅動模型
- jedis 老牌的客戶端，使用commons-pool來完成線程池開發
- redisson 非常豐富的分布式數據結構，包括鎖，分布式Map等。大量使用Lua腳本?
使用規范
根據公司情況自定義裁剪，沒有萬能的規范。更多：
這可能是最中肯的Redis規范了
- 使用連接池，不要頻繁創建關閉客戶端連接
- 消息大小限制 消息體在10kb以下，可以使用snappy、msgpack等壓縮
- 避免大key和hot key
- 不使用O(n)指令
- 不使用不帶范圍的Zrange指令
- 不使用database(容易覆蓋數據)
- 不使用高級數據結構(使用基本的5種)
- 不使用事務操作
- 禁止長時間monitor
springboot cache redis
- 使用時更要注意規范性
- cache層抽象層次太高，如需要操作底層的數據結構，直接使用redisTemplate
Redis是多線程?
要看哪個階段。數據操作階段，一直是單線程的，哪怕是redis6。
作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。
