mysql主从复制原理：
1.从库生成两个线程，一个IO线程一个SQL线程
2.IO线程会去请求主库binlog，并将得到的binlog写到本地的relay-log（中继日志）文件中
3.主库会生成一个log dump线程，用来给从库IO线程传送binlog
4.SQL线程会读取relay-log文件中的日志，并解析成SQL逐一执行
DataBase分库分表
一、分库分表
分库场景：如果数据库的查询QPS过高，就要考虑拆库，比如：查询QPS为3500，假设单库可以支撑1000个连接数，那么就考虑拆分成4个库，来分散查询压力。
分库分表场景：
切分方案 解决的问题 只分库不分表 数据库读/写 QPS过高，数据库连接数不足 只分表不分库 单表数据量过大，存储性能遇到瓶颈 既分库又分表 连接数不足+存储性能遇到瓶颈
二、数据切分方法
水平切分
这是一种按业务维度切分的方式，比如，常见的按会员维度进行切分，根据一定规则，把不同会员的数据散落在不同的库表中。
垂直切分
垂直切分可以理解为：把一张表的不同字段拆分到不同的表中
三 分库分表后会遇到哪些坑
事务一致性
解决办法：XA协议、两阶段提交、TCC，通常使用最终一致性的方案，采用事务补偿的方式
分页、排序问题
1）如果排序字段恰好是分片字段，通过分片规则就可以定位到分片的位置；如果排序字段是非分片字段，就需要在不同的分片点中将数据进行排序再返回；然后不同分片的数据汇集到一起再进行汇总和排序，最终返回给用户。
2）用ES
全局唯一主键问题
分布式id生产方案
四 分库分表后历史数据如何做迁移
一般采用【双写】的方式进行迁移
1.增量的消息往新表和老表各写一份
2.将旧表的数据迁移至新库
3.迟早新表的数据会赶上旧表的数据
4.校验新表数据和老表数据是否对得上
5.开启双读（一部分流量走新表，一部分流量走老表），相当于灰度的过程
6.读流量全部切换至新表，停止旧表的写入
7.提前准备回滚机制，临时切换失败能恢复正常业务以及修复数据的相关程序
五 分库分表中间件对比
Sharding-jdbc：client层方案
优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高（轻便，维护成本低，比较推荐中小型公司项目使用）
缺点：如果遇到升级，各个系统都需要重新升级版本再发布，各个系统都需要耦合Sharding-jdbc的依赖
Mycat：proxy层方案
- 缺点： 需要部署，自己要运维一套中间件，运维成本高
- 优点：对于各个项目都是透明的，如果遇到升级问题，自己中间件搞定就行了（推荐大型公司项目使用）。
MySQL-堆排序问题
MySQL-堆排序查询慢
问题：
根据主键排序，获取一条时，查询异常缓慢，测试260万数据需2.8s-3s
如果根据唯一键排序，则需要6s
原因：
由于MySQL 5.6的 priority queue ，在5.7 出现问题：
1 | ORDER BY id DESC LIMIT 1 |
此问题应仅发生在MySQL 5.7版本 ORDERBY 排序 配合 LIMIT 1 使用时发生。测试分页以及批量暂未发生相同异常
解决方案：
使用FORCE INDEX 可修复部分问题，但需针对性加索引
1
2
3
4
5
6
7-- 强制使用索引
EXPLAIN
SELECT * FROM `table_name`
FORCE INDEX (`index_name`)
WHERE (`conditions`)
ORDER BY `id` DESC
LIMIT 1;根据 主键 && 唯一键 排序, 全表条件查询可缩短至0.3s,增加条件筛选可在0.03左右查询结束
ORDER BY id,code DESC LIMIT 1
具体原因:
MessageQueue-面试题
为什么使用MQ
- 解耦
- 异步
- 削峰
MQ选型
Kafka：追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务，大型公司建议可以选用，如果有日志采集功能，肯定是首选 Kafka。
RocketMQ：天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。
RocketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ。
RabbitMQ：结合 erlang 语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护，不过 RabbitMQ 的社区十分活跃，可以解决开发过程中遇到的 bug。如果你的数据量没有那么大，小公司优先选择功能比较完备的 RabbitMQ。
ActiveMQ：官方社区现在对 ActiveMQ 5.x 维护越来越少，较少在大规模吞吐的场景中使用。
JAVA面试思路
通用问题
JAVA
提问走向 – 优点、缺点、匹配点
各自优缺点，项目为何选用某一种
List
ArrayList、LinkedList
Map
HashMap、LinkedHshMap、TreeMap、ConcurrentHashMap
JUC
GC
SQL
- CURD
- 多次Create
- 幂等性
- 批量Delete
- 如何删除大量数据，分批次？另起Job删？
- 并发Update
- 保证变更顺序，避免对账异常
- 海量Require
- 索引相关
- 多次Create
Middleware
Register
MQ
- 各自优缺点、为何选型
Cache
Config
Job
RPC
- 集群、分布式特性
- 集群
- 分布式
- CAP
- 不同Middleware复合CAP中的哪一部分，以及优缺点
SpringBoot如何与中间件集成
DesignPattern
Spring、Middleware使用哪些设计模式
是否Singleton
- 配置类一般是Singleton
是否线程安全
业务问题
业务量
UV – 独立访问量
PV
QPS
- 每小时最大UV / 3600 = QPS
TPS
访问量激增时如何搭建高并发系统
- 页面缓存
- Nginx Cache
- Load Balance
- Server Cache
- 读写DB
- 分库分表
链路
- 上下游
- 优化、重构
- 读多写少、写多读少
- 实时性要求
难点
- 思路
- 影响力
来源：
JVM-ZGC
JVM-G1
G1
G1垃圾收集器简介
Garbage First(简称:G1)收集器是垃圾收集器技术发展历史上的一个里程碑,它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式.
G1是一款主要面向服务端应用的垃圾收集器,HotSpot开发团队赋予它的期望是未来可以替换掉JDK5中发布的CMS收集器. JDK9发布之日,G1宣布取代了
Parallel Scavenge加Parallel Old的组合,成为服务端模式下默认的垃圾收集器,而CMS则被声明为(Deprecate)使用的收集器.G1收集器兼顾
低延迟和高吞吐在服务端运行,HotSpot团队期望取代CMS收集器。也就是在满足停顿时间的情况下获取最大的吞度量。有两种收集模式Young GC和Mixed GC。G1收集器将堆内存划分成大小相等的Region,新生代,老年代也就成了逻辑概念。整体上采用的是标记-整理算法,局部采用了复制算法。G1实现了可控停顿时间的垃圾收集器,通过
-XX:MaxGCPauseMillis参数进行设置，默认是200ms。G1是jdk1.9的默认垃圾收集器,-XX:+UseG1GC开启
