前言
今天刚好有空,跟大家聊聊如何学好算法进大厂。
前两天一个读者和我说,他坚持刷算法题2个月,薪资翻番去了他梦寐以求的大厂,期间面字节跳动还遇到了原题…其实据我所知目前国内的大厂和一些独角兽,已经越来越效仿硅谷公司的做法,通过编程定题面试,来考察数据结构和算法的扎实程度。
以我的经验来说,**对于新手来说,扎实的掌握一门语言是其一,其二就是要有基本的算法能力,这个非常重要。对于进阶的用户,更多技术栈的掌握就是必须的了。另外,还需要你学习高阶算法,掌握这些技术栈匹配的算法技能。**现在很多大厂技术面试的要求是:技术要好,计算机基础扎实,熟练掌握算法和数据结构,语言不重要,熟练度很重要。每一轮技术面试不只考算法,但一定会考算法。
为什么这几年算法成了其中必要的一个环节?因为考察算法的核心就是,看候选人是不是足够聪明!很多大厂的算法面试题一般对应的是 LeetCode 中级模式,一般会直接让你说思路或上手写代码。
要通过面试,你肯定得花时间好好准备。但是只靠刷题去提升算法能力,进度太慢,而且还容易抓不住重点很难坚持,并且没有完整的学习体系,也没人指导,导致最后的结果就是一知半解,浪费了大量的时间成本。
主备同步的实现原理
我们先来了解一下主备同步的原理,下面以一个update语句来介绍主库与备库间是如何进行同步的。
上图是一个update语句在节点A执行,然后同步到节点B的完整流程图,具体步骤有:
- 主库接受到客户端发送的一条update语句,执行内部事务逻辑,同时写binlog。
- 备库通过 change master 命令,设置主库的IP、端口、用户名和密码,以及要从哪个位置开始请求 binlog。这个位置包含文件名和偏移量。
- 在备库上执行start slave命令,启动两个线程 io_thread 和 sql_thread,其中 io_thread 负责与主机进行连接。
- 主库校验完用户名和密码,按照接收到的位置去读取binlog,发给备库。
- 备库接收到binlog后,写到本地文件(relay log,中转文件)。
- 备库读取中转文件,解析出命令,然后执行。
主备同步的工作原理其实就是一个完全备份加上二进制日志备份的还原。不同的是这个二进制日志的还原操作基本上是实时的。
备库通过两个线程来实现同步:
- 一个是 I/O 线程,负责读取主库的二进制日志,并将其保存为中继日志。
- 一个是 SQL 线程,负责执行中继日志。
从上面的流程可以看出,主备同步的关键是binlog。
常见的两种主备切换流程
M-S结构
M-S结构,两个节点,一个当主库、一个当备库,不允许两个节点互换角色。
在状态1中,客户端的读写都直接访问节点A,而节点B是A的备库,只是将A的更新都同步过来,到本地执行。这样可以保持节点B和A的数据是相同的。
当需要切换的时候,就切成状态2。这时候客户端读写访问的都是节点B,而节点A是B的备库。
双M结构
双M结构,两个节点,一个当主库,一个当备库,允许两个节点互换角色。
对比前面的M-S结构图,可以发现,双M结构和M-S结构,其实区别只是多了一条线,即节点A和B之间总是互为主备关系。这样在切换的时候就不用再修改主备关系。
双M结构的循环复制问题
在实际生产使用中,多数情况是使用双M结构的。但是,双M结构还有一个问题需要解决。
业务逻辑在节点A执行更新,会生成binlog并同步到节点B。节点B同步完成后,也会生成binlog。(log_slave_updates设置为on,表示备库也会生成binlog)。
当节点A同时也是节点B的备库时,节点B的binlog也会发送给节点A,造成循环复制。
解决办法:
- 设置节点的server-id,必须不同,不然不允许设置为主备结构
- 备库在接到binlog后重放时,会记录原记录相同的server-id,即谁产生即为谁的。
- 每个节点在接受binlog时,会判断server-id,如果是自己的就丢掉。
解决后的流程:
- 业务逻辑在节点A执行更新,会生成带有节点A的server-id的binlog。
- 节点B接受到节点A发过来的binlog,并执行完成后,会生成带有节点A的server-id的binlog。
- 节点A接受到binlog后,发现是自己的,就丢掉。死循环就在这里断掉了。
最后
2020年在匆匆忙忙慌慌乱乱中就这么度过了,我们迎来了新一年,互联网的发展如此之快,技术日新月异,更新迭代成为了这个时代的代名词,坚持下来的技术体系会越来越健壮,JVM作为如今是跳槽大厂必备的技能,如果你还没掌握,更别提之后更新的新技术了。
更多JVM面试整理:
l3rkBVW-1621042878403)]
更多JVM面试整理:
[外链图片转存中…(img-a6hA7698-1621042878405)]