Redis主从复制的HA部署

boss44

　　Redis2.6的Sentinel方案，加上Redis的Master/Slave的复制，可以打造一个高可用的Redis集群。下图是一个典型的部署逻辑图。

　　图中Redis集群采用一个Master两个Slave做复制，而三个Sentinel哨兵实时监控Redis的集群。客户端使用Jedis的JedisSentinelPool来连接三个Sentinel来提供HA的连接。
　　Sentinel是Redis2.6版开始加入的另一组独立运行的节点, 提供自动Failover的支持。Redis Sentinel具有的功能包括：
　　l  监控：定时检查Redis的Master和Slave服务器是否正常；
　　l  通知：在发生异常时通知系统管理员和其他程序；
　　l  自动Failover：如果Master不可用，Sentinel会自动执行Failover，选择一个Slave提升为Master，其他的Salve会重新设置使用新的Master。当应用程序重新连接时会被通知连接新的Master。
　　Redis Sentinel 是一个分布式系统， 你可以在架构中运行多个 Sentinel 进程， 这些 Sentinel 进程通过相互通讯来判断一个主服务器是否断线， 以及是否应该执行故障转移。
　　虽然Redis Sentinel为一个单独的可执行文件 redis-sentinel，但实际上它只是一个运行在特殊模式下的 Redis 服务器， 你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动 Redis Sentinel 。
　　Redis.conf：
　　# 是否以后台方式执行，写pid 文件/var/run/redis.pid
　　daemonize yes
　　# 指定pid文件路径
　　pidfile /var/run/redis.pid
　　# 指定端口号，默认6379.
　　port 6379
　　# Client空闲多少秒后关闭连接(0 to disable)
　　timeout 0
　　# TCP keepalive，0禁用
　　tcp-keepalive 0
　　# 指定服务器的verbosity级别.
　　# 可以是下列值之一:debug、verbose、notice、warning
　　loglevel notice
　　# 指定输出的日志文件
　　logfile /opt/logs/redis2/redis.log
　　# 设置databases的数量
　　databases 16
　　# 设置保存DB到磁盘的频率，这里禁用
　　save ""
　　# 当一个slave对master不可用时，slave的行为:
　　# 1) 如果slave-serve-stale-data为 'yes' (默认)，slave仍然可以处理客户端请求
　　# 2) 如果slave-serve-stale-data为'no'，slave将返回一个"SYNC with master in progress"的错误，除了
　　# INFO 和 SLAVEOF命令.
　　slave-serve-stale-data yes
　　# 设置slave是否只读（2.6为默认）.
　　slave-read-only yes
　　# 在slave socket的SYNC后禁用TCP_NODELAY
　　# 如果选择“yes”,Redis将使用一个较小的数字TCP数据包和更少的带宽将数据发送到slave. But this can add a delay for
　　# 但是这可能导致数据发送到slave端会有延迟, 如果是Linux kernel的默认配置，会达到40毫秒.
　　# 如果选择"no"，则发送数据到slave端的延迟会降低，但将使用更多的带宽用于复制.
　　repl-disable-tcp-nodelay no
　　# 指定slave的优先级，用于Redis Sentinel选择一个slave提升为master.
　　# 默认优先级为100.
　　slave-priority 100
　　# 设置Redis的最大内存限制。当使用的内存达到最大的限制值时，Reids将依照eviction策略删除缓存项
　　maxmemory 8gb
　　# 最大内存策略：当达到最大内存限制时，Redis将以何种方式删除缓存项，可选项包括:
　　# volatile-lru -> 使用LRU算法来删除过期的项
　　# allkeys-lru -> 使用LRU算法来删除任意key
　　# volatile-random -> 在过期的项中随机删除一个key
　　# allkeys-random -> 在全部key中随机删除一个key
　　# volatile-ttl -> 删除最近过期的key(较小的 TTL)
　　# noeviction -> 不过期，针对写操作返回一个错误
　　maxmemory-policy volatile-lru
　　#下面的时间是微秒，所以1000000就是相当于一秒钟。需要注意的是负数禁用慢日志，而零值强制每个命令输出日志记录。
　　slowlog-log-slower-than 10000
　　#这个长度没有限制，不过它会消耗内存。使用SLOWLOG RESET可以回收慢日志使用的内存。
　　slowlog-max-len 128
　　#Hash使用一个高效的内存数据结构来编码多个条目，而最大的条目不超过给定阀值。
　　#这些阈值可以使用下面的指令来配置
　　hash-max-ziplist-entries 512
　　hash-max-ziplist-value 64
　　# 和Hash一样，多个小的list以特定的方式编码来节省空间。
　　list-max-ziplist-entries 512
　　list-max-ziplist-value 64
　　# set数据类型内部数据如果全部是数值型，且包含指定节点以下会采用紧凑格式存储
　　set-max-intset-entries 512
　　# 和hashe和list一样, 排序的set在指定的长度内以指定编码方式存储以节省空间
　　zset-max-ziplist-entries 128
　　zset-max-ziplist-value 64
　　#Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash，可以降低内存的使用
　　#当你的使用场景中，有非常严格的实时性需要，不能够接受Redis时不时的对请求有2毫秒的延迟的话，把这项配置为no。
　　#如果没有这么严格的实时性要求，可以设置为yes，以便能够尽可能快的释放内存
　　activerehashing yes
　　#客户端的输出缓冲区的限制，因为某种原因客户端从服务器读取数据的速度不够快，
　　#可用于强制断开连接（一个常见的原因是一个发布/订阅客户端消费消息的速度无法赶上生产它们的速度）。
　　# 可以三种不同客户端的方式进行设置：
　　# normal -> 正常客户端
　　# slave  -> slave和MONITOR客户端
　　# pubsub -> 至少订阅了一个pubsub channel或pattern的客户端
　　# 每个client-output-buffer-limit语法:
　　# client-output-buffer-limit   
　　# 一旦达到硬限制客户端会立即断开，或者达到软限制并保持达成的指定秒数（连续）。
　　# 例如，如果硬限制为32兆字节和软限制为16兆字节/10秒，客户端将会立即断开
　　# 如果输出缓冲区的大小达到32兆字节，客户端达到16兆字节和连续超过了限制10秒，也将断开连接。
　　# 默认normal客户端不做限制，因为他们在一个请求后未要求时（以推的方式）不接收数据，
　　# 只有异步客户端可能会出现请求数据的速度比它可以读取的速度快的场景。
　　# 把硬限制和软限制都设置为0来禁用该特性.
　　client-output-buffer-limit normal 0 0 0
　　client-output-buffer-limit slave 256mb 64mb 60
　　client-output-buffer-limit pubsub 32mb 8mb 60
　　# Redis调用内部函数来执行许多后台任务，如关闭客户端超时的连接，清除过期的Key，等等。
　　# 不是所有的任务都以相同的频率执行，但Redis依照指定的“Hz”值来执行检查任务。
　　# 默认情况下，“Hz”的被设定为10。
　　# 提高该值将在Redis空闲时使用更多的CPU时，但同时当有多个key同时到期会使Redis的反应更灵敏，以及超时可以更精确地处理。
　　# 范围是1到500之间，但是值超过100通常不是一个好主意。
　　# 大多数用户应该使用10这个预设值，只有在非常低的延迟的情况下有必要提高最大到100。
　　hz 10
　　原文来自：http://blog.csdn.net/wilbertzhou/article/details/17784965