Redis集羣服務器-高可用調研隨筆[轉]

今天改了一天的Bug，本想下午開始專研Redis命令集，結果也泡湯了。只能在下班的路上考慮下Redis集羣服務器的高可用方案。隨筆而已，還沒有成型，僅做記錄。 固然，我說的可能比較片面，歡迎拍磚、斧正。

1、Redis與MySQL對比

相同點：

 

• Master-Slave架構，集羣架構下沒法很好的完成數據拷貝，確保數據一致性。
• 支持數據文件持久化存儲，但數據文件過大時，宕機重啓可能存在安全隱患。

不一樣點：

 

• Redis時效性能遠比MySQL要高得多，支持複雜的數據類型，基本上都是內存操做，效率遠勝於MySQL。
• Redis是NoSQL型數據庫，或者說是Store-Cache型數據庫，而MySQL屬於RDBMS，關係型數據庫，雖然自身作了查詢緩存，但效果通常。
• Redis支持以數據橫向切分，便於根據業務需求擴展，鍵值構建相似於數據庫索引，靈活高效，沒必要忌諱數據之間的關聯。Redis依賴其數據類型，完成交集、並集、補集計算，更勝一籌。
• MySQL在數據量和鏈接數量上都有上限：單表數據量500萬條記錄，併發鏈接數3000/秒。
• Redis定時、定量將數據保存至本地，命中數據大部分存活在內存中，下降了數據文件讀取消耗；數據更新，之內存修改成主，不存磁盤在IO消耗。

結論：

 

• 二者在高併發環境下，依靠自身的Master-Slave架構，完成橫向擴容都存在難度。要控制每一個實例的數據文件大小，留有足夠的磁盤，內存空間。確保宕機後，服務可恢復。
• Redis更適合做爲頻繁查詢爲主，對數據進行交集、補集、並集操做，相似於SNS用戶社區關聯關係展示等，有着良好的數據類型支持，以及高效性。

2、Redis與Memcached，以及EhCache/OSCache

EhCache/OSCache、Memcached可謂是緩存架構裏的一朵朵奇葩。

 

• EhCache、OSCache在幾年前，都是小應用最喜歡使用緩存實現。尤爲是當應用之間不須要考慮數據一致性問題時，幾乎無所不能。但到了分佈式緩存時代，雖然二者也提供了相應的架構實現，但實現成本較高，且存在必定風險。例如EhCache，提供了EhCache Server架構，主要經過各個EhCache集羣網絡多播等方式同步數據。但高併發下，網絡多播易演變成網絡風暴。增長了系統安全隱患。
• Memcached走了另外一條路，經過一致性哈希根據Key與Server的Hash對應關係，或者餘數算法等，將數據散落在不一樣的Server上，確保每一個Server上都能平均Cache數據。也基緣於此，Memcached適合進行快速地橫向擴展。沒必要考慮磁盤存儲，只須要提供一個內存足夠大的Server主機便可。
• Memcached也有瓶頸，單個ObjectSize不得大於1MB，KeySize不得大於250個字符，Write要比Read耗時長，對大對象作Write Cache時尤其明顯。所以，Memcached適合小數據量對象的Cache。且當服務器宕機時，瘋漲的數據庫操做IO，極可能將數據庫服務器拖垮。

Redis能夠簡單理解爲 Store-Cache，用做 Cache： ObjectSize支持1GB， KeySize支持512Bytes，並支持複雜數據類型，可在內存中直接排序等。但 Redis不能像 Memcached那樣實現 Sharding，直接進行橫向擴展。且自身做爲 Database時，也可能存在單點故障風險。

 

3、基於Redis高可用服務器架構簡單設想

 

1. Redis以Master-Slave爲單元，公用虛擬IP，經過Keepalive實現自動切換，完成主從互備。
2. 經過Redis Client，如Jedis，在Client端完成Sharding，訪問多個Redis Server。
3. 讀寫分離，Write-Master，Read-Slave。
    未盡之處，若橫向擴容時，Client一致性哈希，是否會由原先的A Server指向，改成新進的C Server？單純拷貝數據文件可解決單點到雙點的實現。但多點服務器擴容，還沒有作一致性哈希嘗試，有必定的風險。