Redis 應用案例 - 在問題中不斷成長

背景

產品類型：酒店搜索

技術選型：前端 PHP + 后端 Java，都會用到 Redis

Redis 使用場景：緩存、數據持久化前的臨時存儲

2010年開始應用 Redis，PHP 對其操作時使用的是 Predis 這個客戶端庫

2013年改用了 phpredis 作為客戶端庫

2014年開始出現問題

問題描述

用戶量快速增長，訪問量在短時間內翻倍，由于前期容量規劃做得比較好，硬件資源可以支撐，可是軟件系統方面出現了大問題：

40%   的請求都會返回   HTTP 500: Internal Server Error

通過查看日志，發現錯誤是在 PHP <-> Redis 的連接處理上

調試處理

第1次

剛開始時并沒有找到根本原因，只能嘗試各種與錯誤相關的辦法，例如：

1. 增加 PHP 連接數，并把超時時間從 500ms 增加到 2.5s

2. 禁止掉 PHP 設置中的 default_socket_timeout

3. 在主機系統中禁止掉 SYN cookies

4. 檢查 Redis 和 Webservers 的文件描述符數量

5. 增加主機系統的 mbuffer

6. 調整 TCP backlog 數量

……

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

第2次

想在預發布環境中重現這個問題，可惜，還是沒成功，應為流量不夠大，無法復現

第3次

會不會是代碼中沒有關閉 Redis 連接呢？

正常來講，PHP在執行結束時會自動關閉資源連接，但老版本中會有內存泄漏的問題，保險起見，把代碼都修改一遍，手動關閉連接

結果還是無效

第4次

懷疑目標：phpredis 這個客戶端庫

做 A/B 測試，替換回 predis 這個庫，部署到數據中心中 20% 的用戶量上

得益于良好的代碼結構，替換工作很快完成

可結果依舊是 無效 ，但也有好的一面，可以證明 phpredis 沒問題嘛

第5次

查看了一下 Redis 的版本，是 v2.6，當時最新版本是 v2.8.9

升級 Redis 試一下吧，升完后還是 不行

沒事兒，要保持樂觀，這不順便把 Redis 版本升為最新的了

第6次

通過查找大量文檔，在官方文檔中發現了一個調試好方法 Redis Software Watchdog ，打開后執行：

$ redis-cli --latency -p 6380 -h 1.2.3.4
min: 0, max: 463, avg: 2.03 (19443 samples)

查看 Redis 日志：

...
[20398] 22 May 09:20:55.351 * 10000 changes in 60 seconds. Saving...
[20398] 22 May 09:20:55.759 * Background saving started by pid 41941
[41941] 22 May 09:22:48.197 * DB saved on disk
[20398] 22 May 09:22:49.321 * Background saving terminated with success
[20398] 22 May 09:25:23.299 * 10000 changes in 60 seconds. Saving...
[20398] 22 May 09:25:23.644 * Background saving started by pid 42027
...

發現了問題：

每隔幾分鐘就向硬盤保存一次數據，fork 一個后臺存儲進行為什么需要大概 400ms（通過上面日志的第1條和第2條的時間可以看出來）

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

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

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

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

第7次

排查可能阻塞 Redis 的慢查詢，發現有地方使用了 keys *

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

可以使用 scan   進行替換

第8次

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

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

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

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

twemproxy還有兩個方便的地方：

1. 支持 memcached

2. 可以阻止非常耗時或者危險的命令，例如 keys、flushall

效果自然很完美，再也不用擔心之前的連接錯誤

第9次

通過數據分片來繼續優化：

1. 對不同上下文的數據拆分隔離

2. 對相同上下文的數據進行一致性哈希分片

效果：

1. 減少了每臺機器上的請求、負載

2. 提升了緩存的可靠性，不擔心節點故障

小結

原文作者寫的非常好，詳細的描述了他們在 Redis 應用上的成長歷程，是很值得參考的實踐經驗

原文地址

http://tech.trivago.com/2017/01/25/learn-redis-the-hard-way-in-production

點擊 “閱讀原文” 查看 文章列表

 

來自：http://tech.trivago.com/2017/01/25/learn-redis-the-hard-way-in-production