0%

mysql面试收集

mysql

主从复制的原理

1
2
3
4
MySql主库在事务提交时会把数据变更作为事件记录在二进制日志Binlog中;
主库推送二进制日志文件Binlog中的事件到从库的中继日志Relay Log中,之后从库根据中继日志重做数据变更操作,通过逻辑复制来达到主库和从库的数据一致性;
MySql通过三个线程来完成主从库间的数据复制,其中Binlog Dump线程跑在主库上,I/O线程和SQL线程跑着从库上;
当在从库上启动复制时,首先创建I/O线程连接主库,主库随后创建Binlog Dump线程读取数据库事件并发送给I/O线程,I/O线程获取到事件数据后更新到从库的中继日志Relay Log中去,之后从库上的SQL线程读取中继日志Relay Log中更新的数据库事件并应用

主从复制的延迟问题

1
2
3
4
5
6
7
进行主从同步的过程中,如果使用异步或半异步模式,均会有主从节点数据不一致的窗口时间。同时,从节点上的 SQL Thread 只能串行执行 relay-log 中的记录,当某条 DDL/DML 耗时较长时,会加剧这个窗口时间;再者在某些场景下会使用 slave 节点进行数据读取,这也可能导致数据加锁等待。基于以上原因在处理主从复制延迟问题上有以下几种方向:

优化主从节点之间的网络延迟
降低 master 负载,以减少 TPS
降低 slave 负载,slave 只做备份使用,不提供服务
调整 slave 参数:关闭 slave bin-log 等
多线程的主从复制:不同 schema 下的表并发提交时的数据不会相互影响,即 slave 节点可以用对 relay log 中不同的 schema 各分配一个SQL Thread,来重放 relay log 中主库已经提交的事务

网络

https

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
一个HTTPS请求实际上包含了两次HTTP传输,可以细分为8步。
1.客户端向服务器发起HTTPS请求,连接到服务器的443端口

2.服务器端有一个密钥对,即公钥和私钥,是用来进行非对称加密使用的,服务器端保存着私钥,不能将其泄露,公钥可以发送给任何人。

3.服务器将自己的公钥发送给客户端。

4.客户端收到服务器端的公钥之后,会对公钥进行检查,验证其合法性,如果发现发现公钥有问题,那么HTTPS传输就无法继续。严格的说,这里应该是验证服务器发送的数字证书的合法性,关于客户端如何验证数字证书的合法性,下文会进行说明。如果公钥合格,那么客户端会生成一个随机值,这个随机值就是用于进行对称加密的密钥,我们将该密钥称之为client key,即客户端密钥,这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密,这样客户端密钥就变成密文了,至此,HTTPS中的第一次HTTP请求结束。

5.客户端会发起HTTPS中的第二个HTTP请求,将加密之后的客户端密钥发送给服务器。

6.服务器接收到客户端发来的密文之后,会用自己的私钥对其进行非对称解密,解密之后的明文就是客户端密钥,然后用客户端密钥对数据进行对称加密,这样数据就变成了密文。

7.然后服务器将加密后的密文发送给客户端。

8.客户端收到服务器发送来的密文,用客户端密钥对其进行对称解密,得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束,整个HTTPS传输完成。

tcp 三次握手

1
2
3
第一次握手:建立连接时,客户端发送 SYN 包(seq=j)到服务器,并进入SYN_SENT状态,等待服务器确认。
第二次握手:服务器收到 SYN 包,必须确认客户的 SYN(ack=j+1),同时自己也发送一个 SYN 包(seq=k),即 SYN + ACK 包,此时服务器进入 SYN_RECV 状态;
第三次握手:客户端收到服务器的 SYN+ACK 包,向服务器发送确认包 ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

tcp 四次挥手

1
2
3
4
5
6
由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。

客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送(报文段4)。
服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1(报文段5)。和SYN一样,一个FIN将占用一个序号。
服务器B关闭与客户端A的连接,发送一个FIN给客户端A(报文段6)。
客户端A发回ACK报文确认,并将确认序号设置为收到序号加1(报文段7)

Pod 的终止

1
2
3
4
5
6
7
8
9
10
11
12
13
14
流程示例:

用户发送命令删除 Pod,使用的是默认的宽限期(30秒)
API 服务器中的 Pod 会随着宽限期规定的时间进行更新,过了这个时间 Pod 就会被认为已 “死亡”。
当使用客户端命令查询 Pod 状态时,Pod 显示为 “Terminating”。
(和第 3 步同步进行)当 Kubelet 看到 Pod 由于步骤 2 中设置的时间而被标记为 terminating 状态时,它就开始执行关闭 Pod 流程。
如果 Pod 定义了 preStop 钩子,就在 Pod 内部调用它。如果宽限期结束了,但是 preStop 钩子还在运行,那么就用小的(2 秒)扩展宽限期调用步骤 2。
给 Pod 内的进程发送 TERM 信号。请注意,并不是所有 Pod 中的容器都会同时收到 TERM 信号,如果它们关闭的顺序很重要,则每个容器可能都需要一个 preStop 钩子。
(和第 3 步同步进行)从服务的端点列表中删除 Pod,Pod 也不再被视为副本控制器的运行状态的 Pod 集的一部分。因为负载均衡器(如服务代理)会将其从轮换中删除,所以缓慢关闭的 Pod 无法继续为流量提供服务。
当宽限期到期时,仍在 Pod 中运行的所有进程都会被 SIGKILL 信号杀死。
kubelet 将通过设置宽限期为 0 (立即删除)来完成在 API 服务器上删除 Pod 的操作。该 Pod 从 API 服务器中消失,并且在客户端中不再可见。
默认情况下,所有删除操作宽限期是 30 秒。kubectl delete 命令支持 --grace-period=<seconds> 选项,允许用户覆盖默认值并声明他们自己的宽限期。设置为 0 会强制删除 Pod。您必须指定一个附加标志 --force 和 --grace-period=0 才能执行强制删除操作。


ReplicaSet Replication Controller

1
2
ReplicaSet 是下一代的 Replication Controller。 ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持
ReplicaSet 支持新的基于集合的选择器需求,这在标签用户指南中有描述。而 Replication Controller 仅支持基于相等选择器的需求。

ReplicaSet Deployment

1
2
3
4
1、Deployment 是一个更高级的概念,它管理 ReplicaSet,并向 Pod 提供声明式的更新以及许多其他有用的功能
2、对于重启策略,.spec.template.spec.restartPolicy 唯一允许的取值是 Always,这也是默认值
3、.spec.template.metadata.labels 必须匹配 .spec.selector,否则它将被 API 拒绝
4、ReplicaSet 将本地容器重启的任务委托给了节点上的某个代理(例如,Kubelet 或 Docker)去完成。