轉載：https://www.cnblogs.com/aspirant/p/6820262.html
redis常見問題和解決方案
持久化、主從問題
(1) Master最好不要做任何持久化工作，如RDB內存快照和AOF日志文件
(a)Master寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫內存快照。
(b)Master AOF持久化，如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復速度。Master最好不要做任何持久化工作，包括內存快照和AOF日志文件，特別是不要啟用內存快照做持久化,如果數據比較關鍵，某個Slave開啟AOF備份數據，策略為每秒同步一次。
(c)Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會占大量的CPU和內存資源，導致服務load過高，出現短暫服務暫停現象。
(2) 如果數據比較重要，某個Slave開啟AOF備份數據，策略設置為每秒同步一次
(3) 為了主從復制的速度和連接的穩定性，Master和Slave最好在同一個局域網內
(4) 盡量避免在壓力很大的主庫上增加從庫
(5) 主從復制不要用圖狀結構，用單向鏈表結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3…
這樣的結構方便解決單點故障問題，實現Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。
Hashtag(可以實現批量操作)
Redis計算槽時並非只簡單的計算鍵值內容，當鍵值內容包括大括號時，則只計算括號內的內容（Hashtag）。比如：key為user:{10000}:books，計算hash值只計算10000。
Redis事務
Redis事務是一些列redis命令的集合：watch redisKey；multi .......exec。
生產上采用的是Redis Cluster集群架構，不同的key是有可能分配在不同的Redis節點上的，在這種情況下Redis的事務機制是不生效的。其次，Redis事務不支持回滾操作，簡直是雞肋！所以基本不用！
Redis的多數據庫機制
Redis支持多個數據庫，並且每個數據庫的數據是隔離的不能共享，單機下的redis可以支持16個數據庫（db0 ~ db15）。
但是，在Redis Cluster集群架構下只有一個數據庫空間，即db0。因此，我們沒有使用Redis的多數據庫功能！
Redis集群機制不足的地方
1. 鍵的批量操作支持有限，比如mset, mget，如果多個鍵映射在不同的槽，就不支持了
2. 鍵事務支持有限，當多個key分布在不同節點時無法使用事務，同一節點是支持事務
3. 鍵是數據分區的最小粒度，不能將一個很大的鍵值對映射到不同的節點
4. 不支持多數據庫，只有0，select 0
5. 復制結構只支持單層結構，不支持樹型結構
Redis集群模式下，如何進行批量操作
如果執行的key數量比較少，就不用mget了，就用串行get操作。如果真的需要執行的key很多，就使用Hashtag保證這些key映射到同一台redis節點上。
如果你用的是Proxy分片集群架構，例如Codis這種，會將mget/mset的多個key拆分成多個命令發往不同得redis實例。
Redis做讀寫分離有什么問題
不做讀寫分離。我們用的是Redis Cluster的架構，是屬於分片集群的架構。而redis本身在內存上操作，不會涉及IO吞吐，即使讀寫分離也不會提升太多性能，Redis在生產上的主要問題是考慮容量，單機最多10-20G，key太多降低redis性能.因此采用分片集群結構，已經能保證了我們的性能。其次，用上了讀寫分離后，還要考慮主從一致性，主從延遲等問題，徒增業務復雜度。
大文本數據必須壓縮再存儲
對於大文本【+超過 500 字節】寫入到 Redis 時，一定要壓縮后存儲。大文本數據存入 Redis，除了帶來極大的內存占用外，在訪問量高時，很容易就會將網卡流量占滿，進而造成整個服務器上的所有服務不可用，並引發雪崩效應，造成各個系統癱瘓。
線上 Redis 禁止使用 Keys 正則匹配操作
redis 是單線程處理，在線上 KEY 數量較多時，操作效率極低【時間復雜度為 O(N)】，該命令一旦執行會嚴重阻塞線上其它命令的正常請求，而且在高 QPS 情況下會直接造成 Redis 服務崩潰！如果有類似需求，請使用 scan 命令代替！
線上禁止使用 monitor 命令
實時打印出 Redis 服務器接收到的命令，調試用。在高並發條件下，會存在內存暴增和影響 Redis 性能的隱患。
與tair的對比選型
1、公司可運維性
2、數據結構類型，明顯redis數據結構多
3、數據量，redis數據存在內存，肯定沒有tair的數據量大
4、安全性，tair數據有持久化，一般不丟數據。redis的持久化相對差
5、性能的話，redis好點，畢竟內存讀寫。redis支持的value的大小更大(理論上1G 256M)
6、都沒有單點。tair的config node也有備份節點
如何借助 有序集合 實現多維排序
有序集合默認情況下只能根據一個因子score進行排序。如此一來，局限性就很大。
例如：熱門排行榜需要按照下載量&最近更新時間&其他因子排序，即類似數據庫中的ORDER BY downloadcount, updatetime DESC。那這樣的需求如果用有序集合該如何實現呢？
事實上很簡單，思路就是將涉及排序的多個維度的列通過一定的方式轉換成一個特殊的列，即result = function(x, y, z)，即x，y，z是三個排序因子，例如下載量、時間等，通過自定義函數function()計算得到result，將result作為有序集合中的score的值，就能實現任意維度的排序需求了。