为了账号安全,请及时绑定邮箱和手机立即绑定
首页 手记 redis集群的架构、问题,附脑洞

redis集群的架构、问题,附脑洞

2021.11.11 23:00 157浏览

Redis 是一种开源(BSD 许可)、数据结构存储在内存中的系统,用作数据库、缓存和消息队列。Redis 提供了诸如字符串、散列、列表、集合、带范围查询的排序集合、位图、超级日志、地理空间索引和流等数据结构。Redis 内置复制、Lua 脚本、LRU 驱逐、事务和不同级别的磁盘持久化,并通过 Redis Sentinel 和 Redis Cluster 自动分区提供高可用性。


1 集群的优势

下面是redis集群的几个明显优势。

1.1 伸缩性,数据规模不断增大的时候,容易扩容

https://img1.sycdn.imooc.com/618d28640001ba3d07320377.jpg

单实例模式:只能垂直扩展,增大机器内存的容量;

集群模式:支持垂直扩展,也支持水平扩展,有更好的灵活性,也可以支持更大的容量;

1. 2 高可用,服务故障的情况,影响范围小

https://img1.sycdn.imooc.com/618d28940001004e04560316.jpg

单实例模式:故障转移前100%不可用(slave转换为master之前);

集群模式:故障转移前部分不可用(集群规模越大,故障影响越小); 

1. 3 高性能,查询和写入的性能 

单实例模式:查询可以分散在多个slave,写入却只有一个master;

集群模式:查询有多个master和多个slave,写入也有多个master;

2 数据分片,一致性hash

实现redis集群的核心点,是针对数据的分片,这里的一致性hash算法就非常关键。

2.1 普通的hash 算法

node=hash(key)%number

数量变化和node顺序变化,导致node选择的差异性巨大,造成巨大的缓存失效。

2.2 一致性hash

https://img2.sycdn.imooc.com/618d28b100011c7a06470481.jpg

hash(node) 形成虚拟节点环,hash(key)落在虚拟节点环,找到对应的node。

由于hash(node)的稳定性,与node顺序无关。node变更只影响一小部分数据。

2.3 redis cluster的hash slot算法

https://img2.sycdn.imooc.com/618d28d90001c3c507320566.jpg

关系: cluster > node > slot > key

Redis Cluster在设计中没有使用一致性哈希(Consistency Hashing),而是使用数据分片引入哈希槽(hash slot)来实现。

一个 Redis Cluster包含16384(0~16383)个哈希槽,存储在Redis Cluster中的所有键都会被映射到这些slot中。

集群中的每个键都属于这16384个哈希槽中的一个,集群使用公式slot=CRC16(key)/16384来计算key属于哪个槽,其中CRC16(key)语句用于计算key的CRC16 校验和。

按照槽来进行分片,通过为每个节点指派不同数量的槽,可以控制不同节点负责的数据量和请求数。

3 集群元数据的一致性

3.1 对比:集中式存储元数据

https://img3.sycdn.imooc.com/618d28f90001dd9205030256.jpg

依赖外部的集中式存储服务,比如:zookeeper, etcd等,会增加运维负担和系统复杂度。

集中式的好处在于,元数据的读取和更新,时效性非常好,一旦元数据出现了变更,就立即更新到集中式的存储中,其它节点读取的时候就可以感知到;不好在于,所有的元数据的更新压力全部集中在一个地方,可能会导致元数据的存储有压力。

3.2 gossip 协议来广播自己的状态以及自己对整个集群认知的改变

https://img1.sycdn.imooc.com/618d29440001b49909960994.jpg

ping / pong 消息来确认节点的存活和同步全部的集群元数据。

集群元数据,包括:master/slave node列表和状态, slot与node关系。

每个master node每秒会执行 10 次 ping,每次会选择 5 个最久没有通信的其它节点。

定时检查全部节点,如果发现某个节点通信延时达到了 cluster_node_timeout / 2,那么立即发送 ping,避免数据交换延时过长。

3.3 增加新节点

https://img1.sycdn.imooc.com/618d297100012b8303820732.jpg

命令 CLUSTER MEET <ip> <port> 

向一个节点 node 发送 CLUSTER MEET 命令,可以让 node 节点与 ip 和 port 所指定的节点进行握手(handshake),当握手成功时,node 节点就会将 ip 和 port 所指定的节点添加到 node 节点当前所在的集群中。

按照gossip协议,广播meet消息,全部节点接收新节点。

重新hash(node),分配和转移相应的slot给到新节点。

4 客户端如何调用

https://img4.sycdn.imooc.com/618d299700012be907320478.jpg

4.1 hash slot 信息

当客户端连接任何一个实例,实例就将哈希槽与实例的映射关系响应给客户端,客户端就会将哈希槽与实例映射信息缓存在本地。

4.2 请求数据

当客户端请求时,会计算出键所对应的哈希槽,在通过本地缓存的哈希槽实例映射信息定位到数据所在实例上,再将请求发送给对应的实例。 

4.3 重定向机制

https://img4.sycdn.imooc.com/618d29b7000197ca07320599.jpg

客户端将请求发送到实例上,这个实例没有相应的数据,该 Redis 实例会告诉客户端更新本地的哈希槽与映射信息的缓存,将请求发送到其他的实例上。

5 新的节点加入集群(扩容)

同3.3 增加新节点的前序步骤是一样的。

这里详细了解下重新扩容时slot迁移和数据。

https://img2.sycdn.imooc.com/618d29e4000181d407940754.jpg

5.1 每个slot的迁移过程如下所示:

https://img1.sycdn.imooc.com/618d29fe0001b5fc04100474.jpg

  • 对目标节点发送cluster setslot {slot_id} importing {sourceNodeId}命令,目标节点的状态被标记为"importing",准备导入这个slot的数据。

  • 对源节点发送cluster setslot {slot_id} migrating {targetNodeID}命令,源节点的状态被标记为"migrating",准备迁出slot的数据。

  • 源节点执行cluster getkeysinslot {slot_id} {count}命令,获取这个slot的所有的key列表(分批获取,count指定一次获取的个数),然后针对每个key进行迁移。

  • 在源节点执行migrate {targetIp} {targetPort} "" 0 {timeout} keys {keys}命令,把一批批key迁移到目标节点(redis-3.0.6之前一次只能迁移一个key),具体来说,源节点对迁移的key执行dump指令得到序列化内容,然后通过客户端向目标节点发送携带着序列化内容的restore指令,目标节点进行反序列化后将接收到的内容存入自己的内存中,目标节点给客户端返回"OK",然后源节点删除这个key,这样,一个key的迁移过程就结束了。

  • 所有的key都迁移完成后,一个slot的迁移就结束了。

  • 迁移所有的slot(应该被迁移的那些),所有的slot迁移完成后,新的集群的slot就重新分配完成了,向集群内所有master发送cluster setslot {slot_id} node {targetNodeId}命令,通知他们哪些槽被迁移到了哪些master上,让它们更新自己的信息。

5.2 slot迁移的其他说明

  • 迁移过程是同步的,在目标节点执行restore指令到原节点删除key之间,原节点的主线程处于阻塞状态,直到key被删除成功。

  • 如果迁移过程突然出现网路故障,整个slot迁移只进行了一半,这时两个节点仍然会被标记为中间过滤状态,即"migrating"和"importing",下次迁移工具连接上之后,会继续进行迁移。

  • 在迁移过程中,如果每个key的内容都很小,那么迁移过程很快,不会影响到客户端的正常访问。

  • 如果key的内容很大,由于迁移一个key的迁移过程是阻塞的,就会同时导致原节点和目标节点的卡顿,影响集群的稳定性,所以,集群环境下,业务逻辑要尽可能的避免大key的产生 。

5.3 slot编号

无需要求每个master的slot编号是连续的,只要每个master管理的slot的数量均衡就可以。

5.4 减少节点(缩容)

缩容的过程与扩容类似,只是slot和数据从下线的节点内转移到其他的节点上。

https://img1.sycdn.imooc.com/618d2a440001f7e408040754.jpg

6 集群中机器出现故障

https://img1.sycdn.imooc.com/618d2a620001c82915881552.jpg

6.1 故障检测,节点失效

如果一个节点认为另外一个节点宕机,那么就是 pfail,主观宕机;

如果超过半数的节点都认为另外一个节点宕机了,那么就是 fail,客观宕机;

6.2 故障转移,节点选举

每个slave节点,都根据自己对 master 复制数据的 offset,来设置一个选举时间,offset 越大(复制数据越多)的从节点,选举时间越靠前,优先进行选举。

所有的 master node 开始 slave 选举投票,给要进行选举的 slave 进行投票,如果大部分 master node(N/2 + 1)都投票给了某个从节点,那么选举通过,那个从节点可以切换成 master。

从节点执行主备切换,从节点切换为主节点。

7 主从同步以及高可用

redis的主从同步在cluster版本之前就存在了,既可以提供更高的查询效率(多slave可以查询),又可以增加服务的可用性(master挂机后可以启用slave成为master)。

7.1 使用主从架构时

https://img1.sycdn.imooc.com/618d2a7f00014f8907000367.jpg

将只有一个 Master 和多个从属用于复制。

所有写入都转到主节点,这会在主节点上产生更多负载。

如果Master宕机,整个架构容易出现SPOF(单点故障)。

当您的用户群增长时,MS 架构无助于扩展。

所以我们需要一个进程来在发生故障或关闭的情况下监控 Master,那就是 Sentinel。

7.2 Redis哨兵

https://img1.sycdn.imooc.com/618d2aac000172c310240561.jpg

故障转移处理

https://img1.sycdn.imooc.com/618d2acc0001dd0307000388.jpg


8 主从同步与数据一致性

8.1 主从同步的实现过程

主从同步分为 2 个步骤:同步和命令传播。

数据同步有sync和psync。

sync全量同步,性能比较差;psync增量同步,速度和实时性好很多。

8.2 全量同步 sync

https://img4.sycdn.imooc.com/618d2ae90001d7d505120257.jpg

从服务器对主服务的同步操作,需要通过 sync 命令来实现,以下是 sync 命令的执行步骤:

  • 从服务器向主服务器发送 sync 命令

  • 收到 sync 命令后,主服务器执行 bgsave 命令,用来生成 rdb 文件,并在一个缓冲区中记录从现在开始执行的写命令。

  • bgsave 执行完成后,将生成的 rdb 文件发送给从服务器,用来给从服务器更新数据

  • 主服务器再将缓冲区记录的写命令发送给从服务器,从服务器执行完这些写命令后,此时的数据库状态便和主服务器一致了。

8.3 部分重同步 psync

https://img2.sycdn.imooc.com/618d2afc00015a1808000549.jpg

部分重同步功能由以下 3 部分组成:

  • 主从服务器的复制偏移量

  • 主服务器的复制积压缓冲区

  • 服务器的运行 id(run id)

8.4 心跳检测

当完成了同步之后,主从服务器就会进入命令传播阶段,此时从服务器会以每秒 1 次的频率,向主服务器发送命令:REPLCONF ACK <replication_offset> 其中 replication_offset 是从服务器当前的复制偏移量

发送这个命令主要有三个作用:

  • 检测主从服务器的网络状态

  • 辅助实现 min-slaves 选项

  • 检测命令丢失(若丢失,主服务器会将丢失的写命令重新发给从服务器)

8.5 主从同步总结

发送 SLAVEOF 命令可以进行主从同步,比如:SLAVEOF 127.0.0.1 6379

主从同步有同步和命令传播 2 个步骤

  • 同步:将从服务器的数据库状态更新成主服务器当前的数据库状态(一个消耗资源的操作)

  • 命令传播:当主服务器数据库状态被修改后,导致主从服务器数据库状态不一致,此时需要让主从数据同步到一致的过程

主从同步分初次复制和断线后重复制两种情况

  • 从 2.8 版本开始,在出现断线后重复制情况时,主服务器会根据复制偏移量、复制积压缓冲区和 run id,来确定执行完整重同步还是部分重同步

  • 2.8 版本使用 psync 命令来代替 sync 命令去执行同步操作。目的是为了解决同步(sync 命令)的低效操作

问题1:集群的规模能否无限大,比如:1w台机器?

答案是否定的,redis 官方给的 Redis Cluster 的规模上限是 1000 个实例。

限制的原因,关键在于实例间的通信开销,集群中的每个节点都保存所有哈希槽与节点对应关系信息(Slot 映射到节点的表),以及自身的状态信息。

参照3.2gossip协议广播方式,节点越多,广播风暴对于网络以及服务器压力也就越大。

虽然可以设置广播消息同步的超时时间,但是节点增多、超时时间变长之后,数据一致性的消息同步延时也会更大,出现元数据不一致的可能性也会增加。

问题2:从库的使用,以及如何权衡?

从库的作用,一是提高可用性,当主库宕机之后,可以立即启用从库作为主库提供服务;一是提高伸缩性,提高了数据查询并发能力,从库提供查询服务就增加了服务资源,更多的节点来支持查询。

由于主从同步存在数据一致性问题,所以在使用从库的过程中,相应的也就会遇到一些问题。

比如:因为从库数据同步慢了,这时候主库宕机了,数据不完整的从库作为主库,就会出现数据丢失的情况。从库用来查询也有类似问题,实时写入的新数据,同步到从库可能会有延时,在数据没有同步到从库的时候查询从库,也会出现查询无数据的情况。

所以在使用从库的情况下,需要考虑到上面的问题。

面对宕机的时候,数据丢失的问题,内存型数据库都会存在的风险,使用redis都需要面对这个风险,否则就要牺牲性能高正数据一致性,redis数据先持久化再提供服务,这样性能就会下降非常明显了,没法满足内存性数据库的优势了。

启用从库查询,可以针对一些数据更新的实时性较低,对于脏数据不那么敏感的业务,或者查询量实在太大而可以忽略部分数据延时的影响。

问题3:redis集群化之后,代理的必要性?

https://img1.sycdn.imooc.com/618d2b1e0001dedc09140761.jpg

代理的性能和稳定性同样是问题所在。

产品的运维难度以及持续的维护,还是官方的redis cluster更加可靠。

有条件的团队,针对redis cluster的不足,还会有更深入的优化,比如咱们自己研发的tendis。

问题4:单key的百万qps限频问题?(待解)

单key的频繁更新,由于单个key有且只能落地到一个master节点的一个slot上面,无法通过增加节点增加slave的方法扩容,性能瓶颈就会受限于机器的CPU/内存的读写能力了。

假设单机最高10w的写如速度,那么,要实现接口的100w的qps限频功能,要怎么实现呢?

请输出你的解答。。。

附-脑洞:三体人来到地球,要消灭近半的地球人(待解)

三体人不像灭霸,直接用手套简单粗暴的一个响指就毁灭一半生灵,而是给每个人一个选择,选择对的人就有机会生存下来。

这个选择的方法也特别简单,但是需要开发一套系统来支持。

那么这套系统的开发工作就落在了地球人最聪明的程序员你的头上。

开发好了可以让自己以及家人获得豁免权而生存下来,开发的不好,直接咔嚓。

这个选择的描述如下

https://img3.sycdn.imooc.com/618d2f7100013d8503780236.jpg

全球有一个三体人的灯球,默认是熄灭状态。

https://img3.sycdn.imooc.com/618d2f8200019e2805120246.jpg

每个人会有一个三体人的开关,上面会显示当前灯球的状态(熄灭或者亮起),有两个操作按钮,分别是控制灯球的熄灭和亮起。每个人只有一次选择机会,两个按钮只能选择一个按钮,按一次。如果一个按钮都不选择,不按的话,无论灯球最终状态如何,都是要被消灭。小孩子或者老人、残疾人,可以由监护人来辅助其完成选择。

系统实现的前提条件和需求

前提条件说明

1 全球80亿人口,必须同时在1分钟时间内完成选择(三体人的开关,全球实时状态同步,无时间偏差,无时延),规定时间范围之外无法操作;

2 三体人提供1000台128核256G内存1T磁盘的服务器,三体人的开关与服务器的网络是直连的,没有时延,没有网络开销;

3 全球80亿人,每个人都有一个唯一的从0开始自增的数字ID,与三体人的开关也是一一对应的;

4 每个人的ID%1000指向特定服务器,请求系统提供的接口 /vote

系统需求

功能,开发这个投票接口(所有请求只会在这1分钟内请求)

/vote?uid=1111&click=1&t=1234143134134134134

参数 

uid 长整型,每个人的唯一ID

click 枚举值,按钮选择,0 熄灭,1 亮起

t 长整型,操作时间,单位纳秒

处理

1 在同一个时刻(同一纳秒),如果有多个人操作,选择次数多的生效,如果2个选择次数相同,状态不变。如:熄灭2次,亮起3次,这个时刻的状态是亮起。

结果数据

1 最终灯球的状态,是熄灭,还是亮起;

2 选择正确的人(ID集合);

3 选择错误的人(ID集合);

4 没有做出选择的人(ID集合);

最终执行

调用三体人在服务器上安装的系统程序 ,完成地球人消灭计划。

kill uid

调用三体人的系统程序无延时,等同于内存读取的效率。

要求在1分钟时间内,把选择错误的人和没有做出选择的人消灭掉。

模拟测试

1 三体人在1分钟内导入测试用例,完成80亿人的选择。

2 1分钟正确执行完成 kill 调用。

如果无法实现上述工作,失败。

请输出你的解答。。。


点击查看更多内容

本文首次发布于慕课网 ,转载请注明出处,谢谢合作

1人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
全栈工程师
手记
粉丝
1.7万
获赞与收藏
1589

关注TA,一起探索更多经验知识

作者相关文章
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消