從rabbitmq談談基於redis的分佈式存儲系統的開發(1)

傳統的數據庫系統如mysql，在數據存儲的可靠性，以及數據多機房的分佈上能夠知足，可是大幾千甚至幾萬、幾十萬每秒的高併發讀寫請求上，因爲硬盤瓶頸，因此性能一般沒法知足，所以，在這種高併發請求的需求下，咱們選擇了redis這種nosql產品。

       redis基於內存的讀寫，有着卓越的性能，號稱能知足將近每秒10萬的讀寫請求，於是能知足咱們業務系統頻繁讀寫（數萬每秒）的需求。Redis支持string、hash、set、sorted set等類型的<key,value>數據讀寫頻繁，支持rdb和aof持久化，支持集羣功能，支持事務，支持訂閱和發佈功能，也支持主從同步等等，可是，redis不支持主主同步，因此在多機房的同步方面無能爲力。

       在主從同步方面，不管是sync仍是psync命令都是比較耗費資源的操做，在執行完整重同步方面，大都需通過如下一些步驟，包括主服務器經過BGSAVE命令生成RDB文件，此時會消耗大量CPU，內存和磁盤I/O；而後將生成的RDB文件發送給從服務器，此時會消耗大量帶寬；從服務器接收主服務器的RDB文件並載入內存，此時會阻塞其餘請求；或者對於psync命令的部分重同步，當redis之間因爲網絡緣由致使斷線，過了一段時間，從服務器從新連上主服務器，此時從服務器的複製偏移量可能已經不存在於主服務器的複製積壓緩衝區，所以，此時主從服務器之間也會執行完整重同步命令，像上述所說的，會是比較耗費資源的操做。

       在主主同步方面，在redis2.8以前的版本，假設有兩個redis服務器A和B，經過執行slaveof命令，成爲各自的從服務器，即A是B的從服務器，同時B也是A的從服務器，則當某個客戶端鏈接上其中一個服務器，而後執行一條簡單命令好比：setex hello 30 world,則會發現這條命令會反覆在A和B之間執行，經過ttl hello命令能夠看出，hello的ttl一直都是30，以下圖所示：

        

       由此致使redis服務器cpu狂飆，當在一臺服務器佈置幾個redis做爲一個集羣對外提供服務時，高併發的讀寫請求會致使服務器宕機，由下圖可見，僅執行一條redis命令，就致使了cpu達到50%左右。

        

       同時考慮，要在一個機房部署多個redis組成集羣對外提供服務，若是每一個redis之間都要經過slaveof進行主從同步，那麼當這些redis在某個時間段比較集中地進行完整重同步時，就要嚴重佔用機房帶寬資源，在redis2.8版以後，redis索性不支持兩個redis互爲主從，或者不容許從服務器執行寫命令，能夠在本身的機器上裝個redis試試。

       所以，從多機房高可用部署方面考慮，不宜直接使用redis的主從同步這一機制，固然若是隻是爲了簡單的主從部署方案，redis的主從同步是能夠考慮的。

       未完待續...

       轉載請註明出處：

       山水間博客：http://blog.csdn.net/linyanwen99/article/details/38513209