我一直在想，在我們的中國及海外客戶不斷快速成長的情況下，如何能夠更好地擴展他們的網站，卻保持其原有網站內容及結構仍舊簡單可用。
一個擴展方法便是，採用數據庫副機來實現讀操作，讀操作在很多網站上表現爲80%以上的SQL查詢，但是對於遊戲類網站而言，讀操作的SQL查詢佔比不盡相同。標準的方法就是，實行讀/寫分離，即數據庫主機實現寫操作，而副機實現讀操作。
這樣一切工作就會很順利，但是，當許多因素，尤其是有大量的MySQL查詢出現的時候，副機會產生延遲現象，而且尤其是在遊戲類、數據採集類及統計類網站中，當有大量的寫操作時，情況會變的更糟糕，這樣讀操作會延遲數秒，甚至更長，導致用戶無法正常操作、站點甚至遊戲無法正常運行。
但是，若僅允許讀操作在主機上實現的話，又會影響到系統擴展，所以，一些站點對讀操作進行區分，重要的讀操作在主機上實現，次要的在副機上實現，但問題是，很難區分出哪些是“不重要的”讀操作，在遊戲中區分出不重要的讀操作更加困難。
若某些副機出問題的話，情況會變得更復雜，當只有幾臺服務器承擔大量的查詢負荷、複雜工作、或數據分析工作時，會使副機延遲現象加重。副機1工作正常，但是突然副機2連續一個小時滯後1分鐘，然後，副機3出現代碼問題，因爲有人在該機執行了寫操作導致複製中止，需即刻修復。
那麼，如何才能夠最好地處理該問題呢？
一個好的主意，就是進行動態的讀/寫分離，運用某個系統來監控系統的複製延遲現象，理想的情況是，在緩存中設置一些標記（旗幟），用以顯示副機的真實狀態並控制查詢去向。基本的處理方式就是，設置一些桶（鬥），用於顯示延遲在1秒內、10秒內、1分鐘內甚至更多的時間內的副機。
然後，帶有重要讀操作的代碼可以檢查緩存頁面開始處，作出明智決定，發出讀操作，先是發到延遲較短的副機，繼而是延遲稍長的副機，最後是發到主機。
同其它動態控制系統一樣，當負荷很重，事務/請求/答覆很頻繁時，系統便會失控，（更不必說有振動及其它問題產生）。最好的方式就是，從簡單開始，實行有限控制，可運用卸載（甩負荷）技術，如時間延遲很長或主機讀數量很大時，禁止佔時較長的大型的讀查詢。
儘管系統不盡完善，但是能自動處理許多問題，尤其是自從配備了合適的系統監控及管理以後。在負荷高峯期，能夠處理單個副機乃至整個系統的延遲問題，確保在特定條件下，能夠提供最好的用戶體驗，並且在系統出問題時，不會帶來嚴重的影響。
（Authored by Steve Mushero / ChinaNetCloud CEO & CTO 本博客英文原文請點此查看）