前段時間開發上線了乙個cache池，使用雙層cache池冗餘，宕掉一台機器的cache失效從1/n降到1/n^2。如果2層cache池分開機器部署，失效率將會降到0。上線不久剛好碰上一次宕機事故，效果很好。該應用有16臺cache伺服器，高峰時每秒訪問約20萬次，平時的命中率約為99.95%，宕掉一台會給8臺db造成1.25萬次/秒訪問（因為命中率很高所以只計算宕機造成的cache失效率），基本上不可能承受，以往遇到此類問題時，只能幹等著高峰慢慢過去、壓力降下來、同時cache命中率緩慢提高，影響時間至少4 小時以上。使用雙層冗餘cache池以後，單台cache宕機給db造成的壓力是1/256，約780次/秒，分攤到8臺db上就沒多少壓力了，對業務沒有造成任何影響。
cache是有狀態服務，增加、刪除伺服器都要考慮資料一致性、對命中率的影響，這方面[url=都是使用bdb/qdbm來做持久化儲存，但把cache持久化是否合適？後端資料量太大以後，也會因為io太大而效能低下，bdb效能會從幾十萬/秒降到幾百/秒，更新操作很可能會丟棄或延遲，意味著犧牲了一致性，雖然有非同步更新但也無法解決效能問題。運營中發現cache容量從每台30gb(bdb)降到2－4gb，cache命中率下降其實很少，效能卻提高了不少，可以完全放在記憶體中。
原打算在memcached的基礎上開發（或者是使用它的協議），經考查有幾個問題，就放棄掉了：
[list]
[*]memcached的slab劃分方式，不利於大小資料混合，考慮一種極端情況：開始時寫的資料全都是100位元組的，把記憶體全部用完；此時再想分配 200位元組，就沒有記憶體可用，由於我們的資料量非常大，隨著使用者資料的增長很容易出現這種情況。它沒有一種有效的記憶體碎片**機制。
[*] memcached的文字協議沒有流水號，只能同步阻塞方式呼叫。udp協議要自己實現許多功能，比如流量控制、丟失重傳等。
[*] 雙層冗餘cache池還設計了一套類似於分布式儲存系統的快速遷移機制，一旦一台cache掛掉後就直接放棄裡面的所有資料，重啟後直接從其它節點遷移過來填充，遷移效率取決於網路頻寬，極短的時間就可以把命中率提高到正常水平，減少系統風險。由於有雙層cache冗餘，在擴容時cache失效率也接近0，比consistent hashing還要高，當然每層cache還是使用consistent hashing來減少擴容時的cache失效率。在memcached的**上增加這些功能，得到的好處太少。
[/list]
cache 是自己開發的，基於記憶體整理的**方式。記憶體硬體的效率非常高，一般伺服器記憶體頻寬都可以達到幾gb/s，因此沒有太擔心效率問題。乙個page上的小塊資料可以一起**，多個邏輯連續的page分組進行空間整理，可以保證每個操作至多處理n個page（n<10）。記憶體整理的開銷完全分攤，實際測試一次cache操作最快只要幾微秒，最慢幾百微秒，壓力測試可以達到80萬/秒，完全滿足業務需要。
架構要素 高可用性
實現高可用架構的主要手段是資料和服務的冗餘備份及失效轉移。高可用的應用 應用層主要處理 應用的業務邏輯，因此也稱業務邏輯層，應用的乙個顯著特點是應用的無狀態。所謂無狀態的應用是指應用伺服器不儲存業務的上下文資訊，而僅根據每次請求提交的資料進行相應的業務邏輯處理，多個服務例項 伺服器 之間完全對等，請...
三 vault 高可用性
高可用 vault用於生產環境的私密資訊管理，基於此，vault服務死機會影響到下游的所有使用者，vault被設計的支援高可用部署，降低一台機器或乙個程序宕掉時的破壞性，設計概述 vault的設計目的在於使其在短時間宕機時能保障vault的高可用，而不是水平可伸縮性。vault通常受限於與儲存庫 s...
Vertica 高可用性測試
vertica也是mpp架構的資料庫，相比大家熟悉的mpp架構，比如greenplum和hadoop這些產品，vertica最大的不同就是沒有主節點這個概念。也就是說vertica集群中 k safe 1情況 任何乙個節點宕機都不會影響到其他節點對外提供服務。而在其他有主節點的架構中，一旦主節點掛掉...