大型web網站緩衝策略設計概要

上篇對瘋狂代碼緩衝配置進行了概要的設計，可能說的有點模糊了，有幾個朋友發了幾個問題探討了下，這裡有必要先澄清一個問題，和常見的緩衝策略不同，我們的緩衝策略將重點放在更新策略而不是唯讀策略上。唯讀緩衝以及共性緩衝策略性質實現的難度並不大，我們要解決的是非共性緩衝，並發更新緩衝，可擴充性緩衝，分布式緩衝更新運算的問題，而對於共性的東西的話我們可以很輕鬆的實現，而不必做太多的運算。 試想一個問題，對於一個多使用者的並發的系統，如果對每個使用者都維護一份緩衝策略還要保證更新的及時性以及處理的必要性來說的話，我們很難想到一個有效處理機制來維護每份（每使用者）緩衝的副本的，緩衝的儲存性質也決定了做分布式緩衝策略處理的難度和分布式通訊更新的的難度，我們也很難嘗試對於一些訪問量很小且少有共性的頁面實現有效快取命中率，比如某某使用者的部落格。 簡單的總結了一下關於緩衝策略討論的重點 A.     基于海量非共性資料的緩衝策略 B.      基於資料緩衝層級並發更新的緩衝策略 C.     基於資料並發儲存的緩衝策略 D.     基於分布式的緩衝策略 E ．   基於搜尋的緩衝策略 我們這裡不再贅談關於頁面靜態化以及類似的問題，靜態化的情況非常適合在系統初期，使用者的基數並不算很大的情況下實現，而在涉及叢集的情況下，靜態化的實現成本，IO成本，維護成本，擴充成本以及更新成本會遠遠的超出緩衝策略的成本，當然我們也會有一套建立在緩衝基礎上的靜態化處理方案，這些放在以後再談。我們的目的是要建立一個可伸縮，便於維護擴充的緩衝策略，下面就具體問題進行分析。  對於問題A：常見的部落格系統就是一個最好的例子，每個使用者的首頁都是相對個性的資料，共性的地方不多，以常見的處理方案來說的話，我們可能需要維護每個使用者訪問的快取複本，而對於一些訪問量極小的部落格網站來說的話這種方式無疑會造成巨大的浪費。 對於大量非共性的資料緩衝來說，幾個處理方案： 1)      量化緩衝目標並分配相應的緩衝權值。（權值分級）目的很簡單，只緩衝有效資料。首先抽取活躍使用者，以及高訪問量使用者，將資料進行分組分權制緩衝（對於交友型的SNS系統來說，我們稱之為美女效應） 2)      非串連持久性的緩衝保持（臨時的持久性）珍惜並有效利用資料查詢，將未被快取命中時的查詢或者無權值的資料持久化儲存（序列化存貯靜態存貯等），當緩衝未被命中時優先取得持久化資料而非資料查詢。可以理解為臨時資料存貯，或者臨時存貯於子伺服器的某個位置。3)   基於資料更新的緩衝清除（一次性使用）當持久性緩衝保持失效（依賴資料發生修改），直接刪除臨時資料（緩衝只在訪問時被啟用並儲存，一旦修改或者失效，我們立刻拋棄）。 4） 緩衝更新代理規則
由另外的線程進行維護，並維護線程的有效性，最大限度的分離主程式對無效緩衝以及臨時持久性快取資料的清理   對於問題B：在小型緩衝策略中，緩衝處理對於整個應用程式對於每個請求來說都是唯一的，可操作的和非實體儲存體的。而在並發更新的過程中，一個小小的並發更新就會很現實的清空所有的緩衝池，造成快取命中率奇低而初始化率奇高而起不到緩衝策略應有的作用。 在這種情況下，處理方案也和A.4中提到的方案是一樣的，由獨立的緩衝更新進程來處理，對於應用程式中所有涉及緩衝更新的請求由專門的更新代理來執行。這個處理方案相對簡單，不再贅述。  對於問題Ｃ：上篇已經提到關於並發資料更新會帶來的問題也就是資料庫的I/O響應，逾時，死結，以及線程的阻塞問題。我們用一個寫入緩衝來處理這個方案，其實這個並非傳統意義上的讀緩衝，姑且命名為寫緩衝吧，我們可以形象的理解為類似硬碟緩衝區的問題。這裡處理的操作稍微有點多了，還要涉及唯讀緩衝的更新的問題了。 根據系統的不同，我們需要分析處理的角度也不同，我們以常見的webgame為例來簡單介紹一下處理機制，這裡有兩種常見的情況1） 對於 webgame的終端使用者玩家來說，每個線上使用者的資料是非共性的(問題A),而在一個戰鬥情境下，每組資料時刻都在變化之中，如果我們對資料的變化採用資料庫日誌記錄的形式儲存的情況顯然對Database的壓力很大，而我們需要記錄的僅僅是戰鬥的結果，戰鬥的過程我們完全沒有必要進行儲存，這個時候我們就用寫入緩衝來執行相應的資料操作。這個處理很簡單，用伺服器變數的形式就能解決他。2） 對於 webgame的伺服器角色來說，如果戰鬥情境的使用者量非常多，而資料更新非常大的情況下，我們採用方法1中的處理也可能力不從心，這個時候我們可以將緩衝來進一步的抽象，在某個時間段內（比如3分鐘），維護一個唯一的緩衝對象，所有的資料操作都在這個時間段來被緩衝進程來記錄，來更新。而由另外的一個進程來進行非同步定時的資料儲存操作。  對於問題D       這個是比較常見的分布式快取服務器組了，而對快取服務器來說其實要解決的問題就是伺服器間之間互相通訊的問題，並保證資料一致性的問題。那麼我們的有四個處理規則：1） 資料緩衝應該被有效分組並索引
目標是實現資料耦合的成都降到最低，甚至沒有耦合。比如以使用者ID為分割的資料緩衝分布，或者以文章分類為分割的緩衝分布2） 資料緩衝應該被有效更新
如果資料被有效分組完成後，這個就是問題C.2的方案了，和C.2不同的是，因為緩衝組可能未必在一組伺服器中，可能涉及緩衝和DATABASE資料通訊延遲的問題。這個時候要保證快取服務器被即時的傳遞到databse，那麼需要另外的一個緩衝檢測進程來完成這項工作（資料完整性檢查,並備份兩個緩衝段的資料）3） 快取服務器間的資料完整性
對於無法分組的資料，比如時間段內的使用者認證資料和資料資料，我們需要保證兩組資料同步，最好的處理方法就是清除相應的緩衝段，讓它在下次使用的時候初始化4） 快取服務器間的連通性
這個取決於物理線路，如果快取服務器在天南地北的話，我們還需要一個隊列進程來進行同步和資料矯正，我們稱之為緩衝路由。 對於問題E在分布式緩衝的情況下，多條件搜尋往往涉及多個快取服務器，處理起來筆者尚未有一套完善的出來方案。筆者用的是敷衍原則和整合原則了 敷衍原則：對於搜尋型的資料來說，很多情況下並不是非常重要，我們的搜尋結果完全可以晚一會提供給使用者，允許搜尋的資料有10分鐘或者更長時間的延遲。 整合原則將搜尋欄位和表整合出來，用獨立的唯讀查詢服務器來分擔負荷轉自：http://www.daxi8.cn/index.php/archives/153/