< 返回技术文档列表

慕课网2021-01-29 Redis6直播笔记 - 下(多线程/哈希slot/集群)

发布时间:2021-01-31 20:29:17⊙投诉举报

io多线程

以前的redis是单线程模型,其实就是多路复用机制,知道多路复用的来一波6,我们在架构师课程中讲过,那么netty也有,看过老师相关课程的也应该知道。这里不多说了。

Redis6开始有了IO读写多线程,只不过执行客户的命令和早期版本也是一样的,都是单线程执行,所以线程安全。

我们先来看一下老版本的单线程:


-w1750

首先读取用户端的命令,读取后执行命令,而后回写给用户端,这个就是一组命令的执行,因为单线程安全,他们会一组一组的去进行执行。

他们的读写命令以及执行命令都是在一个线程中执行的,这个线程在redis6中称之为主线程。

在这里我们可以回顾一下netty的reactor的线程模型,也就是多路复用。


-w1505

你可以把这个单线程了解为是一个人,他是酒吧会所的接待员,在门口接待了以后,而后还要领到里面去一个一个的招待他们。

我们可以打开redis.conf配置文件,看一下:


-w1216

默认情况下,是按照老版本的样子,假如要使用多线程,那么开启就可,这里的io-threads就是设置多线程的数量,开启多线程后,整体的性能要比单线程要更高。

io-threads设置的数量最大不建议超过8,提升的空间不大。另外线程数和服务器的硬件配置也是有关系的。比方4核8g,那么建议设置2或者者3,假如8核建议设置6或者者7,由于肯定要预留,万事兜底万事保底,这一点和nginx的配置也是同样的道理。

假设现在io-threads设置为4,那么他的模型就如下:

-w1339

那么在这里,读客户的命令以及执行命令都是在一个线程中执行的,而后写操作是多线程执行。在这里假如比作是一个银行的话,那么读操作相当于是门口的保安,给你测个体温,执行就是店里的大堂经理,会带你去取号,多个写操作就是窗口的办事人员。

可以参考一下图:


-w1704

刚刚我们举例是只有一个人在接待和招待,这个时候接待只有一个人,他只在门口把客人带进里面,里面会有专门的多个招待员来解决这些客人的请求。

读操作能不可设置多线程呢?

-w1072

假如想要读操作也变成多线程读的话,那么io-threads-do-reads可以开启,设置为yes就行。这个时候他的模型就是下面这张图:

-w1327

只不过官方说明,这个多线程读开启的意义不大,不会帮助很多的。


-w1672

这个时候,还是引入刚刚的例子,客人多了,生意好了,门口的接待员添加了,那么两边接待和招待都是多个员工在解决客人了。

那么在这里说明一点,多线程只针对数据的读写以及协议的解析。真正客户端的命令执行还是单线程,所以是线程安全的。

Redis集群原理

-w1327

其实只需涉及到中间件,那么必定会有集群的概念,一方面为了高可用,一方面为了达到水平扩容,那么这次来讲一下redis的集群。

其实在很早以前,早期的redis版本是没有集群这个概念的,你需要实现集群得依靠少量中间件,比方codis,还有twemproxy。redis集群概念是在3.0开始引入的,它是自带的分布式存储方案,是一个去中心化的集群,叫做Redis Cluster,是由多个主从节点共同存在的一个模式,一般以3主3从为比较经典的模式,当然多主多从也可以。其中master负责读写请求以及整个集群信息的维护,slave只做他所对应的主节点数据和状态信息的复制。

Redis Cluster

关于集群,有两点需要注意

  • 之前我们聊过主从模式,可以做读写分离,redis集群尽管是3主3从,也有主从的概念,但是我们并不会做读写分离,读写都是交给master去解决,数据会同步给slave,假如集群做读写分离一方面没有意义一方面slave就没有容错机制了,这一点是需要注意。
  • 此外还有一点,单节点的redis默认有16个db,但是在集群模式下,这些db都融合了,没有db库的概念,他是一片汪洋大海。

按照单节点,主从,哨兵来说的话,redis始终都可以说是单库,数据存储量是有上限的,你的服务器节点内存有多大,那么这个就是存储上限。一旦到达存储上限,redis就会进行缓存key的自我淘汰机制。很显著,这种方式面对海量数据的时候并不太好,哪怕你买1个t内存的,也总有一天会到达存储瓶颈,所以任何分布式系统我们都要考虑一个水平扩容机制,这个redis集群即可以做到。扩容的同时也满足高可用机制。

同时,使用集群之后,数据其实进行了分片,多个master节点都能够提供读写服务,这样整体集群的响应能力就要比原价单节点来的更好。并且,在集群模式下,任意节点发生故障时,集群还是可以继续对外提供服务,主节点有故障转移的功能。

传统的水平扩容

传统早期的redis扩容方案其实是基于业务层的,在业务层进行redis的分割,可以扩容,可以集群隔离。
我们之前讲过redis主从,以这个为例,当然用哨兵也可以,我们可以手动来实现redis的扩容,先看下图:


-w1712

上图中的3主3从其实是由3个主从redis构成的,客户在进行set或者者get的时候,首先需要对key做哈希,哈希后的值对节点数求模,取模的值就是数据路由到某个主从库里,就针对这个主从库去做set和get的操作,这个哈希原理其实和nginx的ip_hash道理是一样的,数据库分库也是这个道理。目的就是根据key哈希后的结果去寻址找到最终他的存储位置去存值或者取值。这个其实就是哈希取模

那么哈希以及寻址的这个过程需要自己在业务层去封装实现,但是本质目的就已经达到了横向扩容,假设每个主从容量是8g,那么目前总容量就是24g,想怎样扩容直接加机器就行。


-w569

这这样的情况之下,那么扩容会带来一个弊端,这个弊端也就是哈希取模带来的,一旦有节点宕机或者者添加节点,那么就需要重新哈希和求模运算,这么一来会影响所有的缓存数据,这个时候所有数据会重新路由,影响会很大,怎样处理呢?可以使用一致性哈希算法,就是小部分数据受影响,这个我们在架构班里有提到过的吧。

一致性哈希

-w1620

首先他会有一个域,这个域很长,有2的32次方减1,哈希不仅针对key,也会针对服务器节点,我们这里是redis,假如是服务器集群那么道理也是一样。


-w1736

Redis集群 - hash slot 算法

上面的传统方式是很古老的,我曾经也见识过一次,我们理解一下就行了。现在都使用redis cluster,这种模式下,redis可以有多个master节点,每个master节点下又可以对应1~n个slave节点,这样会形成一个多主多从的集群模式,这种模式下不再需要向上面讲过的那样需要在业务层去解决,redis自身帮我们做好了存取的过程,我们可以不用过多关注业务过程即可以直接使用和应用了。他自身是基于hash slot的算法来存值的,不管是哪种算法,其实本质为理解决的就是数据分布的问题。

redis集群其实是把数据分片了,因为他有多个master共同构成,他会分数据,他有一个hash slot算法,也可以称之为哈希槽,每个槽上存放了少量数据,slot的范围是0~16384,redis对key的存取会有一个CRC16的算法,得到的值,在对16384做取模,最终判断该key应该在哪个slot中进行存取,本质和服务器节点数取模是一样的,只不过redis cluster的slot算法更精妙,成本更低廉。

以三主三从为例,这个时候的slot总数会平均等份,使得每个master节点中都会有slot,目前3个的话那就是{0..5461}{5462..10922}{10923..16383},这个取值区间在搭建好集群之后是可以看到的。

假如这个时候,集群环境添加或者者减少节点,slot可以重新迁移或者者合并,那么slot中的缓存key其实还是存在的,如此一来,节点宕机或者者新添加就不会造成缓存丢失了。这就相当于家里房子拆迁,我到新家里以后,会把我的私人物品家具啊电器啊一起携带过去,东西跟着人走,东西就是缓存key,人就slot,服务器节点是redis实例,比较灵活。并不是说你房子没了,家里的东西就没了。


-w1671

提问:搬家的过程,新家能住人吗?
当然,你搬家并不是马上就能完成的,搬家需要耗时,需要等待,所以等待期间你的家具啊电器啊不可用。redis slot也是这样,宕机的时候,那部分需要迁移的slot是不可用,会有一个短暂的迁移的过程,等待迁移完成之后,才能为客户提供读写服务。

hash slot 图示:


image

如下图:中间的master宕机了,slot会迁移到slave


-w1054

假如,新添加master节点,重新分配,那么会把少量slot迁移过去,缓存数据不变,跟着slot走,尽管slot会变动到其余的master节点,但是数据key哈希的时候,还是会到跟着固定的slot。

格子铺

假如还不能了解,那就再举个栗子,格子铺,每个格子归属一个卖家,这个卖家把各自托管给某些商铺,由他们代经营,假如商铺倒闭,格子还是存在的,他可以把各自带着走,各自里的商品就是redis集群中的数据呀,它是不会发生更改的,只是外壳换了一家商铺而已。

Redis集群搭建

时间关系,我们在这里就只讲原理了,操作部分,我们提供了慕课网的手记文档,很简单,大家可以去看一下就行。
链接地址:https://www.imooc.com/article/313301

只不过在集群中有少量注意点,我们大致总结了如下:

  1. 读写都是在master,slave加入集群,会进行数据同步,连接集群中的任意主或者从节点去读写数据,都会根据key哈希取模后路由到某个master节点去解决。slave不提供读写服务,只会同步数据。

  2. 关闭任意一主,会导致部分写操作失败,是因为从节点不能执行写操作,在Slave更新为Master期间可能会有一些的失败。

  3. 关闭从节点对于整个集群没有影响

  4. 某个主节点和他麾下的所有从节点一律挂掉,我们集群就进入faill状态,不可用。由于slot不完整。

  5. 假如集群超过半数以上master挂掉,无论他们能否有对应slave,集群进入fail状态,由于无法选举。

  6. 假如集群中的任意master宕机,且此master没有slave。集群不可用。(同3)

  7. 投票选举过程是集群中所有master参加,假如半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉。

  8. 选举只会针对某个master下的所有slave选举,而不是对所有全量的slave选举。

  9. 原价的master重新恢复连接后,他会成为新master的从服务器。因为主从同步,用户端的写入命令,有可能会丢失。redis并非强一致性,因为主从特性,所以最后一部分数据会丢失。这也符合CAP理论。

  10. 集群只实现了主节点的故障转移;从节点故障时只会被下线,不会进行故障转移。因而,使用集群时,一般不会使用读写分离技术,由于从节点故障会导致读服务不可用,可用性变差了。所以不要在集群里做读写分离。

需要注意,为了保证集群的完整性,只有当16384个槽slot完全的一律分配完毕,集群才可以上线。而且,假如主节点发生故障转移,并且处于故障转移过程中还未完成时,原主节点的槽slot不会在任何节点中,集群会处于下线状态,用户端无法调用。CAP原理。

Redis集群数据迁移

已有数据的单节点的redis如何扩展为集群

搭建集群的时候,包清理节点中现有的aof以及rdb文件,那么假如现在原本就是单节点,那么如何扩展为集群呢?并且要保证数据不丢失。其实原理就是把rdb或者者aof文件保存以后,再导入,而后通过slot来分配。具体步骤如下:


-w1098

如上图,其原理就是slot迁移。整个过程阻塞,网站服务不对外提供服务。假如使用自建集群,那么运维成本很高,一般采用云redis的话会更好。哪怕阿里云,也会在配置变更的时候出现网络中断的情况。


-w732

/template/Home/Zkeys/PC/Static