高频面试题

采用二进制格式，替换字符串

头部压缩

多路复用

服务器推送

当客户端发出最后的 ACK 确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完 ACK 确认报文之后，会设置一个时长为 2 MSL 的计时器。MSL（Maximum Segment Lifetime），指一段 TCP 报文在传输过程中的最大生命周期。2 MSL 即是服务器端发出 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。 若服务器在 1 MSL 内没有收到客户端发出的 ACK 确认报文，再次向客户端发出 FIN 报文。如果客户端在 2 MSL 内收到了服务器再次发来的 FIN 报文，说明服务器由于一些原因并没有收到客户端发出的 ACK 确认报文。客户端将再次向服务器发出 ACK 确认报文，并重新开始 2 MSL 的计时。 若客户端在 2MSL 内没有再次收到服务器发送的 FIN 报文，则说明服务器正常接收到客户端 ACK 确认报文，客户端可以进入 CLOSE 阶段，即完成四次挥手。 所以客户端要经历 2 MSL 时长的 TIME-WAIT 阶段，为的是确认服务器能否接收到客户端发出的 ACK 确认报文。 作者：力扣 (LeetCode) 链接：https://leetcode-cn.com/leetbook/read/networks-interview-highlights/esno32/ 来源：力扣（LeetCode） 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

原因

解决办法

何时需要处理

拥塞控制四种算法’

数据分块

超时重传

拥塞控制

流量控制

校验和

序列号和确认应答

ARQ

使用数据库、redis、zookeeper分别如何实现

锁超时问题

Redlock算法

轮训

随机

哈希

一致性哈希

带权重

取模

C

A

P

Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）

单点故障

同步阻塞

数据不一致

在2pc基础上引入超时机制和准备阶段

基于数据库实现

redis

zookeeper或者etcd实现

增加版本号属性

token或者GUID

provider

高级功能

产品

跳表和压缩列表

压缩列表和哈希表

惰性删除

定时删除

定时删除

惰性删除

定期删除

集群监控

消息通知

故障转移

配置中心

常规锁

锁过期，但是还未处理完

看门狗之守护线程

RedLock红锁

先更新数据库再更新缓存(不建议使用)；

先更新数据库再删除缓存（推荐）；

先删除缓存再更新数据库不推荐

解决方案

解决方案

解决方案

解决方案

场景

读未提交（Read Uncommitted） 读已提交（Read Committed） 可重复读（Repeatable Read） 串行化（Serializable）

事务A、B交替执行，事务A被事务B干扰到了，因为事务A读取到事务B未提交的数据,这就是脏读。 在一个事务范围内，两个相同的查询，读取同一条记录，却返回了不同的数据，这就是不可重复读。 事务A查询一个范围的结果集，另一个并发事务B往这个范围中插入/删除了数据，并静悄悄地提交，然后事务A再次查询相同的范围，两次读取得到的结果集不一样了，这就是幻读。

原理解析

AICD

hash

b树

红黑树

b-树

b+树

聚簇索引和非聚簇索引

主键索引、普通索引

覆盖索引

联合索引

查询条件包含or，可能导致索引失效 如何字段类型是字符串，where时一定用引号括起来，否则索引失效 like通配符可能导致索引失效。 联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。 在索引列上使用mysql的内置函数，索引失效。 对索引列运算（如，+、-、*、/），索引失效。 索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。 索引字段上使用is null， is not null，可能导致索引失效。 左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。 mysql估计使用全表扫描要比使用索引快,则不使用索引。

数据量少的不适合加索引 更新比较频繁的也不适合加索引 区分度低的字段不适合加索引（如性别）

覆盖索引 回表 索引数据结构（B+树） 最左前缀原则 索引下推

最左前缀匹配原则 频繁作为查询条件的字段才去创建索引 频繁更新的字段不适合创建索引 索引列不能参与计算，不能有函数操作 优先考虑扩展索引，而不是新建索引，避免不必要的索引 在order by或者group by子句中，创建索引需要注意顺序 区分度低的数据列不适合做索引列(如性别） 定义有外键的数据列一定要建立索引。 对于定义为text、image数据类型的列不要建立索引。 删除不再使用或者很少使用的索引

如何实现的

算法有哪些

悲观锁

乐观锁

排查步骤

InnoDB支持事务，MyISAM不支持事务 InnoDB支持外键，MyISAM不支持外键 InnoDB 支持 MVCC(多版本并发控制)，MyISAM 不支持 select count(*) from table时，MyISAM更快，因为它有一个变量保存了整个表的总行数，可以直接读取，InnoDB就需要全表扫描。 Innodb不支持全文索引，而MyISAM支持全文索引（5.7以后的InnoDB也支持全文索引） InnoDB支持表、行级锁，而MyISAM支持表级锁。 InnoDB表必须有主键，而MyISAM可以没有主键 Innodb表需要更多的内存和存储，而MyISAM可被压缩，存储空间较小，。 Innodb按主键大小有序插入，MyISAM记录插入顺序是，按记录插入顺序保存。 InnoDB 存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全，与 MyISAM 比 InnoDB 写的效率差一些，并且会占用更多的磁盘空间以保留数据和索引 InnoDB 属于索引组织表，使用共享表空间和多表空间储存数据。MyISAM用.frm、.MYD、.MTI来储存表定义，数据和索引。

原因

解决办法

步骤一：主库的更新事件(update、insert、delete)被写到binlog 步骤二：从库发起连接，连接到主库。 步骤三：此时主库创建一个binlog dump thread，把binlog的内容发送到从库。 步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log 步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

存储精度都为秒 区别： DATETIME 的日期范围是 1001——9999 年；TIMESTAMP 的时间范围是 1970——2038 年 DATETIME 存储时间与时区无关；TIMESTAMP 存储时间与时区有关，显示的值也依赖于时区 DATETIME 的存储空间为 8 字节；TIMESTAMP 的存储空间为 4 字节 DATETIME 的默认值为 null；TIMESTAMP 的字段默认不为空(not null)，默认值为当前时间(CURRENT_TIMESTAMP)

分库分表 某个表有近千万数据，可以考虑优化表结构，分表（水平分表，垂直分表），当然，你这样回答，需要准备好面试官问你的分库分表相关问题呀，如 分表方案（水平分表，垂直分表，切分规则hash等） 分库分表中间件（Mycat，sharding-jdbc等） 分库分表一些问题（事务问题？跨节点Join的问题） 解决方案（分布式事务等）

索引优化 除了分库分表，优化表结构，当然还有所以索引优化等方案~

优化shema、sql语句+索引； 可以考虑加缓存，memcached, redis，或者JVM本地缓存； 主从复制，读写分离； 分库分表；

查看是否涉及多表和子查询，优化Sql结构，如去除冗余字段，是否可拆表等 优化索引结构，看是否可以适当添加索引 数量大的表，可以考虑进行分离/分表（如交易流水表） 数据库主从分离，读写分离 explain分析sql语句，查看执行计划，优化sql 查看mysql执行日志，分析是否有其他方面的问题

Show status, 一些值得监控的变量值： Bytes_received和Bytes_sent 和服务器之间来往的流量。 Com 服务器正在执行的命令。 Created 在查询执行期限间创建的临时表和文件。 Handler 存储引擎操作。 Select 不同类型的联接执行计划。 Sort 几种排序信息。 Show profiles 是MySql用来分析当前会话SQL语句执行的资源消耗情况

拷贝大切片一定比小切片代价大吗?

对已经关闭的chan进行读写会怎么样?为什么?

对未初始化的chan进行读写，会怎么样?为什么?

for循环select时， 如果通道关闭会怎么样?如果select中的case只有一 个，又会怎么样?

传递共享数据

取消信号

reflect (反射包)如何获取字段tag? 为什么json包不能导出私有变量的tag?

知道Golang的内存逃逸吗?什么情况下回发生内存逃逸?

怎么避免逃逸分析?

三种方案

consul

etcd

zookeeper