redis集群三种方式（使用 redis-cli 搭建 Redis 集群）

本文目录

• 使用 redis-cli 搭建 Redis 集群
• Redis集群模式1-主从复制+哨兵机制
• redis集群方案有哪些
• redis如何集群
• 五分钟系列之Redis大规模数据存储简述
• redis怎么组建集群
• Redis主从模式、哨兵模式以及Cluster 集群模式
• Redis Cluster集群的搭建
• redis怎么实现集群

使用 redis-cli 搭建 Redis 集群

参考： Redis 集群教程

redis.conf 文件中包含很多信息，如：端口号、持久化方式、持久化的文件等等。

使用写入了不同端口号的配置文件就可以启动多个 Redis 实例。
下面是一个最少选项的集群的配置文件:

文件中的 cluster-enabled 选项用于开实例的集群模式， 而 cluster-conf-file 选项则设定了保存节点配置文件的路径， 默认值为 nodes.conf 。节点配置文件无须人为修改， 它由 Redis 集群在启动时创建， 并在有需要时自动进行更新。

要让集群正常运作至少需要三个主节点，不过在刚开始试用集群功能时， 强烈建议使用六个节点： 其中三个为主节点， 而其余三个则是各个主节点的从节点。

首先， 让我们进入一个新目录， 并创建六个以端口号为名字的子目录， 稍后我们在将每个目录中运行一个 Redis 实例： 命令如下:

在文件夹 7000 至 7005 中， 各创建一个 redis.conf 文件， 文件的内容可以使用上面的示例配置文件， 但记得将配置中的 port 和 cluster-conf-file 中的端口号数字 从 7000 改为与文件夹名字相同的号码。不同的集群节点要使用不同的 cluster-conf-file 。
配置文件的路径是可以自定义的。创建完毕后分别启动一个实例。

网上看到的教程，包括参考的官方文档里的文章，大多是使用以下方式创建集群。

这个命令在这里用于创建一个新的集群, 选项–replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。
之后跟着的其他参数则是这个集群实例的地址列表，3 个 master 3 个 slave redis-trib 会打印出一份预想中的配置给你看，如果你觉得没问题的话，就可以输入 yes，redis-trib 就会将这份配置应用到集群当中，让各个节点开始互相通讯，最后可以得到如下信息：

这表示集群中的 16384 个槽都有至少一个主节点在处理，集群运作正常。

但是在 Redis 的 github 仓库 中看到，该文件已经不建议使用。

我在 手把手教你实现 Docker 部署 Redis 集群 的评论中看到， 现在 redis-cli --cluster 命令已经可以创建集群，分配槽，分配主从服务器了 ，于是使用以下命令了解到相关的命令。

可以看到，命令的组成形式和旧方式是一致的。

可以看到执行命令后，redis 客户端做了以下工作：

输入 yes 后，redis 客户端做了以下工作：

集群搭建完毕。

因为 Redis Cluster 默认要求所有的槽位被覆盖，可以通过修改 cluster-require-full-coverage yes 配置来改变该行为。
CLUSTERDOWN The cluster is down in redis 这里的回答中提到：我们可以使用 N 个Master 和 N+1 个 Slave，正常情况下多余的一个实例作为随机一个 Master 的 Slave，一旦有实例宕机，可以迅速顶替，以保证每个主节点总是有至少一个从节点保持数据同步。

ps：搜索命令行的输出时，才看到 深入理解Redis系列之集群环境搭建 这篇文章，有时候搜索的关键词不合适容易走弯路啊……

Redis集群模式1-主从复制+哨兵机制

单个Redis服务如果宕机的话，服务就不可用了，为了解决这种问题，redis也提供有集群服务。传统的Redis集群采用的主从复制模式，一般为一主多从，主节点有读写权限，但是从节点只有读的权限。主节点会定期将数据同步到从节点中，保证数据一致性的问题。这种集群方式在运行时存在一些问题：

Redis的哨兵机制就是解决主从复制存在缺陷（选举问题），解决问题保证我们的Redis高可用，实现自动化故障发现与故障转移。
要使用哨兵机制，除了启动Redis服务以外，还要启动哨兵服务来进行监控，会介绍详细步骤。哨兵服务的工作原理如下：

演示集群采用1主2从，采用伪集群，在一台虚拟机中启动，端口暂定6381、6382、6383，集群结构可以选择下面2种，因为数量较少，此次采用普通样式。

主节点配置文件和单机的时候一样，主要修改以下几点

基本和主节点差不多，但要加上 slaveof 配置和主节点账号密码。

哨兵配置文件是 sentinel.conf ，因为有3个redis服务，所以启动3个哨兵服务，对应的配置文件分别为： sentinel_26381.conf 、 sentinel_26382.conf 、 sentinel_26383.conf

Redis服务和哨兵服务都启动了，可以测试哨兵的自动选举了，将6381沙雕，等几秒，再查看6382,6382的主从信息

注意：这个时候如果去看redis的配置文件，会发现配置文件中已经自动改好了主节点为6383了；而且哨兵的配置文件中，也改了主节点为6383了。这些都是哨兵帮我们做的

因集群中已有了新主节点，所以6381再启动只能作为从节点。此时6381启动，需要在配置文件中加入主节点信息：

redis集群方案有哪些

Redis数据量日益增大，而且使用的公司越来越多，不仅用于做缓存，同时趋向于存储这块，这样必促使集群的发展，各个公司也在收集适合自己的集群方案，目前行业用的比较多的是下面几种集群架构，大部分都是采用分片技术，解决单实例内存增大带来的一系列问题。
本篇文章简单介绍五种方案：
官方cluster方案
twemproxy代理方案
哨兵模式
codis
客户端分片
官方cluser方案
从redis 3.0版本开始支持redis-cluster集群，redis-cluster采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他节点连接。redis-cluster是一种服务端分片技术。
redis-cluster架构图
redis-cluster特点：
每个节点都和n-1个节点通信，这被称为集群总线（cluster bus）。它们使用特殊的端口号，即对外服务端口号加10000。所以要维护好这个集群的每个节点信息，不然会导致整个集群不可用，其内部采用特殊的二进制协议优化传输速度和带宽。
redis-cluster把所有的物理节点映射到slot（槽）上，cluster负责维护node--slot--value。
集群预分好16384个桶，当需要在redis集群中插入数据时，根据CRC16(KEY) mod 16384的值，决定将一个key放到哪个桶中。
客户端与redis节点直连，不需要连接集群所有的节点，连接集群中任何一个可用节点即可。
redis-trib.rb脚本（rub语言）为集群的管理工具，比如自动添加节点，规划槽位，迁移数据等一系列操作。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
整个cluster被看做是一个整体，客户端可连接任意一个节点进行操作，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点。
为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。如果主节点失效，redis cluster会根据选举算法从slave节点中选择一个上升为master节点，整个集群继续对外提供服务。
twemproxy代理方案
twemproxy代理架构图：
Redis代理中间件twemproxy是一种利用中间件做分片的技术。twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后（sharding），再转发给后端真正的redis服务器。也就是说，客户端不直接访问redis服务器，而是通过twemproxy代理中间件间接访问。降低了客户端直连后端服务器的连接数量，并且支持服务器集群水平扩展。
twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可以避免单点压力或故障。
twemproxy又称nutcracker，起源于推特系统中redis、memcached集群的轻量级代理。
***隐藏网址***
从上面架构图看到twemproxy是一个单点，很容易对其造成很大的压力，所以通常会结合keepalived来实现twemproy的高可用。这时，通常只有一台twemproxy在工作，另外一台处于备机，当一台挂掉以后，vip自动漂移，备机接替工作。关于keepalived的用法可自行网上查阅资料。
哨兵模式
Sentinel哨兵
Sentinel（哨兵）是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器以及这些主服务器下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。
例如:
在Server1掉线后：
升级Server2为新的主服务器：
Sentinel的工作方式
每个Sentinel以每秒钟一次的频率向它所知的Master、Slave以及其他Sentinel实例发送一个PING命令。
如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds选项所指定的值，则这个实例会被Sentinel标记为主观下线。
如果一个Master被标记为主观下线，则正在监视这个Master的所有Sentinel要以每秒一次的频率确认Master的确进入了主观下线状态。
当有足够数量的Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线。
在一般情况下，每个Sentinel会以每10秒一次的频率向它所知的所有Master、Slave发送INFO命令。
当Master被Sentinel标记为客观下线时，Sentinel向下线的Master的所有Slave发送INFO命令的频率会从10秒一次改为每秒一次。
若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除。若Master重新向Sentinel的PING命令返回有效值，Master的主观下线状态就会被移除。
codis
codis是一个分布式的Redis解决方案，由豌豆荚开源，对于上层的应用来说，连接codis proxy和连接原生的redis server没什么明显的区别，上层应用可以像使用单机的redis一样使用，codis底层会处理请求的转发，不停机的数据迁移等工作，所有后边的事情，对于前面的客户端来说是透明的，可以简单的认为后边连接的是一个内存无限大的redis服务。
客户端分片
分区的逻辑在客户端实现，由客户端自己选择请求到哪个节点。方案可参考一致性哈希，这种方案通常适用于用户对客户端的行为有完全控制能力的场景。
总结：没有最好的方案，只有最合适的方案。
更多Redis相关技术文章，请访问Redis教程栏目进行学习！

redis如何集群

Redis Sharding集群
Redis Sharding是一种客户端Sharding分片技术。
Redis Sharding可以说是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。（推荐学习：Redis视频教程）
这样，客户端就知道该向哪个Redis节点操作数据,需要说明的是，这是在客户端完成的。
java redis客户端jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。Jedis的Redis Sharding实现具有如下特点:
1、采用一致性哈希算法(consistent hashing)
***隐藏网址***
2、虚拟节点
ShardedJedis会对每个Redis节点，根据名字虚拟化出160个虚拟节点进行散列。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动更分配更均匀，而不是只有相邻节点受影响。如图，Redis节点1虚拟化成NODE1-1和NODE1-2,散列中哈希环上。这样当object1、object2散列时，选取最近节点NODE1-1和NODE1-2,而NODE1-1和NODE1-2又是NODE节点的虚拟节点，即实际存储在NODE节点上。
增加虚拟节点，可以保证平衡性，即每台Redis机器，存储的数据都差不多，而不是一台机器存储的数据较多，其它的少。
3、ShardedJedis支持keyTagPattern模式
抽取key的一部分keyTag做sharding，这样通过合理命名key,可以将一组相关联的key放入同一Redis节点，避免跨节点访问。即客户端将相同规则的key值，指定存储在同一Redis节点上。
添加或减少节点时？
Redis Sharding采用客户端Sharding方式，服务端的Redis还是一个个相对独立的Redis实例节点。同时，我们也不需要增加额外的中间处理组件，这是一种非常轻量、灵活的Redis多实例集群方案。
当然，这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，那么不同的key分布到不同的Redis节点上。
当我们需要扩容时，增加机器到分片列表中。这时候客户端根据key算出来落到跟原来不同的机器上，这样如果要取某一个值，会出现取不到的情况。
对于这一种情况，一般的作法是取不到后，直接从后端数据库重新加载数据，但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。
Redis作者给出了一个办法--presharding。
是一种在线扩容的方法，原理是将每一台物理机上，运行多个不同端口的Redis实例，假如三个物理机，每个物理机运行三个Redis实例，那么我们的分片列表中实际有9个Redis实例，当我们需要扩容时，增加一台物理机，步骤如下：
1、在新的物理机上运行Redis-server
2、该Redis-server从属于（slaveof）分片列表中的某一Redis-Server(假设叫RedisA)。
3、主从复制(Replication)完成后，将客户端分片列表中RedisA的IP和端口改为新物理机上Redis-Server的IP和端口。
4、停止RedisA
这样相当于将某一Redis-Server转移到了一台新机器上。但还是很依赖Redis本身的复制功能，如果主库快照数据文件过大，这个复制的过程也会很久，同时也会给主Redis带来压力，所以做这个拆分的过程最好选择业务访问低峰时段进行。
节点发生故障时
并不是只有增删Redis节点引起键值丢失问题，更大的障碍来自Redis节点突然宕机。
为不影响Redis性能，尽量不开启AOF和RDB文件保存功能，因此需架构Redis主备模式，主Redis宕机，备Redis留有备份，数据不会丢失。
Sharding演变成如下：
这样，我们的架构模式变成一个Redis节点切片包含一个主Redis和一个备Redis，主备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性.
Redis Sentinel哨兵
提供了主备模式下Redis监控、故障转移等功能，达到系统的高可用性。
读写分离
高访问时量下，即使采用Sharding分片，一个单独节点还是承担了很大的访问压力，这时我们还需要进一步分解。
通常情况下，读常常是写的数倍，这时我们可以将读写分离，读提供更多的实例数。利用主从模式实现读写分离，主负责写，从负责只读，同时一主挂多个从。在Redis Sentinel监控下，还可以保障节点故障的自动监测。
更多Redis相关技术文章，请访问Redis数据库使用入门教程栏目进行学习！

五分钟系列之Redis大规模数据存储简述

互联网场景下面临的主要技术问题之一是高并发大数据量。为了提高性能保护数据库通常会在数据库之上加一层缓存。目前常用的缓存是Redis，那么Redis如何存储大规模数据？如何将数据库的数据同步到Redis？Redis缓存设计要注意哪些问题？

Redis大规模数据存储通过集群实现。目前常见的集群方式有三种方案。

第一种使用Redis自带的集群技术Redis cluster。

第二种是使用代理方式，在客户端与Redis节点之间加一层代理服务目前开源的实现有codis和twemproxy。

第三种是定制客户端实现，在客户端实现节点的寻址功能。

数据库数据同步到缓存目前常见的方式有四种方式。

方式一在业务应用服务中实现。在修改数据库的同时更新缓存。

方式二通过消息队列异步更新。在业务中更新数据后发送消息，消息消费者订阅消息对缓存进行更新。

方式三通过定时任务更新。通过定时任务监控数据变更，同步更新数据到缓存。

方式三通过数据库Binlog更新。通过一些开源中间间如canal订阅数据库日志更新，解析日志然后对解析后的日志执行缓存更新操作。

缓存设计需要注意下面四个问题。

数据一致性问题。

数据库和缓存数据保持一致。目前常见的四种缓存更新模式。cache aside、read through 、write through、write behind caching。

缓存穿透问题。

目前解决缓存击穿的思路主要是过滤无效请求。如通过键的规则校验过滤恶意请求，布隆过滤器过滤无效请求。其次是缓存空结果。

缓存击穿问题。

目前解决缓存击穿的思路是对请求加全局锁，还有就是对即将过期的数据进行主动刷新。

缓存雪崩问题。

缓存雪崩目前常见的思路是设置缓存过期时间时随机设置失效时间避免缓存同时失效。还有缓存存储时划分更小的缓存区间按区间设置缓存失效时间。

缓存的使用是一个整体方案分层分布式设计。上述只是整体性描述，实际过程中的细节很多也很复杂。

redis怎么组建集群

简要说明
2018年十月 Redis 发布了稳定版本的 5.0 版本，推出了各种新特性，其中一点是放弃 Ruby的集群方式，改为 使用 C语言编写的 redis-cli的方式，是集群的构建方式复杂度大大降低。关于集群的更新可以在 Redis5 的版本说明中看到，如下：
The cluster manager was ported from Ruby (redis-trib.rb) to C code inside redis-cli. check `redis-cli --cluster help ` for more info.可以查看Redis官网查看集群搭建方式，连接如下
***隐藏网址***
以下步骤是在一台 Linux 服务器上搭建有6个节点的 Redis集群。
操作步骤
创建目录
新建目录：/root/software/redis
下载源码并解压编译
***隐藏网址***
tar xzf redis-5.0.0.tar.gz
cd redis-5.0.0
make创建6个Redis配置文件
6个配置文件不能在同一个目录，此处我们定义如下：
/root/software/redis/redis-cluster-conf/7001/redis.conf
/root/software/redis/redis-cluster-conf/7002/redis.conf
/root/software/redis/redis-cluster-conf/7003/redis.conf
/root/software/redis/redis-cluster-conf/7004/redis.conf
/root/software/redis/redis-cluster-conf/7005/redis.conf
/root/software/redis/redis-cluster-conf/7006/redis.conf配置文件的内容为：
port 7001 #端口
cluster-enabled yes #启用集群模式
cluster-config-file nodes.conf
cluster-node-timeout 5000 #超时时间
appendonly yes
daemonize yes #后台运行
protected-mode no #非保护模式
pidfile /var/run/redis_7001.pid其中 port 和 pidfile 需要随着 文件夹的不同调增
启动节点
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7001/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7002/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7003/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7004/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7005/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7006/redis.conf启动集群
/root/software/redis/redis-5.0.0/src/redis-cli --cluster create 192.168.2.40:7001 192.168.2.40:7002 192.168.2.40:7003 192.168.2.40:7004 192.168.2.40:7005 192.168.2.40:7006 --cluster-replicas 1启动后，可看到成功信息，如下：
》》》 Performing hash slots allocation on 6 nodes...
Master -》 Slots 0 - 5460
Master -》 Slots 5461 - 10922
Master -》 Slots 10923 - 16383
Adding replica 192.168.2.40:7004 to 192.168.2.40:7001
Adding replica 192.168.2.40:7005 to 192.168.2.40:7002
Adding replica 192.168.2.40:7006 to 192.168.2.40:7003
》》》 Trying to optimize slaves allocation for anti-affinity
Some slaves are in the same host as their master
M: 191c645200a8b4d267f71e3354c8248dbb533dde 192.168.2.40:7001
slots: (5461 slots) master
M: 400a08d4e5a534c1b609988105d3e045395fbd12 192.168.2.40:7002
slots: (5462 slots) master
M: 684f6aa0fbccda295ce6818a8c01ee7255a7b002 192.168.2.40:7003
slots: (5461 slots) master
S: f2701549ae98315b432d73b49d139ee77d5685b4 192.168.2.40:7004
replicates 684f6aa0fbccda295ce6818a8c01ee7255a7b002
S: 9fdc1e375436767ab815cbddd3df674f3bc2ca99 192.168.2.40:7005
replicates 191c645200a8b4d267f71e3354c8248dbb533dde
S: e7742888ed85b37cff4a98e861e99bb16e8bae2c 192.168.2.40:7006
replicates 400a08d4e5a534c1b609988105d3e045395fbd12
Can I set the above configuration? (type ’yes’ to accept): yes
》》》 Nodes configuration updated
》》》 Assign a different config epoch to each node
》》》 Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
....
》》》 Performing Cluster Check (using node 192.168.2.40:7001)
M: 191c645200a8b4d267f71e3354c8248dbb533dde 192.168.2.40:7001
slots: (5461 slots) master
1 additional replica(s)
M: 684f6aa0fbccda295ce6818a8c01ee7255a7b002 192.168.2.40:7003
slots: (5461 slots) master
1 additional replica(s)
S: 9fdc1e375436767ab815cbddd3df674f3bc2ca99 192.168.2.40:7005
slots: (0 slots) slave
replicates 191c645200a8b4d267f71e3354c8248dbb533dde
S: e7742888ed85b37cff4a98e861e99bb16e8bae2c 192.168.2.40:7006
slots: (0 slots) slave
replicates 400a08d4e5a534c1b609988105d3e045395fbd12
M: 400a08d4e5a534c1b609988105d3e045395fbd12 192.168.2.40:7002
slots: (5462 slots) master
1 additional replica(s)
S: f2701549ae98315b432d73b49d139ee77d5685b4 192.168.2.40:7004
slots: (0 slots) slave
replicates 684f6aa0fbccda295ce6818a8c01ee7255a7b002
All nodes agree about slots configuration.
》》》 Check for open slots...
》》》 Check slots coverage...
All 16384 slots covered.至此，Reids集群搭建完成。

Redis主从模式、哨兵模式以及Cluster 集群模式

主从模式指的是使用一个Redis实例作为主机，其余的实例作为备份机。一般来说主节点负责写请求，从节点负责读请求，主节点异步的同步给从节点。主节点和从节点保存的数据是相同的，但是因为同步，从节点的数据会有一点延迟。但是主从模式的高可用会有问题。因为主节点挂了之后是没有自动选主机制的，需要人工干预来指定一个从节点作为主节点。

为了解决主从模式不能高可用的问题，哨兵模式就出现了。哨兵模式就是在主从模式的基础上再加一个哨兵集群。每个哨兵都会监控主节点和从节点的状态。如果主节点挂了，就会从从节点中选出一个来作为主节点，以达到高可用的目的。（也就是有了自动选主机制）

哨兵集群中的每个节点都会启动三个定时任务

如果一个 实例（instance）距离最后一次有效回复 PING命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel标记为 主观下线 。

如果一个 主服务器 被标记为主观下线，那么正在 监视 这个主服务器的所有 Sentinel 节点，要以 每秒一次的频率确认 该主服务器是否的确进入了主观下线状态。

如果一个主服务器 被标记为主观下线，并且有 足够数量的 Sentinel（至少要达到配置文件指定的数量）在指定的 时间范围 内同意这一判断，那么这个该主服务器被标记为 客观下线。
哨兵模式解决了故障不能自动恢复的问题，但仍存在的问题是：Redis较难支持在线扩容，对于集群，容量达到上限时在线 扩容会变得很复杂 。

Redis Cluster采用虚拟槽分区，所有的键按照哈希函数映射到0~16383槽中，每个Redis节点维护部分槽和槽中的数据。

Redis Cluster集群的搭建

搭建集群工作需要以下三个步骤：

1）准备节点。

2）节点握手。

3）分配槽。

Redis集群一般由多个节点组成，节点数量至少为6个才能保证组成完整高可用的集群。每个节点需要开启配置cluster-enabled yes，让Redis运行在集群模式下。建议为集群内所有节点统一目录，一般划分三个目录：conf、data、log，分别存放配置、数据和日志相关文件。把6个节点配置统一放在conf目录下，集群相关配置如下：

其他配置和单机模式一致即可，配置文件命名规则redis-{port}.conf，准备好配置后启动所有节点。

Cluster集群启动过程如下图：
每个节点目前只能识别出自己的节点信息，可以执行cluster nodes命令获取集群节点状

态。

节点握手是指一批运行在集群模式下的节点通过Gossip协议彼此通信，达到感知对方的过程。节点握手是集群彼此通信的第一步，由客户端发起命令：cluster meet{ip}{port}

cluster meet命令是一个异步命令，执行之后立刻返回。内部发起与目标节点进行握手通信，握手通信过程：

1）节点6379本地创建6380节点信息对象，并发送meet消息。

2）节点6380接受到meet消息后，保存6379节点信息并回复pong消息。

3）之后节点6379和6380彼此定期通过ping/pong消息进行正常的节点通

信。

分别执行meet命令让其他节点加入到集群中，

最后执行cluster nodes命令确认6个节点都彼此感知并组成集群。

节点建立握手之后集群还不能正常工作，这时集群处于下线状态，所有的数据读写都被禁止，通过cluster info命令可以获取集群当前状态。

Redis集群把所有的数据映射到16384个槽中。每个key会映射为一个固定的槽，只有当节点分配了槽，才能响应和这些槽关联的键命令。通过cluster addslots命令为节点分配槽。这里利用bash特性批量设置槽（slots），命令如下：

执行cluster info查看集群状态，如下所示：

当前集群状态是OK，集群进入在线状态。所有的槽都已经分配给节点，执行cluster nodes命令可以看到节点和槽的分配关系：

集群模式下，Reids节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。使用cluster replicate{nodeId}命令让一个节点成为从节点。其中命令执行必须在对应的从节点上执行，nodeId是要复制主节点的节点ID，命令如下：

Redis集群模式下的主从复制使用了之前介绍的Redis复制流程，依然支持全量和部分复制。复制（replication）完成后，整个集群的结构如图：
集群搭建需要很多步骤当集群节点众多时，必然会加大搭建集群的复杂度和运维成本。因此Redis官方提供了redis-trib.rb工具方便我们快速搭建集群。

redis-trib.rb是采用Ruby实现的Redis集群管理工具。内部通过Cluster相关命令帮我们简化集群创建、检查、槽迁移和均衡等常见运维操作，使用之前需要安装Ruby依赖环境。

1、安装Ruby：

2、安装rubygem redis依赖：

3、安装redis-trib.rb：

4、安装完Ruby环境后，执行redis-trib.rb命令确认环境是否正确，输出如

下：

首先我们跟之前内容一样准备好节点配置并启动：

启动好6个节点之后，使用redis-trib.rb create命令完成节点握手和槽分配过程，命令如下：

--replicas参数指定集群中每个主节点配备几个从节点，这里设置为1。

如果部署节点使用不同的IP地址，redis-trib.rb会尽可能保证主从节点不分配在同一机器下，因此会重新排序节点列表顺序。节点列表顺序用于确定主从角色，先主节点之后是从节点。创建过程中首先会给出主从节点角色分配的计划，当我们同意这份计划之后输入yes，redis-trib.rb开始执行节点握手和槽分配操作。

集群完整性指所有的槽都分配到存活的主节点上，只要16384个槽中有一个没有分配给节点则表示集群不完整。可以使用redis-trib.rb check命令检测之前创建的集群是否成功，check命令只需要给出集群中任意一个节点地址就可以完成整个集群的检查工作，命令如下：

redis怎么实现集群

1.主从复制
主从复制原理：
从服务器连接主服务器，发送SYNC命令；
主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）
主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操作）
主从复制优缺点：
优点：
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成
Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。
Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据
缺点：
Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。
2.哨兵模式
当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
（1）监控主服务器和从服务器是否正常运行。
（2）主服务器出现故障时自动将从服务器转换为主服务器。
哨兵的工作方式：
每个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较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。
3.Redis-Cluster集群
redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
Redis-Cluster采用无中心结构,它的特点如下：
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
工作方式：
在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。
更多Redis相关技术文章，请访问Redis教程栏目进行学习！