AQS

介绍：

• 用途：是并发包的一个基础组件，用来实现各种锁，各种同步组件。ReentrantLock就是用AQS实现的

  比如，Semaphore用它来表现剩余的许可数，ReentrantLock用它来表现拥有它的线程已经请求了多少次锁；FutureTask用它来表现任务的状态等。

  使用 AQS 来实现一个同步器需要覆盖实现如下几个方法，并且使用getState、setState和compareAndSetState这三个方法来操作状态。

• AQS全称：AbstractQueuedSynchrinizer，抽象队列同步器。

mysql主从复制原理：

1.从库生成两个线程，一个IO线程一个SQL线程

2.IO线程会去请求主库binlog，并将得到的binlog写到本地的relay-log（中继日志）文件中

3.主库会生成一个log dump线程，用来给从库IO线程传送binlog

4.SQL线程会读取relay-log文件中的日志，并解析成SQL逐一执行

一、分库分表

• 分库场景：如果数据库的查询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-堆排序查询慢

问题：

根据主键排序，获取一条时，查询异常缓慢，测试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

具体原因:

https://blog.csdn.net/wolfchenxing/article/details/88947577

为什么使用MQ

• 解耦
• 异步
• 削峰

MQ选型

Kafka：追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务，大型公司建议可以选用，如果有日志采集功能，肯定是首选 Kafka。

RocketMQ：天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。

RocketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ。

RabbitMQ：结合 erlang 语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护，不过 RabbitMQ 的社区十分活跃，可以解决开发过程中遇到的 bug。如果你的数据量没有那么大，小公司优先选择功能比较完备的 RabbitMQ。

ActiveMQ：官方社区现在对 ActiveMQ 5.x 维护越来越少，较少在大规模吞吐的场景中使用。

通用问题

JAVA

• 提问走向 – 优点、缺点、匹配点

  • 各自优缺点，项目为何选用某一种

    • List

      ArrayList、LinkedList

    • Map

      HashMap、LinkedHshMap、TreeMap、ConcurrentHashMap

    • JUC

    • GC

SQL

• CURD
  • 多次Create
    • 幂等性
  • 批量Delete
    • 如何删除大量数据，分批次？另起Job删？
  • 并发Update
    • 保证变更顺序，避免对账异常
  • 海量Require
    • 索引相关

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
  • 分库分表

链路

• 上下游
• 优化、重构
  • 读多写少、写多读少
  • 实时性要求

难点

• 思路
• 影响力

来源：

https://www.bilibili.com/video/BV1KU4y1L7JA

https://github.com/alibaba/spring-cloud-alibaba/issues/1909

https://rumenz.com/rumenbiji/jvm-zgc.html

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开启

CMS

ConcurrentMarkSweep（并发标记清除）

CMS垃圾收集器从jdk1.6中开始应用,是一个老年代垃圾收集器,在JVM的发展过程中扮演了重要的历史作用,jdk1.7,jdk1.8中都可以开启使用。在jdk9中已废弃。

垃圾收集器