2023年郑州春招3年开发面试总结

企业开发 2023-05-18 01:24:31 阅读次数: 0

MySQL必备知识

MySQL索引结构

介绍B树结构

首先，常规的数据库存储引擎，一般都是采用 B 树或者 B+树来实现索引的存储。 因为 B 树是一种多路平衡树，用这种存储结构来存储大量数据，它的整个高度 会相比二叉树来说，会矮很多。 而对于数据库来说，所有的数据必然都是存储在磁盘上的，而磁盘 IO 的效率实际上是很低的，特别是在随机磁盘 IO 的情况下效率更低。 所以树的高度能够决定磁盘 IO 的次数，磁盘 IO 次数越少，对于性能的提升就越大，这也是为什么采用 B 树作为索引存储结构的原因，但是在 Mysql 的 InnoDB 存储引擎里面，它用了一种增强的 B 树结构，也就是 B+树来作为索引和数据的存储结构。

B+树相比较与B树优化

B+树的所有数据都存储在叶子节点，非叶子节点只存储索引

1 B+树非叶子节点不存储数据，所以每一层能够存储的索引数量会增加，意味着 B+树在层高相同的情况下存储的数据量要比 B 树要多，使得磁盘 IO 次数更少。

2 在 Mysql 里面，范围查询是一个比较常用的操作，而 B+树的所有存储在叶子节点的数据使用了双向链表来关联，所以在查询的时候只需查两个节点进行遍历就行，而 B 树需要获取所有节点，所以 B+树在范围查询上效率更高。

3 基于 B+树这样一种结构，如果采用自增的整型数据作为主键，还能更好 的避免增加数据的时候，带来叶子节点分裂导致的大量运算的问题。

为什么不用二叉树

二叉树的话有一个问题，随着数据量越来越大，它会发生倾斜，就是斜树，不管是左倾斜还是右倾斜，编程一个线性表，树会退化成一个相对平坦的线性表结构。

为什么不用红黑树

红黑树是一颗平衡二叉树，数据量大的时候，树的深度也很深，如果树的深度有20层，而查找的数据在叶子节点，就要进行20次IO操作，性能低。

b树和b+树区别

节点存放数据的区别，B+树叶子结点，飞叶子节点，一个存放行记录具体数据，一个存放索引；

B树每个节点都会存放真实数据的，每页的数据量比较少，而且会造成一种现象，查询数据的时候，跟磁盘交互更多更频繁。

事务特性和隔离级别

首先，A 表示 Atomic 原子性，也就是需要保证多个 DML 操作是原子的，要么都成功，要么都失败。

那么，失败就意味着要对原本执行成功的数据进行回滚，所以 InnoDB 设计了一 个 UNDO_LOG 表，在事务执行的过程中，把修改之前的数据快照保存到

UNDO_LOG 里面，一旦出现错误，就直接从 UNDO_LOG 里面读取数据执行反 向操作就行了。

其次，C 表示一致性，表示数据的完整性约束没有被破坏，这个更多是依赖于业 务层面的保证，数据库本身也提供了一些，比如主键的唯一约束，字段长度和类型的保证等等。

接着，I 表示事务的隔离性，也就是多个并行事务对同一个数据进行操作的时候，如何避免多个事务的干扰导致数据混乱的问题。

而 InnoDB 提供了四种隔离级别的实现

RU（未提交读）

RC（已提交读）

RR（可重复读）

Serializable（串行化）

InnoDB 默认的隔离级别是 RR（可重复读），然后使用了 MVCC 机制解决了脏读和不可重复读的问题，然后使用了行锁/表锁的方式解决了幻读的问题。

最后一个是 D，表示持久性，也就是只要事务提交成功，那对于这个数据的结果的影响一定是永久性的。

理论上来说，事务提交之后直接把数据持久化到磁盘就行了，但是因为随机磁盘 IO 的效率确实很低，所以 InnoDB 设计了 Buffer Pool 缓冲区来优化，也就是数据发生变更的时候先更新内存缓冲区，然后在合适的时机再持久化到磁盘。 那在持久化这个过程中，如果数据库宕机，就会导致数据丢失，也就无法满足持久性了,所以 InnoDB 引入了 Redo_LOG 文件，这个文件存储了数据被修改之后的值， 当我们通过事务对数据进行变更操作的时候，除了修改内存缓冲区里面的数据以外，还会把本次修改的值追加到 REDO_LOG 里面。

当提交事务的时候，直接把 REDO_LOG 日志刷到磁盘上持久化，一旦数据库出 现宕机，在 Mysql 重启在以后可以直接用 REDO_LOG 里面保存的重写日志读 取出来，再执行一遍从而保证持久性。

MyISAM与InnoDB区别

理解：不同数据文件在磁盘的不同组织形式

事务处理：InnoDB支持事务，MyISAM不支持；我们业务一般都是需要可靠性要求的，基本上用的都是InnoDB,而MyISAM存储引擎适用于读多写少场景，类似于博客系统，

InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构） MyISAM是非聚集索引，也是使用B+Tree作为索引结构，索引和数据文件是分离的，索引保存的是数据文件的指针。

外键的支持：innodb有外键，myisam没有；

延伸

为什么只读场景myisam比innodb快

查询的时候，由于innodb支持事务，所以会有mvcc的一个比较。这个过程会损耗性能。
查询的时候，如果走了索引，而索引又不是主键索引，此时，由于innodb是聚簇索引，会有一个回表的过程，即：先去非聚簇索引树（非主键索引树）中查询数据，找到数据对应的key之后，再通过key回表到聚簇索引树，最后找到需要的数据。而myisam是非聚集索引，而且叶子节点存储的是磁盘地址，所以，查询的时候查到的最后结果不是聚簇索引树的key，而是会直接去查询磁盘。
其次，锁的一个损耗，innodb锁支持行锁，在检查锁的时候不仅检查表锁，还要看行锁。

常见的事务有哪些问题

脏读，不可重复读，幻读

脏读：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

不可重复读：是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。

幻读：是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

buffer pool如何理解

buffer pool是个缓冲池，在进行数据更新时候，MySQL 不会直接去修改磁盘的数据，因为这样做太慢了，MySQL 会先改内存，然后记录 redo log，等有空了再刷磁盘，如果内存里没有数据，就去磁盘 load；而这些数据存放的地方，就是 Buffer Pool。

我们平时开发时，会用 redis 来做缓存，缓解数据库压力，其实 MySQL 自己也做了一层类似缓存的东西。

MySQL 是以「页」（page）为单位从磁盘读取数据的，Buffer Pool 里的数据也是如此，实际上，Buffer Pool 是a linked list of pages，一个以页为元素的链表。

谈谈对MySQL日志的理解

binlog用于记录数据库执行的写入性操作，以二进制的形式保存在磁盘中。binlog 是 mysql的逻辑日志（可以理解为是sql语句的二进制存储），并且由 Server 层进行记录，使用任何存储引擎的 mysql 数据库都会记录 binlog 日志。在实际应用中， binlog 的主要使用场景有两个，分别是 主从复制 和 数据恢复 。

​ redo log 包括两部分：一个是内存中的日志缓冲( redo log buffer )，另一个是磁盘上的日志文件( redo log file )。mysql 每执行一条 DML 语句，先将记录写入 redo log buffer，后续某个时间点再一次性将多个操作记录写到 redo log file 。这种 先写日志，再写磁盘 的技术就是 MySQL里经常说到的 WAL(Write-Ahead Loggin``g) 技术。

​ 数据库事务四大特性中有一个是 原子性 ，具体来说就是 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。实际上， 原子性 底层就是通过 undo log 实现的。undo log 主要记录了数据的逻辑变化，比如一条 INSERT 语句，对应一条 DELETE 的 undo log ，对于每个 UPDATE 语句，对应一条相反的 UPDATE 的 undo log ，这样在发生错误时，就能回滚到事务之前的数据状态。

说说行锁与表锁

行锁：操作时只锁某一（些）行，不对其它行有影响。开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高。

表锁：即使操作一条记录也会锁住整个表。开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突概率高，并发度最低。

页锁：操作时锁住一页数据（16kb）。开销和加锁速度介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般。

InnoDB 有行锁和表锁，MyIsam 只有表锁。

说说读锁和写锁

从数据操作的类型划分，可以分为读锁和写锁，读锁也叫共享锁（S)，写锁也叫排他锁（X)

读锁：针对同一份数据，多个事务的读操作可以同时进行互不影响，相互不阻塞

写锁：也叫排他锁，英文为（X)，针对同一份数据，只能有一个事务（事务A)进行操作，其他事务（事务B）阻塞，不能读，也不能写，只有等事务A执行完毕，事务B等其他事务才能进行操作。

在Innodb中，读锁和写锁可以加载表上，也可以加在行上（行锁和表锁）

数据库锁，到底锁的是什么

Record Lock表示记录锁，锁的是索引记录。

Record Lock，翻译成记录锁，是加在索引记录上的锁。例如，SELECT c1 FROM t WHERE c1 = 10 For UPDATE;会对c1=10这条记录加锁，为了防止任何其他事务插入、更新或删除c1值为10的行。

需要特别注意的是，记录锁锁定的是索引记录。即使表没有定义索引，InnoDB也会创建一个隐藏的聚集索引，并使用这个索引来锁定记录。

Gap Lock是间隙锁，说的是索引记录之间的间隙。

Gap指的是InnoDB的索引数据结构中可以插入新值的位置。当你用语句SELECT…FOR UPDATE锁定一组行时。InnoDB可以创建锁，应用于索引中的实际值以及他们之间的间隙。例如，如果选择所有大于10的值进行更新，间隙锁将阻止另一个事务插入大于10的新值。

Next-Key Lock是Record Lock和Gap Lock的组合，同时锁索引记录和间隙。他的范围是左开右闭的。

这三种锁都是自动添加的。

InnoDB的RR级别中，加锁的基本单位是 next-key lock，只要扫描到的数据都会加锁。唯一索引上的范围查询会访问到不满足条件的第一个值为止。

MVCC机制如何理解

简单来说，MVCC就是存储了同一条数据的不同历史版本链，不同事务可以访问不同的数据版本。

相关的概念

1、事务版本号

事务每次开启时，都会从数据库获得一个自增长的事务ID，可以从事务ID判断事务的执行先后顺序。这就是事务版本号。

也就是每当begin的时候,首选要做的就是从数据库获得一个自增长的事务ID,它也就是当前事务的事务ID。

2、隐藏字段

对于InnoDB存储引擎，每一行记录都有两个隐藏列trx_id、roll_pointer,如果数据表中存在主键或者非NULL的UNIQUE键时不会创建row_id,否则InnoDB会自动生成单调递增的隐藏主键row_id。

列名 是否必须 描述
row_id 否 单调递增的行ID，不是必需的，占用6个字节。 这个跟MVCC关系不大
trx_id 是 记录操作该行数据事务的事务ID
roll_pointer 是 回滚指针，指向当前记录行的undo log信息

这里的记录操作，指的是insert|update|delete。对于delete操作而已，InnoDB认为是一个update操作，不过会更新一个另外的删除位，将行表示为deleted,并非真正删除。

3、undo log

undo log可以理解成回滚日志,它存储的是老版本数据。在表记录修改之前，会先把原始数据拷贝到undo log里，如果事务回滚，即可以通过undo log来还原数据。或者如果当前记录行不可见，可以顺着undo log链找到满足其可见性条件的记录行版本。

在insert/update/delete(本质也是做更新，只是更新一个特殊的删除位字段)操作时，都会产生undo log。

在InnoDB里，undo log分为如下两类：

1）insert undo log : 事务对insert新记录时产生的undo log, 只在事务回滚时需要, 并且在事务提交后就可以立即丢弃。

2）update undo log : 事务对记录进行delete和update操作时产生的undo log，不仅在事务回滚时需要，快照读也需要，只有当数据库所使用的快照中不涉及该日志记录，对应的回滚日志才会被删除。

undo log有什么用途呢？

1、事务回滚时，保证原子性和一致性。
2、如果当前记录行不可见，可以顺着undo log链找到满足其可见性条件的记录行版本(用于MVCC快照读)。

4、版本链

多个事务并行操作某一行数据时，不同事务对该行数据的修改会产生多个版本，然后通过回滚指针（roll_pointer），连成一个链表，这个链表就称为版本链。如下：

img

5、快照读和当前读

快照读： 读取的是记录数据的可见版本（有旧的版本）。不加锁,普通的select语句都是快照读,如：

select * from user where id = 1;

当前读：读取的是记录数据的最新版本，显式加锁的都是当前读

select * from user where id = 1 for update;
select * from user where id = 1 lock in share mode;

6、ReadView

ReadView是事务在进行快照读的时候生成的记录快照, 可以帮助我们解决可见性问题的

如果一个事务要查询行记录，需要读取哪个版本的行记录呢？ ReadView 就是来解决这个问题的。 ReadView 保存了当前事务开启时所有活跃的事务列表。换个角度，可以理解为: ReadView 保存了不应该让这个事务看到的其他事务 ID 列表。

ReadView是如何保证可见性判断的呢？我们先看看 ReadView 的几个重要属性

  • trx_ids: 当前系统中那些活跃(未提交)的读写事务ID, 它数据结构为一个List。(重点注意:这里的trx_ids中的活跃事务，不包括当前事务自己和已提交的事务，这点非常重要)
  • low_limit_id: 目前出现过的最大的事务ID+1，即下一个将被分配的事务ID。
  • up_limit_id: 活跃事务列表trx_ids中最小的事务ID，如果trx_ids为空，则up_limit_id 为 low_limit_id。
  • creator_trx_id: 表示生成该 ReadView 的事务的事务id

访问某条记录的时候如何判断该记录是否可见,具体规则如下：

  • 如果被访问版本的 事务ID = creator_trx_id，那么表示当前事务访问的是自己修改过的记录，那么该版本对当前事务可见；
  • 如果被访问版本的 事务ID < up_limit_id，那么表示生成该版本的事务在当前事务生成 ReadView 前已经提交，所以该版本可以被当前事务访问。
  • 如果被访问版本的 事务ID > low_limit_id 值，那么表示生成该版本的事务在当前事务生成 ReadView 后才开启，所以该版本不可以被当前事务访问。
  • 如果被访问版本的 事务ID在 up_limit_id和m_low_limit_id 之间，那就需要判断一下版本的事务ID是不是在 trx_ids 列表中，如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问；
    如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

画张图来理解下

img

这里需要思考的一个问题就是 何时创建ReadView？

上面说过,ReadView是来解决一个事务需要读取哪个版本的行记录的问题的。那么说明什么？只有在select的时候才会创建ReadView。但在不同的隔离级别是有区别的:

在RC隔离级别下，是每个select都会创建最新的ReadView；而在RR隔离级别下，则是当事务中的第一个select请求才创建ReadView(下面会详细举例说明)。

那insert/update/delete操作呢？

这样操作不会创建ReadView。但是这些操作在事务开启(begin)且其未提交的时候，那么它的事务ID,会存在在其它存在查询事务的ReadView记录中，也就是trx_ids中。

查询流程

  1. 获取事务自己事务ID,即trx_id。(这个也不是select的时候获取的，而是这个事务开启的时候获取的 也就是begin的时候)
  2. 获取ReadView(这个才是select的时候才会生成的)
  3. 数据库表中如果查询到数据，那就到ReadView中的事务版本号进行比较。
  4. 如果不符合ReadView的可见性规则， 即就需要Undo log中历史快照,直到返回符合规则的数据;

InnoDB 实现MVCC，是通过ReadView+ Undo Log 实现的，Undo Log 保存了历史快照，ReadView可见性规则帮助判断当前版本的数据是否可见。

总结

简单来说，MVCC就是存储了同一条数据的不同历史版本链，不同事务可以访问不同的数据版本。

1 事务版本号：也就是每当begin的时候,首选要做的就是从数据库获得一个自增长的事务ID,它也就是当前事务的事务ID。回滚指针roll_pointer：指向当前记录行的undo log信息

2 版本链：多个事务并行操作某一行数据时，不同事务对该行数据的修改会产生多个版本，然后通过回滚指针（roll_pointer），连成一个链表，这个链表就称为版本链

3 快照读：读取的是记录数据的可见版本（有旧的版本）。不加锁,普通的select语句都是快照读；当前读：读取的是记录数据的最新版本，显式加锁的都是当前读

4 ReadView：是事务在进行快照读的时候生成的记录快照, 可以帮助我们解决可见性问题的

5 undo log：保存了历史快照

流程

  1. 获取事务自己事务ID,即trx_id。(这个也不是select的时候获取的，而是这个事务开启的时候获取的 也就是begin的时候)
  2. 获取ReadView(这个才是select的时候才会生成的)
  3. 数据库表中如果查询到数据，那就到ReadView中的事务版本号进行比较。
  4. 如果不符合ReadView的可见性规则， 即就需要Undo log中历史快照,直到返回符合规则的数据;

什么是回表查询

InnoDB 中，对于主键索引，只需要走一遍主键索引的查询就能在叶子节点拿到数据。

而对于普通索引，叶子节点不存储行记录，无法直接定位行记录，需要扫描两次索引树，先定位主键值，通过主键索引找到行记录，再定位行记录。

什么是索引下推

概念：索引下推是把本应该在 server 层进行筛选的条件，下推到存储引擎层来进行筛选判断，这样能有效减少回表。

举例说明：

首先使用联合索引（name，age），现在有这样一个查询语句：

select *  from t_user where name like 'L%' and age = 17;

这条语句从最左匹配原则上来说是不符合的，原因在于只有name用的索引，但是age并没有用到。

不用索引下推的执行过程：

第一步：利用索引找出name带'L'的数据行：LiLei、Lili、Lisa、Lucy 这四条索引数据
第二步：再根据这四条索引数据中的 id 值，逐一进行回表扫描，从聚簇索引中找到相应的行数据，将找到的行数据返回给 server 层。
第三步：在server层判断age = 17,进行筛选，最终只留下 Lucy 用户的数据信息。

使用索引下推的执行过程：

第一步：利用索引找出name带'L'的数据行：LiLei、Lili、Lisa、Lucy 这四条索引数据
第二步：根据 age = 17 这个条件，对四条索引数据进行判断筛选，最终只留下 Lucy 用户的数据信息。
（注意：这一步不是直接进行回表操作，而是根据 age = 17 这个条件，对四条索引数据进行判断筛选）
第三步：将符合条件的索引对应的 id 进行回表扫描，最终将找到的行数据返回给 server 层。

比较二者的第二步我们发现，索引下推的方式极大的减少了回表次数。

索引下推需要注意的情况：

下推的前提是索引中有 age 列信息，如果是其它条件，如 gender = 0，这个即使下推下来也没用

开启索引下推：

索引下推是 MySQL 5.6 及以上版本上推出的，用于对查询进行优化。默认情况下，索引下推处于启用状态。我们可以使用如下命令来开启或关闭。

set optimizer_switch='index_condition_pushdown=off';  -- 关闭索引下推
set optimizer_switch='index_condition_pushdown=on';  -- 开启索引下推

为什么需要二阶段提交

场景描述

如果没有两阶段提交，那么 binlog 和 redolog 的提交，无非就是两种形式：

先写 binlog 再写 redolog。
先写 redolog 再写 binlog。
这两种情况我们分别来看。

假设我们要向表中插入一条记录 R，如果是先写 binlog 再写 redolog，那么假设 binlog 写完后崩溃了，此时 redolog 还没写。那么重启恢复的时候就会出问题：binlog 中已经有 R 的记录了，当从机从主机同步数据的时候或者我们使用 binlog 恢复数据的时候，就会同步到 R 这条记录；但是 redolog 中没有关于 R 的记录，所以崩溃恢复之后，插入 R 记录的这个事务是无效的，即数据库中没有该行记录，这就造成了数据不一致。

相反，假设我们要向表中插入一条记录 R，如果是先写 redolog 再写 binlog，那么假设 redolog 写完后崩溃了，此时 binlog 还没写。那么重启恢复的时候也会出问题：redolog 中已经有 R 的记录了，所以崩溃恢复之后，插入 R 记录的这个事务是有效的，通过该记录将数据恢复到数据库中；但是 binlog 中还没有关于 R 的记录，所以当从机从主机同步数据的时候或者我们使用 binlog 恢复数据的时候，就不会同步到 R 这条记录，这就造成了数据不一致。

那么按照前面说的两阶段提交就能解决问题吗？

我们来看如下三种情况：

情况一： redo log时候崩溃了，此时：

由于 binlog 还没写，redo log 处于 prepare 状态还没提交，所以崩溃恢复的时候，这个事务会回滚，此时 binlog 还没写，所以也不会传到备库。

**情况二：**假设写完 binlog 之后崩溃了，此时：

redolog 中的日志是不完整的，处于 prepare 状态，还没有提交，那么恢复的时候，首先检查 binlog 中的事务是否存在并且完整，如果存在且完整，则直接提交事务，如果不存在或者不完整，则回滚事务。

**情况三：**假设 redolog 处于 commit 状态的时候崩溃了，那么重启后的处理方案同情况二。

由此可见，两阶段提交能够确保数据的一致性。

为什么innodb表必须创建主键，并且使用整形的自增主键

InnoDB中采用的是聚簇索引，表数据文件本身就是按照B+Tree组织的一个索引结构文件，主键索引默认就是B+Tree，由此主键索引可以维护整张表。如果在实际建表过程中不建立主键，MySQL会自动在表中找一列数据（该列数据没有重复值）来建立唯一索引，在B+tree中维护整张表的数据。

整型比大小更快，整型对于UUID来说占用存储空间小。

用自增方便每次插入到叶子节点链的后面，对于B+树的分裂来说更加方便。如果不用自增的话，有可能插入到叶子节点的中间位置，对于B+树的分裂来说不太方便。主要影响数据写入表的性能。

如何处理线上慢SQL

1、通过相关指令开启慢查询日志

-- 查看是否开启了慢查询日志
show variables like 'slow_query_log';
-- 默认是OFF，不开启，可以手动开启
-- 方式一 set global slow_query_log=1;
--  修改配置文件my.cnf，加入下面一行命令 slow_query_log = ON

2、慢查询日志找到对应的SQL，分析SQL

-- 查询慢查询日志文件路径
show variables like '%slow_query_log_file%';
-- MySQL提供了分析慢查询日志的工具mysqldumpslow
mysqldumpslow -s t -t 10 /usr/local/mysql/data/localhost_slow.log

-- 例如 ，休眠20s
SELECT sleep(20); 

常用参数有 -s: 表示按何种方式排序：　　c: 访问次数　　l: 锁定时间　　r: 返回记录　　t: 查询时间　　al: 平均锁定时间　　ar: 平均返回记录数　　at: 平均查询时间-t: 返回前面多少条的数据

3、where条件单表查，锁定最小返回记录表。这句话的意思是把查询语句的where都应用到表中返回的记录数最小的表开始查起，单表每个字段分别查询，看哪个字段的区分度最高

看一下accurate_result = 1的记录数：

select count(*),accurate_result from stage_poi  group by accurate_result;
+----------+-----------------+
| count(*) | accurate_result |
+----------+-----------------+
|     1023 |              -1 |
|  2114655 |               0 |
|   972815 |               1 |
+----------+-----------------+

我们看到accurate_result这个字段的区分度非常低，整个表只有-1,0,1三个值，加上索引也无法锁定特别少量的数据。

4、explain查看执行计划，是否与1预期一致（从锁定记录较少的表开始查询 ）

索引是否应用，联合索引是否完全应用，扫描行数rows

explain select * from a;

explain select * from b;

5、了解业务应用场景，实时数据，历史数据，定期删除等因素,辅助我们更好的分析和优化查询语句

6、加索引时参照建索引的几大原则

最左匹配原则

区分度高的列作为索引，count(distinct name)/count(*),表示字段不重复的比例，比例越大扫描记录越少

索引失效情况

尽量扩展索引，不要新建索引

7、mysqldumpslow

使用帮助

-s ORDER     what to sort by (al, at, ar, c, l, r, t), 'at' is default # 默认是at 平均查询时间
                al: average lock time
                ar: average rows sent
                at: average query time
                 c: count
                 l: lock time
                 r: rows sent
                 t: query time  # 查询时间排序
-r           reverse the sort order (largest last instead of first) # 反转排序顺序 
-t n  just show the top n queries # 仅仅显示前n行

实践

mysqldumpslow -s t -t 10 localhost-slow.log

总结

1 根据命令mysqldumpslow找到慢查询时间耗时比较长的SQL

2 explain查看执行计划，需要重点关注 type索引是否应用，联合索引是否完全应用，扫描行数rows

3 加索引时参照建索引的几大原则

3.1 最左匹配原则

3.2 区分度高的列作为索引，count(distinct name)/count(*),表示字段不重复的比例，比例越大扫描记录越少

3.3 索引失效情况

3.4 尽量扩展索引，不要新建索引

4 了解业务应用场景，实时数据，历史数据，定期删除等因素,辅助我们更好的分析和优化查询语句

MySQL调优

1 加索引

增加索引是一种简单搞笑的手段，但是需要选择合适的列，同时避免导致索引失效的操作，比如like，函数等。

2 避免返回不必要的数据列，减少返回的数据列可以增加查询效率

3 根据执行计划适当优化SQL结构，比如是否全表扫描，避免子查询等问题

4 分库分表

在单表数据量比较大时候或者并发连接数过多，通过这种方式提高查询效率

5 读写分离

讲一下MySQL死锁，如何解决排查

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。

常见的解决死锁的方法

1、如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。

2、在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；

3、对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；

如果业务处理不好可以用分布式事务锁或者使用乐观锁

如何查看死锁

使用命令show engine innodb status查看最近一次出现的死锁。
还可以使用Innodb Lock Monitor 打开监控，每15s输出一次日志。 使用完后建议关闭，会影响性能。

如何处理死锁

  1. 通过Innodbblockwait_timeout 来设置超时时间，一直等待直到超时。
  2. 发起死锁检测，发现死锁后，主动回滚到死锁中的某一事务，让其他事务继续执行。

innodb如何解决幻读

事务隔离级别

Mysql 有四种事务隔离级别，这四种隔离级别代表当存在多个事务并发冲突时，

可能出现的脏读、不可重复读、幻读的问题。

其中 InnoDB 在 RR 的隔离级别下，解决了幻读的问题

幻读

那么，什么是幻读呢？

幻读是指在同一个事务中，前后两次查询相同的范围时，得到的结果不一致

第一个事务里面我们执行了一个范围查询，这个时候满足条件的数据只有一条

第二个事务里面，它插入了一行数据，并且提交了

接着第一个事务再去查询的时候，得到的结果比第一查询的结果多出来了一条数

据。

如何解决

InnoDB 引入了间隙锁和 next-key Lock 机制来解决幻读问题，为了更清晰的说明这两种锁，

我举一个例子： 假设现在存在这样这样一个 B+Tree 的索引结构，这个结构中有四个索引元素分 别是：1、4、7、10。

当我们通过主键索引查询一条记录，并且对这条记录通过 for update 加锁

这个时候，会产生一个记录锁，也就是行锁，锁定 id=1 这个索引

被锁定的记录在锁释放之前，其他事务无法对这条记录做任何操作。

前面我说过对幻读的定义：幻读是指在同一个事务中，前后两次查询相同的范围时，得到的结果不一致！ 注意，这里强调的是范围查询， 也就是说，InnoDB 引擎要解决幻读问题，必须要保证一个点，就是如果一个事务通过这样一条语句进行锁定时，另外一个事务再执行这样一条 insert 语句，需要被阻塞，直到前面获得锁的事务释放；所以，在 InnoDB 中设计了一种间隙锁，它的主要功能是锁定一段范围内的索引。

记录当对查询范围 id>4 and id<7 加锁的时候，会针对 B+树中（4，7）这个开区间范

围的索引加间隙锁。 意味着在这种情况下，其他事务对这个区间的数据进行插入、更新、删除都会被

锁住。

但是，还有另外一种情况，比如像这样这条查询语句是针对 id>4 这个条件加锁，那么它需要锁定多个索引区间，所以

在这种情况下 InnoDB 引入了 next-key Lock 机制。

next-key Lock 相当于间隙锁和记录锁的合集，记录锁锁定存在的记录行，间隙

锁锁住记录行之间的间隙，而 next-key Lock 锁住的是两者之和每个数据行上的非唯一索引列上都会存在一把 next-key lock，当某个事务持有该数

据行的 next-key lock 时，会锁住一段左开右闭区间的数据。

因此，当通过 id>4 这样一种范围查询加锁时，会加 next-key Lock，锁定的区间

范围是：(4,7],(7,10],(10,+∞]，间隙锁和 next-key Lock 的区别在于加锁的范围，间隙锁只锁定两个索引之间的引用间隙，而 next-key Lock 会锁定多个索引区间，它包含记录锁和间隙锁。

总结

虽然 InnoDB 中通过间隙锁的方式解决了幻读问题，但是加锁之后一定会影响到 并发性能，因此，如果对性能要求较高的业务场景中，可以把隔离级别设置成 RC(读已提交)，这个级别中不存在间隙锁

乐观锁和悲观锁了解

乐观锁

顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。

如何实现乐观锁

第一种方案
通过 数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将 version 字段的值一同读出，数据每更新一次，对此 version 值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的 version 值进行比对，如果数据库表当前版本号与第一次取出来的 version 值相等，则予以更新，否则认为是过期数据，如果更新失败则说明是重复请求，直接异常中断或者查询出上次执行的结果数据返回即可。

第二种方案
在需要乐观锁控制的 table 中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的 version 类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则 OK，否则就是版本冲突。

应用场景

比如A、B操作员同时读取一余额为1000元的账户，A操作员为该账户增加100元，B操作员同时为该账户扣除50元，A先提交，B后提交。最后实际账户余额为1000-50=950元，但本该为1000+100-50=1050。这就是典型的并发问题。

悲观锁

对于并发间操作产生的线程安全问题持悲观状态，悲观锁认为竞争总是会发生，因此每次对某资源进行操作时，都会持有一个独占的锁，然后再操作资源。

悲观锁采用的是「先获取锁再访问」的策略，来保障数据的安全。但是加锁策略，依赖数据库实现，会增加数据库的负担，且会增加死锁的发生几率。此外，对于不会发生变化的只读数据，加锁只会增加额外不必要的负担。在实际的实践中，对于并发很高的场景并不会使用悲观锁，因为当一个事务锁住了数据，那么其他事务都会发生阻塞，会导致大量的事务发生积压拖垮整个系统。

场景

在商品购买场景中，当有多个用户对某个库存有限的商品同时进行下单操作。若采用先查询库存，后减库存的方式进行库存数量的变更，将会导致超卖的产生。

若使用悲观锁，当B用户获取到某个商品的库存数据时，用户A则会阻塞，直到B用户完成减库存的整个事务时，A用户才可以获取到商品的库存数据。则可以避免商品被超卖。

初始化表结构和数据
CREATE TABLE `tbl_user` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `status` int(11) DEFAULT NULL,
  `name` varchar(255) COLLATE utf8_bin DEFAULT NULL,
  PRIMARY KEY (`id`)
);


INSERT INTO `tbl_user` (`id`, `status`, `name`)
VALUES
    (1,1,X'7469616E'),
    (2,1,X'63697479');
事务操作

窗口1

// 关闭mysql数据库的自动提交属性
set autocommit=0;

// 开启事务
BEGIN;

SELECT * FROM tbl_user where id=1 for update;

窗口2

SELECT * FROM tbl_user where id=1 for update;

image-20211214200901760

如何使用

如何使用悲观锁

用法：SELECT … FOR UPDATE;

如下操作

select * from tbl_user where id=1 for update;

获取锁的前提：结果集中的数据没有使用排他锁或共享锁时，才能获取锁，否则将会阻塞。

需要注意的是， FOR UPDATE 生效需要同时满足两个条件时才生效：

  • 数据库的引擎为 innoDB
  • 操作位于事务块中（BEGIN/COMMIT）

InnoDB 四大特性或者如何设计的

插入缓冲（insert buffer）

索引是存储在磁盘上的，所以对于索引的操作需要涉及磁盘操作。如果我们使用自增主键，那么在插入主键索引（聚簇索引）时，只需不断追加即可，不需要磁盘的随机 I/O。但是如果我们使用的是普通索引，大概率是无序的，此时就涉及到磁盘的随机 I/O，而随机I/O的性能是比较差的（Kafka 官方数据：磁盘顺序I/O的性能是磁盘随机I/O的4000~5000倍）。

因此，InnoDB 存储引擎设计了 Insert Buffer ，对于非聚集索引的插入或更新操作，不是每一次直接插入到索引页中，而是先判断插入的非聚集索引页是否在缓冲池（Buffer pool）中，若在，则直接插入；若不在，则先放入到一个 Insert Buffer 对象中，然后再以一定的频率和情况进行 Insert Buffer 和辅助索引页子节点的 merge（合并）操作，这时通常能将多个插入合并到一个操作中（因为在一个索引页中），这就大大提高了对于非聚集索引插入的性能。

插入缓冲的使用需要满足以下两个条件：1）索引是辅助索引；2）索引不是唯一的。

二次写（double write）：

脏页刷盘风险：InnoDB 的 page size一般是16KB，操作系统写文件是以4KB作为单位，那么每写一个 InnoDB 的 page 到磁盘上，操作系统需要写4个块。于是可能出现16K的数据，写入4K 时，发生了系统断电或系统崩溃，只有一部分写是成功的，这就是 partial page write（部分页写入）问题。这时会出现数据不完整的问题。

这时是无法通过 redo log 恢复的，因为 redo log 记录的是对页的物理修改，如果页本身已经损坏，重做日志也无能为力。

doublewrite 就是用来解决该问题的。doublewrite 由两部分组成，一部分为内存中的 doublewrite buffer，其大小为2MB，另一部分是磁盘上共享表空间中连续的128个页，即2个区(extent)，大小也是2M。

为了解决 partial page write 问题，当 MySQL 将脏数据刷新到磁盘的时候，会进行以下操作：

1）先将脏数据复制到内存中的 doublewrite buffer

2）之后通过 doublewrite buffer 再分2次，每次1MB写入到共享表空间的磁盘上（顺序写，性能很高）

3）完成第二步之后，马上调用 fsync 函数，将doublewrite buffer中的脏页数据写入实际的各个表空间文件（离散写）。

如果操作系统在将页写入磁盘的过程中发生崩溃，InnoDB 再次启动后，发现了一个 page 数据已经损坏，InnoDB 存储引擎可以从共享表空间的 doublewrite 中找到该页的一个最近的副本，用于进行数据恢复了。

自适应哈希索引(adaptive hash index）

哈希（hash）是一种非常快的查找方法，一般情况下查找的时间复杂度为 O(1)。但是由于不支持范围查询等条件的限制，InnoDB 并没有采用 hash 索引，但是如果能在一些特殊场景下使用 hash 索引，则可能是一个不错的补充，而 InnoDB 正是这么做的。

具体的，InnoDB 会监控对表上索引的查找，如果观察到某些索引被频繁访问，索引成为热数据，建立哈希索引可以带来速度的提升，则建立哈希索引，所以称之为自适应（adaptive）的。自适应哈希索引通过缓冲池的 B+ 树构造而来，因此建立的速度很快。而且不需要将整个表都建哈希索引，InnoDB 会自动根据访问的频率和模式来为某些页建立哈希索引。

预读（read ahead）：

InnoDB 在 I/O 的优化上有个比较重要的特性为预读，当 InnoDB 预计某些 page 可能很快就会需要用到时，它会异步地将这些 page 提前读取到缓冲池（buffer pool）中，这其实有点像空间局部性的概念。

空间局部性（spatial locality）：如果一个数据项被访问，那么与他地址相邻的数据项也可能很快被访问。

InnoDB使用两种预读算法来提高I/O性能：线性预读（linear read-ahead）和随机预读（randomread-ahead）。

其中，线性预读以 extent（块，1个 extent 等于64个 page）为单位，而随机预读放到以 extent 中的 page 为单位。线性预读着眼于将下一个extent 提前读取到 buffer pool 中，而随机预读着眼于将当前 extent 中的剩余的 page 提前读取到 buffer pool 中。

线性预读（Linear read-ahead）：线性预读方式有一个很重要的变量 innodb_read_ahead_threshold，可以控制 Innodb 执行预读操作的触发阈值。如果一个 extent 中的被顺序读取的 page 超过或者等于该参数变量时，Innodb将会异步的将下一个 extent 读取到 buffer pool中，innodb_read_ahead_threshold 可以设置为0-64（一个 extend 上限就是64页）的任何值，默认值为56，值越高，访问模式检查越严格。

随机预读（Random read-ahead）: 随机预读方式则是表示当同一个 extent 中的一些 page 在 buffer pool 中发现时，Innodb 会将该 extent 中的剩余 page 一并读到 buffer pool中，由于随机预读方式给 Innodb code 带来了一些不必要的复杂性，同时在性能也存在不稳定性。

数据库数据量有多少

2000万

聚集索引、辅助索引、覆盖索引、联合索引的使用

聚集索引就是按照每张表的主键构造一棵B+树，同时叶子节点中存放的即为整张表的行记录数据。

辅助索引，也叫非聚集索引。和聚集索引相比，叶子节点中并不包含行记录的全部数据。叶子节点除了包含键值以外，每个叶子节点的索引行还包含了一个书签（bookmark），该书签用来告诉InnoDB哪里可以找到与索引相对应的行数据。

InnoDB存储引擎支持覆盖索引，即从辅助索引中就可以得到查询的记录，而不需要查询聚集索引中的记录。

如果要查询辅助索引中不含有的字段，得先遍历辅助索引，再遍历聚集索引，而如果要查询的字段值在辅助索引上就有，就不用再查聚集索引了，这显然会减少IO操作。

联合索引是指对表上的多个列进行索引。

聚集索引的叶子节点称为数据页，每个数据页通过一个双向链表来进行链接，而且数据页按照主键的顺序进行排列。

每个数据页上存放的是完整的行记录，而在非数据页的索引页中，存放的仅仅是键值及指向数据页的偏移量，而不是一个完整的行记录。

分库分表

主要是对两个方法进行拦截，一个query方法，一个是update方法
那么对这两个方法进行拦截，并且在这个接口上面实现这个或者
自定义的这个注解Annotation，通过反射拿到这个接口的注解
根据注解的参数来分表操作，再去修改原来这个SQL这个执行结果
按照年份来划分的，这个是按照业务场景来划分的，也可以根据id取模。

Redis必备知识

SDS了解吗

背景

Redis 是用 C 语言实现的，但是它没有直接使用 C 语言的 char* 字符数组来实现字符串，而是自己封装了一个名为简单动态字符串（simple dynamic string，SDS） 的数据结构来表示字符串，也就是 Redis 的 String 数据类型的底层数据结构是 SDS。

c语言字符串缺陷

C 语言的字符串其实就是一个字符数组，即数组中每个元素是字符串中的一个字符。

1 在 C 语言里，对字符串操作时，char * 指针只是指向字符数组的起始位置，而字符数组的结尾位置就用“\0”表示，意思是指字符串的结束。

举个例子，C 语言获取字符串长度的函数 strlen，就是通过字符数组中的每一个字符，并进行计数，等遇到字符为“\0”后，就会停止遍历，然后返回已经统计到的字符个数，即为字符串长度

C 语言的字符串用 “\0” 字符作为结尾标记有个缺陷。假设有个字符串中有个 “\0” 字符，这时在操作这个字符串时就会提早结束，比如 “xiao\0lin” 字符串，计算字符串长度的时候则会是 4

2 用 char* 字符串中的字符必须符合某种编码（比如ASCII）。这些限制使得 C 语言的字符串只能保存文本数据，不能保存像图片、音频、视频文化这样的二进制数据

3 C 语言标准库中字符串的操作函数是很不安全的，对程序员很不友好，稍微一不注意，就会导致缓冲区溢出。

举个例子，strcat 函数是可以将两个字符串拼接在一起。

c //将 src 字符串拼接到 dest 字符串后面 char *strcat(char *dest, const char* src);

C 语言的字符串是不会记录自身的缓冲区大小的，所以 strcat 函数假定程序员在执行这个函数时，已经为 dest 分配了足够多的内存，可以容纳 src 字符串中的所有内容，而一旦这个假定不成立，就会发生缓冲区溢出将可能会造成程序运行终止，（*这是一个可以改进的地方*）。

而且，strcat 函数和 strlen 函数类似，时间复杂度也很高，也都需要先通过遍历字符串才能得到目标字符串的末尾。然后对于 strcat 函数来说，还要再遍历源字符串才能完成追加，对字符串的操作效率不高。

sds结构设计

图片

结构中的每个成员变量分别介绍下：

  • len，SDS 所保存的字符串长度。这样获取字符串长度的时候，只需要返回这个变量值就行，时间复杂度只需要 O（1）。
  • alloc，分配给字符数组的空间长度。这样在修改字符串的时候，可以通过 alloc - len 计算 出剩余的空间大小，然后用来判断空间是否满足修改需求，如果不满足的话，就会自动将 SDS 的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用 SDS 既不需要手动修改 SDS 的空间大小，也不会出现前面所说的缓冲区益处的问题。
  • flags，SDS 类型，用来表示不同类型的 SDS。一共设计了 5 种类型，分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64，后面在说明区别之处。
  • buf[]，字节数组，用来保存实际数据。不需要用 “\0” 字符来标识字符串结尾了，而是直接将其作为二进制数据处理，可以用来保存图片等二进制数据。它即可以保存文本数据，也可以保存二进制数据，所以叫字节数组会更好点。

总的来说，Redis 的 SDS 结构在原本字符数组之上，增加了三个元数据：len、alloc、flags，用来解决 C 语言字符串的缺陷。

优势
O（1）复杂度获取字符串长度

Redis 的 SDS 结构因为加入了 len 成员变量，那么获取字符串长度的时候，直接返回这个变量的值就行，所以复杂度只有 O（1）

二进制安全

因为 SDS 不需要用 “\0” 字符来标识字符串结尾了，而且 SDS 的 API 都是以处理二进制的方式来处理 SDS 存放在 buf[] 里的数据，程序不会对其中的数据做任何限制，数据写入的时候时什么样的，它被读取时就是什么样的

不会发生缓冲区溢出

C 语言的字符串标准库提供的字符串操作函数，大多数（比如 strcat 追加字符串函数）都是不安全的，因为这些函数把缓冲区大小是否满足操作的工作交由开发者来保证，程序内部并不会判断缓冲区大小是否足够用，当发生了缓冲区溢出就有可能造成程序异常结束。

所以，Redis 的 SDS 结构里引入了 alloc 和 leb 成员变量，这样 SDS API 通过 alloc - len 计算，可以算出剩余可用的空间大小，这样在对字符串做修改操作的时候，就可以由程序内部判断缓冲区大小是否足够用。

而且，当判断出缓冲区大小不够用时，Redis 会自动将扩大 SDS 的空间大小，以满足修改所需的大小。

在扩展 SDS 空间之前，SDS API 会优先检查未使用空间是否足够，如果不够的话，API 不仅会为 SDS 分配修改所必须要的空间，还会给 SDS 分配额外的「未使用空间」。

这样的好处是，下次在操作 SDS 时，如果 SDS 空间够的话，API 就会直接使用「未使用空间」，而无须执行内存分配，有效的减少内存分配次数。

节省内存空间

SDS 结构中有个 flags 成员变量，表示的是 SDS 类型。

Redis 一共设计了 5 种类型，分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64。

这 5 种类型的主要区别就在于，它们数据结构中的 len 和 alloc 成员变量的数据类型不同，

之所以 SDS 设计不同类型的结构体，是为了能灵活保存不同大小的字符串，从而有效节省内存空间。比如，在保存小字符串时，结构头占用空间也比较少。

使用了专门的编译优化来节省内存空间

如何使用，常用哪些数据结构

用途：缓存热点数据，白名单，延时队列，分布式锁

数据结构：sds，hash，压缩列表，双向链表，整数集合，跳表

Redis五种数据类型及应用场景

STRING 字符串、整数或者浮点数 对整个字符串或者字符串的其中一部分执行操作 对整数和浮点数执行自增或者自减操作 注：一个键最大能存储512MB 1、分布式锁：SETNX(Key, Value)，释放锁：DEL(Key)，2、复杂计数功能缓存（用户量，视频播放量）
LIST 列表 从两端压入或者弹出元素 对单个或者多个元素进行修剪， 只保留一个范围内的元素 存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的数据，简单的消息队列的功能
SET 无序集合 添加、获取、移除单个元素 检查一个元素是否存在于集合中 计算交集、并集、差集 从集合里面随机获取元素 交集、并集、差集的操作，比如交集，可以把两个人的粉丝列表整一个交集，做全局去重的功能，点赞，转发，收藏；
HASH 包含键值对的无序散列表 添加、获取、移除单个键值对 获取所有键值对 检查某个键是否存在 结构化的数据，比如一个对象，单点登录
ZSET 有序集合 添加、获取、删除元素 根据分值范围或者成员来获取元素 计算一个键的排名 去重但可以排序，如获取排名前几名的用户，做排行榜应用，取TOPN操作；延时任务；做范围查找。周榜，月榜，年榜

持久化技术

1、持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

2、rdb:rdb:快照方式,按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

aop:aof:将数据每隔一秒追加到文件中。

3、两者区别联系

  • AOF文件比RDB更新频率高，优先使用AOF还原数据。
  • AOF比RDB更安全也更大
  • RDB性能比AOF好
  • 如果两个都配了优先加载AOF

bgsave做镜像全量持久化，aof做增量持久化。因为bgsave会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要aof来配合使用。在redis实例重启时，会使用bgsave持久化文件重新构建内存，再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。

对方追问那如果突然机器掉电会怎样？取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

对方追问bgsave的原理是什么？你给出两个词汇就可以了，fork和cow。fork是指redis通过创建子进程来进行bgsave操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

缓存雪崩，缓存穿透，缓存击穿

缓存雪崩是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决：redis高可用

  1. redis有可能挂掉，多增加几台redis实例，（一主多从或者多主多从），这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。

缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决：采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力；

接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；

缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。和缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

解决：

  1. 设置热点数据永远不过期。
  2. 加互斥锁，互斥锁

（1）一个“冷门”key，突然被大量用户请求访问。

（2）一个“热门”key，在缓存中时间恰好过期，这时有大量用户来进行访问。

分布式锁实现方式，区别

zookeeper

Zookeeper数据存储结构是一颗树，树由节点组成，节点叫ZNode

Znode分四种类型：

1、持久节点（persistent）

默认节点类型，创建节点的客户端和Zookeeper断开链接后，节点依旧存在

2、持久节点顺序节点（persistent_sequential）

创建节点时，根据创建时间给节点编号。

3、临时节点

断开链接后，节点被删除

4、临时顺序节点

Zookeeper分布式锁的原理：

获取锁：

  1. 在Zookeeper创建一个持久节点ParentLock，当客户端想要获取锁时，在ParentLock节点下创建临时顺序节点。
  2. 然后客户端再去获取临时节点是否是最靠前的一个，如果是则获取锁。
  3. 另外一个客户端先创建临时节点，然后获取临时节点是靠前，如果不是靠前的，并且不是最小的序号，此时向前面的节点注册Watcher，用于监听前一个节点的锁是否存在。

释放锁：

  1. 任务完成删除临时节点
  2. 由于节点都是相互监听，当前一个节点消失，下一个节点被置顶
  3. 如果机器宕机了，会自动删除临时节点。

redis

1、加锁

加锁实际上就是在redis中，给Key键设置一个值，为避免死锁，并给定一个过期时间。 SET lock_key random_value NX PX 5000 值得注意的是：

random_value 是客户端生成的唯一的字符串。
NX 代表只在键不存在时，才对键进行设置操作。
PX 5000 设置键的过期时间为5000毫秒。
这样，如果上面的命令执行成功，则证明客户端获取到了锁。

2、解锁

解锁的过程就是将Key键删除。但也不能乱删，不能说客户端1的请求将客户端2的锁给删除掉。这时候random_value的作用就体现出来。 为了保证解锁操作的原子性，我们用LUA脚本完成这一操作。先判断当前锁的字符串是否与传入的值相等，是的话就删除Key，解锁成功。

 if redis.call('get',KEYS[1]) == ARGV[1] then
     return redis.call('del',KEYS[1])
 else
     return 0
 end

3、使用

首先，我们在pom文件中，引入Redis包。在这里，笔者用的是最新版本，注意由于版本的不同，API可能有所差异。

Redis有哪些场景导致数据丢失

主从复制：因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了。

脑裂导致的数据丢失：脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着
此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master
这个时候，集群里就会有两个master，也就是所谓的脑裂
此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据

解决脑裂问题：通过在redis.conf配置控制同步时间减少数据丢失.

# 要求至少有1个slave，数据复制和同步延迟不能超过10秒
min-slaves-to-write 1
 
# 如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么master就会拒绝接收任何请求
min-slaves-max-lag 10

看门狗机制了解吗

基于时间轮算法实现，底层数据结构就是数组+链表，数组相当于一个时钟的一个位置，当我们初始化一个时间轮时候，只是初始化一个数组，然后它还没有启动一个新的线程，当我们真正添加一个任务到时间轮当中，才会新起一个线程，避免了空转的发生，放任务的时候也不是直接加入时间轮当中，会先加入一个mpsc队列当中，对于这块设计并发的一个考虑，就是多生产者，单消费者一个模式下，然后当时间轮走过哪个ticket，一个数组的位置的时候，会有一个判断，这次是否达到了时间轮，开始工作的一个时间，如果还没到的话，就会睡眠；直到下一次时间轮开始时间，它就会继续工作，然后从队列中把任务取出来，然后放在不同数组下标里面，如果任务在同一个数组的位置，以链表形式添加这个桶。

数据库锁

1、根据名字获取锁信息

2、更新锁信息（比如版本，状态等）占有锁

如何保证Redis与数据库的数据一致性

问题 解决思路
先更新数据库，再删除缓存。如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致 先删除缓存，再更新数据库。如果数据库更新失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致。因为读的时候缓存没有，所以去读了数据库中的旧数据，然后更新到缓存中
数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改。一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。随后数据变更的程序完成了数据库的修改。完了，数据库和缓存中的数据不一样了 方案一：写请求先删除缓存，再去更新数据库，（异步等待段时间)再删除缓存（成功表示有脏数据出现）;这种方案读取快速，但会出现短时间的脏数据。,异步删除对线上业务无影响，串行化处理保障并发情况下正确删除,如果双删失败怎么办，整个重试机制，可以借助消息队列的重试机制，也可以自己整个表，记录重试次数 方案二：写请求先修改缓存为指定值，再去更新数据库，再更新缓存。读请求过来后，先读缓存，判断是指定值后进入循环状态，等待写请求更新缓存。如果循环超时就去数据库读取数据，更新缓存。这种方案保证了读写的一致性，但是读请求会等待写操作的完成，降低了吞吐量。

如何解决redis并发竞争的key问题

问题描述：多个客户端set同一个key《=》三个请求有序的修改某个key，正常情况数据版本应该是123，但是由于网络原因变成了132，出现问题了。

第一种方案：分布式锁+时间戳

这种情况，主要是准备一个分布式锁，大家去抢锁，抢到锁就做set操作。

加锁的目的实际上就是把并行读写改成串行读写的方式，从而来避免资源竞争。

写入时顺便写一个时间戳；

写入之前比较一下自己的时间戳是否早于现有记录的时间戳，如果早于的话，说明自己的时间戳过期了，就

不需要写入了；

分布式锁

  1. 加锁：SET lock_key $unique_id EX $expire_time NX
  2. 操作共享资源
  3. 释放锁：Lua 脚本，先 GET 判断锁是否归属自己，再 DEL 释放锁

问题

1、如何避免死锁

2、锁被别人释放怎么办

3、锁过期时间不好评估

时间戳

要求key的操作需要顺序执行，所以需要保存一个时间戳判断set顺序

第二种方案：利用消息队列

在并发量过大的情况下,可以通过消息中间件进行处理,把并行读写进行串行化。

把Redis.set操作放在队列中使其串行化,必须的一个一个执行。

这种方式在一些高并发的场景中算是一种通用的解决方案。

Redis常见性能问题和解决方案

Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。

Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。

Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。

Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。

Redis淘汰key算法

Redis官方给的警告，当内存不足时，Redis会根据配置的缓存策略淘汰部分keys，以保证写入成功。当无淘汰策略时或没有找到适合淘汰的key时，Redis直接返回out of memory错误。

1、volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

2、volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

3、volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

4、allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

5、allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

6、no-enviction（驱逐）：禁止驱逐数据

应用场景：
1).在Redis中，数据有一部分访问频率较高，其余部分访问频率较低，或者无法预测数据的使用频率时，设置allkeys-lru是比较合适的。
2). 如果所有数据访问概率大致相等时，可以选择allkeys-random。
3). 如果研发者需要通过设置不同的ttl来判断数据过期的先后顺序，此时可以选择volatile-ttl策略。
4). 如果希望一些数据能长期被保存，而一些数据可以被淘汰掉时，选择volatile-lru或volatile-random都是比较不错的。
5). 由于设置expire会消耗额外的内存，如果计划避免Redis内存在此项上的浪费，可以选用allkeys-lru 策略，这样就可以不再设置过期时间，高效利用内存了。

延时队列如何实现，哪几种方案

项目中的流程监控，有几种节点，需要监控每一个节点是否超时。按传统的做法，肯定是通过定时任务，去扫描然后判断，但是定时任务有缺点：1，数据量大会慢；2，时间不好控制，太短，怕一次处理不完，太长状态就会有延迟。所以就想到用延迟队列的方式去实现。

方案一：redis的zset实现延迟队列

生产者：可以看到生产者很简单，其实就是利用zset的特性，给一个zset添加元素而已，而时间就是它的score。

消费者：消费者的代码也不难，就是把已经过期的zset中的元素给删除掉，然后处理数据。

方案二：rabbitmq通过TTL+死信队列实现延迟队列

我们需要建立2个队列，一个用于发送消息，一个用于消息过期后的转发目标队列，生产者输出消息到Queue1，并且这个消息是设置有有效时间的，比如60s。消息会在Queue1中等待60s，如果没有消费者收掉的话，它就是被转发到Queue2，Queue2有消费者，收到，处理延迟任务。

方案三：rocketmq 临时存储+定时任务。

RocketMQ是支持延时消息的，只需要在生产消息的时候设置消息的延时级别，Broker收到延时消息了，会先发送到主题（SCHEDULE_TOPIC_XXXX）的相应时间段的Message Queue中，然后通过一个定时任务轮询这些队列，到期后，把消息投递到目标Topic的队列中，然后消费者就可以正常消费这些消息。

红锁

主从模式问题：有一个严重的单点失败问题：如果Redis挂了怎么办？你可能会说，可以通过增加一个slave节点解决这个问题。但这通常是行不通的。这样做，我们不能实现资源的独享，因为Redis的主从同步通常是异步的

客户端A从master获取到锁

在master将锁同步到slave之前，master宕掉了。

slave节点被晋级为master节点

客户端B从新的master获取到锁

这个锁对应的资源之前已经被客户端A已经获取到了。安全失效！

解决方案：红锁采用主节点过半机制，即获取锁或者释放锁成功的标志为：在过半的节点上操作成功。

获取当前的时间（单位是毫秒）。
使用相同的key和随机值在N个节点上请求锁。这里获取锁的尝试时间要远远小于锁的超时时间，防止某个masterDown了，我们还在不断的获取锁，而被阻塞过长的时间。
只有在大多数节点上获取到了锁，而且总的获取时间小于锁的超时时间的情况下，认为锁获取成功了。
如果锁获取成功了，锁的超时时间就是最初的锁超时时间进去获取锁的总耗时时间。
如果锁获取失败了，不管是因为获取成功的节点的数目没有过半，还是因为获取锁的耗时超过了锁的释放时间，都会将已经设置了key的master上的key删除。

网络IO模型或者redis为什么是单线程

Redis单线程：所谓的单线程是指从网络连接(accept) -> 读取请求内容(read) -> 执行命令 -> 响应内容(write)，这整个过程是由一个线程完成的。

我们在传统的I/O模型中，如果服务端需要支持多个客户端，我们可能要为每个客户端分配一个进程/线程。

不管是基于重一点的进程模型，还是轻一点的线程模型，假如连接多了，操作系统是扛不住的。

所以就引入了I/O多路复用 技术。

简单说，就是一个进程/线程维护多个Socket，这个多路复用就是多个连接复用一个进程/线程。

I/O多路复用

我们来看看I/O多路复用三种实现机制：

  • select

select 实现多路复⽤的⽅式是：

将已连接的 Socket 都放到⼀个⽂件描述符集合fd_set，然后调⽤ select 函数将fd_set集合拷⻉到内核⾥，让内核来检查是否有⽹络事件产⽣，检查的⽅式很粗暴，就是通过遍历fd_set的⽅式，当检查到有事件产⽣后，将此 Socket 标记为可读或可写， 接着再把整个fd_set拷⻉回⽤户态⾥，然后⽤户态还需要再通过遍历的⽅法找到可读或可写的 Socket，再对其处理。

select 使⽤固定⻓度的 BitsMap，表示⽂件描述符集合，⽽且所⽀持的⽂件描述符的个数是有限制的，在Linux 系统中，由内核中的 FD_SETSIZE 限制， 默认最⼤值为 1024 ，只能监听 0~1023 的⽂件描述符。

select机制的缺点：

（1）每次调用select，都需要把fd_set集合从用户态拷贝到内核态，如果fd_set集合很大时，那这个开销也很大，比如百万连接却只有少数活跃连接时这样做就太没有效率。

（2）每次调用select都需要在内核遍历传递进来的所有fd_set，如果fd_set集合很大时，那这个开销也很大。

（3）为了减少数据拷贝带来的性能损坏，内核对被监控的fd_set集合大小做了限制，一般为1024，如果想要修改会比较麻烦，可能还需要编译内核。

（4）每次调用select之前都需要遍历设置监听集合，重复工作。

  • poll

poll 不再⽤ BitsMap 来存储所关注的⽂件描述符，取⽽代之⽤动态数组，以链表形式来组织，突破了select 的⽂件描述符个数限制，当然还会受到系统⽂件描述符限制。

但是 poll 和 select 并没有太⼤的本质区别，都是使⽤线性结构存储进程关注的Socket集合，因此都需要遍历⽂件描述符集合来找到可读或可写的Socke，时间复杂度为O(n)，⽽且也需要在⽤户态与内核态之间拷⻉⽂件描述符集合，这种⽅式随着并发数上来，性能的损耗会呈指数级增⻓。

  • epoll

epoll 通过两个⽅⾯，很好解决了 select/poll 的问题。

第⼀点，epoll 在内核⾥使⽤红⿊树来跟踪进程所有待检测的⽂件描述字，把需要监控的 socket 通过epoll_ctl() 函数加⼊内核中的红⿊树⾥，红⿊树是个⾼效的数据结构，增删查⼀般时间复杂度是O(logn) ，通过对这棵⿊红树进⾏操作，这样就不需要像 select/poll 每次操作时都传⼊整个 socket 集合，只需要传⼊⼀个待检测的 socket，减少了内核和⽤户空间⼤量的数据拷⻉和内存分配。

第⼆点， epoll 使⽤事件驱动的机制，内核⾥维护了⼀个链表来记录就绪事件，当某个 socket 有事件发⽣时，通过回调函数，内核会将其加⼊到这个就绪事件列表中，当⽤户调⽤ epoll_wait() 函数时，只会返回有事件发⽣的⽂件描述符的个数，不需要像 select/poll 那样轮询扫描整个 socket 集合，⼤⼤提⾼了检测的效率。

epoll接口作用-来源参考[3]

epoll 的⽅式即使监听的 Socket 数量越多的时候，效率不会⼤幅度降低，能够同时监听的 Socket 的数⽬也⾮常的多了，上限就为系统定义的进程打开的最⼤⽂件描述符个数。因⽽，epoll 被称为解决 C10K 问题的利器。

Redis 是单线程，主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

布隆过滤器

布隆过滤器的原理是，当一个元素被加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，我们只要看看这些点是不是都是1就（大约）知道集合中有没有它了：如果这些点有任何一个0，则被检元素一定不在；如果都是1，则被检元素很可能在。这就是布隆过滤器的基本思想。

某样东西一定不存在或者可能存在

假如，数据库中有100条订单数据，id分别从1到100，现在用户通过id查询订单数据，为了防止缓存穿透，我们需要提前做一个bloom filter（一个自定义的bit数组长度为1000，并自定义一个hash算法），将数据库中的所有id提前通过hash算法计算后，放到bit数组中；当用户的请求到达controller层中，先到这个数组中查询这个id是否存在，如果存在，在让请求往下走，访问redis或mysql；如果不存在则直接返回。

存在问题：假设id=110的数据经过hash函数计算的值也是3，那么当用户查询这条数据时，数据库不存在这条数据，但是bloom filter查询后显示数据存在，所有也会查询redis和mysql。这就是hash碰撞导致的假阳性

解决方案：可以通过增加hash函数的个数和增加bit数组的长度来解决

Redis为什么那么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路I/O复用模型，非阻塞IO；

统计问题HyperLoglog

Redis 在 2.8.9 版本添加了 HyperLogLog 数据结构，用来做基数统计，其优点是在输入元素的数量非常大时，计算基数所需的空间比较小并且一般比较恒定。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，并不会储存输入元素本身，所以 HyperLogLog 不能像集合那样能返回输入的各个元素。

比如数据集 {1, 3, 5, 7, 5, 7, 8}， 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。基数估计就是在误差可接受的范围内，快速计算基数。

一致性hash，hash槽

redis cluster采用数据分片的哈希槽来进行数据存储和数据的读取。redis cluster一共有2^14（16384）个槽，所有的master节点都会有一个槽区比如0～1000，槽数是可以迁移的。master节点的slave节点不分配槽，只拥有读权限。但是注意在代码中redis cluster执行读写操作的都是master节点，并不是读是从节点，写是主节点。

为什么是16384个槽？
在握手成功后，两个节点之间会定期发送ping/pong消息，交换数据信息，在redis节点发送心跳包时需要把所有的槽信息放到这个心跳包里，以便让节点知道当前集群信息，在发送心跳包时使用char进行bitmap压缩后是2k（16384÷8÷1024=2kb），也就是说使用2k的空间创建了16k的槽数。
虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，65535=65k，压缩后就是8k（8 * 8 (8 bit) * 1024(1k) = 8K），也就是说需要需要8k的心跳包，作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。

如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
redis的集群主节点数量基本不可能超过1000个。集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。
槽位越小，节点少的情况下，压缩率高
Redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。
如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

和一致性哈希相比

并不是闭合的，key的定位规则是根据CRC-16(key)%16384的值来判断属于哪个槽区，从而判断该key属于哪个节点，而一致性哈希是根据hash(key)的值来顺时针找第一个hash(ip)的节点，从而确定key存储在哪个节点。
一致性哈希是创建虚拟节点来实现节点宕机后的数据转移并保证数据的安全性和集群的可用性的。redis cluster是采用master节点有多个slave节点机制来保证数据的完整性的,master节点写入数据，slave节点同步数据。当master节点挂机后，slave节点会通过选举机制选举出一个节点变成master节点，实现高可用。但是这里有一点需要考虑，如果master节点存在热点缓存，某一个时刻某个key的访问急剧增高，这时该mater节点可能操劳过度而死，随后从节点选举为主节点后，同样宕机，进入fail状态。

扩容和缩容
一致性哈希算法在新增和删除节点后，数据会按照顺时针来重新分布节点。而redis cluster的新增和删除节点都需要手动来分配槽区。

redis客户端是什么

RedisDesktopManager

redis相比较数据库优势

  1. 性能很好，基于纯内存操作，所以读写性能很好，可以达到10w/s的频率
  2. 支持数据持久化，便于数据备份、恢复，支持简单的事务，操作满足原子性
  3. 支持主从复制，实现读写分离，分担读的压力

多线程

说说你对原子性、可见性、有序性的理解？

原子性、有序性、可见性是并发编程中非常重要的基础概念，JMM的很多技术都是围绕着这三大特性展开。

  • 原子性：原子性指的是一个操作是不可分割、不可中断的，要么全部执行并且执行的过程不会被任何因素打断，要么就全不执行。
  • 可见性：可见性指的是一个线程修改了某一个共享变量的值时，其它线程能够立即知道这个修改。
  • 有序性：有序性指的是对于一个线程的执行代码，从前往后依次执行，单线程下可以认为程序是有序的，但是并发时有可能会发生指令重排。

分析下面几行代码的原子性？

int i = 2;
int j = i;
i++;
i = i + 1;
  • 第1句是基本类型赋值，是原子性操作。
  • 第2句先读i的值，再赋值到j，两步操作，不能保证原子性。
  • 第3和第4句其实是等效的，先读取i的值，再+1，最后赋值到i，三步操作了，不能保证原子性。

原子性、可见性、有序性都应该怎么保证呢？

  • 原子性：JMM只能保证基本的原子性，如果要保证一个代码块的原子性，需要使用synchronized 。
  • 可见性：Java是利用volatile关键字来保证可见性的，除此之外，final和synchronized也能保证可见性。
  • 有序性：synchronized或者volatile都可以保证多线程之间操作的有序性。

synchronize

为什么会需要synchronized？什么场景下使用synchronized？

这个就要说到多线程访问共享资源了，当一个资源有可能被多个线程同时访问并修改的话，需要用到锁。

应用场景：

1 两个线程同时访问同一个对象的同步方法

package com.geekmice.sbcmgenerator;

import javax.sound.midi.Soundbank;

/**
 * @version: V1.0
 * @author: pmb
 * @className: MethodLock
 * @packageName: com.geekmice.sbcmgenerator
 * @description:
 * @date: 2023-03-01 23:20
 **/
public class MethodLock implements Runnable {
    
    
    private static MethodLock instance = new MethodLock();

    /**
     * 同步方法 先执行线程1，四秒钟之后，执行线程2，再执行四秒。
     */
    private synchronized void method() {
    
    
        System.out.println("线程：" + Thread.currentThread().getName() + ",运行开始");
        try {
    
    
            Thread.sleep(4000);
            System.out.println("线程：" + Thread.currentThread().getName() + ",运行结束");
        } catch (Exception e) {
    
    
            e.printStackTrace();
        }
    }

    @Override
    public void run() {
    
    
        method();
    }

    public static void main(String[] args) {
    
    
        Thread threadOne = new Thread(instance);
        Thread threadTwo = new Thread(instance);
        threadOne.start();
        threadTwo.start();
        // 方法isAlive() 的功能是判断当前的线程是否处于活动状态；活动状态就是线程已经启动尚未终止，
        // 那么这时候线程就是存活的，则返回true，否则则返回false
        while (threadOne.isAlive() || threadTwo.isAlive()) {
    
    
        }
        System.out.println("测试结束");
    }
}

2 两个线程同时访问两个对象的同步方法

package com.geekmice.sbcmgenerator;

/**
 * @version: V1.0
 * @author: pmb
 * @className: ConditionTwo
 * @packageName: com.geekmice.sbcmgenerator
 * @description:
 * @date: 2023-03-01 23:32
 **/
public class ConditionTwo implements Runnable {
    
    
    static ConditionTwo oneInstance = new ConditionTwo();
    static ConditionTwo twoInstance = new ConditionTwo();

    private static synchronized void method() {
    
    
        System.out.println("线程：" + Thread.currentThread().getName() + ",开始");
        try {
    
    
            Thread.sleep(4000);
        } catch (Exception e) {
    
    
            e.printStackTrace();
        }
        System.out.println("线程：" + Thread.currentThread().getName() + ",结束");
    }

    @Override
    public void run() {
    
    
        method();
    }

    public static void main(String[] args) {
    
    
        Thread threadOne = new Thread(oneInstance);
        Thread threadTwo = new Thread(twoInstance);
        threadOne.start();
        threadTwo.start();
        while (threadOne.isAlive() || threadTwo.isAlive()) {
    
    
            //System.out.println("线程还存活");
        }
        System.out.println("测试结束");
    }
}

image-20230301234041470

问题在此：

两个线程（thread1、thread2），访问两个对象（instance1、instance2）的同步方法（method()）,两个线程都有各自的锁，不能形成两个线程竞争一把锁的局势，所以这时，synchronized修饰的方法method()和不用synchronized修饰的效果一样（不信去把synchronized关键字去掉，运行结果一样），所以此时的method()只是个普通方法。

如何解决这个问题：

若要使锁生效，只需将method()方法用static修饰，这样就形成了类锁，多个实例（instance1、instance2）共同竞争一把类锁，就可以使两个线程串行执行了。

synchronized 还有别的作用范围吗？

  1. 在静态方法上加锁；
  2. 在实例方法上加锁；
  3. 在代码块上加锁；

那你了解 synchronized 这三种作用范围的加锁方式的区别吗

这三种作用范围的区别实际是被加锁的对象的区别，请看下表：

作用范围 锁对象
非静态方法 当前对象 => this
静态方法 类对象 => SynchronizedSample.class （一切皆对象，这个是类对象）
代码块 指定对象 => lock （以上面的代码为例）

那你清楚 JVM 是怎么通过synchronized 在对象上实现加锁，保证多线程访问竞态资源安全的吗？

先说在JDK6 以前，synchronized 那时还属于重量级锁，每次加锁都依赖操作系统Mutex Lock实现，涉及到操作系统让线程从用户态切换到内核态，切换成本很高；

到了JDK6，研究人员引入了偏向锁和轻量级锁，因为Sun 程序员发现大部分程序大多数时间都不会发生多个线程同时访问竞态资源的情况，每次线程都加锁解锁，每次这么搞都要操作系统在用户态和内核态之间来回切，太耗性能了。

synchronize理解

synchronized经常用的，用来保证代码的原子性。

场景：两个线程分别同时访问（一个或两个）对象的同步方法和非同步方法

修饰实例方法: 作用于当前对象实例加锁，进入同步代码前要获得 当前对象实例的锁

修饰静态方法：也就是给当前类加锁，会作⽤于类的所有对象实例 ，进⼊同步代码前要获得当前 class 的锁。因为静态成员不属于任何⼀个实例对象，是类成员（ static 表明这是该类的⼀个静态资源，不管 new 了多少个对象，只有⼀份）。

如果⼀个线程 A 调⽤⼀个实例对象的⾮静态 synchronized ⽅法，⽽线程 B 需要调⽤这个实例对象所属类的静态 synchronized ⽅法，是允许的，不会发⽣互斥现象，因为访问静态 synchronized ⽅法占⽤的锁是当前类的锁，⽽访问⾮静态 synchronized ⽅法占⽤的锁是当前实例对象锁。

修饰代码块 ：指定加锁对象，对给定对象/类加锁。 synchronized(this|object) 表示进⼊同步代码库前要获得给定对象的锁。 synchronized(类.class) 表示进⼊同步代码前要获得 当前 class 的锁。

synchronized底层实现

我们使用synchronized的时候，发现不用自己去lock和unlock，是因为JVM帮我们把这个事情做了。

  1. synchronized修饰代码块时，JVM采用monitorenter、monitorexit两个指令来实现同步，monitorenter 指令指向同步代码块的开始位置， monitorexit 指令则指向同步代码块的结束位置。

    反编译一段synchronized修饰代码块代码，javap -c -s -v -l SynchronizedDemo.class，可以看到相应的字节码指令。

  2. synchronized修饰同步方法时，JVM采用ACC_SYNCHRONIZED标记符来实现同步，这个标识指明了该方法是一个同步方法。

  3. monitorenter、monitorexit或者ACC_SYNCHRONIZED都是基于Monitor实现的。

    实例对象结构里有对象头，对象头里面有一块结构叫Mark Word，Mark Word指针指向了monitor。

    所谓的Monitor其实是一种同步工具，也可以说是一种同步机制。在Java虚拟机（HotSpot）中，Monitor是由ObjectMonitor实现的，可以叫做内部锁，或者Monitor锁。

锁升级的过程

synchronized默认采用的是偏向锁，然后程序运行过程中始终是只有一个线程去获取，这个synchronized的这个锁，那么java对象中记录一个线程id,我们下次再获取这个synchronize的锁时候，只需要比较这个线程id就行了，在运行过程中如果出现第二个线程请求synchronized的锁时候，分两种情况，在没有发生并发竞争锁情况下，这个synchronized就会自动升级为轻量级锁，这个时候，第二个线程就会尝试自旋锁方式获取锁，很快便可以拿到锁，所以第二个线程也不会阻塞，但是如果出现两个线程竞争锁情况，这个synchronize就会升级为重量级锁，这个时候就是只有一个线程获取锁，那么另外一个线程就是阻塞状态，需要等待第一个线程释放锁之后，才能拿到锁。

synchronized如何使用

  • 修饰实例方法
public class SynchronizedDemo {
    
    
    private int count=0;

    private synchronized void add(){
    
    
        count++;
    }

    public static void main(String[] args) throws InterruptedException {
    
    
        SynchronizedDemo synchronizedDemo = new SynchronizedDemo();
        Thread t1=new Thread(()->{
    
    
            for (int i=0;i<100;i++){
    
    
                synchronizedDemo.add();
            }
        });

        Thread t2=new Thread(()->{
    
    
            for (int i=0;i<100;i++){
    
    
                synchronizedDemo.add();
            }
        });

        t1.start();
        t2.start();
        t1.join();// 阻塞线程，等待线程t1完成
        t2.join();// 阻塞线程，等待线程t2完成

        System.out.println("结果："+synchronizedDemo.count);// 200

    }
}

分析:在上面的代码当中的add方法只有一个简单的count++操作，因为这个方法是使用synchronized修饰的因此每一个时刻只能有一个线程执行add方法，因此上面打印的结果是200。如果add方法没有使用synchronized修饰的话，那么线程t1和线程t2就可以同时执行add方法，这可能会导致最终count的结果小于200，因为count++操作不具备原子性。

上面的分析还是比较明确的，但是我们还需要知道的是synchronized修饰的add方法一个时刻只能有一个线程执行的意思是对于一个SyncDemo类的对象来说一个时刻只能有一个线程进入。比如现在有两个SyncDemo的对象s1和s2，一个时刻只能有一个线程进行s1的add方法，一个时刻只能有一个线程进入s2的add方法，但是同一个时刻可以有两个不同的线程执行s1和s2的add方法，也就说s1的add方法和s2的add是没有关系的，一个线程进入s1的add方法并不会阻止另外的线程进入s2的add方法，也就是说synchronized在修饰一个非静态方法的时候“锁”住的只是一个实例对象，并不会“锁”住其它的对象。其实这也很容易理解，一个实例对象是一个独立的个体别的对象不会影响他，他也不会影响别的对象。

  • 修饰静态方法
public class SynchronizedDemo {
    
    
    private static int count=0;

    private static synchronized void add(){
    
    
        count++;
    }

    public static void main(String[] args) throws InterruptedException {
    
    
        SynchronizedDemo synchronizedDemo = new SynchronizedDemo();
        Thread t1=new Thread(()->{
    
    
            for (int i=0;i<100;i++){
    
    
                synchronizedDemo.add();
            }
        });

        Thread t2=new Thread(()->{
    
    
            for (int i=0;i<100;i++){
    
    
                synchronizedDemo.add();
            }
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();

        System.out.println("结果："+synchronizedDemo.count);// 200	

    }
}

上面的代码最终输出的结果也是200，但是与前一个程序不同的是。这里的add方法用static修饰的，在这种情况下真正的只能有一个线程进入到add代码块，因为用static修饰的话是所有对象公共的，因此和前面的那种情况不同，不存在两个不同的线程同一时刻执行add方法。

你仔细想想如果能够让两个不同的线程执行add代码块，那么count++的执行就不是原子的了。那为什么没有用static修饰的代码为什么可以呢？因为当没有用static修饰时，每一个对象的count都是不同的，内存地址不一样，因此在这种情况下count++这个操作仍然是原子的！

说说synchronized和ReentrantLock的区别？

  • 锁的实现： synchronized是Java语言的关键字，基于JVM实现。而ReentrantLock是基于JDK的API层面实现的（一般是lock()和unlock()方法配合try/finally 语句块来完成。）
  • ReentrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。
  • synchronized与wait()和notify()/notifyAll()方法结合实现等待/通知机制，ReentrantLock类借助Condition接口与newCondition()方法实现。
  • ReentrantLock需要手工声明来加锁和释放锁，一般跟finally配合释放锁。而synchronized不用手动释放锁。

synchronized如何保证原子性、可见性、有序性

原子性： 即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

Java内存模型提供了字节码指令monitorenter和monitorexit来隐式的使用这两个操作，在synchronized块之间的操作是具备原子性的。
线程1在执行monitorenter指令的时候，会对Monitor进行加锁，加锁后其他线程无法获得锁，除非线程1主动解锁。即使在执行过程中，由于某种原因，比如CPU时间片用完，线程1放弃了CPU，但是它并没有进行解锁。而由于synchronized的锁是可重入的，下一个时间片还是只能被他自己获取到，还是会继续执行代码。直到所有代码执行完。这就保证了原子性。

有序性： 程序执行的顺序按照代码的先后顺序执行。

在并发时，程序的执行可能会出现乱序。给人的直观感觉就是：写在前面的代码，会在后面执行。但是synchronized提供了有序性保证，这其实和as-if-serial语义有关。
as-if-serial语义是指不管怎么重排序（编译器和处理器为了提高并行度），单线程程序的执行结果都不能被改变。编译器和处理器无论如何优化，都必须遵守as-if-serial语义。只要编译器和处理器都遵守了这个语义，那么就可以认为单线程程序是按照顺序执行的，由于synchronized修饰的代码，同一时间只能被同一线程访问。那么可以认为是单线程执行的。所以可以保证其有序性。
但是需要注意的是synchronized虽然能够保证有序性，但是无法禁止指令重排和处理器优化的。

可见性： 当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

被synchronized修饰的代码，在开始执行时会加锁，执行完成后会进行解锁，但在一个变量解锁之前，必须先把此变量同步回主存中，这样解锁后，后续其它线程就可以访问到被修改后的值，从而保证可见性。

ThreadLocal

你在工作中用到过ThreadLocal吗？

场景：有用到过的，用来做用户信息上下文的存储。

我们的系统应用是一个典型的MVC架构，登录后的用户每次访问接口，都会在请求头中携带一个token，在控制层可以根据这个token，解析出用户的基本信息。那么问题来了，假如在服务层和持久层都要用到用户信息，比如rpc调用、当前用户获取等等，那应该怎么办呢？

一种办法是显式定义用户相关的参数，比如账号、用户名……这样一来，我们可能需要大面积地修改代码，多少有点瓜皮，那该怎么办呢？

这时候我们就可以用到ThreadLocal，在控制层拦截请求把用户信息存入ThreadLocal，这样我们在任何一个地方，都可以取出ThreadLocal中存的用户数据。

ThreadLoca存放用户上下文

每个线程内需要保存类似于全局变量的信息（例如在拦截器中获取的用户信息），可以让不同方法直接使用，避免参数传递的麻烦却不想被多线程共享（因为不同线程获取到的用户信息不一样）。

例如，用 ThreadLocal 保存一些业务内容（用户权限信息、从用户系统获取到的用户名、用户ID 等），这些信息在同一个线程内相同，但是不同的线程使用的业务内容是不相同的。

在线程生命周期内，都通过这个静态 ThreadLocal 实例的 get() 方法取得自己 set 过的那个对象，避免了将这个对象（如 user 对象）作为参数传递的麻烦。

ThreadLocal怎么实现的呢？

我们看一下ThreadLocal的set(T)方法，发现先获取到当前线程，再获取ThreadLocalMap，然后把元素存到这个map中。

    public void set(T value) {
    
    
        //获取当前线程
        Thread t = Thread.currentThread();
        //获取ThreadLocalMap
        ThreadLocalMap map = getMap(t);
        //讲当前元素存入map
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

ThreadLocal实现的秘密都在这个ThreadLocalMap了，可以Thread类中定义了一个类型为ThreadLocal.ThreadLocalMap的成员变量threadLocals。

public class Thread implements Runnable {
    
    
   //ThreadLocal.ThreadLocalMap是Thread的属性
   ThreadLocal.ThreadLocalMap threadLocals = null;
}

ThreadLocalMap既然被称为Map，那么毫无疑问它是<key,value>型的数据结构。我们都知道map的本质是一个个<key,value>形式的节点组成的数组，那ThreadLocalMap的节点是什么样的呢？

static class Entry extends WeakReference<ThreadLocal<?>> {
    
    
    /** The value associated with this ThreadLocal. */
    Object value;

    //节点类
    Entry(ThreadLocal<?> k, Object v) {
    
    
        //key赋值
        super(k);
        //value赋值
        value = v;
    }
}

这里的节点，key可以简单低视作ThreadLocal，value为代码中放入的值，当然实际上key并不是ThreadLocal本身，而是它的一个弱引用，可以看到Entry的key继承了 WeakReference（弱引用），再来看一下key怎么赋值的：

public WeakReference(T referent) {
    
    
    super(referent);
}

key的赋值，使用的是WeakReference的赋值。

ThreadLoca结构图

所以，怎么回答ThreadLocal原理？要答出这几个点：

  • Thread类有一个类型为ThreadLocal.ThreadLocalMap的实例变量threadLocals，每个线程都有一个属于自己的ThreadLocalMap。
  • ThreadLocalMap内部维护着Entry数组，每个Entry代表一个完整的对象，key是ThreadLocal的弱引用，value是ThreadLocal的泛型值。
  • 每个线程在往ThreadLocal里设置值的时候，都是往自己的ThreadLocalMap里存，读也是以某个ThreadLocal作为引用，在自己的map里找对应的key，从而实现了线程隔离。
  • ThreadLocal本身不存储值，它只是作为一个key来让线程往ThreadLocalMap里存取值。

ThreadLocal 内存泄露是怎么回事？

我们先来分析一下使用ThreadLocal时的内存，我们都知道，在JVM中，栈内存线程私有，存储了对象的引用，堆内存线程共享，存储了对象实例。

所以呢，栈中存储了ThreadLocal、Thread的引用，堆中存储了它们的具体实例。

ThreadLocal内存分配

ThreadLocalMap中使用的 key 为 ThreadLocal 的弱引用。

“弱引用：只要垃圾回收机制一运行，不管JVM的内存空间是否充足，都会回收该对象占用的内存。”

那么现在问题就来了，弱引用很容易被回收，如果ThreadLocal（ThreadLocalMap的Key）被垃圾回收器回收了，但是ThreadLocalMap生命周期和Thread是一样的，它这时候如果不被回收，就会出现这种情况：ThreadLocalMap的key没了，value还在，这就会造成了内存泄漏问题。

那怎么解决内存泄漏问题呢？

很简单，使用完ThreadLocal后，及时调用remove()方法释放内存空间。

ThreadLocal<String> localVariable = new ThreadLocal();
try {
    
    
    localVariable.set("鄙人三某”);
    ……
} finally {
    
    
    localVariable.remove();
}

那为什么key还要设计成弱引用？

key设计成弱引用同样是为了防止内存泄漏。

假如key被设计成强引用，如果ThreadLocal Reference被销毁，此时它指向ThreadLoca的强引用就没有了，但是此时key还强引用指向ThreadLoca，就会导致ThreadLocal不能被回收，这时候就发生了内存泄漏的问题。

ThreadLocalMap的结构了解吗？

ThreadLocalMap虽然被叫做Map，其实它是没有实现Map接口的，但是结构还是和HashMap比较类似的，主要关注的是两个要素：元素数组和散列方法。

ThreadLocalMap结构示意图

  • 元素数组

    一个table数组，存储Entry类型的元素，Entry是ThreaLocal弱引用作为key，Object作为value的结构。

 private Entry[] table;

  • 散列方法

    散列方法就是怎么把对应的key映射到table数组的相应下标，ThreadLocalMap用的是哈希取余法，取出key的threadLocalHashCode，然后和table数组长度减一&运算（相当于取余）。

int i = key.threadLocalHashCode & (table.length - 1);

这里的threadLocalHashCode计算有点东西，每创建一个ThreadLocal对象，它就会新增0x61c88647，这个值很特殊，它是斐波那契数 也叫 黄金分割数。hash增量为 这个数字，带来的好处就是 hash 分布非常均匀。

    private static final int HASH_INCREMENT = 0x61c88647;
    
    private static int nextHashCode() {
    
    
        return nextHashCode.getAndAdd(HASH_INCREMENT);
    }

ThreadLocalMap怎么解决Hash冲突的？

我们可能都知道HashMap使用了链表来解决冲突，也就是所谓的链地址法。

ThreadLocalMap没有使用链表，自然也不是用链地址法来解决冲突了，它用的是另外一种方式——开放定址法。开放定址法是什么意思呢？简单来说，就是这个坑被人占了，那就接着去找空着的坑。

ThreadLocalMap解决冲突

如上图所示，如果我们插入一个value=27的数据，通过 hash计算后应该落入第 4 个槽位中，而槽位 4 已经有了 Entry数据，而且Entry数据的key和当前不相等。此时就会线性向后查找，一直找到 Entry为 null的槽位才会停止查找，把元素放到空的槽中。

在get的时候，也会根据ThreadLocal对象的hash值，定位到table中的位置，然后判断该槽位Entry对象中的key是否和get的key一致，如果不一致，就判断下一个位置。

ThreadLocalMap扩容机制了解吗？

在ThreadLocalMap.set()方法的最后，如果执行完启发式清理工作后，未清理到任何数据，且当前散列数组中Entry的数量已经达到了列表的扩容阈值(len*2/3)，就开始执行rehash()逻辑：

if (!cleanSomeSlots(i, sz) && sz >= threshold)
    rehash();

再着看rehash()具体实现：这里会先去清理过期的Entry，然后还要根据条件判断size >= threshold - threshold / 4 也就是size >= threshold* 3/4来决定是否需要扩容。

private void rehash() {
    
    
    //清理过期Entry
    expungeStaleEntries();

    //扩容
    if (size >= threshold - threshold / 4)
        resize();
}

//清理过期Entry
private void expungeStaleEntries() {
    
    
    Entry[] tab = table;
    int len = tab.length;
    for (int j = 0; j < len; j++) {
    
    
        Entry e = tab[j];
        if (e != null && e.get() == null)
            expungeStaleEntry(j);
    }
}

接着看看具体的resize()方法，扩容后的newTab的大小为老数组的两倍，然后遍历老的table数组，散列方法重新计算位置，开放地址解决冲突，然后放到新的newTab，遍历完成之后，oldTab中所有的entry数据都已经放入到newTab中了，然后table引用指向newTab

ThreadLocalMap扩容

具体代码：

ThreadLocalMap resize

父子线程怎么共享数据？

父线程能用ThreadLocal来给子线程传值吗？毫无疑问，不能。那该怎么办？

这时候可以用到另外一个类——InheritableThreadLocal 。

使用起来很简单，在主线程的InheritableThreadLocal实例设置值，在子线程中就可以拿到了。

public class InheritableThreadLocalTest {
    
    
    
    public static void main(String[] args) {
    
    
        final ThreadLocal threadLocal = new InheritableThreadLocal();
        // 主线程
        threadLocal.set("不擅技术");
        //子线程
        Thread t = new Thread() {
    
    
            @Override
            public void run() {
    
    
                super.run();
                System.out.println("鄙人三某 ，" + threadLocal.get());
            }
        };
        t.start();
    }
}

那原理是什么呢？

原理很简单，在Thread类里还有另外一个变量：

ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;

在Thread.init的时候，如果父线程的inheritableThreadLocals不为空，就把它赋给当前线程（子线程）的inheritableThreadLocals 。

if (inheritThreadLocals && parent.inheritableThreadLocals != null)
    this.inheritableThreadLocals =
        ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);

CAS呢？CAS了解多少？有什么问题

是什么

CAS叫做CompareAndSwap，⽐较并交换，主要是通过处理器的指令来保证操作的原⼦性的。

CAS 指令包含 3 个参数：共享变量的内存地址 A、预期的值 B 和共享变量的新值 C。

只有当内存中地址 A 处的值等于 B 时，才能将内存中地址 A 处的值更新为新值 C。作为一条 CPU 指令，CAS 指令本身是能够保证原子性的 。

应用场景

CAS就是通过一个原子操作，用预期值去和实际值做对比，如果实际值和预期相同，则做更新操作。
如果预期值和实际不同，我们就认为，其他线程更新了这个值，此时不做更新操作。
而且这整个流程是原子性的，所以只要实际值和预期值相同，就能保证这次更新不会被其他线程影响。

public class ThreadSafeTest {
    
    
  public static volatile int i = 0;
  public synchronized void increase() {
    
    
    i++;
  }
}

保证i++的原子操作，在increase方法上使用了重量级的锁synchronized，这会导致该方法的性能低下，所有调用该方法的操作都需要同步等待处理。保证i++的原子操作，在increase方法上使用了重量级的锁synchronized，这会导致该方法的性能低下，所有调用该方法的操作都需要同步等待处理。

public class ThreadSafeTest {
    
    
  private final AtomicInteger counter = new AtomicInteger(0);
  public int increase(){
    
    
    return counter.addAndGet(1);
  }
}

其中，在static静态代码块中，基于Unsafe类获取value字段相对当前对象的“起始地址”的偏移量，用于后续Unsafe类的处理。

在处理自增的原子操作时，使用的是Unsafe类中的getAndAddInt方法，CAS的实现便是由Unsafe类的该方法提供，从而保证自增操作的原子性。

同时，在AtomicInteger类中，可以看到value值通过volatile进行修饰，保证了该属性值的线程可见性。在多并发的情况下，一个线程的修改，可以保证到其他线程立马看到修改后的值。

通过源码可以看出， AtomicInteger 底层是通过volatile变量和CAS两者相结合来保证更新数据的原子性。

public class AtomicInteger extends Number implements java.io.Serializable {
    
    
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;
    static {
    
    
        try {
    
    
            // 用于获取value字段相对当前对象的“起始地址”的偏移量
            valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) {
    
     throw new Error(ex); }
    }
​
    private volatile int value;
​
    //返回当前值
    public final int get() {
    
    
        return value;
    }
​
    //递增加detla
    public final int getAndAdd(int delta) {
    
    
        // 1、this：当前的实例 
        // 2、valueOffset：value实例变量的偏移量 
        // 3、delta：当前value要加上的数(value+delta)。
        return unsafe.getAndAddInt(this, valueOffset, delta);
    }
​
    //递增加1
    public final int incrementAndGet() {
    
    
        return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }
...
}

有什么问题

1 ABA 问题

并发环境下，假设初始条件是A，去修改数据时，发现是A就会执行修改。但是看到的虽然是A，中间可能发生了A变B，B又变回A的情况。此时A已经非彼A，数据即使成功修改，也可能有问题。

怎么解决ABA问题？

  • 加版本号

每次修改变量，都在这个变量的版本号上加1，这样，刚刚A->B->A，虽然A的值没变，但是它的版本号已经变了，再判断版本号就会发现此时的A已经被改过了。参考乐观锁的版本号，这种做法可以给数据带上了一种实效性的检验。

Java提供了AtomicStampReference类，它的compareAndSet方法首先检查当前的对象引用值是否等于预期引用，并且当前印戳（Stamp）标志是否等于预期标志，如果全部相等，则以原子方式将引用值和印戳标志的值更新为给定的更新值。

2 循环性能开销

自旋CAS，如果一直循环执行，一直不成功，会给CPU带来非常大的执行开销。

怎么解决循环性能开销问题？

在Java中，很多使用自旋CAS的地方，会有一个自旋次数的限制，超过一定次数，就停止自旋。

3 只能保证一个变量的原子操作

CAS 保证的是对一个变量执行操作的原子性，如果对多个变量操作时，CAS 目前无法直接保证操作的原子性的。

怎么解决只能保证一个变量的原子操作问题？

  • 可以考虑改用锁来保证操作的原子性
  • 可以考虑合并多个变量，将多个变量封装成一个对象，通过AtomicReference来保证原子性。

线程池理解

线程池： 简单理解，它就是一个管理线程的池子。

  • 它帮我们管理线程，避免增加创建线程和销毁线程的资源损耗。因为线程其实也是一个对象，创建一个对象，需要经过类加载过程，销毁一个对象，需要走GC垃圾回收流程，都是需要资源开销的。
  • 提高响应速度。 如果任务到达了，相对于从线程池拿线程，重新去创建一条线程执行，速度肯定慢很多。
  • 重复利用。 线程用完，再放回池子，可以达到重复利用的效果，节省资源。

执行流程

  1. 线程池刚创建时，里面没有一个线程。任务队列是作为参数传进来的。不过，就算队列里面有任务，线程池也不会马上执行它们。
  2. 当调用 execute() 方法添加一个任务时，线程池会做如下判断：
  • 如果正在运行的线程数量小于 corePoolSize，那么马上创建线程运行这个任务；
  • 如果正在运行的线程数量大于或等于 corePoolSize，那么将这个任务放入队列；
  • 如果这时候队列满了，而且正在运行的线程数量小于 maximumPoolSize，那么还是要创建非核心线程立刻运行这个任务；
  • 如果队列满了，而且正在运行的线程数量大于或等于 maximumPoolSize，那么线程池会根据拒绝策略来对应处理。
  • 当一个线程完成任务时，它会从队列中取下一个任务来执行。
  • 当一个线程无事可做，超过一定的时间（keepAliveTime）时，线程池会判断，如果当前运行的线程数大于 corePoolSize，那么这个线程就被停掉。所以线程池的所有任务完成后，它最终会收缩到 corePoolSize 的大小。

线程池如何配置的，有哪些参数

之前我们有一个和第三方对接的需求，需要向第三方推送数据，引入了多线程来提升数据推送的效率，其中用到了线程池来管理线程。

线程池的参数如下：

  • corePoolSize：线程核心参数选择了CPU数×2

  • maximumPoolSize：最大线程数选择了和核心线程数相同

  • keepAliveTime：非核心闲置线程存活时间直接置为0

  • unit：非核心线程保持存活的时间选择了 TimeUnit.SECONDS 秒

  • workQueue：线程池等待队列，使用 LinkedBlockingQueue阻塞队列

同时还用了synchronized 来加锁，保证数据不会被重复推送

线程池拒绝策略

  • AbortPolicy ：直接抛出异常，默认使用此策略
  • CallerRunsPolicy：用调用者所在的线程来执行任务
  • DiscardOldestPolicy：丢弃阻塞队列里最老的任务，也就是队列里靠前的任务
  • DiscardPolicy ：当前任务直接丢弃

想实现自己的拒绝策略，实现RejectedExecutionHandler接口即可。

线程池有哪几种工作队列

常用的阻塞队列主要有以下几种：

线程池常用阻塞队列

  • ArrayBlockingQueue：ArrayBlockingQueue（有界队列）是一个用数组实现的有界阻塞队列，按FIFO排序量。
  • LinkedBlockingQueue：LinkedBlockingQueue（可设置容量队列）是基于链表结构的阻塞队列，按FIFO排序任务，容量可以选择进行设置，不设置的话，将是一个无边界的阻塞队列，最大长度为Integer.MAX_VALUE，吞吐量通常要高于ArrayBlockingQuene；newFixedThreadPool线程池使用了这个队列
  • DelayQueue：DelayQueue（延迟队列）是一个任务定时周期的延迟执行的队列。根据指定的执行时间从小到大排序，否则根据插入到队列的先后排序。newScheduledThreadPool线程池使用了这个队列。
  • PriorityBlockingQueue：PriorityBlockingQueue（优先级队列）是具有优先级的无界阻塞队列
  • SynchronousQueue：SynchronousQueue（同步队列）是一个不存储元素的阻塞队列，每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQuene，newCachedThreadPool线程池使用了这个队列。

线程池怎么关闭知道吗？

可以通过调用线程池的shutdown或shutdownNow方法来关闭线程池。它们的原理是遍历线程池中的工作线程，然后逐个调用线程的interrupt方法来中断线程，所以无法响应中断的任务可能永远无法终止。

shutdown() 将线程池状态置为shutdown,并不会立即停止：

  1. 停止接收外部submit的任务
  2. 内部正在跑的任务和队列里等待的任务，会执行完
  3. 等到第二步完成后，才真正停止

shutdownNow() 将线程池状态置为stop。一般会立即停止，事实上不一定：

  1. 和shutdown()一样，先停止接收外部提交的任务
  2. 忽略队列里等待的任务
  3. 尝试将正在跑的任务interrupt中断
  4. 返回未执行的任务列表

shutdown 和shutdownnow简单来说区别如下：

  • shutdownNow()能立即停止线程池，正在跑的和正在等待的任务都停下了。这样做立即生效，但是风险也比较大。
  • shutdown()只是关闭了提交通道，用submit()是无效的；而内部的任务该怎么跑还是怎么跑，跑完再彻底停止线程池。

线程池异常怎么处理知道吗

线程池异常处理

如何做线程复用

线程池的线程复用就是通过取 Worker 的 firstTask 或者通过 getTask 方法从 workQueue 中不停地取任务，并直接调用 Runnable 的 run 方法来执行任务，这样就保证了每个线程都始终在一个循环中，反复获取任务，然后执行任务，从而实现了线程的复用。

volatile

如何保证可见性和有序性

volatile有两个作用，保证可见性和有序性。

volatile怎么保证可见性的呢？

相比synchronized的加锁方式来解决共享变量的内存可见性问题，volatile就是更轻量的选择，它没有上下文切换的额外开销成本。

volatile可以确保对某个变量的更新对其他线程马上可见，一个变量被声明为volatile 时，线程在写入变量时不会把值缓存在寄存器或者其他地方，而是会把值刷新回主内存 当其它线程读取该共享变量 ，会从主内存重新获取最新值，而不是使用当前线程的本地内存中的值。

volatile怎么保证有序性的呢？

重排序可以分为编译器重排序和处理器重排序，valatile保证有序性，就是通过分别限制这两种类型的重排序。

volatile重排序规则表

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。

为什么不能保证原子性

原子性指的是，当某个线程正在执行某件事情的过程中，是不允许被外来线程打断的。也就是说，原子性的特点是要么不执行，一旦执行就必须全部执行完毕。而volatile是不能保证原子性的，即执行过程中是可以被其他线程打断甚至是加塞的。

所以，volatile变量的原子性与synchronized的原子性是不同的。synchronized的原子性是指，只要声明为synchronized的方法或代码块，在执行上就是原子操作的。而volatile是不修饰方法或代码块的，它只用来修饰变量，对于单个volatile变量的读和写操作都具有原子性，但类似于volatile++这种复合操作不具有原子性。所以volatile的原子性是受限制的。并且在多线程环境中，volatile并不能保证原子性。

如何保证原子性

方式一：方法上加 synchronized 关键字。

方式二：利用AtomicInteger类实现原子性

import java.util.concurrent.atomic.AtomicInteger;

/**
 * 变量上加了volatile关键字 ，
 * 但 不能保证原子性 的 解决方式。
 */
public class Test2 {
    
    

    volatile int number = 0;

    //解决方式一：方法上加 synchronized 关键字
    public void add(){
    
    
        number++;
    }

    //解决方式二：如下
    AtomicInteger atomicInteger = new AtomicInteger();
    public void addMyAtomic(){
    
    
        //每调用一次此方法，加个一。
        atomicInteger.getAndIncrement();
    }



    public static void main(String[] args) {
    
    
        Test2 test2 = new Test2();


        //创建10个线程
        for (int i = 0;i < 10;i++){
    
    
            new Thread(() -> {
    
    
                //每个线程执行1001次+1操作
                for (int j = 0;j<100;j++){
    
    
                    test2.add();//调用不能保证原子性的方法
                    test2.addMyAtomic();//调用可以保证原子性的方法。
                }
            },"Thread_"+(i+1)).start();
        }

        //如果正在运行的线程数>2个(除了main线程和GC线程以外，还有其他线程正在运行)
        while(Thread.activeCount() >2){
    
    
            Thread.yield();//礼让其他线程，暂不执行后续程序
        }

        System.out.println("执行 1000次 +1操作后，number = "+test2.number);
        System.out.println("执行 1000次 +1操作后，atomicInteger = "+test2.atomicInteger);

    }
}

image-20230308015735948

你先跟我举几个实际volatile 实际项目中的例子

比如我们工程中经常用一个变量标识程序是否启动、初始化完成、是否停止等

img

volatile 很适合只有一个线程修改，其他线程读取的情况。volatile 变量被修改之后，对其他线程立即可见。

比如这是一个带前端交互的系统，有A、 B二个线程，用户点了停止应用按钮，A 线程调用shutdown() 方法，让变量shutdown 从false 变成 true，但是因为没有使用volatile 修饰, B 线程可能感知不到shutdown 的变化，而继续执行 doWork 内的循环，这样违背了程序的意愿：当shutdown 变量为true 时，代表应用该停下了，doWork函数应该跳出循环，不再执行。

线程通信方式

  • volatile 基于共享内存

关键字volatile可以用来修饰字段（成员变量），就是告知程序任何对该变量的访问均需要从共享内存中获取，而对它的改变必须同步刷新回共享内存，它能保证所有线程对变量访问的可见性。

多个线程同时监听一个变量，当该变量发生变化的时候，线程能够感知并执行相应的业务。这是最简单的一种实现方式

    @Test
    public void t1() {
    
    
        List<String> list = new ArrayList<>();
        //线程A
        Thread threadA = new Thread(() -> {
    
    
            for (int i = 1; i <= 10; i++) {
    
    
                list.add("abc");
                System.out.println("线程A添加元素，此时list的size为：" + list.size());
                try {
    
    
                    Thread.sleep(500);
                } catch (InterruptedException e) {
    
    
                    e.printStackTrace();
                }
                if (list.size() == 5)
                    notice = true;
            }
        });
        //线程B
        Thread threadB = new Thread(() -> {
    
    
            while (true) {
    
    
                if (notice) {
    
    
                    System.out.println("线程B收到通知，开始执行自己的业务...");
                    break;
                }
            }
        });
        //需要先启动线程B
        threadB.start();
        try {
    
    
            Thread.sleep(1000);
        } catch (InterruptedException e) {
    
    
            e.printStackTrace();
        }
        // 再启动线程A
        threadA.start();
    }
  • wait,notify,notifyall

注意：wait()/notify()/notifyAll() 必须配合 synchronized 使用，wait 方法释放锁，notify 方法不释放锁。wait 是指在一个已经进入了同步锁的线程内，让自己暂时让出同步锁，以便其他正在等待此锁的线程可以得到同步锁并运行，只有其他线程调用了notify()notify并不释放锁，只是告诉调用过wait()的线程可以去参与获得锁的竞争了，但不会马上得到锁，因为锁还在别人手里，别人还没释放，调用 wait() 的一个或多个线程才会解除 wait 状态，重新参与竞争对象锁，程序如果可以再次得到锁，就可以继续向下运行

public class TestSync {
    
    
    public static void main(String[] args) {
    
    
        //定义一个锁对象
        Object lock = new Object();
        List<String>  list = new ArrayList<>();
        // 线程A
        Thread threadA = new Thread(() -> {
    
    
            synchronized (lock) {
    
    
                for (int i = 1; i <= 10; i++) {
    
    
                    list.add("abc");
                    System.out.println("线程A添加元素，此时list的size为：" + list.size());
                    try {
    
    
                        Thread.sleep(500);
                    } catch (InterruptedException e) {
    
    
                        e.printStackTrace();
                    }
                    if (list.size() == 5)
                        lock.notify();//唤醒B线程
                }
            }
        });
        //线程B
        Thread threadB = new Thread(() -> {
    
    
            while (true) {
    
    
                synchronized (lock) {
    
    
                    if (list.size() != 5) {
    
    
                        try {
    
    
                            lock.wait();
                        } catch (InterruptedException e) {
    
    
                            e.printStackTrace();
                        }
                    }
                    System.out.println("线程B收到通知，开始执行自己的业务...");
                }
            }
        });
        //需要先启动线程B
        threadB.start();
        try {
    
    
            Thread.sleep(1000);
        } catch (InterruptedException e) {
    
    
            e.printStackTrace();
        }
        //再启动线程A
        threadA.start();
    }
}

juc并发包

CountdownLatch 实现计数器功能，可以用来控制等待多个线程执行任务后进行汇总。

AtomicInteger类是系统底层保护的int类型，通过对int类型的数据进行封装，提供执行方法的控制进行值的原子操作，AtomicInteger它不能当作Integer来使用，想让线程安全，往往可能需要通过加锁的方式去保证线程安全，但是，加锁对性能会有很大的影响；而AtomicInteger原子类型就是让程序在不加锁的时候也能保障线程安全。

  static int b =0;
   public static void main(String[] args) throws InterruptedException {
    
    

       AtomicInteger a = new AtomicInteger(0);
        Thread t1 = new Thread(new Runnable() {
    
    
            @Override
            public void run() {
    
    
                for (int i = 0; i < 10000; i++) {
    
    
                    a.incrementAndGet();
                   b++;
                }
                
            }
        });
        t1.start();
       Thread t2 = new Thread(new Runnable() {
    
    
           @Override
           public void run() {
    
    
               for (int i = 0; i < 10000; i++) {
    
    
                   a.incrementAndGet();
                   b++;
               }
           }
       });
       t2.start();
        Thread.sleep(1000);
       System.out.println("a="+a);
       System.out.println("b="+b);
   }

image-20230223151845308

Tomcat线程池

Tomcat 的实现就是为了，线程池即使核心线程数满了以后，且使用无界队列的时候，线程池依然有机会创建新的线程，直到达到线程池的最大线程数。

处理逻辑

如果当前运行的线程，少于corePoolSize，则创建一个新的线程来执行任务。

如果线程数大于 corePoolSize了，Tomcat 的线程不会直接把线程加入到无界的阻塞队列中，而是去判断，submittedCount（已经提交线程数）是否等于 maximumPoolSize。

如果等于，表示线程池已经满负荷运行，不能再创建线程了，直接把线程提交到队列，

如果不等于，则需要判断，是否有空闲线程可以消费。

如果有空闲线程则加入到阻塞队列中，等待空闲线程消费。

如果没有空闲线程，尝试创建新的线程。（这一步保证了使用无界队列，仍然可以利用线程的 maximumPoolSize）。

如果总线程数达到 maximumPoolSize，则继续尝试把线程加入 BlockingQueue 中。

如果 BlockingQueue 达到上限（假如设置了上限），被默认线程池启动拒绝策略，tomcat 线程池会 catch 住拒绝策略抛出的异常，再次把尝试任务加入中 BlockingQueue 中。

再次加入失败，启动拒绝策略。

Java中的四大引用

1 强引用

我们平常使用new操作符来创建的对象就是强引用对象，只要有一个引用存在，垃圾回收器永远不可能回收具有强引用的对象。

2 软引用

软引用是用来描述一些还有用但并非必须的对象。当内存充足时，垃圾回收器不会清理具有软引用的对象，只有当内存不足时垃圾回收器才会去清理这些对象，如果清理完软引用的对象后内存还是不足才会抛出异常。

3 弱引用

无论内存够不够，只要垃圾回收器启动，弱引用关联的对象肯定被回收。

4 虚引用

虚引用，又称作幻象引用，如果一个对象具有虚引用，那么它和没有任何引用一样，被虚引用关联的对象引用通过get方法获取到的永远为null，也就是说这种对象在任何时候都有可能被垃圾回收器回收，通过这种方式关联的对象也无法调用对象中的方法。虚引用主要是用来管理堆外内存的，通过ReferenceQueue这个类实现，当一个对象被回收的时候，会向这个引用队列里面添加相关数据，给一个通知。

RocketMQ

2.为什么要选择RocketMQ?

市场上几大消息队列对比如下：

四大消息队列对比

总结一下：

选择中间件的可以从这些维度来考虑：可靠性，性能，功能，可运维行，可拓展性，社区活跃度。目前常用的几个中间件，ActiveMQ作为“老古董”，市面上用的已经不多，其它几种：

  • RabbitMQ：
  • 优点：轻量，迅捷，容易部署和使用，拥有灵活的路由配置
  • 缺点：性能和吞吐量不太理想，不易进行二次开发
  • RocketMQ：
  • 优点：性能好，高吞吐量，稳定可靠，有活跃的中文社区
  • 缺点：兼容性上不是太好
  • Kafka：
  • 优点：拥有强大的性能及吞吐量，兼容性很好
  • 缺点：由于“攒一波再处理”导致延迟比较高

我们的系统是面向用户的C端系统，具有一定的并发量，对性能也有比较高的要求，所以选择了低延迟、吞吐量比较高，可用性比较好的RocketMQ。

3.RocketMQ有什么优缺点？

RocketMQ优点：

  • 单机吞吐量：十万级
  • 可用性：非常高，分布式架构
  • 消息可靠性：经过参数优化配置，消息可以做到0丢失
  • 功能支持：MQ功能较为完善，还是分布式的，扩展性好
  • 支持10亿级别的消息堆积，不会因为堆积导致性能下降
  • 源码是Java，方便结合公司自己的业务二次开发
  • 天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况
  • RoketMQ在稳定性上可能更值得信赖，这些业务场景在阿里双11已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择RocketMQ

RocketMQ缺点：

  • 支持的客户端语言不多，目前是Java及c++，其中c++不成熟
  • 没有在 MQ核心中去实现JMS等接口，有些系统要迁移需要修改大量代码

4.消息队列有哪些消息模型？

消息队列有两种模型：队列模型和发布/订阅模型。

  • 队列模型

这是最初的一种消息队列模型，对应着消息队列“发-存-收”的模型。生产者往某个队列里面发送消息，一个队列可以存储多个生产者的消息，一个队列也可以有多个消费者，但是消费者之间是竞争关系，也就是说每条消息只能被一个消费者消费。

队列模型

  • 发布/订阅模型

如果需要将一份消息数据分发给多个消费者，并且每个消费者都要求收到全量的消息。很显然，队列模型无法满足这个需求。解决的方式就是发布/订阅模型。

在发布 - 订阅模型中，消息的发送方称为发布者（Publisher），消息的接收方称为订阅者（Subscriber），服务端存放消息的容器称为主题（Topic）。发布者将消息发送到主题中，订阅者在接收消息之前需要先“订阅主题”。“订阅”在这里既是一个动作，同时还可以认为是主题在消费时的一个逻辑副本，每份订阅中，订阅者都可以接收到主题的所有消息。

发布-订阅模型

它和 “队列模式” 的异同：生产者就是发布者，队列就是主题，消费者就是订阅者，无本质区别。唯一的不同点在于：一份消息数据是否可以被多次消费。

5.那RocketMQ的消息模型呢？

RocketMQ使用的消息模型是标准的发布-订阅模型，在RocketMQ的术语表中，生产者、消费者和主题，与发布-订阅模型中的概念是完全一样的。

RocketMQ本身的消息是由下面几部分组成：

RocketMQ消息的组成

  • Message

Message（消息）就是要传输的信息。

一条消息必须有一个主题（Topic），主题可以看做是你的信件要邮寄的地址。

一条消息也可以拥有一个可选的标签（Tag）和额处的键值对，它们可以用于设置一个业务 Key 并在 Broker 上查找此消息以便在开发期间查找问题。

  • Topic

Topic（主题）可以看做消息的归类，它是消息的第一级类型。比如一个电商系统可以分为：交易消息、物流消息等，一条消息必须有一个 Topic 。

Topic 与生产者和消费者的关系非常松散，一个 Topic 可以有0个、1个、多个生产者向其发送消息，一个生产者也可以同时向不同的 Topic 发送消息。

一个 Topic 也可以被 0个、1个、多个消费者订阅。

  • Tag

Tag（标签）可以看作子主题，它是消息的第二级类型，用于为用户提供额外的灵活性。使用标签，同一业务模块不同目的的消息就可以用相同 Topic 而不同的 Tag 来标识。比如交易消息又可以分为：交易创建消息、交易完成消息等，一条消息可以没有 Tag 。

标签有助于保持你的代码干净和连贯，并且还可以为 RocketMQ 提供的查询系统提供帮助。

  • Group

RocketMQ中，订阅者的概念是通过消费组（Consumer Group）来体现的。每个消费组都消费主题中一份完整的消息，不同消费组之间消费进度彼此不受影响，也就是说，一条消息被Consumer Group1消费过，也会再给Consumer Group2消费。

消费组中包含多个消费者，同一个组内的消费者是竞争消费的关系，每个消费者负责消费组内的一部分消息。默认情况，如果一条消息被消费者Consumer1消费了，那同组的其他消费者就不会再收到这条消息。

  • Message Queue

Message Queue（消息队列），一个 Topic 下可以设置多个消息队列，Topic 包括多个 Message Queue ，如果一个 Consumer 需要获取 Topic下所有的消息，就要遍历所有的 Message Queue。

RocketMQ还有一些其它的Queue——例如ConsumerQueue。

  • Offset

在Topic的消费过程中，由于消息需要被不同的组进行多次消费，所以消费完的消息并不会立即被删除，这就需要RocketMQ为每个消费组在每个队列上维护一个消费位置（Consumer Offset），这个位置之前的消息都被消费过，之后的消息都没有被消费过，每成功消费一条消息，消费位置就加一。

也可以这么说，Queue 是一个长度无限的数组，Offset 就是下标。

RocketMQ的消息模型中，这些就是比较关键的概念了。画张图总结一下：

img

6.消息的消费模式了解吗？

消息消费模式有两种：Clustering（集群消费）和Broadcasting（广播消费）。

两种消费模式

默认情况下就是集群消费，这种模式下一个消费者组共同消费一个主题的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。

而广播消费消息会发给消费者组中的每一个消费者进行消费。

7.RoctetMQ基本架构了解吗？

先看图，RocketMQ的基本架构：

RocketMQ架构

RocketMQ 一共有四个部分组成：NameServer，Broker，Producer 生产者，Consumer 消费者，它们对应了：发现、发、存、收，为了保证高可用，一般每一部分都是集群部署的。

8.那能介绍一下这四部分吗？

类比一下我们生活的邮政系统——

邮政系统要正常运行，离不开下面这四个角色， 一是发信者，二 是收信者， 三是负责暂存传输的邮局， 四是负责协调各个地方邮局的管理机构。对应到 RocketMQ 中，这四个角色就是 Producer、 Consumer、 Broker 、NameServer。

RocketMQ类比邮政体系

NameServer

NameServer 是一个无状态的服务器，角色类似于 Kafka使用的 Zookeeper，但比 Zookeeper 更轻量。

特点：

  • 每个 NameServer 结点之间是相互独立，彼此没有任何信息交互。
  • Nameserver 被设计成几乎是无状态的，通过部署多个结点来标识自己是一个伪集群，Producer 在发送消息前从 NameServer 中获取 Topic 的路由信息也就是发往哪个 Broker，Consumer 也会定时从 NameServer 获取 Topic 的路由信息，Broker 在启动时会向 NameServer 注册，并定时进行心跳连接，且定时同步维护的 Topic 到 NameServer。

功能主要有两个：

  • 1、和Broker 结点保持长连接。
  • 2、维护 Topic 的路由信息。
Broker

消息存储和中转角色，负责存储和转发消息。

  • Broker 内部维护着一个个 Consumer Queue，用来存储消息的索引，真正存储消息的地方是 CommitLog（日志文件）。

RocketMQ存储-图片来源官网

  • 单个 Broker 与所有的 Nameserver 保持着长连接和心跳，并会定时将 Topic 信息同步到 NameServer，和 NameServer 的通信底层是通过 Netty 实现的。
Producer

消息生产者，业务端负责发送消息，由用户自行实现和分布式部署。

  • Producer由用户进行分布式部署，消息由Producer通过多种负载均衡模式发送到Broker集群，发送低延时，支持快速失败。
  • RocketMQ 提供了三种方式发送消息：同步、异步和单向
  • 同步发送：同步发送指消息发送方发出数据后会在收到接收方发回响应之后才发下一个数据包。一般用于重要通知消息，例如重要通知邮件、营销短信。
  • 异步发送：异步发送指发送方发出数据后，不等接收方发回响应，接着发送下个数据包，一般用于可能链路耗时较长而对响应时间敏感的业务场景，例如用户视频上传后通知启动转码服务。
  • 单向发送：单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发，适用于某些耗时非常短但对可靠性要求并不高的场景，例如日志收集。
Consumer

消息消费者，负责消费消息，一般是后台系统负责异步消费。

  • Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费和广播消费，提供实时的消息订阅机制。
  • Pull：拉取型消费者（Pull Consumer）主动从消息服务器拉取信息，只要批量拉取到消息，用户应用就会启动消费过程，所以 Pull 称为主动消费型。
  • Push：推送型消费者（Push Consumer）封装了消息的拉取、消费进度和其他的内部维护工作，将消息到达时执行的回调接口留给用户应用程序来实现。所以 Push 称为被动消费类型，但其实从实现上看还是从消息服务器中拉取消息，不同于 Pull 的是 Push 首先要注册消费监听器，当监听器处触发后才开始消费消息。

进阶

9.如何保证消息的可用性/可靠性/不丢失呢？

消息可能在哪些阶段丢失呢？可能会在这三个阶段发生丢失：生产阶段、存储阶段、消费阶段。

所以要从这三个阶段考虑：

消息传递三阶段

生产

在生产阶段，主要通过请求确认机制，来保证消息的可靠传递。

  • 1、同步发送的时候，要注意处理响应结果和异常。如果返回响应OK，表示消息成功发送到了Broker，如果响应失败，或者发生其它异常，都应该重试。
  • 2、异步发送的时候，应该在回调方法里检查，如果发送失败或者异常，都应该进行重试。
  • 3、如果发生超时的情况，也可以通过查询日志的API，来检查是否在Broker存储成功。
存储

存储阶段，可以通过配置可靠性优先的 Broker 参数来避免因为宕机丢消息，简单说就是可靠性优先的场景都应该使用同步。

  • 1、消息只要持久化到CommitLog（日志文件）中，即使Broker宕机，未消费的消息也能重新恢复再消费。
  • 2、Broker的刷盘机制：同步刷盘和异步刷盘，不管哪种刷盘都可以保证消息一定存储在pagecache中（内存中），但是同步刷盘更可靠，它是Producer发送消息后等数据持久化到磁盘之后再返回响应给Producer。

同步刷盘和异步刷盘-图片来源官网

  • 3、Broker通过主从模式来保证高可用，Broker支持Master和Slave同步复制、Master和Slave异步复制模式，生产者的消息都是发送给Master，但是消费既可以从Master消费，也可以从Slave消费。同步复制模式可以保证即使Master宕机，消息肯定在Slave中有备份，保证了消息不会丢失。
消费

从Consumer角度分析，如何保证消息被成功消费？

  • Consumer保证消息成功消费的关键在于确认的时机，不要在收到消息后就立即发送消费确认，而是应该在执行完所有消费业务逻辑之后，再发送消费确认。因为消息队列维护了消费的位置，逻辑执行失败了，没有确认，再去队列拉取消息，就还是之前的一条。

10.如何处理消息重复的问题呢？

对分布式消息队列来说，同时做到确保一定投递和不重复投递是很难的，就是所谓的“有且仅有一次” 。RocketMQ择了确保一定投递，保证消息不丢失，但有可能造成消息重复。

处理消息重复问题，主要有业务端自己保证，主要的方式有两种：业务幂等和消息去重。

消息重复处理

业务幂等：第一种是保证消费逻辑的幂等性，也就是多次调用和一次调用的效果是一样的。这样一来，不管消息消费多少次，对业务都没有影响。

消息去重：第二种是业务端，对重复的消息就不再消费了。这种方法，需要保证每条消息都有一个惟一的编号，通常是业务相关的，比如订单号，消费的记录需要落库，而且需要保证和消息确认这一步的原子性。

具体做法是可以建立一个消费记录表，拿到这个消息做数据库的insert操作。给这个消息做一个唯一主键（primary key）或者唯一约束，那么就算出现重复消费的情况，就会导致主键冲突，那么就不再处理这条消息。

11.怎么处理消息积压？

发生了消息积压，这时候就得想办法赶紧把积压的消息消费完，就得考虑提高消费能力，一般有两种办法：

消息积压处理

  • 消费者扩容：如果当前Topic的Message Queue的数量大于消费者数量，就可以对消费者进行扩容，增加消费者，来提高消费能力，尽快把积压的消息消费玩。
  • 消息迁移Queue扩容：如果当前Topic的Message Queue的数量小于或者等于消费者数量，这种情况，再扩容消费者就没什么用，就得考虑扩容Message Queue。可以新建一个临时的Topic，临时的Topic多设置一些Message Queue，然后先用一些消费者把消费的数据丢到临时的Topic，因为不用业务处理，只是转发一下消息，还是很快的。接下来用扩容的消费者去消费新的Topic里的数据，消费完了之后，恢复原状。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-x9di1wua-1678634582882)(null)]

12.顺序消息如何实现？

顺序消息是指消息的消费顺序和产生顺序相同，在有些业务逻辑下，必须保证顺序，比如订单的生成、付款、发货，这个消息必须按顺序处理才行。

顺序消息

顺序消息分为全局顺序消息和部分顺序消息，全局顺序消息指某个 Topic 下的所有消息都要保证顺序；

部分顺序消息只要保证每一组消息被顺序消费即可，比如订单消息，只要保证同一个订单 ID 个消息能按顺序消费即可。

部分顺序消息

部分顺序消息相对比较好实现，生产端需要做到把同 ID 的消息发送到同一个 Message Queue ；在消费过程中，要做到从同一个Message Queue读取的消息顺序处理——消费端不能并发处理顺序消息，这样才能达到部分有序。

部分顺序消息

发送端使用 MessageQueueSelector 类来控制 把消息发往哪个 Message Queue 。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5avDGIQU-1678634576522)(https://camo.githubusercontent.com/a15bef253022797650e9ff6d58995aa2310e5b7ada0dbe459ad2a9e69e663afa/68747470733a2f2f63646e2e746f62656265747465726a61766165722e636f6d2f746f62656265747465726a61766165722f696d616765732f6e6963652d61727469636c652f77656978696e2d6d69616e7a6e78726f636b65746d71657373772d34616164383533652d346464372d346364652d623238642d6236653734636139333331662e6a7067)]

消费端通过使用 MessageListenerOrderly 来解决单 Message Queue 的消息被并发处理的问题。

img

全局顺序消息

RocketMQ 默认情况下不保证顺序，比如创建一个 Topic ，默认八个写队列，八个读队列，这时候一条消息可能被写入任意一个队列里；在数据的读取过程中，可能有多个 Consumer ，每个 Consumer 也可能启动多个线程并行处理，所以消息被哪个 Consumer 消费，被消费的顺序和写人的顺序是否一致是不确定的。

要保证全局顺序消息， 需要先把 Topic 的读写队列数设置为 一，然后Producer Consumer 的并发设置，也要是一。简单来说，为了保证整个 Topic全局消息有序，只能消除所有的并发处理，各部分都设置成单线程处理 ，这时候就完全牺牲RocketMQ的高并发、高吞吐的特性了。

全局顺序消息

13.如何实现消息过滤？

有两种方案：

  • 一种是在 Broker 端按照 Consumer 的去重逻辑进行过滤，这样做的好处是避免了无用的消息传输到 Consumer 端，缺点是加重了 Broker 的负担，实现起来相对复杂。
  • 另一种是在 Consumer 端过滤，比如按照消息设置的 tag 去重，这样的好处是实现起来简单，缺点是有大量无用的消息到达了 Consumer 端只能丢弃不处理。

一般采用Cosumer端过滤，如果希望提高吞吐量，可以采用Broker过滤。

对消息的过滤有三种方式：

消息过滤

  • 根据Tag过滤：这是最常见的一种，用起来高效简单
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_EXAMPLE");
consumer.subscribe("TOPIC", "TAGA || TAGB || TAGC");
  • SQL 表达式过滤：SQL表达式过滤更加灵活
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name_4");
// 只有订阅的消息有这个属性a, a >=0 and a <= 3
consumer.subscribe("TopicTest", MessageSelector.bySql("a between 0 and 3");
consumer.registerMessageListener(new MessageListenerConcurrently() {
   @Override
   public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
       return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
   }
});
consumer.start();
  • Filter Server 方式：最灵活，也是最复杂的一种方式，允许用户自定义函数进行过滤

14.延时消息了解吗？

电商的订单超时自动取消，就是一个典型的利用延时消息的例子，用户提交了一个订单，就可以发送一个延时消息，1h后去检查这个订单的状态，如果还是未付款就取消订单释放库存。

RocketMQ是支持延时消息的，只需要在生产消息的时候设置消息的延时级别：

// 实例化一个生产者来产生延时消息
DefaultMQProducer producer = new DefaultMQProducer("ExampleProducerGroup");
// 启动生产者
producer.start();
int totalMessagesToSend = 100;
for (int i = 0; i < totalMessagesToSend; i++) {
    Message message = new Message("TestTopic", ("Hello scheduled message " + i).getBytes());
    // 设置延时等级3,这个消息将在10s之后发送(现在只支持固定的几个时间,详看delayTimeLevel)
    message.setDelayTimeLevel(3);
    // 发送消息
    producer.send(message);
}

但是目前RocketMQ支持的延时级别是有限的：

private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";

RocketMQ怎么实现延时消息的？

简单，八个字：临时存储+定时任务。

Broker收到延时消息了，会先发送到主题（SCHEDULE_TOPIC_XXXX）的相应时间段的Message Queue中，然后通过一个定时任务轮询这些队列，到期后，把消息投递到目标Topic的队列中，然后消费者就可以正常消费这些消息。

延迟消息处理流程-图片来源见水印

15.怎么实现分布式消息事务的？半消息？

半消息：是指暂时还不能被 Consumer 消费的消息，Producer 成功发送到 Broker 端的消息，但是此消息被标记为 “暂不可投递” 状态，只有等 Producer 端执行完本地事务后经过二次确认了之后，Consumer 才能消费此条消息。

依赖半消息，可以实现分布式消息事务，其中的关键在于二次确认以及消息回查：

RocketMQ实现消息事务

  • 1、Producer 向 broker 发送半消息
  • 2、Producer 端收到响应，消息发送成功，此时消息是半消息，标记为 “不可投递” 状态，Consumer 消费不了。
  • 3、Producer 端执行本地事务。
  • 4、正常情况本地事务执行完成，Producer 向 Broker 发送 Commit/Rollback，如果是 Commit，Broker 端将半消息标记为正常消息，Consumer 可以消费，如果是 Rollback，Broker 丢弃此消息。
  • 5、异常情况，Broker 端迟迟等不到二次确认。在一定时间后，会查询所有的半消息，然后到 Producer 端查询半消息的执行情况。
  • 6、Producer 端查询本地事务的状态
  • 7、根据事务的状态提交 commit/rollback 到 broker 端。（5，6，7 是消息回查）
  • 8、消费者段消费到消息之后，执行本地事务，执行本地事务。

16.死信队列知道吗？

死信队列用于处理无法被正常消费的消息，即死信消息。

当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中，该特殊队列称为死信队列。

死信消息的特点：

  • 不会再被消费者正常消费。
  • 有效期与正常消息相同，均为 3 天，3 天后会被自动删除。因此，需要在死信消息产生后的 3 天内及时处理。

死信队列的特点：

  • 一个死信队列对应一个 Group ID， 而不是对应单个消费者实例。
  • 如果一个 Group ID 未产生死信消息，消息队列 RocketMQ 不会为其创建相应的死信队列。
  • 一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic。

RocketMQ 控制台提供对死信消息的查询、导出和重发的功能。

17.如何保证RocketMQ的高可用？

NameServer因为是无状态，且不相互通信的，所以只要集群部署就可以保证高可用。

NameServer集群

RocketMQ的高可用主要是在体现在Broker的读和写的高可用，Broker的高可用是通过集群和主从实现的。

Broker集群、主从示意图

Broker可以配置两种角色：Master和Slave，Master角色的Broker支持读和写，Slave角色的Broker只支持读，Master会向Slave同步消息。

也就是说Producer只能向Master角色的Broker写入消息，Cosumer可以从Master和Slave角色的Broker读取消息。

Consumer 的配置文件中，并不需要设置是从 Master 读还是从 Slave读，当 Master 不可用或者繁忙的时候， Consumer 的读请求会被自动切换到从 Slave。有了自动切换 Consumer 这种机制，当一个 Master 角色的机器出现故障后，Consumer 仍然可以从 Slave 读取消息，不影响 Consumer 读取消息，这就实现了读的高可用。

如何达到发送端写的高可用性呢？在创建 Topic 的时候，把 Topic 的多个Message Queue 创建在多个 Broker 组上（相同 Broker 名称，不同 brokerId机器组成 Broker 组），这样当 Broker 组的 Master 不可用后，其他组Master 仍然可用， Producer 仍然可以发送消息 RocketMQ 目前还不支持把Slave自动转成 Master ，如果机器资源不足，需要把 Slave 转成 Master ，则要手动停止 Slave 色的 Broker ，更改配置文件，用新的配置文件启动 Broker。

原理

18.说一下RocketMQ的整体工作流程？

简单来说，RocketMQ是一个分布式消息队列，也就是消息队列+分布式系统。

作为消息队列，它是发-存-收的一个模型，对应的就是Producer、Broker、Cosumer；作为分布式系统，它要有服务端、客户端、注册中心，对应的就是Broker、Producer/Consumer、NameServer

所以我们看一下它主要的工作流程：RocketMQ由NameServer注册中心集群、Producer生产者集群、Consumer消费者集群和若干Broker（RocketMQ进程）组成：

  1. Broker在启动的时候去向所有的NameServer注册，并保持长连接，每30s发送一次心跳
  2. Producer在发送消息的时候从NameServer获取Broker服务器地址，根据负载均衡算法选择一台服务器来发送消息
  3. Conusmer消费消息的时候同样从NameServer获取Broker地址，然后主动拉取消息来消费

RocketMQ整体工作流程

19.为什么RocketMQ不使用Zookeeper作为注册中心呢？

Kafka我们都知道采用Zookeeper作为注册中心——当然也开始逐渐去Zookeeper，RocketMQ不使用Zookeeper其实主要可能从这几方面来考虑：

  1. 基于可用性的考虑，根据CAP理论，同时最多只能满足两个点，而Zookeeper满足的是CP，也就是说Zookeeper并不能保证服务的可用性，Zookeeper在进行选举的时候，整个选举的时间太长，期间整个集群都处于不可用的状态，而这对于一个注册中心来说肯定是不能接受的，作为服务发现来说就应该是为可用性而设计。
  2. 基于性能的考虑，NameServer本身的实现非常轻量，而且可以通过增加机器的方式水平扩展，增加集群的抗压能力，而Zookeeper的写是不可扩展的，Zookeeper要解决这个问题只能通过划分领域，划分多个Zookeeper集群来解决，首先操作起来太复杂，其次这样还是又违反了CAP中的A的设计，导致服务之间是不连通的。
  3. 持久化的机制来带的问题，ZooKeeper 的 ZAB 协议对每一个写请求，会在每个 ZooKeeper 节点上保持写一个事务日志，同时再加上定期的将内存数据镜像（Snapshot）到磁盘来保证数据的一致性和持久性，而对于一个简单的服务发现的场景来说，这其实没有太大的必要，这个实现方案太重了。而且本身存储的数据应该是高度定制化的。
  4. 消息发送应该弱依赖注册中心，而RocketMQ的设计理念也正是基于此，生产者在第一次发送消息的时候从NameServer获取到Broker地址后缓存到本地，如果NameServer整个集群不可用，短时间内对于生产者和消费者并不会产生太大影响。

20.Broker是怎么保存数据的呢？

RocketMQ主要的存储文件包括CommitLog文件、ConsumeQueue文件、Indexfile文件。

img

消息存储的整体的设计：

消息存储整体设计-来源官网

  • CommitLog：消息主体以及元数据的存储主体，存储Producer端写入的消息主体内容,消息内容不是定长的。单个文件大小默认1G, 文件名长度为20位，左边补零，剩余为起始偏移量，比如00000000000000000000代表了第一个文件，起始偏移量为0，文件大小为1G=1073741824；当第一个文件写满了，第二个文件为00000000001073741824，起始偏移量为1073741824，以此类推。消息主要是顺序写入日志文件，当文件满了，写入下一个文件。

CommitLog文件保存于${Rocket_Home}/store/commitlog目录中，从图中我们可以明显看出来文件名的偏移量，每个文件默认1G，写满后自动生成一个新的文件。

CommitLog

  • ConsumeQueue：消息消费队列，引入的目的主要是提高消息消费的性能，由于RocketMQ是基于主题topic的订阅模式，消息消费是针对主题进行的，如果要遍历commitlog文件中根据topic检索消息是非常低效的。

Consumer即可根据ConsumeQueue来查找待消费的消息。其中，ConsumeQueue（逻辑消费队列）作为消费消息的索引，保存了指定Topic下的队列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的HashCode值。

ConsumeQueue文件可以看成是基于Topic的CommitLog索引文件，故ConsumeQueue文件夹的组织方式如下：topic/queue/file三层组织结构，具体存储路径为：$HOME/store/consumequeue/{topic}/{queueId}/{fileName}。同样ConsumeQueue文件采取定长设计，每一个条目共20个字节，分别为8字节的CommitLog物理偏移量、4字节的消息长度、8字节tag hashcode，单个文件由30W个条目组成，可以像数组一样随机访问每一个条目，每个ConsumeQueue文件大小约5.72M；

Comsumer Queue

  • IndexFile：IndexFile（索引文件）提供了一种可以通过key或时间区间来查询消息的方法。Index文件的存储位置是： {fileName}，文件名fileName是以创建时的时间戳命名的，固定的单个IndexFile文件大小约为400M，一个IndexFile可以保存 2000W个索引，IndexFile的底层存储设计为在文件系统中实现HashMap结构，故RocketMQ的索引文件其底层实现为hash索引。

IndexFile文件示意图

总结一下：RocketMQ采用的是混合型的存储结构，即为Broker单个实例下所有的队列共用一个日志数据文件（即为CommitLog）来存储。

RocketMQ的混合型存储结构(多个Topic的消息实体内容都存储于一个CommitLog中)针对Producer和Consumer分别采用了数据和索引部分相分离的存储结构，Producer发送消息至Broker端，然后Broker端使用同步或者异步的方式对消息刷盘持久化，保存至CommitLog中。

只要消息被刷盘持久化至磁盘文件CommitLog中，那么Producer发送的消息就不会丢失。正因为如此，Consumer也就肯定有机会去消费这条消息。当无法拉取到消息后，可以等下一次消息拉取，同时服务端也支持长轮询模式，如果一个消息拉取请求未拉取到消息，Broker允许等待30s的时间，只要这段时间内有新消息到达，将直接返回给消费端。

这里，RocketMQ的具体做法是，使用Broker端的后台服务线程—ReputMessageService不停地分发请求并异步构建ConsumeQueue（逻辑消费队列）和IndexFile（索引文件）数据。

img

21.说说RocketMQ怎么对文件进行读写的？

RocketMQ对文件的读写巧妙地利用了操作系统的一些高效文件读写方式——PageCache、顺序读写、零拷贝。

  • PageCache、顺序读取

在RocketMQ中，ConsumeQueue逻辑消费队列存储的数据较少，并且是顺序读取，在page cache机制的预读取作用下，Consume Queue文件的读性能几乎接近读内存，即使在有消息堆积情况下也不会影响性能。而对于CommitLog消息存储的日志数据文件来说，读取消息内容时候会产生较多的随机访问读取，严重影响性能。如果选择合适的系统IO调度算法，比如设置调度算法为“Deadline”（此时块存储采用SSD的话），随机读的性能也会有所提升。

页缓存（PageCache)是OS对文件的缓存，用于加速对文件的读写。一般来说，程序对文件进行顺序读写的速度几乎接近于内存的读写速度，主要原因就是由于OS使用PageCache机制对读写访问操作进行了性能优化，将一部分的内存用作PageCache。对于数据的写入，OS会先写入至Cache内，随后通过异步的方式由pdflush内核线程将Cache内的数据刷盘至物理磁盘上。对于数据的读取，如果一次读取文件时出现未命中PageCache的情况，OS从物理磁盘上访问读取文件的同时，会顺序对其他相邻块的数据文件进行预读取。

  • 零拷贝

另外，RocketMQ主要通过MappedByteBuffer对文件进行读写操作。其中，利用了NIO中的FileChannel模型将磁盘上的物理文件直接映射到用户态的内存地址中（这种Mmap的方式减少了传统IO，将磁盘文件数据在操作系统内核地址空间的缓冲区，和用户应用程序地址空间的缓冲区之间来回进行拷贝的性能开销），将对文件的操作转化为直接对内存地址进行操作，从而极大地提高了文件的读写效率（正因为需要使用内存映射机制，故RocketMQ的文件存储都使用定长结构来存储，方便一次将整个文件映射至内存）。

说说什么是零拷贝?

在操作系统中，使用传统的方式，数据需要经历几次拷贝，还要经历用户态/内核态切换。

传统文件传输示意图-来源《图解操作系统》

  1. 从磁盘复制数据到内核态内存；
  2. 从内核态内存复制到用户态内存；
  3. 然后从用户态内存复制到网络驱动的内核态内存；
  4. 最后是从网络驱动的内核态内存复制到网卡中进行传输。

所以，可以通过零拷贝的方式，减少用户态与内核态的上下文切换和内存拷贝的次数，用来提升I/O的性能。零拷贝比较常见的实现方式是mmap，这种机制在Java中是通过MappedByteBuffer实现的。

mmap示意图-来源《图解操作系统》

22.消息刷盘怎么实现的呢？

RocketMQ提供了两种刷盘策略：同步刷盘和异步刷盘

  • 同步刷盘：在消息达到Broker的内存之后，必须刷到commitLog日志文件中才算成功，然后返回Producer数据已经发送成功。
  • 异步刷盘：异步刷盘是指消息达到Broker内存后就返回Producer数据已经发送成功，会唤醒一个线程去将数据持久化到CommitLog日志文件中。

Broker 在消息的存取时直接操作的是内存（内存映射文件），这可以提供系统的吞吐量，但是无法避免机器掉电时数据丢失，所以需要持久化到磁盘中。

刷盘的最终实现都是使用NIO中的 MappedByteBuffer.force() 将映射区的数据写入到磁盘，如果是同步刷盘的话，在Broker把消息写到CommitLog映射区后，就会等待写入完成。

异步而言，只是唤醒对应的线程，不保证执行的时机，流程如图所示。

异步刷盘

22.能说下 RocketMQ 的负载均衡是如何实现的？

RocketMQ中的负载均衡都在Client端完成，具体来说的话，主要可以分为Producer端发送消息时候的负载均衡和Consumer端订阅消息的负载均衡。

Producer的负载均衡

Producer端在发送消息的时候，会先根据Topic找到指定的TopicPublishInfo，在获取了TopicPublishInfo路由信息后，RocketMQ的客户端在默认方式下selectOneMessageQueue()方法会从TopicPublishInfo中的messageQueueList中选择一个队列（MessageQueue）进行发送消息。具这里有一个sendLatencyFaultEnable开关变量，如果开启，在随机递增取模的基础上，再过滤掉not available的Broker代理。

img

所谓的"latencyFaultTolerance"，是指对之前失败的，按一定的时间做退避。例如，如果上次请求的latency超过550Lms，就退避3000Lms；超过1000L，就退避60000L；如果关闭，采用随机递增取模的方式选择一个队列（MessageQueue）来发送消息，latencyFaultTolerance机制是实现消息发送高可用的核心关键所在。

Consumer的负载均衡

在RocketMQ中，Consumer端的两种消费模式（Push/Pull）都是基于拉模式来获取消息的，而在Push模式只是对pull模式的一种封装，其本质实现为消息拉取线程在从服务器拉取到一批消息后，然后提交到消息消费线程池后，又“马不停蹄”的继续向服务器再次尝试拉取消息。如果未拉取到消息，则延迟一下又继续拉取。在两种基于拉模式的消费方式（Push/Pull）中，均需要Consumer端知道从Broker端的哪一个消息队列中去获取消息。因此，有必要在Consumer端来做负载均衡，即Broker端中多个MessageQueue分配给同一个ConsumerGroup中的哪些Consumer消费。

  1. Consumer端的心跳包发送

在Consumer启动后，它就会通过定时任务不断地向RocketMQ集群中的所有Broker实例发送心跳包（其中包含了，消息消费分组名称、订阅关系集合、消息通信模式和客户端id的值等信息）。Broker端在收到Consumer的心跳消息后，会将它维护在ConsumerManager的本地缓存变量—consumerTable，同时并将封装后的客户端网络通道信息保存在本地缓存变量—channelInfoTable中，为之后做Consumer端的负载均衡提供可以依据的元数据信息。

  1. Consumer端实现负载均衡的核心类—RebalanceImpl

在Consumer实例的启动流程中的启动MQClientInstance实例部分，会完成负载均衡服务线程—RebalanceService的启动（每隔20s执行一次）。

通过查看源码可以发现，RebalanceService线程的run()方法最终调用的是RebalanceImpl类的rebalanceByTopic()方法，这个方法是实现Consumer端负载均衡的核心。

rebalanceByTopic()方法会根据消费者通信类型为“广播模式”还是“集群模式”做不同的逻辑处理。这里主要来看下集群模式下的主要处理流程：

img

(1) 从rebalanceImpl实例的本地缓存变量—topicSubscribeInfoTable中，获取该Topic主题下的消息消费队列集合（mqSet）；

(2) 根据topic和consumerGroup为参数调用mQClientFactory.findConsumerIdList()方法向Broker端发送通信请求，获取该消费组下消费者Id列表；

(3) 先对Topic下的消息消费队列、消费者Id排序，然后用消息队列分配策略算法（默认为：消息队列的平均分配算法），计算出待拉取的消息队列。这里的平均分配算法，类似于分页的算法，将所有MessageQueue排好序类似于记录，将所有消费端Consumer排好序类似页数，并求出每一页需要包含的平均size和每个页面记录的范围range，最后遍历整个range而计算出当前Consumer端应该分配到的的MessageQueue。

Cosumer分配

(4) 然后，调用updateProcessQueueTableInRebalance()方法，具体的做法是，先将分配到的消息队列集合（mqSet）与processQueueTable做一个过滤比对。

img

  • 上图中processQueueTable标注的红色部分，表示与分配到的消息队列集合mqSet互不包含。将这些队列设置Dropped属性为true，然后查看这些队列是否可以移除出processQueueTable缓存变量，这里具体执行removeUnnecessaryMessageQueue()方法，即每隔1s 查看是否可以获取当前消费处理队列的锁，拿到的话返回true。如果等待1s后，仍然拿不到当前消费处理队列的锁则返回false。如果返回true，则从processQueueTable缓存变量中移除对应的Entry；
  • 上图中processQueueTable的绿色部分，表示与分配到的消息队列集合mqSet的交集。判断该ProcessQueue是否已经过期了，在Pull模式的不用管，如果是Push模式的，设置Dropped属性为true，并且调用removeUnnecessaryMessageQueue()方法，像上面一样尝试移除Entry；
  • 最后，为过滤后的消息队列集合（mqSet）中的每个MessageQueue创建一个ProcessQueue对象并存入RebalanceImpl的processQueueTable队列中（其中调用RebalanceImpl实例的computePullFromWhere(MessageQueue mq)方法获取该MessageQueue对象的下一个进度消费值offset，随后填充至接下来要创建的pullRequest对象属性中），并创建拉取请求对象—pullRequest添加到拉取列表—pullRequestList中，最后执行dispatchPullRequest()方法，将Pull消息的请求对象PullRequest依次放入PullMessageService服务线程的阻塞队列pullRequestQueue中，待该服务线程取出后向Broker端发起Pull消息的请求。其中，可以重点对比下，RebalancePushImpl和RebalancePullImpl两个实现类的dispatchPullRequest()方法不同，RebalancePullImpl类里面的该方法为空。

消息消费队列在同一消费组不同消费者之间的负载均衡，其核心设计理念是在一个消息消费队列在同一时间只允许被同一消费组内的一个消费者消费，一个消息消费者能同时消费多个消息队列。

23.RocketMQ消息长轮询了解吗？

所谓的长轮询，就是Consumer 拉取消息，如果对应的 Queue 如果没有数据，Broker 不会立即返回，而是把 PullReuqest hold起来，等待 queue 有了消息后，或者长轮询阻塞时间到了，再重新处理该 queue 上的所有 PullRequest。

长轮询简单示意图

  • PullMessageProcessor#processRequest
//如果没有拉到数据
case ResponseCode.PULL_NOT_FOUND:
// broker 和 consumer 都允许 suspend，默认开启
if (brokerAllowSuspend && hasSuspendFlag) {
    long pollingTimeMills = suspendTimeoutMillisLong;
    if (!this.brokerController.getBrokerConfig().isLongPollingEnable()) {
        pollingTimeMills = this.brokerController.getBrokerConfig().getShortPollingTimeMills();
    }

    String topic = requestHeader.getTopic();
    long offset = requestHeader.getQueueOffset();
    int queueId = requestHeader.getQueueId();
    //封装一个PullRequest
    PullRequest pullRequest = new PullRequest(request, channel, pollingTimeMills,
            this.brokerController.getMessageStore().now(), offset, subscriptionData, messageFilter);
    //把PullRequest挂起来
    this.brokerController.getPullRequestHoldService().suspendPullRequest(topic, queueId, pullRequest);
    response = null;
    break;
}

挂起的请求，有一个服务线程会不停地检查，看queue中是否有数据，或者超时。

  • PullRequestHoldService#run()
@Override
public void run() {
    
    
    log.info("{} service started", this.getServiceName());
    while (!this.isStopped()) {
    
    
        try {
    
    
            if (this.brokerController.getBrokerConfig().isLongPollingEnable()) {
    
    
                this.waitForRunning(5 * 1000);
            } else {
    
    
                this.waitForRunning(this.brokerController.getBrokerConfig().getShortPollingTimeMills());
            }

            long beginLockTimestamp = this.systemClock.now();
            //检查hold住的请求
            this.checkHoldRequest();
            long costTime = this.systemClock.now() - beginLockTimestamp;
            if (costTime > 5 * 1000) {
    
    
                log.info("[NOTIFYME] check hold request cost {} ms.", costTime);
            }
        } catch (Throwable e) {
    
    
            log.warn(this.getServiceName() + " service has exception. ", e);
        }
    }

    log.info("{} service end", this.getServiceName());
}

猜你喜欢

转载自blog.csdn.net/greek7777/article/details/129483114
今日推荐
《美国对全球网络空间安全与发展的威胁和破坏》报告发布
火速冲上 GitHub 热榜 —— 开源编程语言、框架哪有这么可爱？
北京人形机器人创新中心发布全球首个纯电驱拟人奔跑的全尺寸人形机器人“天工”
LFOSSA 源来如此公开课 | 掌握云原生未来：CNCF 认证全面攻略与备考秘籍
国产云输入法——仅华为无云端数据上传安全问题
周排行
Python环境安装与基础语法（1）——计算机基础知识
IMU预积分
ADAS中的LDW、FCW、BSD、LCA、ACC、AEB、APA、DMS代表的含义
B站笔试两道题
skyeye arm 硬件虚拟机环境的搭建
Web前端静态页面示例
数组-合并排序数组 II-简单
springcloud之版本问题启动报错
面向对象-------------匿名对象(六)
输入URL到页面呈现中间发生了什么？
每日归档
更多
2024-04-30(1)
2024-04-29(40)
2024-04-28(0)
2024-04-27(56)
2024-04-26(39)
2024-04-25(22)
2024-04-24(36)
2024-04-23(26)
2024-04-22(39)
2024-04-21(0)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022