1.現狀描述

1.1.生產環境

生產環境配置6套 Redis 服務。

1、配置為3節點物理服務器的 Redis 緩存群集，通過控制應用的主、備處于不同的物理服務器實現 Redis 訪問的高可用，按不同的應用訪問配置對應的內存大小。

2、單臺物理服務器的 Redis 服務，主要用于應急備用資源。

【資料圖】

3、配置為3節點的虛擬服務器 Redis 集群，用于電商類應用。

4、單獨配置的IOT、智能門店、會員應用的緩存資源，使用 6.0.5版本。

生產環境的物理服務器群集采用 SSD 盤配置，Redis 的版本為4.0.1，硬盤同步的模式采用 AOF 數據持久化配置；

虛擬群集的Redis 版本為 6.0.5，取消 AOF 持久化配置，啟用新版本的多線程功能。

4、生產環境的 Redis 服務器集群配置開源性能監控軟件cacheCloud，通過GUI圖形方式呈現群集的慢查詢情況。

1.2.測試環境

試環境配置3臺 Redis 虛擬群集，在6月初配置升級為 6.0.5版本（由4.x 升級到 6.x）。版本升級完成后測試環境的應用數據訪問無異常。

2.故障現象

Redis主從頻繁切換導致業務訪問異常，出現無法登錄或頁面無響應的情況

3.故障原因

1、群集啟用持久化配置，磁盤寫入頻繁導致主從檢查超時引起自動切換

2、業務程序代碼緩沖池占用鏈接過多不釋放

3、Redis資源應用不規范，將緩存服務器當數據庫使用

4.問題分析

4.1.Redis AOF 存在IO瓶頸

集群采用 RDB 與 AOF 雙持久化的機制。其中RDB平均約2分鐘運行一次，持續時間為28秒，數據量為2700余萬左右；而AOF實時記錄寫操作，對master資源占用更高。對Linux服務器進行監控，觀察到15時左右寫入操作峰值約100MB/s，存在瞬時數據寫入壓力

4.2.Redis 使用不規范

例如wmXXXX系列和openid系列大量使用根目錄或者隨機目錄使用數據，未建立層級目錄（如外賣系統做的就比較好，可以借鑒），導致無法通過工具查看redis中數據，首先不利于運維查看，其次也不利于監控維護。

超時時間設置為-1的（永不刪除）的約占20%，超時時間大于1個小時的約占78%，兩者相加共占98%。大量數據超時時間設置為-1，導致無法利用Redis自動回收數據機制，降低查詢命中率，同時增加了數據的維護資源消耗。

4.3.Redis應用沒有讀寫分離

網絡資源消耗在主從切換時波動較大，切換時訪問流量自動遷移至master節點，而slave節點幾乎無訪問。

除切換主從引發的流量異常增加外，選取7月10日1:00~11:00數據進行觀察，觀察到只有Master發生讀寫，Slave幾乎無讀寫，只有數據同步引發的IO。

4.4.應用代碼緩沖池應用不規范

代碼緩沖池持續占用緩存服務器網絡連接，影響緩存服務器整體網絡性能

開發回收緩沖池后緩存群集穩定性提升（沒有出現自動切換報警）。其中 192.168.0.203占用的連接數由1.36K降為30、192.168.0.218由372降為124。

4.5.電商應用

優化前（2020-7-28）

Sampled 202749 keys in the keyspace!Total key length in bytes is 8949425 (avg len 44.14)

Biggest string found "001:002:003:groupon:activity:indexlist:" has 949198 bytesBiggest list found "addoplog" has 6365167 itemsBiggest set found "001:002:003:store:groupstore:20" has 22013 membersBiggest hash found "alipay:mp:coupon_user_get_count" has 1291419 fieldsBiggest zset found "001:002:003:store:geo:channel:1" has 21310 members

135631 strings with 66782153 bytes (66.90% of keys, avg size 492.38)6449 lists with 6818691 items (03.18% of keys, avg size 1057.33)38894 sets with 2347603 members (19.18% of keys, avg size 60.36)21770 hashs with 1521001 fields (10.74% of keys, avg size 69.87)5 zsets with 76302 members (00.00% of keys, avg size 15260.40)

優化后

192.18.5.145:9020

Sampled 16701335 keys in the keyspace!

Total key length in bytes is 755221587 (avg len 45.22)

Biggest string found "portal.mp_coupon_allstorecodeV1" has 840115 bytesBiggest list found "groupon:activity_user_behavior_list" has 4047488 itemsBiggest set found "portal:mp:sendgiftbaguser:" has 4182827 membersBiggest hash found "alipay:mp:coupon_user_get_count" has 7822308 fieldsBiggest zset found "alipay:store:geo:temp" has 24579 members

14805770 strings with 1318411927 bytes (88.65% of keys, avg size 89.05)12479 lists with 4583765 items (00.07% of keys, avg size 367.32)3284 sets with 4499371 members (00.02% of keys, avg size 1370.09)1879799 hashs with 12640365 fields (11.26% of keys, avg size 6.72)3 zsets with 45714 members (00.00% of keys, avg size 15238.00)0 streams with 0 entries (00.00% of keys, avg size 0.00)

解決方案

1、調整緩存群集內存空間、調整系統硬盤配置參數等基于服務器硬件的調整

2、增加臨時單主機獨立的 Redis服務器配置，遷移部分業務，如電商應用部分功能

3、增加電商、會員、IOT、智能門店的獨立Redis資源，獨立緩存版本升級為 6.0.3，啟用多線程支持。

4、增加服務器端口監控，調整業務程序代碼；調整緩存持久化配置參數

5、遷移業務應用到獨立緩存；會員、智能門店應用需要優化和調整代碼。