某小公司:MySQL连环问,你接得住吗?
共 2363字,需浏览 5分钟
·
2021-04-19 15:16
MySQL 面试题开始要更新啦!
请接招。
你们公司数据库有备份的吧?
我:有的,因为单点故障的情况不可避免,所以我们公司有主从。面试官:那你知道主备、主从、主主有什么区别?
主备就是:主机和备机。
备机是不干活的,也就是不对外提供服务,只是默默地在同步主机的数据,然后等着某一天主机挂了之后,它取而代之!
![](https://filescdn.proginn.com/540ee34586ed9416425d3cd2f0c7d190/8efff56db5243fe3d62e7b7d3f7980c4.webp)
至于切换的话主要有两种方式:
人工切换,得知主机挂了之后手动把备机切成主机,缺点就是慢。 利用 keepalived 或者自己写个脚本来作监控,然后自动切换。
主从就是主机和从机。
从机和备机的区别在于,它是对外提供服务的,一般而言主从就是读写分离,写请求指派到主机,读请求指派到从机。
![](https://filescdn.proginn.com/11a968a928a601e76b3df622fed385a7/72e56aaeadeaa9696412b2b96edfdc23.webp)
主主就是两个都是主机
![](https://filescdn.proginn.com/cae453372d465b0f967400d4526f5b70/80706fca36f774d674f73509ee72b24b.webp)
一般情况下都不会有主主的架构。
当同时有两个写请求达到分别打到两个主库同一张表的时候,则会同时创建一条记录,这条记录的 ID 是一样的,这样数据同步之后其中有一条就会被覆盖了,这会出问题的。
为什么要读写分离啊?
读写分离就是读操作和写操作从以前的一台服务器上剥离开来,将主库压力分担一些到从库。
本质上是因为访问量太大,主库的压力过大,单机数据库无法支撑并发读写。
然后一般而言读的次数远高于写,因此将读操作分发到从库上,这就是常见的读写分离。
读写分离还有个操作就是主库不建查询的索引,从库建查询的索引。
因为索引是需要维护的,比如你插入一条数据,不仅要在聚簇索引上面插入,对应的二级索引也得插入,修改也是一样的。
所以将读操作分到从库了之后,可以在主库把查询要用的索引删了,减少写操作对主库的影响。
你们读写分离是用中间件的还是代码封装的?
代码封装。
讲白了就是代码层面抽出一个中间层,由中间层来实现读写分离和数据库连接。
就是搞了个代理类,对外暴露正常的读写接口,里面封装了逻辑,将读操作指向从库的数据源,写操作指向主库的数据源。
优点:简单,并且可以根据业务定制化变化,随心所欲。 缺点:如果数据库宕机了,发生主从切换了之后,就得修改配置重启。如果系统是多语言的话,需要为每个语言都实现一个中间层代码,重复开发。
中间件
一般而言是独立部署的系统,客户端与这个中间件的交互是通过 SQL 协议的。
![](https://filescdn.proginn.com/33b3fa8cd108f577992812bee5a1c124/7c292855bb86d18de987f2d2a5b2dd30.webp)
所以在客户端看来连接的就是一个数据库,通过 SQL 协议交互也可以屏蔽多语言的差异。
缺点就是整体架构多了一个系统需要维护,并且可能成为性能瓶颈,毕竟交互都需要经过它中转。
常见的开源数据库中间件有:官方的MySQL-Proxy、360的Atlas、Mycat 等。
MySQL 主从同步机制你知道吗?
主从同步主要依赖的就是 binlog,MySQL 默认是异步复制,具体流程如下:
主库:
接受到提交事务请求 更新数据 将数据写到binlog中 给客户端响应 推送binlog到从库中
从库:
由 I/O 线程将同步过来的 binlog 写入到 relay log 中。 由 SQL 线程从 relay log 重放事件,更新数据 给主库返回响应。
![](https://filescdn.proginn.com/3736a82a00271c18757d5164921368fe/fcaad057bb3f59275a405e7b4538d9d8.webp)
用一句话概括一下:主库提交事务会写binlog,会由一个 dump 线程推送给从库,从库接受之后会有一个I/O线程将其写到 relay log 中,慢慢消化,由 SQL 线程来重放更新数据。
异步复制有数据丢失风险,例如数据还未同步到从库,主库就给客户端响应,然后主库挂了,此时从库晋升为主库的话数据是缺失的。
所以有同步复制,主库需要将 binlog 复制到所有从库,等所有从库响应了之后才会给客户端响应,这样的话性能很差,一般不会选择同步复制。
MySQL 5.7 之后搞了个半同步复制,有个参数可以选择“成功同步几个从库就返回响应。”
比如一共有 3 个从库,我参数配置 1,那么只要有一个从库响应说复制成功了,主库就直接返回响应给客户端,不会等待其他两个从库。
这样的话性能就比较好,并且数据可靠性也增强了,只有当那个从库和主库同时都挂了,才会缺失数据。
主从同步延迟怎么处理啊?
从上图的流程就可以得知,延迟是必然存在的。
延迟过大的话就有可能出现一个用户刚注册,然后登陆报该用户不存在的....
因为数据是写到主库中的,查询走从库有可能还未来同步完毕,导致查不到这个用户。
这就非常不友好了。
常见解决方式有以下几种:
二次查询。如果从库查不到数据,则再去主库查一遍,由 API 封装即可,算是一个兜底策略,比较简单。不过等于读的压力又转移到主库身上了,如果有不法分子估计搞一下必定查不到的查询,这就难受了。
强制将写之后立马读的操作转移到主库上。这种属于代码写死了,比如一些写入之后立马查询的操作,就绑定在一起,写死都走主库。不推荐,太僵硬了。
关键业务读写都走主库,非关键还是读写分离。比如上面我举例的用户注册这种,可以读写主库,这样就不会有登陆报该用户不存在的问题,这种访问量频次应该也不会很多,所以看业务适当调整此类接口。
—————END————— 推荐阅读:
MyBatis动态SQL,写SQL更爽 面试官:String长度有限制吗?是多少? 阿里首推的 SpringBoot + Vue 全栈项目 凭啥不能用uuid做MySQL的主键!? SpringBoot+vue.js搭建图书管理系统 MyBatis-Plus常用API全套教程,看完没有不懂的
最近面试BAT,整理一份面试资料《Java面试BAT通关手册》,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。 获取方式:关注公众号并回复 java 领取,更多内容陆续奉上。 明天见(。・ω・。)ノ♡