程式設計中，如何用好緩衝？，程式設計中用好緩衝

程式設計中，如何用好緩衝？，程式設計中用好緩衝

緩衝是最佳化系統效能最常用的方式之一，通過在耗時組件（如資料庫）之前添加緩衝，可以減少實際調用次數，降低回應時間。但是在引入緩衝之前，務必三思而後行。本文通過一些引入緩衝時的常見錯誤，對如何用好緩衝提供了一些建議。
一.常見錯誤
1.啟動時緩衝
有時候，我們會發現應用程式啟動很慢，最終發現是其中一個依賴的服務回應時間很長，這時該怎麼辦？
通常來說，遇到這類問題，說明這個依賴服務無法滿足需求。如果這是一個第三方服務，控制權不在自己手上，這時我們可能會引入緩衝。
此時引入緩衝的問題，是緩衝失效策略難以生效，因為緩衝設計的本意就是儘可能少的請求依賴的服務。
2.過早緩衝
這裡提到“早”，不是應用程式的生命週期，而是開發的周期。有的時候我們會看見，一些開發人員在開發初期就已經估算出系統瓶頸，並引入緩衝。
事實上，這樣的做法掩蓋了可能進行效能最佳化的點。反正到時候這個服務的傳回值會被緩衝住，我幹嘛還要花時間去最佳化這部分代碼呢？
3.整合緩衝
SOLID原則中的“S”代表——單一功能原則（Single responsibility principle）。當應用程式整合緩衝模組之後，緩衝模組和服務層就有了強耦合，無法在沒有緩衝模組的參與下單獨運行。
4.緩衝所有內容
有的時候為了降低響應延遲，可能會盲目的對外部調用都加上緩衝。事實上，這樣的行為很容易讓開發人員和維護者無法意識到緩衝模組的存在，最終對底層相依模組的可靠性做出了錯誤的評估。
5.級聯緩衝
緩衝所有內容，或者只是緩衝了大部分內容，可能會導致快取資料中包含其他快取資料。
如果應用程式中包含這種級聯的緩衝結構，可能導致的情況是緩衝失效時間不可控。最上層的緩衝需要等每一級緩衝都失效更新之後，最終返回的資料才會徹底更新。
6.不可重新整理緩衝
通常情況下，緩衝中介軟體會提供一個重新整理緩衝的工具。例如Redis，維護人員可以通過其提供的工具，刪除部分資料，甚至重新整理整個緩衝。
但是，一些臨時緩衝，可能不會包含這樣的工具。例如簡單的將資料儲存在內容中的緩衝，通常不會允許外部工具來修改或者刪除緩衝內容。這時，如果發現快取資料異常，維護人員只能採取重啟服務的方式，這將大大增加營運成本和回應時間。更有甚者，一些緩衝可能會將緩衝內容寫在檔案系統中進行備份。此時除了重啟服務，還需要確保應用程式啟動之前刪除檔案系統上的緩衝備份。
7.緩衝帶來的影響
上面提到了引入緩衝可能導致的常見錯誤，這些問題在無緩衝系統中通過不會考慮。
部署一個重度依賴緩衝的系統，可能會因為等待緩衝失效而花費大量時間。例如通過CDN緩衝內容，系統發布之後去重新整理CDN配置、CDN緩衝的內容，可能需要幾個小時。
另外，出現效能瓶頸優先考慮緩衝，會導致效能問題被掩蓋，得不到真正的解決。事實上，很多時候調優代碼花費的時間，和引入緩衝組件不會相差太多。
最後，對於包含緩衝組件的系統，調試成本會大大增加。經常會發生追蹤半天代碼，結果資料來自緩衝，和實際邏輯上應該依賴的組件沒有任何關係。同樣的問題也可能出現在執行了所有相關測試案例之後，修改到的代碼實際沒有被測試到。
二.如何用好緩衝？
1.放棄緩衝！
好吧，很多時候緩衝是無法避免的。基於互連網的系統，很難完全避免使用緩衝，甚至連http協議頭，都包含緩衝配置：Cache-Control: max-age=xxx。
2.瞭解資料
如果要將資料訪問緩衝，首先需要瞭解資料更新策略。只有明確瞭解資料何時需要更新，才能通過If-Modified-Since頭來判斷用戶端請求的資料是否需要更新，是簡單返回304 Not Modified響應讓用戶端複用之前的本機快取資料，還是返回最新資料。另外，為了更好利用http協議中的緩衝，建議給資料區分版本，或者利用eTag來標記快取資料的版本。
3.最佳化效能而不是使用緩衝
使用緩衝往往會將潛在效能問題掩蓋。儘可能利用效能分析工具，找到應用程式響應緩慢的真實原因並且修複它。例如減少無效代碼調用，根據SQL執行計畫最佳化SQL等。
三.總結
緩衝是非常有用的工具，但極易被濫用。不到最後一刻不要使用緩衝，優先考慮使用其他方式最佳化應用程式效能。