从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