文章目录

  • 前言
  • 一、Redis-Cluster(集群)长什么样子?
  • 二、Redis-Cluster集群搭建
    • 1. Redis集群搭建
    • 2. 客户端测试
    • 3. 增加主节点(6000)到集群环境中
    • 4. 添加从节点6001和6002到集群环境(6000的从节点)
    • 5. 删除集群中的节点
      • 5.1 删除从节点
      • 5.2 删除主节点
  • 三、RedisCluster(集群)原理分析
    • 1、 槽位定位算法
    • 2、跳转重定位
    • 3、Redis集群间的节点通信
      • 3.1 集中式:
      • 3.2 gossip
      • 3.3 gossip通信的10000端口
    • 4、网络抖动
    • 5、Redis集群选举原理分析
    • 6、集群脑裂数据丢失问题
    • 7、集群是否完整才能对外提供服务
    • 8、Redis集群为什么至少需要三个master节点,并且推荐节点数为奇数?
    • 9、Redis集群对批量操作命令的支持
  • 四、总结

前言

今天和大家分享一下Redis真正意义上的一种高可用架构,就是Redis-Cluster(Redis集群)。它具有复制、高可用和分片的特性。他可以完全不用sentinel哨兵也能实现节点删除和故障转移的功能。并且当主节点挂掉以后新选举主节点的速度也比sentinel快。当然,他的主节点可以有很多个。官方提供的数据是最多可以有10000个,但是官方也建议最好不要超过1000个,否则会影响Redis的性能。这也为什么说Redis-Cluster是真正意义上实现了高可用。今天主要分两个部分分享,一是分享Redis-Cluster如何搭建。二是Redis-Cluster的工作原理以及相关问题作出解释。

一、Redis-Cluster(集群)长什么样子?

我还是通过一张图作出解释:

从结构图上可以看出Redis-Cluster明显不同于和主从架构和哨兵架构。Redis集群里面可以看到他有好多个主节点。Redis集群至少需要三个主节点。后面我会解释为什么至少需要三个主节点。通过这幅图重点去理解复制、高可用和分片。复制就是说我们的主从节点可以横向扩展。建议不要超过1000个。高可用是相比哨兵架构模式,在哨兵架构模式下虽然能做到故障转移但是不能用于并发特别高的场景中,因为只有一个主节点。而集群模式下他可以有很多个主节点对客户端提供服务。分片就是分片存储。用户在set一个key的时候,服务端拿到这个key会做哈希槽定位算法,把这个key所对应的值 存放到对应的哈希槽中。所以他是分片的。后面还会详细说明哈希槽定位算法。


二、Redis-Cluster集群搭建

1. Redis集群搭建

搭建图我已经在上面提供了。不过这里需要申明一下,我们我也是在虚拟机上搭建的。计算机本身硬件条件有限,所有我就创建了三台虚拟机,分别是vm-server1、vm-server2和vm-server3。在每一台虚拟机机器上分别搭建一个主节点和两个从节点。是不是有很多疑惑,一台机器可以安装多个Redis实例。怎么安装?很简单。我们只需要提前把Redis安装好(按照在一台机器上安装Redis的方式安装就ok了),接下来我们只需要把redis安装根目录下面的redis.conf文件复制多分,配置对应的redis.config文件,然后启动的时候指定对应的配置文件即可。那我们就开始安装吧

为了整体结构清晰,我就不在redis的根目录下操作了。我在 /usr/local 目录下面新建一个redis-cluster文件夹,存放对应节点的redis配置文件
[root@192 local]# mkdir redis-cluster# vm-server1配置主节点和从节点
在vm-serever1的redis-cluster文件下面新建三个目录7000、7001和7002。7000目录用来存放master节点的redis配置文件,7001和7002分别存放从节点的redis配置文件。
创建三个文件夹命令如下:
[root@192 redis-cluster]# mkdir 7000 7001 7002
分别将redis.config文件复制到这三个文件夹中
[root@192 redis-cluster]# cp ../redis-5.0.14/redis.conf 7000/
[root@192 redis-cluster]# cp ../redis-5.0.14/redis.conf 7001/
[root@192 redis-cluster]# cp ../redis-5.0.14/redis.conf 7002/#进入7000目录下面的redis.config文件进行配置:
[root@192 redis-cluster]# vim 7000/redis.conf
#接下来就正式开始配置了,前面的都是辅助工作:
1、daemonize yes  //开启后台启动
2、port 7000   //修改端口(如果在一台机器上开启多个redis实例,就需要为每个redis实例配置不同的端口号)
3、pidfile /var/run/redis_7000.pid   //把pid进程号写入pidfile配置的文件
4、dir /usr/local/redis-cluster/7000/   //指定数据文件的存放位置,必须指定存放在不同的目录中,否则会丢失数据
5、cluster-enabled yes   //开启集群模式
6、cluster-config-file nodes-7000.conf  //集群节点信息文件,建议最好与port一致
7、cluster-node-timeout 10000     //集群节点的超时时间(超过这个时间,集群中的其他主节点就认为这个挂了)
8、#bind 127.0.0.1    //bind绑定的是自己机器网卡的ip,如果有多块网卡可以配多个ip,代表允许客户端通过机器的哪些网卡ip去访问,内网一般可以不配置bind,注释掉即可
9、protected-mode no  //关闭保护模式
10、appendonly yes   //开启aof持久化#如果需要配置密码(可以不配置)
11、requirepass root  //设置访问redis的密码
12、masterauth root  //设置集群节点间访问密码#其他节点也是这样配置,只是上面设计到端口号的需要改变一下。为了方便期间,我们直接把刚才配置号的配置文件分别复制到7001和7002里面(其他机器也是这样配置,改端口就行)。
#下面我列举一下具体改那些端口号:
1、port:xxxx   //修改对应的端口号   7000 7001 7002 8000 8001等
2、pidfile /var/run/redis_xxxx.pid  //修改对应的端口号 7000 7001 7002 8000 8001等
3、dir /usr/local/redis-cluster/xxxx/  //修改成对应端口号 7000 7001 7002 8000 8001等
4、cluster-config-file nodes-xxxx.conf   //修改i成对应端口号 7000 7001 7002 8000 8001等
配置就完成了

启动如下命令如下(启动vm-server1机器的redis实例):
redis-5.0.14/src/redis-server redis-cluster/7000/redis.conf
redis-5.0.14/src/redis-server redis-cluster/7001/redis.conf
redis-5.0.14/src/redis-server redis-cluster/7002/redis.conf

启动如下命令如下(启动vm-server2机器的redis实例):
redis-5.0.14/src/redis-server redis-cluster/8000/redis.conf
redis-5.0.14/src/redis-server redis-cluster/8001/redis.conf
redis-5.0.14/src/redis-server redis-cluster/8002/redis.conf

启动如下命令如下(启动vm-server3机器的redis实例):
redis-5.0.14/src/redis-server redis-cluster/9000/redis.conf
redis-5.0.14/src/redis-server redis-cluster/9001/redis.conf
redis-5.0.14/src/redis-server redis-cluster/9002/redis.conf

以上就完成了所有主从redis节点的启动。但是,他们彼此之间都是游离的状态,还没有组成集群。我们只是以集群的方式启动了。好,接下来我们就配置他们成为集群。我们使用redis-cli创建redis集群(redis5以前是使用ruby脚本redis-trib.rb实现)配置之前,记得关闭机器的防火墙,否则,节点之间没发通信。要不就将节点的所有端口都加入到防火墙中(所有端口包括redis服务端口和集群节点gossip通信端口16739,集群端口默认是在redis端口上加上1万)。

systemctl status firewalld.service #查看防火墙状态
systemctl stop firewalld # 临时关闭防火墙
systemctl disable firewalld # 禁止开机启动

生成集群的命令如下(我们只需要在三台机器上任意一台机器运行这段命令即可):

redis-5.0.14/src/redis-cli -a root --cluster create --cluster-replicas 2 192.168.1.7:7000 192.168.1.8:8000 192.168.1.9:9000 192.16168.1.7:7001 192.168.1.7:7002 192.168.1.8:8001 192.168.1.8:8002 192.168.1.9:9001 192.168.1.9:9002详细解释如下图


集群创建成功如下图:

接下来我们验证一下集群是否搭建成功。连接任意一个客户端 redis-5.0.14/src/redis-cli -a -c -h -p(-a 访问redis服务端密码,-c 表示集群模式、-h 指定IP地址、-p 端口号)
例如:redis-5.0.14/src/redis-cli -a root -c -h 192.168.1.8 -p 8000

进如以后,可以使用cluster info查看集群信息以及使用cluster nodes查看节点信息
使用cluster info 命令查看节点信息如下图:

使用cluster nodes查看集群节点信息如下图所示:

不知道大家使用cluster nodes命令查看完集群的节点信息以后会不会有疑问?就是在文章最开始的时候有一个结构吴图,上面描述着每个主节点信息以及主节点对应的从节点信息。例如:7000端口的主节点对应的从节点按照架构图上的描述应该是7001和7002机器。但是,根据cluster nodes命令查看结果来看,好像跟我们说的还有点差别。可以看出,7000主节点对应的从节点分别是8001和9001。为什么会这样?我来解释一下,Redis在创建集群的过程中,我们可以控制让那些节点成为主节点,但是不能控制主节点对应的从节点。这个分配是随机的。其实更重要有的原因是,Redis集群认为,如果一个主节点和他的从节点都在一台机器上。如果这台机器宕机了,那么所有的主从节点都将不能使用。所以,才会分散开来。
关闭集群需要逐个去关闭,使用如下命令:
redis-5.0.14/src/redis-cli -a root -c -h 192.168.1.7 -p 7000 shutdown
在关闭集群以后再次启动redis集群时,不需要再次配置集群。只需要我们正常启动redis实例就可以。集群的配置文件已经记录了集群的配置信息,集群会根据配置信息进行内部通信调整。

2. 客户端测试

通过jedis客户端连接测试:

@SpringBootTest
class RedisTestApplicationTests {@Testvoid testRedisCluster() throws IOException {JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();jedisPoolConfig.setMaxTotal(20);jedisPoolConfig.setMaxIdle(10);jedisPoolConfig.setMinIdle(5);Set<HostAndPort> set = new HashSet<>();set.add(new HostAndPort("192.168.1.7",7000));set.add(new HostAndPort("192.168.1.8",8000));set.add(new HostAndPort("192.168.1.9",9000));set.add(new HostAndPort("192.168.1.7",7001));set.add(new HostAndPort("192.168.1.7",7002));set.add(new HostAndPort("192.168.1.8",8001));set.add(new HostAndPort("192.168.1.8",8002));set.add(new HostAndPort("192.168.1.9",9001));set.add(new HostAndPort("192.168.1.9",9002));JedisCluster jedisCluster = null;try {jedisCluster = new JedisCluster(set,6000,5000,10,"root",jedisPoolConfig);jedisCluster.set("wife","duanting");System.out.println("jedisCluster.get(\"wife\") = " + jedisCluster.get("wife"));}catch (Exception e){e.printStackTrace();}finally {if(jedisCluster != null){jedisCluster.close();}}}}

运行结果图如下:

springboot集成测试:
首先需要引入两个依赖:

     <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId></dependency><dependency><groupId>org.apache.commons</groupId><artifactId>commons-pool2</artifactId></dependency>

其次,需要在springboot的配置文件中配置:

server:port: 7500
spring:redis:database: 0  #配置redis默认的数据库timeout: 5000 #配置超市时间cluster:  #配置redis集群的所有主从节点nodes: 192.168.1.7:7000,192.168.1.8:8000,192.168.1.9:9000,192.168.1.7:7001,192.168.1.7:7002,192.168.1.8:8001,192.168.1.8:8002,192.168.1.9:9001,192.168.1.9:9002lettuce:#配置连接池的信息pool:max-active: 100max-idle: 50min-idle: 10max-wait: 1000password: root #配置密码

测试代码如下:

 @Autowiredprivate StringRedisTemplate stringRedisTemplate;@Testpublic void testSpringbootRedis() {int i = 1;while (true) {try {stringRedisTemplate.opsForValue().set("xiaohua" + i, "luxiaohua" + i);System.out.println("设置小花" + i);Thread.sleep(1000);i++;} catch (Exception e) {e.printStackTrace();}}}

运行结果:

到这里,我们的集群基本就搭建完成了。

3. 增加主节点(6000)到集群环境中

试试想,如果在实际生产环境中,我们的集群性能可能跟不上业务的并发要求,这时候需要我们扩充性能,之前讲过,redis集群他是可以横向扩展的,所以,我们架构图变成如下图:

我们新加入了一组节点,主节点是6000,从节点分别是6001和6002。由于机器资源有限,我就将新添加的节点扩充在vm-server1机器上了。真实环境中肯定是部署在不同的机器上的。我们还是在redis-cluster目录下面新建三个文件夹,分别是6000、6001和6002。同样,将redis.config文件复制到这三个目录下面并修改对应的端口号。最后将新加入的节点redis启动起来。

分别启动三台新加入的节点redis

在将新节点加入集群之前,先来介绍几个redis命令:在redis客户端输入 --cluster help可以查看相关命令,具体如下图所示:

接下来我们使用add-node命令将端口号为6000的机器添加到集群环境中,并且是master节点。
添加命令:redis-5.0.14/src/redis-cli -a root --cluster add-node 192.168.1.7:6000 192.168.1.7:7000

接下来我们使用cluster nodes命令查看集群中有没有端口号为6000的节点:

所以,当新添加的节点成功以后,新增的节点不会有任何数据,因为之前说过,redis的集群环境中,它具有分片能力,他把JedisCluster分成了16384个槽位,然后根据槽位定位算法(hash(key)%16384)看最终定位到那个分片中。所以,此时新增加的节点还没有任何的slot(hash槽位),所以接下来需要我们手动去分配槽位信息给新加的主节点。
使用reshard命令对新加入的主节点进行分配哈希槽。
命令:redis-5.0.14/src/redis-cli -a root --cluster reshard 192.168.1.7:6000

紧接着会输出如下信息:
How many slots do you want to move (from 1 to 16384)?
翻译:就是需要多少个哈希槽分配给这个节点,自己设置,比如2000个,就在问好后面输入2000,回车即可。

What is the receiving node ID?
翻译:把这2000个哈希槽移动到那个节点上去,需要指定节点的id(id可以使用cluster nodes命令查看),在问号后面输入节点id,回车即可:

Please enter all the source node IDs.
Type ‘all’ to use all the nodes as source nodes for the hash slots.
Type ‘done’ once you entered all the source nodes IDs.
Source node #1:
翻译:意思就是我们需要分配的2000个节点怎么来,all是从所有的主节点(7000、8000、9000)中分别抽取相应的槽位指定到新的节点,周抽取的总槽数为2000个。这里我们在冒号后面输入all,回车即可:

Do you want to proceed with the proposed reshard plan (yes/no)?
翻译:确认 ,问好后面输入yes即可。

这就分配成功了。
再来验证一下:进入到集群中的任何一台机器,输入cluster nodes命令查看:

经过验证,我们的槽位信息已经分配成功了。

4. 添加从节点6001和6002到集群环境(6000的从节点)

还是使用添加节点的命令add-node命令来进行添加。
命令:redis-5.0.14/src/redis-cli -a root --cluster add-node 192.168.1.7:6001 192.168.1.7:6000

去集群环境中查看是否添加成功:cluster nodes

经过查看集群节点信息,我们看到6001已经加入到集群环境了,接下来我们只需要将它配置成6000的从节点。怎么配置?我们需要执行replicate命令来指定当前节点(从节点)主节点id为那个?首先需要连接新加的6001节点的客户端,然后使用集群命令进行操作。把当前节点6001指定到节点6000的从节点。

指定完成了。接下来使用集群命令查看:

好了,搞定了。使用同样的方式把6002也搞定。过程都一样。我就不演示了。

5. 删除集群中的节点

5.1 删除从节点

删除从节点6001和6002,使用del-node命令,指定删除节点ip和端口以及节点的id。
删除6001命令:
redis-5.0.14/src/redis-cli -a root --cluster del-node 192.168.1.7:6001 578dd71df799ad68b692a59e1824e2058aeb4e79
删除6002命令:
redis-5.0.14/src/redis-cli -a root --cluster del-node 192.168.1.7:6002 ba2fcd1b773146773c43c26e6b4642d8a8fc9448

在集群环境中在查看一下,确定是否被删除:

5.2 删除主节点

删除主节点,主节点的删除可能与从节点有点不同。因为主节点里面分配了哈希槽,所以,我们在删除主节点之前必须把主节点里面的哈希槽放入到其他可用的节点去,然后在进行移除操作,否则会出现数据丢失问题。
执行命令如下:
redis-5.0.14/src/redis-cli -a root --cluster reshard 192.168.1.7:6000

输出如下信息:
How many slots do you want to move (from 1 to 16384)?
翻译:移动多少个哈希槽位,还是当初我们分配的2000

What is the receiving node ID?
翻译:数据移动到哪里?需要移动到哪里的节点id,这里就移动到8000,暂时就不做平均分配了。
Please enter all the source node IDs.
Type ‘all’ to use all the nodes as source nodes for the hash slots.
Type ‘done’ once you entered all the source nodes IDs.
Source node #1:
翻译:这里需要我们的数据源,也就是6000节点的id

Source node #2:
翻译:这里直接输入done开始生成迁移计划

输入yes ,点击回车完成
至此,我们已经把6000的主节点的哈希槽位已经全部迁移了,接下来我们查看验证一下,看看是否迁移成功:

最后,我们直接用del-node命令删除主节点即可:
命令:redis-5.0.14/src/redis-cli -a root --cluster del-node 192.168.1.7:6000 966c98a2e30215b22d04dc907e058f487215c68e

接下来,我们在在集群环境中查看,确保删除成功:

经过验证,集群环境中已经没有6000节点了。最后,需要说明的就是,集群中的节点一旦被移除之后,他的实例也会被销毁。

看看vm-server1机器上确实只有原来的三台redis实例,新加入的三台redis实例已经销毁了。

代码如下(示例):

三、RedisCluster(集群)原理分析

Redis Cluster 将所有数据划分为 16384 个 slots(槽位),每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。当 Redis Cluster 的客户端来连接集群时,它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时,可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况,还需要纠正机制来实现槽位信息的校验调整。

1、 槽位定位算法

Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值,然后用这个整数值对 16384 进行取模来得到具体槽位。
HASH_SLOT = CRC16(key) mod 16384

2、跳转重定位

当客户端向一个错误的节点发出了指令,该节点会发现指令的 key 所在的槽位并不归自己管理,这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址,告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作,还会同步更新纠正本地的槽位映射表缓存,后续所有 key 将使用新的槽位映射表。

3、Redis集群间的节点通信

redis cluster节点间采取gossip协议进行通信 维护集群的元数据(集群节点信息,主从角色,节点数量,各节点共享的数据等)有两种方式:集中式和gossip

3.1 集中式:

优点在于元数据的更新和读取,时效性非常好,一旦元数据出现变更立即就会更新到集中式的存储中,其他节点读取的时候立即就可以立即感知到;不足在于所有的元数据的更新压力全部集中在一个地方,可能导致元数据的存储压力。 很多中间件都会借助zookeeper集中式存储元数据。gossip:

3.2 gossip


gossip协议包含多种消息,包括ping,pong,meet,fail等等。 meet:某个节点发送meet给新加入的节点,让新节点加入集群中,然后新节点就会开始与其他节点进行通信;ping:每个节点都会频繁给其他节点发送ping,其中包含自己的状态还有自己维护的集群元数据,互相通过ping交换元数据(类似自己感知到的集群节点增加和移除,hash slot信息等); pong: 对ping和meet消息的返回,包含自己的状态和其他信息,也可以用于信息广播和更新; fail: 某个节点判断另一个节点fail之后,就发送fail给其他节点,通知其他节点,指定的节点宕机了。gossip协议的优点在于元数据的更新比较分散,不是集中在一个地方,更新请求会陆陆续续,打到所有节点上去更新,有一定的延时,降低了压力;缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。

3.3 gossip通信的10000端口

每个节点都有一个专门用于节点间gossip通信的端口,就是自己提供服务的端口号+10000,比如7001,那么用于节点间通信的就是17001端口。 每个节点每隔一段时间都会往另外几个节点发送ping消息,同时其他几点接收到ping消息之后返回pong消息。

4、网络抖动

真实世界的机房网络往往并不是风平浪静的,它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象,突然之间部分连接变得不可访问,然后很快又恢复正常。为解决这种问题,Redis Cluster 提供了一种选项cluster­node­timeout,表示当某个节点持续 timeout 的时间失联时,才可以认定该节点出现故障,需要进行主从切换。如果没有这个选项,网络抖动会导致主从频繁切换 (数据的重新复制)。

5、Redis集群选举原理分析

当slave发现自己的master变为FAIL状态时,便尝试进行Failover,以期成为新的master。由于挂掉的master可能会有多个slave,从而存在多个slave竞争成为master节点的过程, 其过程如下:1.slave发现自己的master变为FAIL2.将自己记录的集群currentEpoch加1,并广播FAILOVER_AUTH_REQUEST 信息3.其他节点收到该信息,只有master响应,判断请求者的合法性,并发送FAILOVER_AUTH_ACK,对每一个epoch只发送一次ack4.尝试failover的slave收集master返回的FAILOVER_AUTH_ACK5.slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点,如果只有两个,当其中一个挂了,只剩一个主节点是不能选举成功的)6.slave广播Pong消息通知其他集群节点。
从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举,而是有一定延迟,一定的延迟确保我们等待FAIL状态在集群中传播,slave如果立即尝试选举,其它masters或许尚未意识到FAIL状态,可能会拒绝投票•延迟计算公式: DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms•SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下,持有最新数据的slave将会首先发起选举(理论上)。

6、集群脑裂数据丢失问题

redis集群没有过半机制会有脑裂问题,网络分区导致脑裂后多个主节点对外提供写服务,一旦网络分区恢复,会将其中一个主节点变为从节点,这时会有大量数据丢失。规避方法可以在redis配置里加上参数(这种方法不可能百分百避免数据丢失,参考集群leader选举机制):

min-replicas-to-write 1
//写数据成功最少同步的slave数量,这个数量可以模仿大于半数机制配置,比如集群总共三个节点可以配置1,加上leader就是2,超过了半数

注意:这个配置在一定程度上会影响集群的可用性,比如slave要是少于1个,这个集群就算leader正常也不能提供服务了,需要具体场景权衡选择。

7、集群是否完整才能对外提供服务

当redis.conf的配置cluster-require-full-coverage为no时,表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时,集群仍然可用,如果为yes则集群不可用。

8、Redis集群为什么至少需要三个master节点,并且推荐节点数为奇数?

因为新master的选举需要大于半数的集群master节点同意才能选举成功,如果只有两个master节点,当其中一个挂了,是达不到选举新master的条件的。 奇数个master节点可以在满足选举该条件的基础上节省一个节点,比如三个master节点和四个master节点的集群相比,大家如果都挂了一个master节点都能选举新master节点,如果都挂了两个master节点都没法选举新master节点了,所以奇数的master节点更多的是从节省机器资源角度出发说的。

9、Redis集群对批量操作命令的支持

对于类似mset,mget这样的多个key的原生批量操作命令,redis集群只支持所有key落在同一slot的情况,如果有多个key一定要用mset命令在redis集群上操作,则可以在key的前面加上{XX},这样参数数据分片hash计算的只会是大括号里的值,这样能确保不同的key能落到同一slot里去,示例如下:

mset {xiaohua}:name xiaohua {xiaohua}:age 19

假设name和age计算的hash slot值不一样,但是这条命令在集群下执行,Redis只会用大括号里的 xiaohua 做hash slot计算,所以算出来的slot值肯定相同,最后都能落在同一slot。


四、总结

Redis集群架构应该是生产环境中最受欢迎的。原因上面已经介绍的很清楚了。本片文章重在如何搭建Redis集群,以及Redis集群环境中的各种问题,例如脑裂问题、集群的选举原理等。搞懂这些就可以。

一文道明Redis集群架构工作原理及搭建相关推荐

  1. redis集群模式工作原理

    目录 1 redis集群模式背景 2 redis cluster介绍 2.1 节点间的内部通信机制 2.2 基本通信原理 2.2.1 gossip 协议 2.2.2 ping 消息深入 3 分布式寻址 ...

  2. 那些年用过的Redis集群架构(含面试解析)

    作者:孤独烟,平安银行资深后端工程师一枚! 引言 今天是2019年2月13号,也就是大年初九,我接到了高中同学刘有码面试失利的消息. 他面试的时候,身份是某知名公司的小码农一枚,却因为不懂自己生产上R ...

  3. Redis集群架构搭建和原理

    Redis集群架构教程 Redis常见的架构有主从.哨兵.高可用集群,接下来的文章分四章分别介绍linux安装redis.主从架构搭建.哨兵模式搭建.集群架构搭建 第一章 Redis的安装 我的cen ...

  4. 技术分享 | Redis 集群架构解析

    作者:贲绍华 爱可生研发中心工程师,负责项目的需求与维护工作.其他身份:柯基铲屎官. 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源. 一.集群架构的 ...

  5. Redis集群架构搭建详解

    一.简介 这其实是一种分布式数据库,就是通过分片的机制储存数据,cluster中的每个节点仅仅储存数据哭的一部分数据,本质上就是实现数据库分片. 这种集群是一种去中心化的集群,也就是说,集群中的每个节 ...

  6. java集群解析文件_干货:一文详解Redis集群原理核心内容

    集群原理 一个系统建立集群主要需要解决两个问题:数据同步问题和集群容错问题. Naive方案 一个简单粗暴的方案是部署多台一模一样的Redis服务,再用负载均衡来分摊压力以及监控服务状态.这种方案的优 ...

  7. Redis:Redis集群模式(Cluster)原理

    1.前言 由于Redis主从复制模式和Redis哨兵模式采用的都是复制Master节点的数据,实现读写分离.但是这种设计存在一个严重的问题,它没有真正意义上实现数据分片.两个模式都有一个问题,不能水平 ...

  8. ActiveMQ集群架构与原理解析

    初识JMIS与其专业术语 小伙伴们大家好,现在我们和大家一起了解一下古老而又神秘的消息中间件"ActiveMQ".首先,说起ActiveMQ,就必须先聊聊JMS (Java Mes ...

  9. RabbitMQ 镜像模式 集群架构 工作最常用集群

    RabbitMQ 镜像模式 镜像模式:保证100%数据不丢失,在实际工作中也是用的最多的,并且实现集群非常的简单,一般互联网大厂都会构建这种镜像进群模式. Mirror镜像队列,目的是为了保证rabb ...

最新文章

  1. 馀承东鸿蒙发布会,余承东确认出席发布会!荣耀智慧屏-首发搭载鸿蒙系统
  2. 51Nod - 2142身份证号排序
  3. endnote x9中科大版_文献管理软件Endnote的一些使用经验
  4. SVN:请求不到主机,应该如何解决?
  5. css scale 缩放基准点
  6. 代码写好了怎么在php里裕兴_8 行代码用Python画一个中国地图
  7. java连接zookeeper 找不到zoo.cfg_ZooInspector 连接不到 Zookeeper 的解决方法
  8. android布局新建联系人,Android中设置搜素联系人的布局
  9. C++11新特性(4)
  10. 基于词典和朴素贝叶斯中文情感倾向分析算法
  11. vim怎么把一个写的代码文件另存到任意文件夹里?
  12. 飞机地铁的java项目怎么做_个人项目-地铁出行路线规划(Java代码实现)
  13. Front Immunol 复现 | 1. GEO数据下载及sva批次校正(PCA可视化)
  14. js获取微信号_前端js可以直接获取到微信用户基本信息吗
  15. 电脑开机后黑屏的解决办法
  16. 复旦大学计算机学院教师简介,复旦大学计算机科学技术学院导师教师师资介绍简介-危辉...
  17. Android webview和HTML的JS交互
  18. [含论文+源码等]SSH超市进销存管理系统
  19. NOI模拟(5.19) JSOID2T3 军训列队 (bzoj5319)
  20. 【Java虚拟机】万字长文,搞定JVM方方面面!

热门文章

  1. 散射噪声仿真理论和实践(理论篇2)
  2. 计算机考研跨考新闻学,研友自述:跨专业考新闻传播学,只用四个月
  3. 汉塞尔曼的奇妙时事通讯:2013年10月14日
  4. Webpack 概念
  5. POI删除所有sheet页
  6. setImmediate 与 setTimeout
  7. 空中网第四季度净利润477万美元 同比降16%
  8. 实现一个黑名单的功能,将指定来源的ip地址加入到黑名单,后续该ip地址访问服务器全部不予访问。
  9. Presto 分布式SQL查询引擎
  10. 响应输出HTML处理,JSP response对象:响应客户端的请求并向客户端输出信息