問題描述
用戶量快速增長，訪問量在短時間內翻倍，由于前期容量規(guī)劃做得比較好，硬件資源可以支撐，可是軟件系統(tǒng)方面出現(xiàn)了大問題：
40% 的請求都會返回 HTTP 500: Internal Server Error
通過查看日志，發(fā)現(xiàn)錯誤是在 PHP <-> Redis 的連接處理上
調試處理

第1次
剛開始時并沒有找到根本原因，只能嘗試各種與錯誤相關的辦法，例如：
增加 PHP 連接數(shù)，并把超時時間從 500ms 增加到 2.5s
禁止掉 PHP 設置中的 default_socket_timeout
在主機系統(tǒng)中禁止掉 SYN cookies
檢查 Redis 和 Webservers 的文件描述符數(shù)量
增加主機系統(tǒng)的 mbuffer
調整 TCP backlog 數(shù)量
……

嘗試了很多方法，但全部無效

第2次
想在預發(fā)布環(huán)境中重現(xiàn)這個問題，可惜，還是沒成功，應為流量不夠大，無法復現(xiàn)

第3次
會不會是代碼中沒有關閉 Redis 連接呢？
正常來講，PHP在執(zhí)行結束時會自動關閉資源連接，但老版本中會有內存泄漏的問題，保險起見，把代碼都修改一遍，手動關閉連接
結果還是無效

第4次
懷疑目標：phpredis 這個客戶端庫
做 A/B 測試，替換回 predis 這個庫，部署到數(shù)據(jù)中心中 20% 的用戶量上
得益于良好的代碼結構，替換工作很快完成
可結果依舊是無效，但也有好的一面，可以證明 phpredis 沒問題嘛

第5次
查看了一下 Redis 的版本，是 v2.6，當時最新版本是 v2.8.9
升級 Redis 試一下吧，升完后還是不行
沒事兒，要保持樂觀，這不順便把 Redis 版本升為最新的了

第6次
通過查找大量文檔，在官方文檔中發(fā)現(xiàn)了一個調試好方法 Redis Software Watchdog，打開后執(zhí)行：

查看 Redis 日志：

發(fā)現(xiàn)了問題：
每隔幾分鐘就向硬盤保存一次數(shù)據(jù)，fork 一個后臺存儲進行為什么需要大概 400ms（通過上面日志的第1條和第2條的時間可以看出來）

到這兒，終于找到問題的根源了，因為 Redis 實例中有大量的數(shù)據(jù)，導致每次持久化操作 fork 后臺進程時非常耗時，并且在他們的業(yè)務中經常修改key，又導致了頻繁觸發(fā)持久化，也就經常產生對 Redis 的阻塞

處理辦法：使用單獨的 slave 來做持久化

這個 slave 不處理真實的流量請求，唯一的作用就是處理持久化，把之前 Redis 實例上的持久化操作轉移到這個 slave 上

效果非常明顯，問題基本解決，但有的時候還是會報錯

第7次
排查可能阻塞 Redis 的慢查詢，發(fā)現(xiàn)有地方使用了 keys *

因為 Redis 中的數(shù)據(jù)越來越多，這個命令自然會產生嚴重阻塞

可以使用 scan 進行替換

第8次
經過前面的調整，問題已經解決，隨后的幾個月，即使流量在不斷增長，也都抗住了

但他們意識到了新的問題：

現(xiàn)在的方式是，來一個請求就創(chuàng)建一個 Redis 連接，執(zhí)行幾個命令，然后再斷開連接，在請求量很大時，這個方式產生了嚴重的性能浪費，一半以上的命令是用來處理連接操作的，這都超過了業(yè)務邏輯上的處理，也使 Redis 變慢

解決方法：引入 proxy，他們選擇了 twitter 的 twemproxy，只需要在每個 webserver 上安裝代理，twemproxy負責與 Redis 實例進行持久連接，這樣就大大減少了連接方面的操作

twemproxy還有兩個方便的地方：

支持 memcached
可以阻止非常耗時或者危險的命令，例如 keys、flushall
效果自然很完美，再也不用擔心之前的連接錯誤

第9次
通過數(shù)據(jù)分片來繼續(xù)優(yōu)化：

對不同上下文的數(shù)據(jù)拆分隔離
對相同上下文的數(shù)據(jù)進行一致性哈希分片
效果：

減少了每臺機器上的請求、負載
提升了緩存的可靠性，不擔心節(jié)點故障

小結
原文作者寫的非常好，詳細的描述了他們在 Redis 應用上的成長歷程，是很值得參考的實踐經驗
原文地址http://tech.trivago.com/2017/01/25/learn-redis-the-hard-way-in-production