聊聊 Redis 效能細節

聊聊記憶體儲存，redis作為分散式記憶體快取，效能極高，但是在高併發讀、高併發、大儲存量寫的場景下很多東西要注意，不然可能達不到預想效能效果。不能用透明方式去使用，而應該多去了解架構以及具體實現。不去了解細節，在高壓力應用下，可能會對線上服務造成很大影響，達不到高可用。

關於資料結構，資料結構redis支援很多種，現在要探討一件事不是這麼多種資料結構，而是在高併發場景下，儘量避免用哪些資料結構，儘量多用哪些資料結構，儘量避免應用資料結構是hash，包含set以及map，因為hash結構複雜既需要更大儲存空間，也需要更多計算才能將資料取出。

舉個以前線上遇到過的問題，就是線上用了很多set，因為在一些場景下過濾等等邏輯，用set很方面，但是卻對redis server不友好，對redis server壓力大。

線上還遇到過，定時拉取過多會導致tp999上升影響介面正常使用，這時就需要降低對於redis過於多的批量讀取，方式就是暫時減少redis server的壓力，等待redis server恢復正常後，拉取是沒有問題的，但後續還是要優化，儘量避免壓力過大。

線上還發生過單個大key對線上，直接在一個時間點服務突然效能就變得很低，並且每5分鐘一次，經定位是一個數據過大並且是通用資料，定時拉取每次定時拉取時整個redis叢集堵住，導致叢集吞吐下降tp99升高。

反推過去看是越小越好，批量奪取越小tp999會變得越小，他是一個動態服務，很難界定一個值多大為好。這就需要線上常年經驗積累以及對於線上問題不斷反思以及調整。

所有辦法都想了，對於儲存以及db架構，原理實現都有了解了就能避免問題嗎？答案是不一定，通過我們對架構理解能解決一部分問題，但還是有一些問題沒有了解到的，或是想不到的，這就需要我們有意外時備選方案，已做到我們能想到的萬無一失。

備選方案具體思路就是減少或者避免對redis依賴，通過本地記憶體來提供業務需要資料，切斷對redis依賴，避免因為redis效能波動導致線上業務效能波動，或者因為redis叢集出現比較嚴重問題，主從斷開、效能及其突然嚴重下跌，或者叢集不穩定，這些是比較極端情況，雖然很少遇到，屬於“黑天鵝”事件，但發生了會對線上業務有極大影響，一定要避免。

降級備選方案，在redis出現嚴重問題時啟用，可以採取基於zookeeper配置中心方式實現，通過配置下發來達到秒級降級，避免對線上業務造成影響，備選方案極其重要不可輕視。從根本上應該是想辦法讓線上服務讀的單個數據儘可能小，批量資料儘可能少，這樣就能讓tp999越來越高，離線計算、準實時以及其他儲存應用是值得去不斷探索的。