一，redis slave连接被master断开，redis版本2.8.0
# I/O error trying to sync with MASTER: connection lost
# I/O error reading bulk count from MASTER: Connection reset by peer
redis log报错如上，事故场景如下：
网站高峰期每分钟70万pv。redis中存放缓存数据，数据量大概6G左右，并且每条数据内容占用空间也较大。redis实例启动时只有最近三个月数据，expire时间为1个月，之后所有新抓取的数据expire时间为2h。master负责数据的写入，slave集群负责数据的读。master由于机房网络原因与slave断开连接，slave在端口的几秒之后连不上master，部分复制不成功。而这时当网站有访问slave没有的数据，就会触发抓取服务从mysql中抓取然后不断写入master，但是写入的数据同步不到slave，所有这段时间master的写入就会逐渐增大，平均每秒3w次写入，最高每秒7w写入。部分复制不成功之后，slave开始请求全同步，在slave接收master数据的过程中，连接断开，slave log中报错如上。
事故分析：
1，基础知识
redis的client连接会有一个output buffer，用于存放对client请求的response data。而不同的client可以在redis配置文件对buffer进行配置，当buffer增长到限制值的时候，就会报如上错，master会主动端口连接。如下三行配置：
client-output-buffer-limit normal 0 0 0 #对一般的client
client-output-buffer-limit slave 256mb 64mb 60 #对redis的slave
client-output-buffer-limit pubsub 32mb 8mb 60 #对发布/订阅这种client
命令格式为：
# client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
class有三种：normal，slave，pubsub
hard limit：当buffer的量达到硬限制之后，redis立即断开与client的连接
soft limit 和 soft seconds：当buffer的在soft seconds秒内超出了soft limit，redis不会端口client连接。如果当buffer的在soft seconds秒之后，仍然超出了soft limit 的限制，则redis立即端口client连接。
数据部分同步：
从2.8开始，当Master和Slave之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步。
Master端为复制流维护一个内存缓冲区（in-memory backlog），记录最近发送的复制流命令；同时，Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID（Master run id）。当网络断开，Slave尝试重连时：
a. 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在，则Master会将缺失的这段时间的所有命令发送给Slave执行，然后复制工作就可以继续执行了；
b. 否则，依然需要全量复制操作；
对in-memory backlog的介绍：
是redis用于存储更新命令的一块buffer，在部分复制的时候Slave会请求Master从这块buffer中获取闪断情况下丢失的更新操作。repl_backlog在redis启动的时候初始化为NULL，当有Slave连接上来的时候，会被指向创建的buffer，默认为1024*1024(即1Mb)。repl_backlog_size表示该buffer的大小(默认1024*1024，即1Mb)。该buffer是作为一个环形缓存区使用的，当有数据超过buffer的大小以后就会重新从buffer的头部开始写入。repl_backlog_idx表示当前缓存数据的尾部(因为是环形buffer)。repl_backlog_off是全局缓存的偏移量，从开始缓存数据起一直在增长。如果Master一个Slave都没有，则超过一段时间以后repl_backlog会被释放，默认超时时间是1小时。
完全同步：
无论是初次连接还是重新连接， 当建立一个从服务器时， 从服务器都将向主服务器发送一个 SYNC 命令。
接到 SYNC 命令的主服务器将开始执行 BGSAVE ， 并在保存操作执行期间， 将所有新执行的写入命令都保存到一个缓冲区里面。当 BGSAVE 执行完毕后， 主服务器将执行保存操作所得的 .rdb 文件发送给从服务器， 从服务器接收这个 .rdb 文件， 并将文件中的数据载入到内存中。之后主服务器会以 Redis 命令协议的格式， 将写命令缓冲区中积累的所有内容都发送给从服务器。
2，结合事故场景：
1）slave在闪断之后不能部分同步master：
slave与master断开连接后，由于数据量大，master的in-memory backlog被很快写满并刷新，故导致部分复制失败。
2）slave不能进行完全同步master：
redis slave到master进行数据完全复制，但是从复制开始到结束这段时间内，redis master的output buffer会积累大量的redis更新数据，导致buffer超限，从而被redis master断开连接。解决办法调整如下指令的值即可：
client-output-buffer-limit slave
二，redis key过期策略
1，键空间通知使得客户端可以通过订阅频道或模式， 来接收那些以某种方式改动了 Redis 数据集的事件。
以下是一些键空间通知发送的事件的例子：
1）所有修改键的命令。
2）所有接收到 LPUSH 命令的键。
3）数据库中所有已过期的键。
事件通过 Redis 的订阅与发布功能（pub/sub）来进行分发， 因此所有支持订阅与发布功能的客户端都可以在无须做任何修改的情况下， 直接使用键空间通知功能。
因为 Redis 目前的订阅与发布功能采取的是发送即忘（fire and forget）策略， 所以如果你的程序需要可靠事件通知（reliable notification of events）， 那么目前的键空间通知可能并不适合你： 当订阅事件的客户端断线时， 它会丢失所有在断线期间分发给它的事件。
2，过期通知的发送时间
Redis 使用以下两种方式删除过期的键：
1）当一个键被访问时，程序会对这个键进行检查，如果键已经过期，那么该键将被删除。
2）redis会每秒10次的做如下事情：
步骤1：从设置过期的key集合中随机抽100个key
步骤2：删除100个key中所有过期的key
步骤3：如果100个key中有25个以上的key过期了，就从步骤1继续开始。
当过期键被以上两个程序的任意一个发现、 并且将键从数据库中删除时， Redis 会产生一个 expired 通知。Redis 并不保证生存时间（TTL）变为 0 的键会立即被删除： 如果程序没有访问这个过期键， 或者带有生存时间的键非常多的话， 那么在键的生存时间变为 0 ， 直到键真正被删除这中间， 可能会有一段比较显著的时间间隔。
因此， Redis 产生 expired 通知的时间为过期键被删除的时候， 而不是键的生存时间变为 0 的时候。
3，key的过期属性修改
1），当redis中一个key有expire属性，我们只能用修改value的方式才能清楚expire属性，如set,del命令。想rename命令，不能呢个清楚expire属性。
2），当在一个已经有expire属性的key上，再使用expire属性的话，过期时间将会被更新。
三，redis高可用问题解决
1，Twemproxy
twemproxy,也叫nutcraker，是一个用C语言实现的快速的单线程redis和memcache代理代理程序。twemproxy官方给出的性能测试结果为，使用此代理，只会有20%的性能损耗。proxy主要功能如下：
1）支持失败节点自动删除
可以设置重新连接该节点的时间
可以设置连接多少次之后删除该节点
该方式适合作为cache存储
2）支持设置HashTag
通过HashTag可以自己设定将带有相同tag的不同的KEY hash到同一个redis实例上去。
3）减少与redis的直接连接数
保持与redis的长连接
可设置代理与后台每个redis连接的数目
4）自动分片到后端多个redis实例上
多种hash算法
可以设置后端实例的权重
5）避免单点问题
可以平行部署多个代理层，client自动选择可用的一个
6）支持redis pipelining request
但是对于事物机制
7）支持状态监控
可设置状态监控ip和端口，访问ip和端口可以得到一个json格式的状态信息串
可设置监控信息刷新间隔时间
8）高吞吐量
连接复用，内存复用。
将多个连接请求，组成reids pipelining统一向redis请求。
nutcraker的xml配置案例如下：
mpc_12251:
listen: 0.0.0.0:12251
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
redis: true
timeout: 1000
server_retry_timeout: 60000
server_failure_limit: 2
servers:
- 10.13.83.108:12251:1
- 10.13.83.118:12251:1
- 10.13.83.128:12251:1
- 10.13.83.40:12251:1
- 10.13.83.52:12251:1
- 10.13.83.78:12251:1
项目地址：https://github.com/twitter/twemproxy
2，sentinel
这是redis中自带的管理软件，主要执行是三个任务:
1)监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2)提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3)自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。
具体参考文章：
http://redis.readthedocs.org/en/latest/topic/sentinel.html
sentinel的配置文件，配置选项不多，在sentinel.conf文件中都有详细的说明
四，作为Nosql的优势
1，性能方面
由于redis和memcached都是把数据直接存放在内存，故速度都非常快
2，提供的数据结构
memcache数据结构单一，只能提供简单的key/value方式
redis数据结构丰富，有list，set，hash等数据结构的存储方式
3，数据可靠性
memcache不支持，通常用在做缓存,提升性能，不支持数据持久化
redis支持（快照、AOF）：依赖快照进行持久化，aof增强了可靠性的同时，对性能有所影响。redis的数据会保存在rdb数据文件中，等redis重启之后，数据会从rdb文件进行加载
4，可用性
Memcache本身没有数据冗余机制，只能做缓存
redis支持master-slave架构，版本2.8.0在某些情况下支持增量复制，可以用sentinel来实现高可用，实现故障自动切换。并且，redis3.0系列正在增加集群功能，相信集群redis的功能会更好的给用户提供高可用的解决方案。
