Redis集群服务器-高可用调研随笔[转]

今天改了一天的Bug，本想下午开始专研Redis命令集，结果也泡汤了。只能在下班的路上考虑下Redis集群服务器的高可用方案。随笔而已，尚未成型，仅作记录。 当然，我说的可能比较片面，欢迎拍砖、斧正。

一、Redis与MySQL对比

相同点：

 

• Master-Slave架构，集群架构下无法很好的完成数据拷贝，确保数据一致性。
• 支持数据文件持久化存储，但数据文件过大时，宕机重启可能存在安全隐患。

不同点：

 

• Redis时效性能远比MySQL要高得多，支持复杂的数据类型，基本上都是内存操作，效率远胜于MySQL。
• Redis是NoSQL型数据库，或者说是Store-Cache型数据库，而MySQL属于RDBMS，关系型数据库，虽然自身做了查询缓存，但效果一般。
• Redis支持以数据横向切分，便于根据业务需求扩展，键值构建类似于数据库索引，灵活高效，不必忌讳数据之间的关联。Redis依赖其数据类型，完成交集、并集、补集计算，更胜一筹。
• MySQL在数据量和连接数量上都有上限：单表数据量500万条记录，并发连接数3000/秒。
• Redis定时、定量将数据保存至本地，命中数据大部分存活在内存中，降低了数据文件读取消耗；数据更新，以内存修改为主，不存磁盘在IO消耗。

结论：

 

• 两者在高并发环境下，依靠自身的Master-Slave架构，完成横向扩容都存在难度。要控制每个实例的数据文件大小，留有足够的磁盘，内存空间。确保宕机后，服务可恢复。
• Redis更适合作为频繁查询为主，对数据进行交集、补集、并集操作，类似于SNS用户社区关联关系展现等，有着良好的数据类型支持，以及高效性。

二、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时，也可能存在单点故障风险。

 

三、基于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？单纯拷贝数据文件可解决单点到双点的实现。但多点服务器扩容，尚未做一致性哈希尝试，有一定的风险。