針對大流量瞬間沖擊，比如秒殺場景
redis前面可以加一層限流 sentinel ／ Hystrix
redis高並發（讀多寫少）下緩存數據庫雙寫誤差：
1. 修改操作使用分布式鎖（就是修改的時候加鎖，一次只能有一個線程修改，可以多線程讀），對於讀多的場景更有利；推薦（以較少的性能代價換取了絕對的一致）
2. 延遲刪除緩存
修改一個key后，刪除緩存，為了防止之前有線程讀過舊數據然后再次寫入，sleep 10毫秒再刪除一次，但此步要后台處理，不然可能會大幅降低整體性能。
3. 寫直接寫入數據庫，通過canal等中間件訂閱binlog，然后將變化應用到緩存，緩存只提供讀操作； 可能存在讀延遲
多讀寫也多
1. 使用消息中間件，不推薦使用redis緩存
2. 直接使用數據庫都比再加個緩存快，尤其那些高速寫入又馬上查詢，甚至還會統計分析的業務。
Redis緩存的超時時間
要把這個因素的考慮，貫穿到所有場景。要根據自己的業務場景來設定超時時間
被動刪除：過期的key不會立即刪除，會在下次被get時刪除。
主動刪除：定期主動刪除過期key
不推薦方案－一個大redis集群后面多個數據庫
這相當於讓並發集中在redis那里了，不僅沒有提升性能，還降低了性能
要讓redis集群與數據庫集群一一對應，拆分開來
如果這樣都行，那么直連數據庫也沒啥問題； 那問題來了，為啥還要浪費一堆資源弄個redis集群呢？
Redis連接池配置
對於高並發場景，配置maxTotal = maxIdle，即減少了連接創建與銷毀的資源； 非高並發的場景不要這么配，因為連接的存在也是耗費資源的。
連接池預熱。Redis的連接是用時才生成，如果你知道某個時間點（定點秒殺，一天都沒有啥請求，就等那個時間點）會瞬間生成大量連接，可以使用使用jedis.ping()提前生成一些連接。