聊聊內存存儲，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越來越高，離線計算、準實時以及其他存儲應用是值得去不斷探索的。
閱讀更多 架構師交流圈 的文章
