Redis集群服务器-高可用调研随笔
今天改了一天的Bug，本想下午开始专研Redis命令集，结果也泡汤了。只能在下班的路上考虑下Redis集群服务器的高可用方案。随笔而已，尚未成型，仅作记录。
?当然，我说的可能比较片面，欢迎拍砖、斧正。
相同点：
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/OSCacheEhCache/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时，也可能存在单点故障风险。
1 楼 亡的剑指 2012-10-24 请问，如果用了多个Master-Slave组，write-master容易实现，但如何保证read-slave时读到存放数据的slave？ 2 楼 snowolf 2012-10-24 亡的剑指 写道请问，如果用了多个Master-Slave组，write-master容易实现，但如何保证read-slave时读到存放数据的slave？