rabbitmq和redis都是常用的中介軟體和快取系統。分別簡單記錄一下他們的分散式叢集方案。以備後用

Rabbitmq: 普通叢集與mirror queue

http://blog.csdn.net/whycold/article/details/19413399

Redis:

1. 最簡單的主從方案：支援master和slave的配置，通過配置檔案進行切換。一般用指令碼進行配置和切換。

2. Jedis&Sentinel實現Redis叢集高可用方案，該方案需要使用Jedis2.2.2及以上版本（強制），Redis2.8及以上版本(可選，Sentinel最早出現在Redis2.4中，Redis2.8中Sentinel更加穩定)，Redis叢集是以分片(Sharding)加主從的方式搭建，滿足可擴充套件性的要求；

通過Sentinel監控主從例項，自動進行故障恢復，該方案有個缺陷：因為主從例項地址(IP&PORT)是不同的，當故障發生進行主從切換後，應用程式無法知道新地址，故在Jedis2.2.2中新增了對Sentinel的支援，應用通過redis.clients.jedis.JedisSentinelPool.getResource()取得的Jedis例項會及時更新到新的主例項地址

參考: http://www.tuicool.com/articles/naeEJbv

附錄：Redis使用的重要點

1.rdb/aof Backup!

我們線上的Redis 95%以上是承擔後端儲存功能的，我們不僅用作cache，而更為一種k-v儲存，他完全替代了後端的儲存服務（MySQL），故其資料是非常重要的，如果出現數據汙染和丟失，誤操作等情況，將是難以恢復的。所以備份是非常必要的！為此，我們有共享的hdfs資源作為我們的備份池，希望能隨時可以還原業務所需資料。

2.Small item & Small instance!

由於Redis單執行緒（嚴格意義上不是單執行緒，但認為對request的處理是單執行緒的）的模型，大的資料結構list,sorted set,hash set的批量處理就意為著其他請求的等待，故使用Redis的複雜資料結構一定要控制其單key-struct的大小。

另外，Redis單例項的記憶體容量也應該有嚴格的限制。單例項記憶體容量較大後，直接帶來的問題就是故障恢復或者Rebuild從庫的時候時間較長，而更糟糕的是，Redis rewrite aof和save rdb時，將會帶來非常大且長的系統壓力，並佔用額外記憶體，很可能導致系統記憶體不足等嚴重影響效能的線上故障。我們線上96G/128G記憶體伺服器不建議單例項容量大於20/30G。