MySQL数据库cpu飙升到500%的话他怎么处理？

当 cpu 飙升到 500%时，先用操作系统命令 top 命令观察是不是 mysqld 占用导致的，如果不是，找出占用高的进程，并进行相关处理如果是 mysqld 造成的， show processlist，看看里面跑的 session 情况，是不是有消耗资源的 sql 在运行。找出消耗高的 sql，看看执行计划是否准确， index 是否缺失，或者实在是数据量太大造成。
一般来说，肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)，等进行相应的调整(比如说加索引、改 sql、改内存参数)之后，再重新跑这些 SQL。也有可能是每个 sql 消耗资源并不多，但是突然之间，有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等

备份的方案

完整/完全备份    full mysqldump

增量备份 incremental backup 每次备份都是基于上一次的时间 一天备份一次

差异备份 differential backup 从上一次完整备份开始，接下来的每一天都是从上一次完整备份开始

在公司用的最多的就是完整备份，增量备份

rsync远程拷贝

rsync远程拷贝，远程管理的服务跟ssh是一样的。但它不是远程管理，它就是远程拷贝。它的功能跟scp一样。scp有个特点不管目的地址有什么东西，只要有一样的，拷贝过去直接覆盖。

简述负载均衡四层和七层的区别？

四层负载均衡器 也称为 4 层交换机，主要通过分析 IP 层及 TCP/UDP 层的流量实现基于 IP 加端口的负载 均衡，如常见的 LVS、F5 等；

七层负载均衡器 也称为 7 层交换机，位于 OSI 的最高层，即应用层，此负载均衡器支持多种协议，如 HTTP、FTP、SMTP 等。7 层负载均衡器可根据报文内容，配合一定的负载均衡算法来选择后端服务 器，即“内容交换器”。如常见的 HAProxy、Nginx。

针对网站访问慢，怎么去排查？

1、首先要确定是用户端还是服务端的问题。当接到用户反馈访问慢，那边自己立即访问网站看看，如果自己这边访问快，基本断定是用户端问题，就需要耐心跟客户解释，协助客户解决问题。不要上来就看服务端的问题。一定要从源头开始，逐步逐步往下。

2、如果访问也慢，那么可以利用浏览器的调试功能，看看加载那一项数据消耗时间过多，是图片加载慢，还是某些数据加载慢。

3、针对服务器负载情况。查看服务器硬件(网络、CPU、内存)的消耗情况。如果是购买的云主机，比如阿里云，可以登录阿里云平台提供各方面的监控，比如CPU、内存、带宽的使用情况。4、如果发现硬件资源消耗都不高，那么就需要通过查日志，比如看看MySQL慢查询的日志，看看是不是某条SQL语句查询慢，导致网站访问慢。

怎么去解决？

1、如果是出口带宽问题，那么久申请加大出口带宽。

2、如果慢查询比较多，那么就要开发人员或DBA协助进行SQL语句的优化。

3、如果数据库响应慢，考虑可以加一个数据库缓存，如Redis等等。然后也可以搭建MySQL主从，一台MySQL服务器负责写，其他几台从数据库负责读。

4、申请购买CDN服务，加载用户的访问。

5、如果访问还比较慢，那就需要从整体架构上进行优化咯。做到专角色专用，多台服务器提供同一个服务。

ELK做过哪些图表?

统计各个接口的请求数量

查看接口响应时长的分布情况

查看请求数量分布情况

具体接口的响应时间

系统错误码数量浏览量的趋势图，

柱图请求响应时间占比-饼图

zabbix报警的策略是什么？

动作里的操作里有设置时间的问题。 第一个是设置的间隔时间，例如1，5，15分钟设置报警周期的时间，例如第一次与第二次报警如果是5分钟的话，那么10分钟之内会报警两次。

第一个报警之后15分钟内解决问题，证明这个月业绩优秀；
第二个报警之后15分钟内解决问题，30分钟内解决，业绩合格；
第三个报警之后15分钟内解决问题，45分钟还未解决，领导会谈话；

RabbitMQ是什么东西？

RabbitMQ也就是消息队列中间件，消息中间件是在消息的传息过程中保存消息的容器 ，消息中间件再将消息从它的源中到它的目标中时充当中间人的作用 ，队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用 ，消息队列不会保留消息，直到可以成功地传递为止，当然，消息队列保存消息也是有期限地。
 

统计ip访问情况，要求分析nginx访问日志，找出访问页面数量在前十位的ip

cat access.log | awk '{print $1}' | uniq -c | sort -rn | head -10

简述TCP三次握手过程

在TCP/IP协议中，TCP协议提供可靠的连务，第一次握手：建立连接时，客户端发送syn包到服务器，并进入syn_sent状态，等待服务器确认；

第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=j+1），同时也发送一个syn+ack包，此时服务器进入syn_rcvd状态；

第三次握手；客户端收到服务器的SYN+ACK 包，向服务器发送确认包ACK（ack=k+1），此包发送完毕，客户端和服务器进入established状态，完成三次握手，客户端与服务器开始传送数据

（三次握手是建立连接的过程）

笔试的时候

把图画上去 必须带箭头因为是数据包的流向。一去带个箭头一回带箭头在一去带个箭头，把两端的状态一写。

为什么不是四次握手？

三次握手的目的是确认双方发送和接收的能力，那四次握手可以嘛？

但为了解决问题，三次就足够了，再多用处就不大了。

四次挥手的过程就是客户端到服务端一次两回再一去   （一定要说出来）

客户端主动关闭 状态从estab-lished到FIN-WAIT-1到FIN -WAIT-2到TIME-WAIT到CLOSED

服务端的变化从ESTAB-LISHED到CLOSE-WAIT到LAST-ACK到CLOSED三次握手和四次挥手其实就是数据的一个连接和一个断开四次挥手是先建立了三次握手（得先建立成连接才能结束）才能进行四次挥手。数据是有一个结束的过程的而这就是tcp的四次挥手，两个建立连接最开始肯定是estab-lished状态，而最后都关闭了是closed。

tcp协议的11种状态

listen：侦听来自远方的TCP端口连接请求

SYN-SENT:再发送连接请求后等待匹配的连接请求

SYN-RECEIVED:再收到和发送一个连接请求后等待对方对连接请求的确认

ESTABLISHED:代表一个打开的连接

FIN-WAIT-1:等待远程TCP连接中断请求，或先前的连接中断请求的确认

FIN-WAIT-2： 从远程TCP等待连接中断请求

CLOSE-WAIT： 等待从本地用户发来的连接中断请求

CLOSING:等待远程TCP对连接中断的确认

LAST-ACK： 等待原来的发向远程TCP的连接中断请求的确认

TIME-WAIT：等待足够的时间以确保TCP接收到连接中断请求的确认

CLOSED: 没有任何连接状态