redis三种集群策略
redis
redis是单线程的，但是一般的作为缓存使用的话，redis足够了，因为它的读写速度太快了。
官方的一个简单测试：
测试完成了50个并发执行100000个请求。
设置和获取的值是一个256字节字符串。
结果:读的速度是110000次/s,写的速度是81000次/s
但对于访问量特别大的服务来说，还是稍有不足。那么，如何提升redis的性能呢？搭建集群。
redis主要提供三种集群策略：
主从复制
集群
哨兵
一、主从复制
在主从复制中，数据库分为俩类，主数据库(master)和从数据库(slave)。
1.1 主从复制有如下特点：
主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
从数据库一般都是只读的，并且接收主数据库同步过来的数据
一个master可以拥有多个slave，但是一个slave只能对应一个master
1.2 工作机制
slave从节点服务启动并连接到Master之后，它将主动发送一个SYNC命令。Master服务主节点收到同步命令后将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中。此后，Master主节点继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。
复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。
如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行。
1.3 主从配置
redis默认是主数据，所以master无需配置，我们只需要修改slave的配置即可。
设置需要连接的master的ip端口:slaveof 192.168.0.107 6379
如果master设置了密码。需要配置：masterauth master-password
连接成功进入命令行后，可以通过以下命令行查看连接该数据库的其他库信息:info replication
1.3 优点
同一个Master可以同步多个Slaves。
Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构。
Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据
为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高。
Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作。
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。
1.4 缺点
Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
Redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦。
Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
其实redis的主从模式很简单，在实际的生产环境中是很少使用的，我也不建议在实际的生产环境中使用主从模式来提供系统的高可用性，之所以不建议使用都是由它的缺点造成的，在数据量非常大的情况，或者对系统的高可用性要求很高的情况下，主从模式也是不稳定的。
二、哨兵
该模式是从Redis的2.6版本开始提供的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本以后，这个哨兵模式才稳定下来，无论是主从模式，还是哨兵模式，这两个模式都有一个问题，不能水平扩容，并且这两个模式的高可用特性都会受到Master主节点内存的限制。
2.1 哨兵的作用是监控 redis系统的运行状况，功能如下
监控主从数据库是否正常运行。
master出现故障时，自动将它的其中一个slave转化为master。
master和slave服务器切换后，master的redis.conf、slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，saster主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。
当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
多哨兵配置的时候，哨兵之间也会自动监控。
多个哨兵可以监控同一个redis。
2.2 哨兵工作机制
哨兵进程启动时会读取配置文件的内容，通过
sentinel monitor master-name ip port quorum查找到master的ip端口。一个哨兵可以监控多个master数据库，只需要提供多个该配置项即可。配置文件还定义了与监控相关的参数，比如master多长时间无响应即即判定位为下线。
哨兵启动后，会与要监控的master建立俩条连接：
3.1 一条连接用来订阅master的sentinel:hello频道，并获取其他监控该master的哨兵节点信息
3.2 另一条连接定期向master发送INFO等命令获取master本身的信息与master建立连接后，哨兵会执行三个操作，这三个操作的发送频率都可以在配置文件中配置：
4.1 定期向master和slave发送INFO命令
4.2 定期向master和slave的sentinel:hello频道发送自己的信息
4.3 定期向master、slave和其他哨兵发送PING命令
这三个操作的意义非常重大，发送INFO命令可以获取当前数据库的相关信息从而实现新节点的自动发现。所以说哨兵只需要配置master数据库信息就可以自动发现其slave信息。获取到slave信息后，哨兵也会与slave建立俩条连接执行监控。通过INFO命令，哨兵可以获取主从数据库的最新信息，并进行相应的操作，比如角色变更等。接下来哨兵向主从数据库的sentinel:hello频道发送信息，并与同样监控这些数据库的哨兵共享自己的信息，发送内容为哨兵的ip端口、运行id、配置版本、master名字、master的ip端口还有master的配置版本。这些信息有以下用处：
5.1 其他哨兵可以通过该信息判断发送者是否是新发现的哨兵，如果是的话会创建一个到该哨兵的连接用于发送ping命令。
5.2 其他哨兵通过该信息可以判断master的版本，如果该版本高于直接记录的版本，将会更新当实现了自动发现slave和其他哨兵节点后，哨兵就可以通过定期发送ping命令定时监控这些数据库和节点有没有停止服务。发送频率可以配置，但是最长间隔时间为1s，可以通过
sentinel down-after-milliseconds mymaster 600设置。如果被ping的数据库或者节点超时未回复，哨兵认为其主观下线。如果下线的是master，哨兵会向其他哨兵点发送命令询问他们是否也认为该master主观下线。如果一个master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。如果达到一定数目（即配置文件中的quorum）投票，哨兵会认为该master已经客观下线（ODOWN），并选举领头的哨兵节点对主从系统发起故障恢复。
如上文所说，哨兵认为master客观下线后，故障恢复的操作需要由选举的领头哨兵执行，选举采用Raft算法:
8.1 发现master下线的哨兵节点（我们称他为A）向每个哨兵发送命令，要求对方选自己为领头哨兵
8.2 如果目标哨兵节点没有选过其他人，则会同意选举A为领头哨兵
8.3 如果有超过一半的哨兵同意选举A为领头，则A当选
8.4 如果有多个哨兵节点同时参选领头，此时有可能存在一轮投票无竞选者胜出，此时每个参选的节点等待一个随机时间后再次发起参选请求，进行下一轮投票精选，直至选举出领头哨兵
8.5 选出领头哨兵后，领头者开始对进行故障恢复，从出现故障的master的从数据库slave中挑选一个来当选新的master,选择规则如下：
8.5.1 所有在线的slave中选择优先级最高的，优先级可以通过slave-priority配置
8.5.2 如果有多个最高优先级的slave，则选取复制偏移量最大（即复制越完整）的当选
8.5.3 如果以上条件都一样，选取id最小的slave挑选出需要继任的slaver后，领头哨兵向该数据库发送命令使其升格为master，然后再向其他slave发送命令接受新的master，最后更新数据。将已经停止的旧的master更新为新的master的从数据库，使其恢复服务后以slave的身份继续运行。
2.3 哨兵配置
sentinel monitor mymaster 192.168.0.107 6379 1
启动哨兵节点：
redis-server sentinel.conf --sentinel &
出现以下类似信息即启动哨兵成功
3072:X 12 Apr 22:40:02.554 ### Sentinel runid is e510bd95d4deba3261de72272130322b2ba650e7
3072:X 12 Apr 22:40:02.554 ### +monitor master mymaster 192.168.0.107 6379 quorum 1
3072:X 12 Apr 22:40:03.516 * +slave slave 192.168.0.108:6379 192.168.0.108 6379 @ mymaster 192.168.0.107 6379
3072:X 12 Apr 22:40:03.516 * +slave slave 192.168.0.109:6379 192.168.0.109 6379 @ mymaster 192.168.0.107 6379
可以在任何一台服务器上查看指定哨兵节点信息：
bin/redis-cli -h 192.168.0.110 -p 26379 info Sentinel
控制台输出哨兵信息redis-cli -h 192.168.0.110 -p 26379 info Sentinel
### Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=192.168.0.107:6379,slaves=2,sentinels=1
三、集群
3.1 特点
3.0版本之前的redis是不支持集群的，我们的徐子睿老师说，那个时候，我们的redis如果想要集群的话，就需要一个中间件，然后这个中间件负责将我们需要存入redis中的数据的key通过一套算法计算得出一个值。然后根据这个值找到对应的redis节点，将这些数据存在这个redis的节点中。在取值的时候，同样先将key进行计算，得到对应的值，然后就去找对应的redis节点，从对应的节点中取出对应的值。这样做有很多不好的地方，比如说我们的这些计算都需要在系统中去进行，所以会增加系统的负担。还有就是这种集群模式下，某个节点挂掉，其他的节点无法知道。而且也不容易对每个节点进行负载均衡。
从redis 3.0版本开始支持redis-cluster集群，redis-cluster采用无中心结构，每一个节点都保存有这个集群所有主节点以及从节点的信息，及集群状态，每个节点都和其他节点连接。所以redis-cluster是一种服务端分片技术。
每个节点都和n-1个节点通信，这被称为集群总线（cluster bus）。它们使用特殊的端口号，即对外服务端口号加10000。所以要维护好这个集群的每个节点信息，不然会导致整个集群不可用，其内部采用特殊的二进制协议优化传输速度和带宽。
redis-cluster把所有的物理节点映射到[0,16383]slot（槽）上，cluster负责维护node--slot--value。
集群预先给所有节点分好16384个桶，每个节点得到部分桶，当需要在redis集群中插入数据时，根据CRC16(KEY) mod 16384的值，决定将一个key放到哪个桶中。
客户端与redis节点直连，不需要连接集群所有的节点，连接集群中任何一个可用节点即可。整个cluster被看做是一个整体，客户端可连接任意一个节点进行操作，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点。
redis-trib.rb脚本（rub语言）为集群的管理工具，比如自动添加节点，规划槽位，迁移数据等一系列操作。
节点的fail是通过集群中超过半数的节点检测失效时才生效。集群节点之间通过互相的ping-pong判断是否可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉，集群就进入fail状态，也可以理解成集群的slot映射[0-16383]不完整时进入fail状态。如果有一半以上的主节点宕机，那么无论这些节点有没有从节点，集群同样进入fail状态。这就是redis的投票机制。
为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。如果主节点失效，redis cluster会根据选举算法从slave节点中选择一个上升为master节点，整个集群继续对外提供服务。
3.2 配置
redis集群依赖ruby，需安装ruby环境，ruby版本需高于2.2
yum install ruby
yum install rubygems
gem install redis
修改配置文件
bind 192.168.0.107
### 配置端口
port 6380
### 配置快照保存路径，6个节点配置不同路径
dir /usr/local/redis-cluster/6380/
### 开启集群
cluster-enabled yes
### 为节点设置不同的工作目录，6个节点配置不同目录
cluster-config-file nodes-6380.conf
### 集群失效时间
cluster-node-timeout 15000
开启集群中的所有节点
redis-service …/6380/redis.conf
redis-service …/6381/redis.conf
redis-service …/6382/redis.conf
redis-service …/6383/redis.conf
redis-service …/6384/redis.conf
redis-service …/6385/redis.conf
将节点加入集群中，中途需要输入yes确定创建集群
redis-trib.rb create --replicas 1 192.168.0.107:6380 192.168.0.107:6381 192.168.0.107:6382 192.168.0.107:6383 192.168.0.107:6384 192.168.0.107:6385进入集群中任何一个节点
redis-cli -c -h 192.168.0.107 -p 6381查看集群中的节点
cluster nodes
[root@buke107 src]### redis-cli -c -h 192.168.0.107 -p 6381
192.168.0.107:6381> cluster nodes
868456121fa4e6c8e7abe235a88b51d354a944b5 192.168.0.107:6382 master - 0 1523609792598 3 connected 10923-16383
d6d01fd8f1e5b9f8fc0c748e08248a358da3638d 192.168.0.107:6385 slave 868456121fa4e6c8e7abe235a88b51d354a944b5 0 1523609795616 6 connected
5cd3ed3a84ead41a765abd3781b98950d452c958 192.168.0.107:6380 master - 0 1523609794610 1 connected 0-5460
b8e047aeacb9398c3f58f96d0602efbbea2078e2 192.168.0.107:6383 slave 5cd3ed3a84ead41a765abd3781b98950d452c958 0 1523609797629 1 connected
68cf66359318b26df16ebf95ba0c00d9f6b2c63e 192.168.0.107:6384 slave 90b4b326d579f9b5e181e3df95578bceba29b204 0 1523609796622 5 connected
90b4b326d579f9b5e181e3df95578bceba29b204 192.168.0.107:6381 myself,master - 0 0 2 connected 5461-10922
如上所示，三主三从节点已创建成功
增加集群节点
cluster meet ip port
其他集群实现方式
中间件
一、twemproxy
twemproxy又称nutcracker，起源于推特系统中redis、memcached集群的轻量级代理。
Redis代理中间件twemproxy是一种利用中间件做分片的技术。twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后（sharding），再转发给后端真正的redis服务器。也就是说，客户端不直接访问redis服务器，而是通过twemproxy代理中间件间接访问。降低了客户端直连后端服务器的连接数量，并且支持服务器集群水平扩展。
twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可以避免单点压力或故障。
从下面架构图看到twemproxy是一个单点，很容易对其造成很大的压力，所以通常会结合keepalived来实现twemproy的高可用。这时，通常只有一台twemproxy在工作，另外一台处于备机，当一台挂掉以后，vip自动漂移，备机接替工作。关于keepalived的用法可自行网上查阅资料。
二、codis
codis是一个分布式的Redis解决方案，由豌豆荚开源，对于上层的应用来说，连接codis proxy和连接原生的redis server没什么明显的区别，上层应用可以像使用单机的redis一样使用，codis底层会处理请求的转发，不停机的数据迁移等工作，所有后边的事情，对于前面的客户端来说是透明的，可以简单的认为后边连接的是一个内存无限大的redis服务。
客户端分片
分区的逻辑在客户端实现，由客户端自己选择请求到哪个节点。方案可参考一致性哈希，这种方案通常适用于用户对客户端的行为有完全控制能力的场景。
一、Jedis sharding集群
Redis Sharding可以说是在Redis cluster出来之前业界普遍的采用方式，其主要思想是采用hash算法将存储数据的key进行hash散列，这样特定的key会被定为到特定的节点上。
庆幸的是，Java Redis客户端驱动Jedis已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool
Jedis的Redis Sharding实现具有如下特点：
采用一致性哈希算法，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。
为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。
ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。
当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。
作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。