分布式理論系列本文主要摘要了一些主要的副本更新策略。
多個副本之間存在乙個主副本（master replica），其他副本為從副本，這種稱為主從更新策略。所有對資料的更新首先提交到主副本，再由主副本通知從副本進行資料更新。如果同時產生多個資料更新操作，由主副本決定不同更新操作的順序。
主副本等待所有從副本更新完成之後才確認更新操作完成，這樣確保資料的強一致性，但是會存在較大的請求延時，尤其是在多副本跨資料中心的情形下，因為請求延時取決於最慢的那個副本的更新速度。
主副本在通知從副本更新之前即可確認更新操作。假設主副本還沒有通知任何其他從副本就發生崩潰，那麼資料一致性可能會出現問題，一般首先在另外的可靠儲存位置將這次更新操作記錄下來，以防這種情況發生。
同步混合非同步，主副本首先同步更新部分從副本，然後確認更新操作完成，其他副本通關非同步方式獲得更新，kafka就是採用這種混合方式來維護資料副本的不一致性。
不區分主從副本，任意節點都可以接收請求，然後又它去通知其他副本進行更新。
存在和主從更新的型別a的情況，除此之外，為了識別出是否存在不同客戶端向不同副本傳送對同一資料的更新操作，還需要額外付出更多的請求延時
存在主從更新的b方式問題。
dynamo/cassandra/riak同時採取了主從式更新的型別c（同步+非同步），以及任意節點更新的策略。
快取更新策略
一般來說，快取有以下三種模式 cache aside更新模式 這種策略下，在併發寫的時候可能會出現髒資料的問題。read write through 更新模式 在read write through 更新模式中，應用程式只需要維護快取，資料庫的維護工作由快取 了。read through 模式就是在...
快取更新策略初探
這裡為什麼不讓更新操作在寫完資料庫之後，緊接著去把快取cache中的資料也修改了呢？主要是因為這樣做的話，就有2個寫操作的事件了，擔心在併發的情況下會導致髒資料，舉個例子 那麼 cache aside 模式就沒有髒資料問題了嗎？不是的，在極端情況下也可能會產生髒資料，比如 不過這種概率比上面一種概率...
網頁爬蟲 WebCrawler 更新策略
顧明思議，歷史參考策略是指根據頁面以往的歷史更新資料，該頁面未來何時會發生變化。一般來說，是通過泊松過程進行建模來 的。儘管搜尋引擎針對某個查詢條件能夠返回數量巨大的結果，但是使用者往往只關注前幾頁結果。因此，抓取系統可以優先更新那些在查詢結果中排名靠前的網頁，然後再更新排名靠後的網頁。這種更新策略...