从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.youkuaiyun.com/linyanwen99/article/details/38513209