Redis的使用非常簡單，只需要安裝配置一下就能輕松上線，短時間不會出現什么問題，但是隨著時間推移，Redis實體增多，客戶端呼叫繁雜，真正的問題開始出現，整個關系就變得非常亂，Redis從使用角度來講是需要像應用服務一樣去治理的，
下面先看一段日常開發程序中常見的對話：
開發：Redis為啥不能訪問了?
運維：剛剛服務器記憶體壞了，服務器自動重啟了，
開發：為什么Redis延遲這么久?
運維：大哥，不要在Zset里面放幾萬條資料，插入排序的后果很嚴重啊!
開發：寫進去的key呢，為什么不見了?
運維：你的Redis記憶體超過最大大小了，不常用的key都丟了呀!
開發：剛剛為啥讀取全部失敗了?
運維：剛剛網路臨時中斷了一下，slave全同步了，在全同步完成之前，slave的讀取全部失敗，
開發：我剛剛想到一個好方案，我需要800GB的Redis，什么時候能準備好呢?
運維：大哥，我們線上的服務器最大也就256GB，別玩這么大好嗎?一些常見策略以及其弊端：
1.單機不是不安全嗎?那么就開啟主從+Keepalived，用虛IP地址在master和 slave兩邊漂移,master掛了直接切換到slave，
主從+Keepalived 的方案，本來是個很好的方案，但是忽略了主資料節點掛掉的情況，Redis的單行程、單執行緒設計是其簡單和穩定的基石，只要不是服務器發生了故障，在一般情況下是不會掛的，但同時，單行程、單執行緒的設計會導致Redis接收到復雜指令時會忙于計算而停止回應，可能就因為一個Zset或者keys之類的指令，Redis計算時間稍長，Keepalived就認為其停止了回應，直接更改虛IP的指向，然后做一次主從切換，過不了多久，Zset和 keys之類的指令又會從客戶端發送過來，于是從機上又開始堵塞，Keepalived就一直在主從機之間不斷地切換IP，終于主節點和從節點都堵了，Keepalived發現后，居然直接將虛IP釋放了，然后所有的客戶端都無法連接Redis了，只能等運維到線上手工系結才行，
2.資料放記憶體不是不安全嗎?可以開啟資料落盤，根據業務需要決定落盤規則，有AOF的，也有RDB的，
資料落盤也引起了很大的問題，RDB屬于非阻塞式的持久化，它會創建一個子行程來專門把記憶體中的資料寫入RDB檔案里，同時主行程可以處理來自客戶端的命令請求，但子行程內的資料相當于是父行程的一個拷貝，這相當于兩個相同大小的Redis行程在系統上運行，會造成記憶體使用率的大幅增加，如果在服務器記憶體本身就比較緊張的情況下再進行RDB配置，記憶體占用率就會很容易達到100%，繼而開啟虛擬記憶體和進行磁盤交換，然后整個Redis的服務性能就直線下降了，
另外，Zset、發布訂閱、訊息佇列、Redis的各種功能不斷被介紹，開發者們也在利用這些特性，開發各種應用，但從來沒想過這么一個小小的Redis 有這么多新奇的功能，它的缺點在什么地方，什么樣的場景是不合適用的?這時Redis在大部分的開發者手上就是像是一把錘子，看什么都是釘子，隨時都一錘了事，同時也會漸漸地淡忘了開發的一些細節點和規范，因為用它解決性能的問題是那么輕松簡單，于是一些基于Redis的新奇功能就接連不斷地出現了:基于Redis的分布式鎖、日志系統、訊息佇列、資料清洗，等等，各種各樣的功能不斷上線使用，從而引發了各種各樣的問題，這時候原來那個救火神器就會變成四處點火的神器，Redis堵塞、網卡打爆、連接數爆表等問題層出不窮，經過這么多折騰，Redis終于也變成了大家的噩夢了，
總結以下幾點需要解決：
- 必須搭建完善的監控系統，在這之前要先預警，不能等到發生了，我們才發現問題，
- 控制和引導Redis 的使用，我們需要有自己研發的Redis客戶端，在使用時就開始控制和引導，
- Redis的部分角色要改，將Redis 由 storage角色降低為cache角色
- Redis的持久化方案要重新做，需要自己研發一個基于Redis協議的持久化方案，讓使用者可以把 Redis當DB用，
- Redis 的高可用要按照場景分開，根據不同的場景決定采用不同的高可用方案，
具體方案：
- 重建Redis客戶端，在客戶端內植入日志，記錄所有操作時間，如：耗時、key、value大小、網路斷開等，由一個收集程式進行分析和處理，
- 設定閾值報警，通知到運維系統，運維系統基于運維資料來自動故障轉移、擴容、分片、負載均衡等，
- 取消直接的IP埠連接方式，通過配置中心分配IP埠，當Redis發生問題需要切換時可直接在配置中心修改，由配置中心推送新的配置到客戶端，
- 解決研發人員使用Redis規范問題，將Redis的命令操作分為安全命令和不安全命令，安全命令可直接使用，不安全命令需要分析審核后才能打開，也由配置中心控制，
- 將Redis定位成快取角色，不做其他用途，
- Redis采用主從+哨兵的模式部署，通過一致性Hash演算法均衡分片，
- 做一個Redis的Proxy，提供統一的入口點，Proxy也可以集群部署，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/291109.html
標籤：其他