最近换了单位用redis和nginx,对于像博主这样之前只听过其大名的菜鸟,深深的感觉到头大,经过几天的研究,对redis和nginx有了初步的了解,下面我们看一下redis的常见模式:单点模式、主从模式、哨兵模式和集群模式。

【单点模式】

   
单点模式又称单节点模式,是最简单的Redis模式,就是一个redis实例,如果只是自己测试缓存或者小程序,数据量很小,仅仅做一个小型的KEY/VALUE型数据库,完全足够。简单来说,单节点模式只适用于了解学习Redis,自己玩一下OK。

【主从模式】

主从模式的概念:

  主从模式就是N个redis实例,可以是1主N从,也可以N主N从(N主N从则不是严格意义上的主从模式了,后续的集群模式会说到,N主N从就是N+N个redis实例。)

        主从模式的一个作用是备份数据,这样当一个节点损坏(指不可恢复的硬件损坏)时,数据因为有备份,可以方便恢复。

  另一个作用是负载均衡,所有客户端都访问一个节点肯定会影响Redis工作效率,有了主从以后,查询操作就可以通过查询从节点来完成。

  对主从模式必须的理解:

  1.一个Master可以有多个Slaves,可以是1主N从。

  2.默认配置下,master节点可以进行读和写,slave节点只能进行读操作,写操作被禁止(readonly)。

  3.不要修改配置让slave节点支持写操作,没有意义,原因一,写入的数据不会被同步到其他节点;原因二,当master节点修改同一条数据后,slave节点的数据会被覆盖掉。

  4.slave节点挂了不影响其他slave节点的读和master节点的读和写,重新启动后会将数据从master节点同步过来。

  5.master节点挂了以后,不影响slave节点的读,Redis将不再提供写服务,master节点启动后Redis将重新对外提供写服务。

  6.特别说明:该种模式下,master节点挂了以后,slave不会竞选成为master。

  对有密码的情况说明一下,当master节点设置密码时:

* 客户端访问master需要密码
* 启动slave需要密码,在配置中进行配置即可
* 客户端访问slave不需要密码
  综上,客户端只需要配置一个密码参数,而redis配置文件中需要配置两个参数。

  分别是:

  Redis服务端配置文件:

  masterauth "chrdw,hdhxt!"

  requirepass "chrdw,hdhxt!"

  客户端配置文件:

  jedis-cluster.password=chrdw,hdhxt!

  注意没有引号。

  2.1 主从节点的缺点

  主从模式的缺点其实从上面的描述中可以得出:

  master节点挂了以后,redis就不能对外提供写服务了,因为剩下的slave不能成为master

  这个缺点影响是很大的,尤其是对生产环境来说,是一刻都不能停止服务的,所以一般的生产坏境是不会单单只有主从模式的。所以有了下面的sentinel模式。

【哨兵模式】

哨兵模式又称sentinel模式
,sentinel的中文含义是哨兵、守卫。也就是说既然主从模式中,当master节点挂了以后,slave节点不能主动选举一个master节点出来,那么我就安排一个或多个sentinel来做这件事,当sentinel发现master节点挂了以后,sentinel就会从slave中重新选举一个master。

  对sentinel模式的理解:

  1.sentinel模式是建立在主从模式的基础上,如果只有一个Redis节点,sentinel就没有任何意义。

  2.当master节点挂了以后,sentinel会在slave中选择一个做为master,并修改它们的配置文件,其他slave的配置文件也会被修改,比如slaveof属性会指向新的master。

  3.当master节点重新启动后,它将不再是master,而是作为slave接收新的master节点的同步数据

  4.sentinel因为也是一个进程有挂掉的可能,所以sentinel也会启动多个形成一个sentinel集群。

  5.当主从模式配置密码时,sentinel也会同步将配置信息修改到配置文件中,不需要担心。

  6.一个sentinel或sentinel集群可以管理多个主从Redis。

  7.sentinel最好不要和Redis部署在同一台机器,不然Redis的服务器挂了以后,sentinel也挂了。

  8.sentinel监控的Redis集群都会定义一个master名字,这个名字代表Redis集群的master Redis。

  当使用sentinel模式的时候,客户端就不要直接连接Redis,而是连接sentinel的ip和port,由sentinel来提供具体的可提供服务的Redis实现,这样当master节点挂掉以后,sentinel就会感知并将新的master节点提供给使用者。

  Sentinel本身也支持集群,只使用单个sentinel进程来监控redis集群是不可靠的,当sentinel进程宕掉后,sentinel本身也有单点问题。所以有必要将sentinel集群,这样有几个好处:

  1.如果只有一个sentinel进程,如果这个进程运行出错,或者是网络堵塞,那么将无法实现redis集群的主备切换(单点问题)。

  2.如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。

  3.sentinel集群自身也需要多数机制,也就是2个sentinel进程时,挂掉一个另一个就不可用了。

  Sentinel集群:

  和其他集群不同,你无须设置其他Sentinel的地址,Sentinel进程可以通过发布与订阅来自动发现正在监视相同主实例的其他Sentinel。当一个
Sentinel 发现一个新的 Sentinel 时,它会将新的 Sentinel 添加到一个列表中,这个列表保存了 Sentinel
已知的,监视同一个主服务器的所有其他Sentinel。

  Sentinel集群中的Sentinel不会再同一时刻并发去failover(故障切换or故障转移)同一个master,第一个进行failover的Sentinel如果失败了(上文配置的failover-timeout),另外一个才会重新进行failover,以此类推。

  当Sentinel将一个slave选举为master并发送SLAVE OF NO
ONE后,即使其它的slave还没针对新master重新配置自己,failover也被认为是成功了。

  上述过度过程中,若此时重启old
master,则redis集群将处于无master状态,此时只能手动修改配置文件,然后重新启动集群.(生产情况下千万不要做如此愚蠢的操作,否则你会导致整个应用集群都启动失败。)

  Master-Slave切换后,Sentinel会改写master,slave和sentinel的conf配置文件。

  一旦一个Sentinel成功地对一个master进行了failover,它将会把关于master的最新配置通过广播形式通知其它sentinel,其它的Sentinel则更新对应master的配置。

  Sentinel模式基本可以满足一般生产的需求,具备高可用性。但是当数据量过大到一台服务器存放不下的情况(这个一般是内存瓶颈,本人进行过Redis的压力测试,Redis在高并发、大数据量的情况下CPU等资源的消耗不高,主要压力是内存。)时,主从模式或sentinel模式就不能满足需求了,这个时候需要对存储的数据进行分片,将数据存储到多个Redis实例中,就是下面要讲的。

【集群模式】

本人所在项目组使用的cluster模式,项目在生产环境有8个Redis集群,每个集群的dbsize都在千万级。这种数据量显然不是哨兵模式可以满足的。

  cluster的出现是为了解决单机Redis容量有限的问题,将Redis的数据根据一定的规则分配到多台机器。对cluster的一些理解:

  一个 Redis 集群包含 16384 个哈希槽(hash slot),数据库中的每个键都属于这 16384
个哈希槽的其中一个,集群中的每个节点负责处理一部分哈希槽。

  例如一个集群有三个主节点,其中:

  节点 A 负责处理 0 号至 5500 号哈希槽。

  节点 B 负责处理 5501 号至 11000 号哈希槽。

  节点 C 负责处理 11001 号至 16384 号哈希槽。

  这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。例如:如果用户将新节点 D 添加到集群中, 那么集群只需要将节点 A 、B
、 C 中的某些槽移动到节点 D 就可以了。

  如果用户要从集群中移除节点 A , 那么集群只需要将节点 A 中的所有哈希槽移动到节点 B 和节点 C , 然后再移除空白(不包含任何哈希槽)的节点 A
就可以了。

  这里需要注意的是,集群如果是5主5从,主节点也是16384个hash
slot,而不会因为主节点的增多slot也增多。我们在分槽的时候,尽量把槽平均分给主节点。因为一个key落在哪个槽里面,是根据key的CRC16值模上16384得出的值来计算的。

  2.Redis 集群对节点使用了主从复制功能: 集群中的每个节点都有 1 个至 N 个复制品(replica),
其中一个复制品为主节点(master), 而其余的 N-1 个复制品为从节点(slave)。

  我们知道集群模式下,1主N从时,当主节点挂掉时,从节点通过心跳监听机制,会竞选成为主节点(这时设置的readonly会失效),所以在部署的时候,主从节点应该部署在不同的机器上,这个时候如果主节点的服务器宕机,从节点竞选成功后会继续承担读写的任务。

  3.Redis 集群的节点间通过Gossip协议通信。

  4.当前Redis集群不支持NAT环境或者IP,端口重新映射的环境。

  cluster这种模式适合数据量巨大的缓存要求,当数据量不是很大使用sentinel即可。

  Redis各种模式的介绍先说这么多,欢迎大家发消息和我讨论。

技术
今日推荐
下载桌面版
GitHub
百度网盘(提取码:draw)
Gitee
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:[email protected]
QQ群:766591547
关注微信