本节主要讲redis的集群模式！

一、Redis集群

集群分类：
主从复制 Replication
高可用 Sentinel
集群 Cluster
分布式 twemproxy

1、主从复制：

一个redis服务可以有多个服务的复制品，这个服务称为这个服务的复制品，这个Redis服务称为Master,其他复制品称为slaves
只要网络连接正常，Master会一直将机子的数据同步更新给slaves,保持主从同步
只有Master可以执行写命令，slaves只能执行读命令，所以可以从slave和master中去读
从服务器执行客户端发送的读命令，比如GET，LRANGE,SMEMMBERS，HGET,ZRANGE等等
客户端可以链接slava进行读命令，来降低Master的读压力
操作：
redis-server slaveof配置当前服务称为某redis服务的slave
例：redis-server –port 6380 –slaveof 127.0.0.1 6379(当谁的从)

SLAVEOF host port 命令，将当前服务器状态从Master修改为别的服务器Slave
例：redis>SLAVEOF 192.168.1.1 6379 将服务器转换为Slave
redis>SLAVEOF NO ONE,将服务器重新回复到Master,不会丢弃已同步的数据

配置方式：启动时，服务器读取配置文件，并自动成为指定服务器的从服务器
slaveof
slaveof 127.0.0.1 6379

2、主从复制问题：

一个Master可以有多个Slaves
Slave下线，只是读请求性能下线
Master下线，写请求无法执行
其中一台Slave使用slaveof no one 命令成为Master，其他slave执行SLaveof命令指向这个新的Master，从他这里同步数据
以上是手动实现的，能够实现自动，这就需要sentine哨兵，实现故障转移failover操作

3、Sentinel

高可用sentinel（master挂了之后，会选新的出来，这样让其他slaved连过来）
官方提供的高可用方案，可以用它管理多个redis服务实例
编译后产生的redis-sentine程序文件
redis Sentinel是一个分布式系统，可以在一个架构中运行多个Sentinel进程

（1）启动Sentinel

将src目录下产生的redis-sentinel程序文件复制到$REDIS_HOME/bin
启动一个运行在sentinel模式下的服务实例
redis-sentinel
redis-server /path/to/sentinel.conf –sentinel
Redis Sentinel是一个分布式系统，可以在一个架构中运行多个Sentinel进程

(2)监控monitoring

Sentinel会不断检查Master和Slave是否正常
每一个Sentinel可以监控多个Master和该Master下的Slaves
sentinel网络：
监控同一个 Master的Sentinel会自动链接，组成分布式的一个sentinel网络，互相通信并交换彼此关于被监控服务器的信息
这里面有个投票机制，要投票才可以解决，超过半数可以

（3）服务器下线：

当一个sentinel认为自己监控的服务器已经下线时，会向网络中的其他sentinel进行确认，判断该服务是否真的下线
如果下线的是主服务器，那么sentinel网络将 对下线进行自动故障转移，通过将下线主服务器的某个从服务器提升为主服务器，让从服务器复制主服务器，让系统重新回到
上线状态，若主服务器又起来了，那自动沦为从

(4)sentinel配置文件：

至少包含一个监控选项，用于被指定监控Master的信息
Sentinel monitor ,例如
sentinel monitor mymaster 127.0.0.1 6379 2
监视mymaster，IP和端口，至少要2个sentinel同意才下线有效，多数sentinel同意才会转移
Sentinel会根据MASTER的配置自动发现Master的slaves
Sentinel的默认端口号：26379
就在端口前加个2

Sentinel配置举例:
执行以下两条命令，将创建两个监视主服务器S1的sentinel实例
$redis-sentinel sential1.conf
$redis-sentinel sentinel2.conf
其中，sentinel1.conf内容为：
port 26379
Sentinel monitor s1 127.0.0.1 6379 2
sentinel2.conf内容为：
port 26380
sentinel monitor s1 127.0.0.1 6379 2
启动sentinel:redis-sentinel sentinel.conf

(5)sentinel总结：

主从复制：解决了读请求分担，从节点下线，会使得读请求能力有所下降
master只有一个，写请求单点问题
Sentinel会在Master下线之后自动只想failover操作，提升一台slave为吗stew人，让其它的Slave重新成为Master的slave
主从复制+哨兵Sentinel只解决了读性能和高可用问题，但没有解决写性能问题（局限性）

二、集群—Redis Twemproxy

1、问题引出：

主从对写压力没有分担
解决思路就是，使用多个节点分担，将写请求分散到不同节点处理
分片Sharing:多节点分担的思路就是关系型数据库处理大表的水平切分思路
（用分片机制）用户只要和代理沟通，twitter出的

2、twemproxy:

tWitter来开发，代理用户的读写请求
twitter开发的服务器，兼容redis和memcached，允许用户将多个redis服务器添加到一个服务器池（pool）里面，并通过用户原则的散列函数和分布函数，来将来自
客户端的命令请求分发给服务器池的各个服务器
通过使用twemproxy，我们可以将数据库分片到多台redis服务器上面，并使用这些服务器来分担系统压力及数据库容量，在硬件条件相同的情况下，对于一个包含N个
redis服务器的池来说，池中每台平均1/N的客户端命令请求
向池中添加更多的服务器可以线性拓展系统处理命令请求的命令，以及系统能够保存的数据量
一个代理里面管理有好多池子！

3、twemproxy安装;

见安装文档(可以去百度)
automake autoconf twemproxy，libtool(有.ac和.am文件却没有makefile文件，就要安装automake和autoconf)等包
twemproxy配置说明：
sxt： 服务器池的名字，支持创建多个服务器池
listen:192.168.56.201:22121 这个服务器池的监听地址和端口号
hash:fnvla_64 hash选择的hash算法
distribution:ketama 选择的分布式算法
auto_eject_hosts:true 这个区间段，连不上就拒绝
redis:true 代理redis命令请求，不给定时默认代理memcached请求
server_retry_timeout:2000 重试的时间
server_failure_limit:3 twemproxy连续三次向同一个服务器发送请求命令都遇到错误时，twemproxy就会将该服务器标记为下线，并交由其他在线服务器处理
servers: 池中个服务器的地址和端口号及权重

• 192.168.56.201:6379:1
• 192.168.56.202:6379:1
• 192.168.56.203:6379:1
  twemproxy运行：
  nutcracker -d -c /opt/sxt/twemproxyconf/nutcracker.sxt.yml(-d表示daemon后台，tewmproxy代理了redis协议，伪装成redis)
  redis-cli -p 22121 -h 192.168.56.201

代理池的概念：一个twemproxy可以有多个池，不同端口对应不同的池

ss -tanl 查看端口
但使用代理有个问题，不同步，所以要考虑主从，但是使用哨兵，这两个没法通信，
问题：
集群没法拓展，没法容错（下线了，就必须重启起来，不能把服务器A里的带到B里面）
总结:
前端使用twemproxy做代理，后端Redis数据基本上可以按照key来进行比较均衡的分布
后台一台redis挂掉后，twemproxy能够自动摘除，恢复后，可以自动识别，恢复并重新加到redis组中重新使用
redis挂掉以后，后端数据是否丢失依据Redis本身的持久化策略配置，与twemproxy无关
如果要新增一台redis,twemproxy必须重启才可以生效，并且数据不会自动重新reblance，需要人工单独写脚本来实现
如果原来已经有2个节点Redis,后续有增加2个redis,则数据分布计算与原来的redistribution分布无关，现有数据如果需要均匀分布的化，需要人工单独处理
如果twemproxy的后端节点数量发生变化，twemproxy相同算法的前提下，原来的数据必须重新处理分布，否则会存在找不着key值的情况
不管twemproxy后端有几台redis,前端的单个twemproxy的性能最大也只能和单台的redis差不多
如同时部署多台twemproxy配置一样，客户端分别链接多台twemproxy可以在一定条件下提高性能
如果你觉着很麻烦，那我们中国人就提供了一种整合方案
redis-mgr
整合了通过了整合复制，sentinel以及twemproxy等组件，提供了一站式的redis服务器部署，监控，迁移等功能，网址：https://github.com/changyibiao/
redis-mgr

Redis原生集群:
刚出来每多久。3.0支持
由多个redis服务器组成的分布式网络服务集群
每一个Redis服务器称为节点NOde,节点之间会相互通信，两两相连（网络io较多，所以不建议使用节点较多）
redis集群无中心节点（无主从概念）

三、redis集群节点复制：

redis集群的每个节点都有两种角色可以选：主节点master node ,从节点 slave node ,其中主节点主要用于存储数据，而从节点则是某个主节点的复制品
当用户需要处理更多读请求的时候，添加从节点可以拓展系统读性能，因为redis集群重用了单机redis复制特性的代码，所以集群的复制行为和我们之前介绍的单机复制特性
是完全一样的
一般是6个节点，3个主，3个从，自带哨兵机制’
redis故障转移：
方法和sentinel相同，但是故障转移由其他主节点负责，所以集群不必使用redis sentinel
redis集群分批分片：
集群将整个数据库分为16384个槽位slot,所有key都数据这些slot中的一个，key的槽位公式：slot number=crc16(key)%16384其中crc16为16位循环冗余校验和函数
集群中的每个主节点都可以处理0个志16383个槽，当16384个槽都有某个节点在负责处理时，集群进入上线状态，并开始处理客户端发送的数据命令请求
举例：
三个主节点7000，7001，7002平均分片16384个slot槽位
节点7000指派的槽位位0到5460
节点7001指派的槽位位5461到10922
节点7002指派的槽位位10923到16383

redis集群Resirect转向：
由于Redis集群无中心节点，请求会发给任意主节点
主节点只会处理自己负责槽位的命令请求，其他命令槽位请求，该主节点会返回客户端一个转向错误‘
客户端根据错误中包含的地址和端口重新向正确的负责的主节点发起命令请求

redis集群搭建：
创建多个主节点
为每个节点指派slot,将多个节点连接起来，组成一个集群
槽位分片完成后，集群进入上线状态
6个节点：3个主节点，每个主节点有一个从节点

多走路，多思考，越努力，越幸运！
———————————————YoungerFary