Redis的复制功能是完全建立在之前我们讨论过的基
于内存快照的持久化策略基础上的，也就是说无论你的持久化策略选择的是什么，只要用到了Redis的复制功能，就一定会有内存快照发生，那么首先要注意你
的系统内存容量规划，原因可以参考我上一篇文章中提到的Redis磁盘IO问题。
Redis复制流程在Slave和Master端各自是一套状态机流转，涉及的状态信息是：
Slave 端：
Master端：
整个状态机流程过程如下：
- Slave端在配置文件中添加了slave of指令，于是Slave启动时读取配置文件，初始状态为REDIS_REPL_CONNECT。
- Slave端在定时任务serverCron(Redis内部的定时器触发事件)中连接Master，发送sync命令，然后阻塞等待master发送回其内存快照文件(最新版的Redis已经不需要让Slave阻塞)。
- Master端收到sync命令简单判断是否有正在进行的内存快照子进程，没有则立即开始内存快照，有则等待其结束，当快照完成后会将该文件发送给Slave端。
- Slave端接收Master发来的内存快照文件，保存到本地，待接收完成后，清空内存表，重新读取Master发来的内存快照文件，重建整个内存表数据结构，并最终状态置位为 REDIS_REPL_CONNECTED状态，Slave状态机流转完成。
- Master端在发送快照文件过程中，接收的任何会改变数据集的命令都会暂时先保存在Slave网络连接的发送缓存队列里（list数据结构），待快照完成后，依次发给Slave,之后收到的命令相同处理，并将状态置位为 REDIS_REPL_ONLINE。
整个复制过程完成，流程如下图所示：
从上面的流程可以看出，Slave从库在连接Master主库时，Master会进行内存快照，然后把整个快照文件发给Slave，也就是没有象MySQL那样有复制位置的概念，即无增量复制，这会给整个集群搭建带来非常多的问题。
比如一台线上正在运行的Master主库配置了一台从
库进行简单读写分离，这时Slave由于网络或者其它原因与Master断开了连接，那么当Slave进行重新连接时，需要重新获取整个Master的内
存快照，Slave所有数据跟着全部清除，然后重新建立整个内存表，一方面Slave恢复的时间会非常慢，另一方面也会给主库带来压力。
所以基于上述原因，如果你的Redis集群需要主从复制，那么最好事先配置好所有的从库，避免中途再去增加从库。
在我们分析过了Redis的复制与持久化功能后，我们不难得出一个结论，实际上Redis目前发布的版本还都是一个单机版的思路，主要的问题集中在，持久化方式不够成熟，复制机制存在比较大的缺陷，这时我们又开始重新思考Redis的定位：Cache还是Storage？
如果作为Cache的话，似乎除了有些非常特殊的业务场景，必须要使用Redis的某种数据结构之外，我们使用Memcached可能更合适，毕竟Memcached无论客户端包和服务器本身更久经考验。
如果是作为存储Storage的话，我们面临的最大的问题是无论是持久化还是复制都没有办法解决Redis单点问题，即一台Redis挂掉了，没有太好的办法能够快速的恢复，通常几十G的持久化数据，Redis重启加载需要几个小时的时间，而复制又有缺陷，如何解决呢？
1.
主动复制避开Redis复制缺陷。
既然Redis的复制功能有缺陷，那么我们不妨放弃Redis本身提供的复制功能，我们可以采用主动复制的方式来搭建我们的集群环境。
所谓主动复制是指由业务端或者通过代理中间件对
Redis存储的数据进行双写或多写，通过数据的多份存储来达到与复制相同的目的，主动复制不仅限于用在Redis集群上，目前很多公司采用主动复制的技
术来解决MySQL主从之间复制的延迟问题，比如Twitter还专门开发了用于复制和分区的中间件gizzard(https://github.com/twitter/gizzard)
。
主动复制虽然解决了被动复制的延迟问题，但也带来了新
的问题，就是数据的一致性问题，数据写2次或多次，如何保证多份数据的一致性呢？如果你的应用对数据一致性要求不高，允许最终一致性的话，那么通常简单的
解决方案是可以通过时间戳或者vector
clock等方式，让客户端同时取到多份数据并进行校验，如果你的应用对数据一致性要求非常高，那么就需要引入一些复杂的一致性算法比如Paxos来保证数据的一致性，但是写入性能也会相应下降很多。
通过主动复制，数据多份存储我们也就不再担心Redis单点故障的问题了，如果一组Redis集群挂掉，我们可以让业务快速切换到另一组Redis上，降低业务风险。
通过主动复制我们解决了Redis单点故障问题，那么还有一个重要的问题需要解决：容量规划与在线扩容问题。
我们前面分析过Redis的适用场景是全部数据存储在
内存中，而内存容量有限，那么首先需要根据业务数据量进行初步的容量规划，比如你的业务数据需要100G存储空间，假设服务器内存是48G，那么根据上一
篇我们讨论的Redis磁盘IO的问题，我们大约需要3~4台服务器来存储。这个实际是对现有业务情况所做的一个容量规划，假如业务增长很快，很快就会发
现当前的容量已经不够了，Redis里面存储的数据很快就会超过物理内存大小，那么如何进行Redis的在线扩容呢？
Redis的作者提出了一种叫做presharding的方案来解决动态扩容和数据分区的问题，实际就是在同一台机器上部署多个Redis实例的方式，当容量不够时将多个实例拆分到不同的机器上，这样实际就达到了扩容的效果。
拆分过程如下：
- 在新机器上启动好对应端口的Redis实例。
- 配置新端口为待迁移端口的从库。
- 待复制完成，与主库完成同步后，切换所有客户端配置到新的从库的端口。
- 配置从库为新的主库。
- 移除老的端口实例。
- 重复上述过程迁移好所有的端口到指定服务器上。
以上拆分流程是Redis作者提出的一个平滑迁移的过程，不过该拆分方法还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。
我们线上的系统使用了我们自己改进版的Redis,主要解决了Redis没有增量复制的缺陷，能够完成类似Mysql Binlog那样可以通过从库请求日志位置进行增量复制。
我们的持久化方案是首先写Redis的AOF文件，并
对这个AOF文件按文件大小进行自动分割滚动，同时关闭Redis的Rewrite命令，然后会在业务低峰时间进行内存快照存储，并把当前的AOF文件位
置一起写入到快照文件中，这样我们可以使快照文件与AOF文件的位置保持一致性，这样我们得到了系统某一时刻的内存快照，并且同时也能知道这一时刻对应的
AOF文件的位置，那么当从库发送同步命令时，我们首先会把快照文件发送给从库，然后从库会取出该快照文件中存储的AOF文件位置，并将该位置发给主库，
主库会随后发送该位置之后的所有命令，以后的复制就都是这个位置之后的增量信息了。
目前大部分互联网公司使用MySQL作为数据的主要持久化存储，那么如何让Redis与MySQL很好的结合在一起呢？我们主要使用了一种基于MySQL作为主库，Redis作为高速数据查询从库的异构读写分离的方案。
为此我们专门开发了自己的MySQL复制工具，可以方便的实时同步MySQL中的数据到Redis上。
（MySQL-Redis 异构读写分离）
总结：
- Redis的复制功能没有增量复制，每次重连都会把主库整个内存快照发给从库，所以需要避免向在线服务的压力较大的主库上增加从库。
- Redis的复制由于会使用快照持久化方式，所以如果你的Redis持久化方式选择的是日志追加方式(aof),那么系统有可能在同一时刻既做aof日志
文件的同步刷写磁盘，又做快照写磁盘操作，这个时候Redis的响应能力会受到影响。所以如果选用aof持久化，则加从库需要更加谨慎。 - 可以使用主动复制和presharding方法进行Redis集群搭建与在线扩容。
http://www.infoq.com/cn/articles/tq-redis-copy-build-scalable-cluster
简单说明下，写此文章算是对自己近一段工作的总结，希望能对你有点帮助，同时也是自己的一点小积累。
一.为什么选择redis
在项目中使用redis做为缓存，还没有使用memcache,考虑因素主要有两点：
1.redis丰富的数据结构,其hash,list,set以及功能丰富的String的支持，对于实际项目中的使用有很大的帮忙。（可参考官网redis.io）
2.redis单点的性能也非常高效（利用项目中的数据测试优于memcache）.
基于以上考虑，因此选用了redis来做为缓存应用。
二.分布式缓存的架构设计
1.架构设计
由于redis是单点，项目中需要使用，必须自己实现分布式。基本架构图如下所示：
2.分布式实现
通过key做一致性哈希，实现key对应redis结点的分布。
一致性哈希的实现：
l hash值计算：通过支持MD5与MurmurHash两种计算方式，默认是采用MurmurHash，高效的hash计算。
l 一致性的实现：通过Java的TreeMap来模拟环状结构，实现均匀分布
3.client的选择
对于jedis修改的主要是分区模块的修改，使其支持了跟据BufferKey进行分
区，跟据不同的redis结点信息，可以初始化不同的ShardInfo，同时也修改了JedisPool的底层实现，使其连接pool池支持跟据
key,value的构造方法，跟据不同ShardInfos，创建不同的jedis连接客户端，达到分区的效果，供应用层调用
4.模块的说明
l 脏数据处理模块，处理失败执行的缓存操作。
l 屏蔽监控模块，对于jedis操作的异常监控，当某结点出现异常可控制redis结点的切除等操作。
整个分布式模块通过hornetq，来切除异常redis结点。对于新结点的增加，也可以通过reload方法实现增加。（此模块对于新增结点也可以很方便实现）
对于以上分布式架构的实现满足了项目的需求。另外使用中对于一些比较重要用途的缓存数据
可以单独设置一些redis结点，设定特定的优先级。另外对于缓存接口的设计，也可以跟据需求，实现基本接口与一些特殊逻辑接口。对于cas相关操作，以
及一些事物操作可以通过其watch机制来实现。（参考我以前写的redis事物介绍）
以上是基于redis分布式架构的介绍！但是应用中读写都是在一起的。
相关写是在应用操作后flush或者update的，有一定的耦合。为了使读写分离，以及缓存模块跟应用的耦合更小，考虑使用mysql
binlog来刷新缓存。以下是基于binlog刷新可性行分析以及实现过程中需要注意的地方。
三.采用binlog架构刷新缓存可行性分析
2.对于使用MIXED日志格式，此日志格式，记录的是对应数据库操作的SQL语句，采用此日志方式存在的问题：
l 对于一些未任何更新操作的SQl语句，像条件不满足，对应的sql也会记录到binlog日志中。
l SQL语句记录的未必包括所有的更新操作。
l 对于一些分布式数据库，对于SQL中的where条件指定的是非均衡字段，也许会存在多条SQL,跟设计有关！
基于以上考虑，采用MIXED的日志格式进行binlog解析是行不通的。（官网给出的指示是failed statementsare not logged ，但不包括语法没错误，更新条件不符合对应的SQL）
3.采用ROW日志格式
对于此日志格式，每行变化都有对应的记录，此日志格式，对于解析及采集数据都是非常方便的，也只有采用此日志格式，才能基于binlog修改，做刷新缓存相关方案的设计。但是基于此日志格式也存在一些问题：
l 需要考虑项目中是否有大量的批量的update操作，如果采用此日志格式，批量操作每一行修改都会记录一条日志，大量的批量操作所产生的日志量，以及所带来的IO开销是否可以接受。
通过以上分析，最终项目中还是考虑基于ROW日志格式进行缓存刷新，还有一个问题需要考
虑，在应用层DB进行了相应的update操作后，所产生的Binlog是会带来一定的延迟，如果Binlog处理模块正常运行，数据是的延迟会非常
少，MS级别以内，对用户体验是没有感知的，但是Binlog模块是多点，异常，以及相应的延迟肯定会是存在的，这样，缓存数据肯定会存在脏数据。
不过通过以上方案，数据能达到最终一致性，因此how to权衡，需要考虑。
通过以上分析，是否采用Binlog来做缓存数据刷新相信大家有一个基本概念了
四.基于binlog刷新缓存的实现时注意的地方
1.如果是采用java做相关开发，可以使用开源的tungstenAPI
2.Binlog日志解析是按照mysql 的master/slave同步流程来实现，即一个线程同步，一个线程解析。
3.设计是可分Binlog处理模块以及缓存处理SqlEvent两部分，其中Binlog处理解析好对应的SqlEvent，然后对应的缓存刷新处理SqlEvent,一个简单的生产者-消费者模式。
4.对于多个Binlog处理模块可以是单点，也可以是通过一些协同工具来管理，看需求。可以使用ZooKeeper等。
5.对于分布式缓存中的数据，对于Binlog来刷新的缓存数据会存在load数据的问题，为了减轻DB的额外压力，flush操作可在get缓存数据处完成。看需求，如果读写完全分享的话此DB的额外压力可以接收的话也可行。
6.对于缓存数据性一致性要求比较高的，可以通过版本号来控制，即在应用层引入一定的耦合，在DB操作时带mark ，缓存刷新是也mark，另外get操作时比较双版本号来达到数据的一致性。（此跟5谈论的一定的联系，读写是否完全分离，以及相应一致性实现的一些方法）
五.一点心得
前前后后，对redis完成调研，以及相关的一些使用，分布式缓存的实现，基于binlog方式的修改等，接触有一年多了，这段时间下来，学了很多，以上算是一点小记，这部分工作的一点小记。实现过程中存在更多的问题。
对于调研相关的一些工作，一定要做的仔细，相应的细节一定要了解透彻，否则也许一此小问题会导致整个方案的不可行，甚至更大的的问题。连锁反应！
接下来有时间会写一篇关于BloomFilter的的文章 ，以及D-Left_BloomFilter，在此说明，只为自己有更大的动力去完成它。项目中实现了D-Left_BloomFilter，但在网上没有相关实现，在对其优化后，会在博文上做一些小小的记录。
以上如果有什么不对的地方请指正，有什么相关问题也可以跟我联系，可以一起交流学习！
简单说明下，写此文章算是对自己近一段工作的总结，希望能对你有点帮助，同时也是自己的一点小积累。
一.为什么选择redis
在项目中使用redis做为缓存，还没有使用memcache,考虑因素主要有两点：
1.redis丰富的数据结构,其hash,list,set以及功能丰富的String的支持，对于实际项目中的使用有很大的帮忙。（可参考官网redis.io）
2.redis单点的性能也非常高效（利用项目中的数据测试优于memcache）.
基于以上考虑，因此选用了redis来做为缓存应用。
二.分布式缓存的架构设计
1.架构设计
由于redis是单点，项目中需要使用，必须自己实现分布式。基本架构图如下所示：
2.分布式实现
通过key做一致性哈希，实现key对应redis结点的分布。
一致性哈希的实现：
l hash值计算：通过支持MD5与MurmurHash两种计算方式，默认是采用MurmurHash，高效的hash计算。
l 一致性的实现：通过java的TreeMap来模拟环状结构，实现均匀分布
3.client的选择
对于jedis修改的主要是分区模块的修改，使其支持了跟据BufferKey进行分
区，跟据不同的redis结点信息，可以初始化不同的ShardInfo，同时也修改了JedisPool的底层实现，使其连接pool池支持跟据
key,value的构造方法，跟据不同ShardInfos，创建不同的jedis连接客户端，达到分区的效果，供应用层调用
4.模块的说明
l 脏数据处理模块，处理失败执行的缓存操作。
l 屏蔽监控模块，对于jedis操作的异常监控，当某结点出现异常可控制redis结点的切除等操作。
整个分布式模块通过hornetq，来切除异常redis结点。对于新结点的增加，也可以通过reload方法实现增加。（此模块对于新增结点也可以很方便实现）
对于以上分布式架构的实现满足了项目的需求。另外使用中对于一些比较重要用途的缓存数据
可以单独设置一些redis结点，设定特定的优先级。另外对于缓存接口的设计，也可以跟据需求，实现基本接口与一些特殊逻辑接口。对于cas相关操作，以
及一些事物操作可以通过其watch机制来实现。（参考我以前写的redis事物介绍）
以上是基于redis分布式架构的介绍！但是应用中读写都是在一起的。
相关写是在应用操作后flush或者update的，有一定的耦合。为了使读写分离，以及缓存模块跟应用的耦合更小，考虑使用mysql
binlog来刷新缓存。以下是基于binlog刷新可性行分析以及实现过程中需要注意的地方。
三.采用binlog架构刷新缓存可行性分析
2.对于使用MIXED日志格式，此日志格式，记录的是对应数据库操作的SQL语句，采用此日志方式存在的问题：
l 对于一些未任何更新操作的SQl语句，像条件不满足，对应的sql也会记录到binlog日志中。
l SQL语句记录的未必包括所有的更新操作。
l 对于一些分布式数据库，对于SQL中的where条件指定的是非均衡字段，也许会存在多条SQL,跟设计有关！
基于以上考虑，采用MIXED的日志格式进行binlog解析是行不通的。（官网给出的指示是failed statementsare not logged ，但不包括语法没错误，更新条件不符合对应的SQL）
3.采用ROW日志格式
对于此日志格式，每行变化都有对应的记录，此日志格式，对于解析及采集数据都是非常方便的，也只有采用此日志格式，才能基于binlog修改，做刷新缓存相关方案的设计。但是基于此日志格式也存在一些问题：
l 需要考虑项目中是否有大量的批量的update操作，如果采用此日志格式，批量操作每一行修改都会记录一条日志，大量的批量操作所产生的日志量，以及所带来的IO开销是否可以接受。
通过以上分析，最终项目中还是考虑基于ROW日志格式进行缓存刷新，还有一个问题需要考
虑，在应用层DB进行了相应的update操作后，所产生的Binlog是会带来一定的延迟，如果Binlog处理模块正常运行，数据是的延迟会非常
少，MS级别以内，对用户体验是没有感知的，但是Binlog模块是多点，异常，以及相应的延迟肯定会是存在的，这样，缓存数据肯定会存在脏数据。
不过通过以上方案，数据能达到最终一致性，因此how to权衡，需要考虑。
通过以上分析，是否采用Binlog来做缓存数据刷新相信大家有一个基本概念了
四.基于binlog刷新缓存的实现时注意的地方
1.如果是采用java做相关开发，可以使用开源的tungstenAPI
2.Binlog日志解析是按照mysql 的master/slave同步流程来实现，即一个线程同步，一个线程解析。
3.设计是可分Binlog处理模块以及缓存处理SqlEvent两部分，其中Binlog处理解析好对应的SqlEvent，然后对应的缓存刷新处理SqlEvent,一个简单的生产者-消费者模式。
4.对于多个Binlog处理模块可以是单点，也可以是通过一些协同工具来管理，看需求。可以使用ZooKeeper等。
5.对于分布式缓存中的数据，对于Binlog来刷新的缓存数据会存在load数据的问题，为了减轻DB的额外压力，flush操作可在get缓存数据处完成。看需求，如果读写完全分享的话此DB的额外压力可以接收的话也可行。
6.对于缓存数据性一致性要求比较高的，可以通过版本号来控制，即在应用层引入一定的耦合，在DB操作时带mark ，缓存刷新是也mark，另外get操作时比较双版本号来达到数据的一致性。（此跟5谈论的一定的联系，读写是否完全分离，以及相应一致性实现的一些方法）
五.一点心得
前前后后，对redis完成调研，以及相关的一些使用，分布式缓存的实现，基于binlog方式的修改等，接触有一年多了，这段时间下来，学了很多，以上算是一点小记，这部分工作的一点小记。实现过程中存在更多的问题。
对于调研相关的一些工作，一定要做的仔细，相应的细节一定要了解透彻，否则也许一此小问题会导致整个方案的不可行，甚至更大的的问题。连锁反应！
接下来有时间会写一篇关于BloomFilter的的文章 ，以及D-Left_BloomFilter，在此说明，只为自己有更大的动力去完成它。项目中实现了D-Left_BloomFilter，但在网上没有相关实现，在对其优化后，会在博文上做一些小小的记录。
以上如果有什么不对的地方请指正，有什么相关问题也可以跟我联系，可以一起交流学习！