緣起

工作上接手一個redis相關專案，幫專案做一些優化與維護，分享一些實務經驗，該專案只是單純將資料push到redis，然後由其他服務pop出來處理

前言

多個docker和redis服務，都是放同機器上

問題

上prod之前，最後的test環境，都已經過壓測，對於redis的time out時間設定(ctx,read,write,pool)，已經找到合理的值，

在redis server端，有做AOF和RDB，確保資料不會遺失，到prod後的部署階段，發現程式會一直出現time out問題，

但test環境用的是同一顆image， redis的conf和版本環境都一樣，兩邊要push的資料大小和速度都是ㄧ致，當下找問題花了蠻多時間

解決

後來發現是資源競爭造成，因為該機器上有多個docker服務，在test環境，這些服務並不一定同時間有被壓測，但在prod環境部署階段，

在有限部署時間內，大家都想要確認沒問題，這些服務都同時間被壓測，導致硬碟IO過高，影響redis AOF和RDB的備份速度，

回頭影響單線程的redis服務，導致time out，後來直接對redis的docker做硬碟限制，也成功還原出狀況

後記

雖然redis是記憶體DB，其問題癥結點有用AOF和RDB時，當硬碟資源不夠時，就會影響運行，當問題常常出現，就要考慮把redis獨立出來，避免和其他服務搶資源

事後回想，應該在test環境做系統及壓測，但機器上有其他部門的服務在上面，如何溝通協調，每次有改動，要求他們配合，這可能又是另一個挑戰了

還是應該從主動限制docker資源下手，去估算自己寫的服務可能的表現，避免影響其他服務