本文转载于https://blog.csdn.net/wy 0123/article/details/79583506
现在，越来越多的项目正在使用redis。 多个实例的redis服务比包含定位、容错和扩展等技术问题的单个实例更复杂。 我们经常使用sharding技术来管理这个。 其聚类模型主要有以下几种。
主从复制
哨兵模式
Redis官方群集模式(服务器端sharding ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )。
Jedis sharding群集(客户机sharding ) ) )。
中间件代理的利用
主从复制，看看哨兵的模式。 这是其他集群的基础配置。
主从复制(Master-Slave Replication ) ) )。
实现主从复制的机制。 主从服务器从节点服务器启动并连接到主机后，它会主动发送SYNC命令。 当接收到同步命令时，主服务器主服务器将启动后台存储进程，并收集所有更改接收的数据集的命令。 后台进程运行完成后，主进程将整个数据库文件传输到Slave以完成完全同步。 从属服务器接收数据库文件数据后，将其保存到磁盘并加载到内存中。 然后，主节点继续将所有收集到的修改命令和新的修改命令依次发送到Slaves，Slave这次将执行这些数据修改命令以实现最终的数据同步。
如果Master和Slave之间的链路断开，Slave可以自动重新连接Master，但连接成功后会自动执行完全同步。
主从配置
修改子节点的配置文件： slaveof masterip masterport
如果设置了密码，请设置主自动主密码
主从模式的优缺点
好处：
同一主服务器可以同步多个Slaves。
由于Slave也可以接受其他Slaves的连接和同步请求，因此可以有效地分散主同步压力。 因此，Redis的复制体系结构可以视为图结构。
主服务器以非阻塞的方式为从属服务器提供服务。 因此，在主同步期间，客户端仍可以发送查询或修改请求。
Slave Server也以未阻止的方式完成数据同步。 如果客户端在同步期间发送查询请求，Redis将返回同步前的数据
为了分散Master读取操作的压力，Slave服务器可以为客户端提供只读服务，写入服务必须由Master完成。 尽管如此，系统的伸缩性得到了很大的提高。
主机可以将数据保存操作交给Slaves，这样主机中就不需要独立的进程来执行此操作。
支持主从复制，主机可以自动将数据同步到从机，实现读写分离。
缺点：
Redis不具备自动容错和恢复功能，主从设备停机导致读写前端部分的请求失败，需要等待机器重新启动或手动切换前端IP才能恢复。
主机停机，停机前某些数据无法及时同步到从设备，切换IP后会引入数据不一致，降低系统可用性。
Redis的主从复制采用完全复制，在复制过程中，主机会对生成内存快照的子进程进行fork，并将子进程的内存快照作为文件保存到从进程在此过程中，必须确保主机有足够的可用内存。 快照文件较大会严重影响群集的服务能力。 此外，复制过程发生在从站重新加入群集或从站和主机网络断开并重新连接时。 也就是说，网络的变化带来了主机和从机之间数据拷贝的总量，给实际的系统运行带来了不少麻烦。
Redis很难支持在线扩展，当群集容量达到上限时，在线扩展会变得复杂。 为了避免此问题，承运人必须确保系统在线时有足够的空间，造成了严重的资源浪费。
其实redis的主从模式很简单，在实际生产环境中很少使用。 我也不建议在实际生产环境中使用主从模式来提供系统的高可用性。 不建议使用是由于其缺点，在数据量非常大或对系统高可用性要求很高的情况下，主从模型也不稳定。
哨兵模式
该模式由redis 2.6版提供，但当时该版本的模式不稳定，只有在redis 2.8版或更高版本后，该模式才稳定。 无论是主从模式还是哨兵模式，这两种模式都存在问题，无法水平扩展，两种模式的高可用性特性都受到主节点内存的限制。
Sentinel (哨兵)进程用于监视redis集群中主服务器的运行状态，在主服务器发生故障时，可以实现主服务器和从服务器的切换，保证系统的高可用性。
Sentinel (哨兵)流程的作用
监视器：哨兵不断检查你的Master和Slave是否正常工作。
注意：如果受监视的Redis节点出现问题，哨兵可以通过API向管理员或其他APP应用程序发送通知。
自动故障切换(Automatic failover )会在主机无法正常工作时，哨兵开始自动故障切换
迁移操作，它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。Sentinel（哨兵）进程的工作方式
每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）
在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。
哨兵模式的优缺点
优点:
哨兵集群模式是基于主从模式的，所有主从的优点，哨兵模式同样具有。
主从可以切换，故障可以转移，系统可用性更好。
哨兵模式是主从模式的升级，系统更健壮，可用性更高。
缺点:
Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
配置复杂
Redis官方 Cluster集群模式
Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。
这里写图片描述
在这个图中，每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。
Redis集群数据分片
在redis的每一个节点上，都有这么两个东西，一个是插槽（slot）可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是：0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的cxdwx槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
还有就是因为如果集群的话，是有好多个redis一起工作的，那么，就需要这个集群不是那么容易挂掉，所以呢，理论上就应该给集群中的每个节点至少一个备用的redis服务。这个备用的redis称为从节点（slave）。那么这个集群是如何判断是否有某个节点挂掉了呢？
首先要说的是，每一个节点都存有这个集群所有主节点以及从节点的信息。
它们之间通过互相的ping-老迟到的丝袜判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉，我们集群就进入faill状态。还有就是如果有一半以上的主节点宕机，那么我们集群同样进入发力了状态。这就是我们的redis的投票机制，具体原理如下图所示：
投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉.
什么时候整个集群不可用(cluster_state:fail)?
如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.
如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.
Redis 3.0的集群方案有以下两个问题。
一个Redis实例具备了“数据存储”和“路由重定向”，完全去中心化的设计。这带来的好处是部署非常简单，直接部署Redis就行，不像Codis有那么多的组件和依赖。但带来的问题是很难对业务进行无痛的升级，如果哪天Redis集群出了什么严重的Bug，就只能回滚整个Redis集群。
对协议进行了较大的修改，对应的Redis客户端也需要升级。升级Redis客户端后谁能确保没有Bug？而且对于线上已经大规模运行的业务，升级代码中的Redis客户端也是一个很麻烦的事情。
Redis Cluster是Redis 3.0以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。
Jedis sharding集群
Redis Sharding可以说是在Redis cluster出来之前业界普遍的采用方式，其主要思想是采用hash算法将存储数据的key进行hash散列，这样特定的key会被定为到特定的节点上。
庆幸的是，Java Redis客户端驱动Jedis已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool
Jedis的Redis Sharding实现具有如下特点：
采用一致性cxdwx算法，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性cxdwx而不是采用简单类似cxdwx求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性cxdwx只影响相邻节点key分配，影响量小。
为了避免一致性cxdwx只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。
ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。
当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性cxdwx，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。
作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。
利用中间件代理
中间件的作用是将我们需要存入redis中的数据的key通过一套算法计算得出一个值。然后根据这个值找到对应的redis节点，将这些数据存在这个redis的节点中。
常用的中间件有这几种
Twemproxy
Codis
nginx
具体用法就不赘述了，可以自行百度。
总结
客户端分片（sharding）需要客户端维护分片算法，这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。
利用中间件的情况则会影响到redis的性能，具体看中间件而定，毕竟所有请求都要经过中间件一层过滤
官方提供方案，现时点成功案例不多。