緩存集羣防止數據庫井噴

   使用緩存數據庫能夠有效的提高系統性能，可是基於因爲緩存數據庫的自身特性，相比起實例化數據庫，在性能抖動，丟失方面，尤爲是緩存失效的嚴重問題層面，處理不足，及其容易帶來，對底層數據庫的瞬間併發訪問，形成數據庫的宕機。

  因此，最好的方案，能夠考慮，略微下降性能，在緩存的集羣上面，仿照實例化數據庫實現一些代理方案，這樣能夠實現相似zoonkeeper概念的一直死活控制。

 如今緩存數據庫，比較常見的是：

 1：支持併發的高效率，無磁盤負責的memcached,自身不支持集羣方案，必須走代理；

 2：讀寫相對均衡的單線程的redis,自身支持無缺的集羣方案，並有可選的實例化方案，實例化與對外業務是從屬於不一樣的線程。

 3：不支持併發的大數據緩存，文檔型數據庫，mongodb，其內部設計，採用了，異常壓制方案，出了問題，比較難以調式，自身有很好的集羣能力。

 實現緩存的集羣方案是很好的，這樣能夠很好的下降了底層數據庫的擴張與成本，且性能遠大於底層數據庫實現的分佈式或者集羣。惟一的關鍵點，是作好底層數據庫與緩存數據庫之間的保護屏障，因而，站在巨人的肩膀上面，能夠選擇以下方案：

 Twitter的Redis/Memcached代理服務：Twemproxy

   Twemproxy是一個使用C語言編寫的Redis 和 Memcache 代理服務器，經過引入一個代理層，將應用程序後端的多臺Redis或Memcached實例進行統一管理，使應用程序只須要在Twemproxy上進行操做，而不用關心後面具體有多少個真實的Redis或Memcached實例。當某個節點宕掉時，Twemproxy能夠自動將它從集羣中剔除，而當它恢復服務時，Twemproxy也會自動鏈接。因爲是代理，因此Twemproxy會有微小的性能損失。 

   不管從底層實現或者其給出的功能，都是絕佳的可選方案。問題是限制在了reids或者memcached的，應該能夠知足絕大部分的場景。

  Facebook的Memcached協議路由器：McRouter

   McRouter是一個使用C++（主要語言，使用了大量的C++ 11特性）開發的基於Memcached協議的路由器，它是Facebook和Instagram緩存架構的核心組件，在高峯時期能夠處理近50億請求。McRouter中客戶端能夠共享鏈接池，這樣能減小鏈接的數量。McRouter能夠根據key前綴把客戶端分配到不一樣的Memcached池中，容許以主機、池或者集羣爲單位設置任何請求的速率的閥值,同時也支持限制請求的速度以減緩請求的發送速度，以保障服務質量。

  鍾愛於併發的可選方案。

Youtube的Mysql中間件：Vitess

緩存層存在的初衷是減小應用與數據庫的交互，以提升響應時間，與其將緩存與數據庫分離，不如直接將緩存嵌入數據庫中。Vitess是Youtube的開源分佈式MySQL工具集，主要使用Go語言編寫，已經用於Youtube生產環境。Vitess支持行級緩存，並與Memcached進行了集成，能夠有效提升帶主鍵查詢的速率，查詢只有在Memcached中查詢不到時纔會進入數據庫查詢，而當數據被修改或者數據庫表結構發生變化時，緩存數據會被刪除。

近來對mysql的nosql化呼聲較高，惋惜看這個數據庫如今半死不活的架勢，不知道後面會被甲骨文怎麼捯飭。

   mongodb的目前沒有，應該是其自身的方案難以超越吧。相對與memcached，mongo即沒有線程的概念，更談不上併發，v8引擎，解釋着C代碼，可是，在妥善的控制客戶端併發訪問句柄的前提下，其基於事件隊列的訪問速度，絕不遜色，只是，因爲其超時機制，不知道是使用難以得當，仍是實現的有問題，老是會在密集訪問下面，致使不少客戶端線程把服務端卡住。基於大數據概念的文檔鬆散型數據結構，每每使人慾罷不能。

  mongodb若是跟memcached的合二爲一，那真是當真的完美了。