00:00
好,各位同学,我们继续转圈圈,就说明什么程序出现了网络卡顿,那么大家试想一下,我们从头开始讲到这都明白,Red是基于分布式的内存数据库,一秒钟可以高达8万次的写入操作和10万次以上的读操作,如果能够在这转圈圈的话,你可想而知,你的程序如果是放在电商系统、金融系统的话,说吧,停顿这么长时间。P0级的生产事故,你是自己走还是我们送你走?OK,好,这是第一个问题,极其严重。第二个问题请同学们回到我们的架构图,我们大家都清楚,现在是Java通过。微服务red temp去访问我们的集群,哎,之前好端端的。一切岁月静好,很自然,像大自然一样自然,但是现在不好意思啊,6381哎。宕机了,我们我们这边6384也已经上位了,刚才我们已经演示了6381MASTER,但是我们的6384也已经上位了,然后呢,运维的这边兄弟说我们子集群配的没问题,但T2程序这边说刚才不好端端的吗?怎么你们这个master氮机以后主从切换是没做好,怎么我写过去的数据刚才写的好好的,现在又写不进去了呢,我程序没动过呀,完了那么经常职场上见到的。
01:24
运维和测试开发几个部门跨部门之间的相爱相杀,对吧?那么你说吧,这个锅该怎么说,是Java没写好还是res没配对呢?对吧?那这个锅谁背呢?好,所以说同学们带着这些问题,我们先来看一下这个到底是怎么回事。来下面我们刚才已经试过了,微服务客户端再次出现访问会转圈圈,那么为什么会出现这种经典的故障呢?那么这个也就如果你用微服务通过red。去连接了以后,经常抱着一个red集群故障,那就是什么概念?Spring的客户端没有动态感知到red集群的最新集群信息,以及因为我们是这样一种情况,在我们原始的架构当中,现在六台机器,那么。
02:19
首次正常上线连接的时候,Red这边假设这是我们,呃呃,微服务这边就明白你的网络架构拓扑图第一代是这样的,但是随着我们red这边的缺失和变动,6381死了,6384上位,也就是说从数量上六台机器变成了五台,从主,从关系上就变成了什么三主两头,那么现在这个组织架构已经变了,它已经变成2.0版了,但是对不起,我们的微服务这边并没有收到最新的通知啊,我不知道。或者说我也没有从最新的拓扑结构上拉下来最新的组织架构去做对应的匹配,所以这就是最经典的red连集群的。
03:08
这就是我们微服务联集群的故障,因为网络抖动缺失数据,没有动态感知到red集群的最新集群信息,导致我们的数据出现了卡顿,甚至数据丢失。那么我们正常的情况,集群三组三层正常读下,反问master节点,Li负责节点备份都OK的,突然当master氮气以后,Red斯特主从切换成功red。运维手动是OK的,也就是所谓的手动,就是我们现在自己写过刚才那些命令。一切都是OK的。但是。Java微服务这边出现了故障,第一个还会去找6381,你去找6381没关系,可是找得到。直接用找不到是不是应该非常聪明的。写给6384它的同子,但是我不头很铁,依旧去找6381导致了什么?
04:05
一分钟以上的超时啊,转圈圈卡顿,整个re集群的高可用性能急剧下降,那么这种是严重的生产故障,OK,好,那么导致原因就是spring2.0,也就现在大家主流的版本啊,因为可能2023年以后才会用SPRING3,那么JDK17等等,那目前还是JAVA8加S2点叉这个版本,我们引入了这个date的话,它默认底层采用的是。Late生态,那么当集群节点发生变化以后,Late默认是不会动态的刷新节点拓扑图,以获得服务器上最新的red结构,也即我还是拿着老版本的33层,而并并不知道。真实的集群环境已经变成了三组二层,6381蛋机,6384直接上位。我并不知道2.0版的这个最新组织架构拓扑图,所以呢,我们要让他知道改写方案三招。
05:01
第一种排除latest用可以能解决问题,那么也就是说在我们的date ready里面默认用的。排除掉,引入我们的简方法上。管用,但是不优雅,因为date red整合了雷生态,是目前最先进的,那么就变成什么整体最先进,然后呢,包容易进去一部分落后的,哎,那么这个时候的话呢,有点不伦不类,新平专旧舅,OK,第二种你艺高人胆大,重写原代码,那么重写连接工厂实例,那么大家都清楚,我们这儿有个red,其实底子而言,连的是不是就是这个latest connection factor呀,OK,好,那么你觉得呢,他这个呢,由于源码上不支持动态刷新,那么如果你们公司有大牛和高手改写了源码以后,不会影响其他的问题,可以干,当然我个人不推荐你看要写这么多,而且还通过各种版本的测试,那么第三种是我最推荐的比较温和非常简单的解决问题,也是官方所推荐的俗称刷新节点集群的拓普动态感应做两个配置线。
06:13
一派即可,那么官网上这个呢。地址在这,有兴趣的同学可以去查看一下,那么他说的人话意思就说,你说集群的配置呢,可能是会在某个时间是会被改变的,所以新的节点可能被加入,那么这个master必须要指定一个槽位,这些对应的呢,可能也会发生改变,所以呢,为了引起这些拓扑图的变化,我们需要干嘛?刷新节点拓扑视图,那么自适应拓扑刷新与定时拓扑刷新默认是关闭的,那么自然而然我们需要把它什么打开,所以解决方法有这么两个,要么是调用这个red集群客户端的重新加载这个partition这个分区结构信息啊,类似要么你呢可以做一些配置,比如说啊这三种方法都可以用啊,那么后台具体时间间隔的周期刷新或者是什么开始我们的动态拓的自适与更新,OK好,那么根据官网的操作,我们来进行一下我们的修改,那么此时我先暂停一下我的为服务,因为现在我们呢,直接去外面去找的话呢,还是会去找老版本的六三八幺一点的话,那么同学们还是转圈圈不OK,那么现在我们要告诉他,你如果按照1.0版的架构图去找6381,找得到请直接用,找不到应该马上去找6384啊。
07:35
OK,不要再给我转圈圈,保证高可用,无感,就跟底层被你屏蔽,什么都不知道,你下层的故障不应该引起上层的程序反问。不OK,所以我们这儿修改我们的样模。增加。集群节点拓扑动态感应刷新的这么一些配置项和刷新时间间隔也即在这儿。
08:01
做这么一个配置完活,哎,所以说呢,第一个把这个那么adaptive,那么大家呢,可以在官网上呢,呃,在这也可以看到啊,我们呢。来自适应时间,那么同学们请看,哎,两秒钟默认它是副词,我们把它改为处,OK,就这么两个选项,好,那么同学们此时呢,我们呢,依旧啊,来看一下class no,我没有回复6381,那么刚才啊,你呢,是六三八幺一死,你呢被拉去陪葬了,也在转圈圈,那么现在我们呢,重新呢,增加我们这两个。把我们的微服务启动来看一下它还会不会继续去转圈圈,这个呢非常关键好,所以说机长集群上的时候,建议大家配上这两个啊,除非你能保证啊你的集群永远不死机,那我就当我没说,我就闭嘴了,好那么同学们请看一眼点一下好哎,这不还在转呢,稍等哎,有没有发现转的时间绝对没有超过一分钟,因为你刚刚来的时候,他也需要集群去拓扑哦6381我去找,找不到死了,然后干嘛马上我呢?ORDER521很好,我们不管get order521同学们请告诉我有没有是不是根据这个槽位跳到了我们的6384这台机器,因为我们都明白,根据我们前面所说的讲解。
09:30
这个槽位分配零到5460的话,是6381占有的,那么6381宕机了以后,是不是6384取而代之上上位,那么说明6384现在是在零到5460这个槽位号上面,听懂了吧,所以说刚才你会。发现一个非常好的现象,就点了一会就转了两三秒,马上哎,找到我们的6384插入成功,那么这个时候他又马上知道了最新的集群拓扑图,同学们请看我点我点我点我点点点点点点点点点点点,怎么样,再也没有出现长时间的转圈了吗?哎,这样就解决了我们的什么,因为。
10:08
组织架构的变动导致网络抖动,数据缺失的问题,哎,所以集群拓扑刷新这种通知机制是一定要采用的,好,那同学们两次对比,我们就已经获得了我们最新的成果,OK,那么看看后台这些的话,那么。看他呢,依旧会去找6381,但是这次没关系了,我们该有的值该怎么写怎么写,OK,那么get what,再来一次178马上告诉你,你看一万多以后去找6385这个机器,我们的集群将将好完全可以正常使用,那么你就可以是无感的,最多诶两秒钟以后诶也可以成功了,那么这样是不是要比转长时间转圈圈好很多?好那么同学们,这个就是我们对red BOO集spring集成red最重要的两部分的讲解,请同学们务必拿下。好那么各位亲,到此为止,我们零基础小白篇彻底完结,那么请同学们不要走开,继续跟着杨哥学习大厂高阶篇,那么这个时候我才可以给大家说更多的科技与很合。嗯嗯,大长篇咱们再见,感谢各位的聆听,谢谢,请一定动手多多练习,谢谢大家。
我来说两句