Redis集群的示例分析

这篇文章主要介绍Redis集群的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！Redis集群详解Redis有三种集群模式，分别是：三种集群模式各有特点，关于Redis介绍可以参考这里：NoSQL（二)——RedisRedis官网：https://redis.io/ ，最新版本5.0.4主从模式主从模式介绍主从模式是三种模式中最简单的，在主从复制中，数据库分为两类：主数据库(master)和从数据库(slave)。其中主从复制有如下特点：工作机制：当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。安全设置：当master节点设置密码后，缺点：从上面可以看出，master节点在主从模式中唯一，若master挂掉，则redis无法对外提供写服务。环境准备：全部下载安装：全部配置成服务：服务文件shutdown脚本修改配置：192.168.30.128192.168.30.129192.168.30.130全部启动redis：查看集群状态：数据演示：可以看到，在master节点写入的数据，很快就同步到slave节点上，而且在slave节点上无法写入数据。主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel应运而生。sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况，特点如下：工作机制：当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。环境准备：修改配置：前面已经下载安装了redis，这里省略，直接修改sentinel配置文件。192.168.30.128这里需要注意，sentinel auth-pass mymaster 123456需要配置在sentinel monitor mymaster 192.168.30.128 6379 2下面，否则启动报错：全部启动sentinel：任一主机查看日志：Sentinel模式下的几个事件：master宕机演示：192.168.30.128从日志中可以看到，master已经从192.168.3免费云主机域名0.128转移到192.168.30.129上192.168.30.129上查看集群信息当前集群中只有一个slave——192.168.30.130，master是192.168.30.129，且192.168.30.129具有写权限。192.168.30.130上查看redis的配置文件也可以看到replicaof 192.168.30.129 6379，这是sentinel在选举master是做的修改。重新把192.168.30.128上进程启动查看集群信息即使192.168.30.128重新启动redis服务，也是作为slave加入redis集群，192.168.30.129仍然是master。sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。使用集群，只需要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行，新增节点非常方便。cluster集群特点：环境准备：修改配置文件：192.168.30.128其它两台机器配置与192.168.30.128一致，此处省略启动redis服务：其它两台机器启动与192.168.30.128一致，此处省略安装ruby并创建集群（低版本）：如果redis版本比较低，则需要安装ruby。任选一台机器安装ruby即可创建集群：我这里是redis5.0.4，所以不需要安装ruby，直接创建集群即可可以看到，自动生成nodes.conf文件：登录集群：查看集群信息：列出节点信息：这里与nodes.conf文件内容相同写入数据：可以看出redis cluster集群是去中心化的，每个节点都是平等的，连接哪个节点都可以获取和设置数据。当然，平等指的是master节点，因为slave节点根本不提供服务，只是作为对应master节点的一个备份。增加节点：192.168.30.129上增加一节点：192.168.30.130上增加一节点：集群中增加节点：可以看到，新增的节点都是以master身份加入集群的更换节点身份：将新增的192.168.30.130:7008节点身份改为192.168.30.129:7007的slavecluster replicate后面跟node_id，更改对应节点身份。也可以登入集群更改查看相应的nodes.conf文件，可以发现有更改，它记录当前集群的节点信息删除节点：保存配置：可以看到，之前删除的节点又恢复了，这是因为对应的配置文件没有删除，执行CLUSTER SAVECONFIG恢复。模拟master节点挂掉：192.168.30.128对应7001的一行可以看到，master fail，状态为disconnected；而对应7004的一行，slave已经变成master。重新启动7001节点：可以看到，7001节点启动后为slave节点，并且是7004的slave节点。即master节点如果挂掉，它的slave节点变为新master节点继续对外提供服务，而原来的master节点如果重启，则变为新master节点的slave节点。另外，如果这里是拿7007节点做测试的话，会发现7008节点并不会切换，这是因为7007节点上根本没数据。集群数据被分为三份，采用哈希槽 (hash slot)的方式来分配16384个slot的话，它们三个节点分别承担的slot 区间是：以上是“Redis集群的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注百云行业资讯频道！

相关推荐: Oracle常见死锁发生的原因以及解决方法

造成死锁的原因就是多个线程或进程对同一个资源的争抢或相互依赖。这里列举一个对同一个资源的争抢造成死锁的实例。 CREATE TABLE testLock( IDNUMBER, test VARCHAR (100) ) COMMIT INSERT INTO te…