温馨提示:文本由机器自动转译,部分词句存在误差,以视频为准
00:00
好,各位同学,我们继续,那么接下来说一下我们最后一节哨兵的使用建议来吧。第一个第二个一起说,哨兵节点的数量应该为多个,本身就要是集群,最好数量是激素,那么保证高可用好投票。第二个问题,各个哨兵节点的配置应该一致。三台机器硬件上最好一致啊,举个不恰当的案例啊,比如有些同学假设这是这个内存的话呢,这是16G,这个呢。32这个呢,干成128。性能上一定不一样的啊,他们三个拼装成集群的时候,你最好硬件一样啊,这个是有规矩的,不建议大家呢搞三台性能上硬件上差距特别大的,你不要去审机器,现在是吧,阿里云啊这些也不是特别贵,华为云啊这些OK,那么接下来如果你少屏节点,因为现在呢是。基本上就是一切在容器。处处是云端,那么这个时候你有可能会要放在刀口里面,尤其要注意端口的正确映射,这个非常重要,OK,那么最后听好重点哨兵集群加主从复射并不能保证数据的什么零丢失。好,同学们,我先暂停一下,大家讨论一下同学的回复啊,有的同学呢,没转过来,我和大家解释一下啊。
01:18
首先3000哨兵他没什么问题,他只是做个监控,你就把它当做我们后台写了个进程,它是个监控程序,他不干业务逻辑,我们这有个缺陷,天生的,他确实能够做到无人值守的。故障迁移,可是这个master一旦挂,我这个业务现在是进不来的,我的写业务是进不来,这个master哨兵要从发现再产生选举算法,最后再从莱瓦形成新的master,形成新的领导班子和权力格局,对外承接业务少说我个人认为生产上。至少有这么个五到十秒钟啊,真是你你看我这样做,因为我是在同一台机器,听懂了吧,很快真真正正生产上只可能比我说的时间慢,那么这个时候好,我们就取个折中,假设有七秒钟,那这个时候互联网的程序这个master现在有七秒钟不能写入,你告诉我丢不丢数据。
02:11
好,七秒钟以后,假设啊,莱瓦上来一个新马斯恢复了好,变成了新的主通复制好,对外暴露了,但是还是有七秒钟的数据直接挂了,因为你只有一个master节点,他做的事是slave上位,但并不保证master数据不丢失,所以这是哨兵的一个缺陷。那么故此我们在工作中。承上启下,会引出我们的下一章。Red集群,Red支付也推荐大家用集群,OK,那么从我的使用工作经验和跟大厂的这些弟子和以我以前的同事交流。一般哨兵家主从有人在用,但是用的少了,一般我们直接上C集群,OK,好,那么同学们这些知识就是我们的一些重要部分,复制哨兵集群。
03:09
一层住一层,慢慢爬楼梯,OK,请同学们呢?每一个知识章节都要细致牢靠的把握好,万丈高楼平地起,一切承担靠地基,绝对不要绕过这两张去直接学集群,你听不懂的现在复制。哪不好,所以引出哨兵复制加哨兵又有什么缺陷,所以引出了我们的集群,OK,那么好,各位亲,我们下一讲给大家介绍我们的集群,那么最后自然而然我们的为服务,结合我们的Java程序直接访问集群,那么这个才是我们的重点,好,各位同学,我们的哨兵就给大家介绍到这。
我来说两句