价值30K-----高级JAVA面试大纲

第一阶段，协调者收集参与者事务执行情况

客户端与zookeeper断开连接，节点依旧存在，不手动删除节点，永远存在

客户端与zookeeper断开连接，节点依旧存在，Zookeeper给该节点名称，进行顺序编号

客户端与zookeeper断开连接后，节点被删除

客户端与zookeeper断开连接，节点被删除，只是Zookeeper给该节点名称，进行顺序编号

3.5.3 版本新增，Container节点下面没有子节点，Container节点
在未来会被Zookeeper自动清除,定时任务默认，60s 检查一次

默认禁用，配置 zookeeper.extendedTypesEnabled=true 开启，不稳定

1，处理事务请求和非事务请求
2，集群内部各服务器调度者

1，处理客户端非事务请求，转发事务给Leader
2，参与事务请求Proposal（提案）投票
3，参与Leader选举投票

1，处理客户端非事务请求，转发事务请求给Leader
2，不参与leader选举，投票。写操作。
3，数据没有持久化到硬盘。Observer只会把数据加载到内存。

Zookeeper 节点状态

事务ID（zxid）

服务器ID（myid）

逻辑时钟（epoch logicalclock）

3台机器，启动到第2台时候，选举过程开始：
1、每Server一个投票。初始情况，ZK1 和 ZK2 将自己作 Leader 进行投票，投票包含推举服务器 myid 和 ZXID， ZK1 (1, 0)，ZK2 (2, 0)，投票发给集群其他机器。
2、接受各服务器投票。服务器收到投票，判断投票有效性，如：是否本轮投票、是否 LOOKING 状态服务器。
3、处理投票。服务器都需要将别人的投票和自己投票进行比较：
ZXID 较大服务器优先作 Leader
ZXID 相同，比较 myid。myid 较大服务器作为Leader服务器
ZK1 更新投票为(2, 0)，将投票重新发送 ZK2。
4、服务器统计投票信息，是否有过半机器接受相同投票，如统计出集群接受了(2, 0)投票信息，选出 ZK2 作为Leader
5、改服务器状态。确定 Leader，服务会更新状态，Follower-》 FOLLOWING， Leader-》 LEADING。节点 ZK3 启动，不再选举，状态 LOOKING-》 FOLLOWING

1、变更状态。Leader 挂后，非 Observer 将状态变为 LOOKING，开始 Leader 选举。
2、Server会发投票。运行期间，每服务器上 ZXID可不同，假定 ZK1 （ZXID： 124），ZK3（ZXID： 123）投票中，ZK1 和 ZK3 都会投自己，产生投票(1, 124)，(3, 123)，将投票发送给集群中所有机器。  
3、接收来自各个服务器的投票。与启动时过程比较。  
4、处理投票。与启动时过程相同 ZK1 事务 ID 大，ZK1 成为 Leader。  
5、统计投票。启动时过程相同。  
6、改变服务器状态。启动时过程相同。

基于Zookeeper的实现方式:
数据存储：将数据（配置信息）存储到Zookeeper节点
数据获取：启动初始化节点，从Zookeeper数据节点读取数据，节点上注册一个数据变更Watcher
数据变更：变更数据时，更新Zookeeper对应节点数据，Zookeeper会将数据变更通知，通过watch事件，发各客户端，接到通知后，变更数据
设计模式
Push 模式
Pull 模式
发布与订阅

注册中心
1、服务提供方（user-service，N个实例）zk中创建临时节点，比如/user-service/1，...，/user-service/n
2、服务调用方（order-serivce）监听/user-service，有变化，新增或删除实例，order-serivce会收到通知，重新获取数据，并重新设置监听

临时有序节点特性分布式锁，属于公平锁。
1、请求进来，直接在/lock节点下创建临时有序节点，比如/order_id
2、判断是不是/lock节点下面最小节点
a.是，获取锁
b.否，对前面节点进行监听（watch）
3、获得锁，处理完任务，释放锁，delete节点，后继第一节点会得到通知，判断。
临时有序节点好处，避免锁释放后，引发多个节点并发竞争锁（羊群效应），缓解服务器压力。

获取锁原理：
1、客户端 create() 持久节点临时有序子节点，返回带序号节点名称；
2、客户端getChildren() 获取持久节点子节点列表；
3、判断自己在子节点顺序，是第一个子节点（序号最小），获取到了锁；否，判断自己获取节点类型，是读节点，判断是否有比自己小的写节点，没有，则获读锁，有则通过 exist() 向比自己小最后写节点，注册Watcher监听；如果是写节点，那么通过 exist() 接口向比自己小最后节点注册一个Watcher监听；
4、等Watcher通知，客户端创建的是读节点，则获取到了读锁；否在继续进行第二步

原理
将启动服务注册到zk注册中心上，采用临时节点。
从zk节点上获取最新服务节点信息，本地使用负载均衡算法，分配服务器

Leader 收到客户端请求后，将请求封成个事务，给事务分配全局递增唯一 ID，称为事务ID（ZXID），ZAB 协议需保证事务顺序，必须将事务按照 ZXID 后排序后处理，通过消息队列实现， Leader 和 Follwer 间还有消息队列，用来解耦他们之间耦合，解除同步阻塞
zookeeper集群中为保证进程能够有序顺序执行， Leader 服务器接受写请求，Follower 服务器接受到客户端写请求，转发到Leader 服务器进行处理，Follower只能处理读请求
ZAB协议规定，事务在一台机器上被处理(commit)成功，所有机器上都被处理成功

ZAB 定义 2 个原则：
丢弃在 Leader 提出/复制，没有提交事务。
确保 Leader 提交事务最终会被所有服务器提交

崩溃恢复后，需在正式工作前（接收客户端请求），Leader 确认事务是否已被过半 Follwer 提交，完成数据同步。为保持数据一致。Follwer 服务器成功同步后，Leader 将这些服务器加到可用服务器列表中。
Zookeeper数据同步为四类
1，直接差异化同步（DIFF同步）
2，先回滚再差异化同步（TRUNC+DIFF同步）
3，仅回滚同步（TRUNC同步）
4，全量同步（SNAP同步）
数据同步前，Leader服务器会完成数据同步初始化：
peerLastZxid：从learner(follower或observer)注册发送ACKEPOCH消息中提取* lastZxid（Learner服务器最后处理ZXID）
minCommittedLog：Leader服务器Proposal缓存队列committedLog中最小ZXID
maxCommittedLog：Leader服务器Proposal缓存队列committedLog中最大ZXID
直接差异化同步（DIFF同步）
场景：peerLastZxid介于minCommittedLog和maxCommittedLog间
先回滚，再差异化同步（TRUNC+DIFF同步）
场景：新Leader服务器发现Learner服务器含自己没有事务记录，就需要Learner服务器进行事务回滚--回滚到Leader服务器同步，也是最接近peerLastZxid的ZXID
仅回滚（TRUNC同步）
场景：peerLastZxid 大于 maxCommittedLog
全量同步（SNAP同步）
场景一：peerLastZxid 小于 minCommittedLog
场景二：Leader服务器上没有Proposal缓存队列，peerLastZxid不等于lastProcessZxid

专为Apache ZooKeeper设计，用于实现一致性的状态机复制服务。

强调顺序一致性，更新在有副本上，以相同顺序执行。
两个关键阶段：崩溃恢复和消息广播。
1，领导者选举过程与数据同步相结合，保证新领导者拥有最新事务状态。
2，简化了Paxos的部分复杂性，并针对ZooKeeper的服务特性进行了优化。

ZAB为Apache ZooKeeper专门设计，高度契合ZooKeeper的需求，确保了数据的强一致性。
强调顺序一致性，保证所有更新操作在所有服务器上按全局一致的顺序进行。
针对崩溃恢复进行了优化，能够快速重新选举并同步集群状态。

主要应用于ZooKeeper这样的协调服务中，通用性不如Raft和Paxos广泛。
对于非ZooKeeper应用场景，需要更多的定制化工作来适应具体需求。

主要用于构建高可用的服务协调系统（如ZooKeeper），处理分布式锁、配置管理等任务。

设计目标：易于理解和实现，是Paxos的一种更具体且工程化的变体。

明确强领导者概念，每任期只有一个领导者，处理客请求，管理日志复制。
详细定义领导人选举、日志复制、安全状态转换内，所有操作流程。
成员变更（如集群扩容或缩容）清晰的操作指导。
对于Paxos，Raft通过更直观的设计降低实现难度，提高可理解性。

设计目标是易于理解与实现，相对于Paxos更直观清晰，适合教学和工程实践。 明确定义了领导者选举机制和日志复制流程，简化了分布式共识过程。 提供了详细的操作步骤和清晰的状态转换图，有利于开发者准确地实现算法。

虽然相比Paxos更易于理解和实现，但在某些复杂场景下可能略显保守，性能上的优势并不总是明显。
在节点数量较多的情况下，其网络通信开销可能会增加。

广泛应用于分布式存储系统、数据库、云原生应用以及各种要求强一致性的分布式系统中。

最早的实用分布式共识算法之一，由Leslie Lamport提出

专注解决“拜占庭将军”问题，网络不稳定情况下，达成一致决策。
基本思想通过提案、投票、接受来达到一致性。
Paxos没有规定领导者角色和选举机制，抽象描述提议和批准过程，直接实现，需要更多工程化努力。
虽然理论基础强大，因其表述相对抽象，实际实现起来相对复杂，不如Raft直观易懂。

是分布式系统中最基础且经过严格理论证明的一致性算法，具有非常高的容错性和稳定性。
理论上可以解决任何分布式一致性问题，提供了强大的理论支撑。

Paxos的原始描述较为抽象和复杂，直接从学术论文中理解并实现起来相对困难。
对于实际工程应用，需要开发人员深入理解并根据具体场景进行适当的优化和简化

常用于构建大型分布式数据库、分布式文件系统以及其他要求极高一致性和容错性的系统底层技术。

acks
0：生产者不会等待任何来自服务器响应
1（默认）：leader写日志成功，才会返回成功
-1或者all：所有ISR的副本全部写日志成功才返回成功

retries
重试次数（默认0），生产者从服务器收到的错误有可能是临时性的错误（比如分区找不到首领），需要重试，
重试间隔默认100ms，可以通过retry.backoff.ms来设置

buffer.memory
生产端用来缓存消息的缓冲区大小，默认32M
生产者发送消息不是直接发到broker，而是放在缓冲区队列里面，再由后台线程不断从队列中取出消息发送，
发送成功后会触发callback。如果缓冲区不足，会先阻塞一段时间（max.block.ms），再抛出异常

batch.size
当有多个消息需要被发送到同一个分区时，生产者会把它们放在同一个批次里，满了就发送。
默认16K，该值过小的话，会降低吞吐量，过大的话，会带来较大的内存压力

linger.ms
该参数指定了生产者在发送批次消息之前等待更多消息加入批次的时间。
KafkaProducer会在批次填满或linger.ms达到上限时把批次发送出去。
默认0，表示不等待，这种情况会导致批次消息过少就被发送了

max.block.ms
默认60秒，KafkaProducer.send() and KafkaProducer.partitionsFor() 方法最大的阻塞时间，
当buffer.memory满了或者集群的Metadata不可用时，这两个方法会被阻塞。

request.timeout.ms
Producer向Broker发送请求以后，等待响应的最长时间，默认30秒

发送并忘记
调用send()方法发送消息，但并不关心它是否正常到达。
producer.send(new ProducerRecord<Integer, String>(topic,msg))

同步发送
调用send()方法发送消息，它会返回一个Future对象，调用get()方法进行等待，就可以知道消息是否发送成功。
producer.send(new ProducerRecord<Integer, String>(topic,msg)).get();

异步发送
调用send()方法发送消息，并指定一个回调函数，服务器在返回响应时调用该函数

至少一次(AtLeastOnce)
默认，可以保证数据不丢失，但是不能保证数据不重复

最多一次(AtMostOnce)
可以保证数据不重复，但是不能保证数据不丢失

精确一次(Exactly Once)
不会漏传输也不会重复传输

Controller（控制器）
在Kafka集群中会有一个broker会被选举为控制器（KafkaController），它负责管理整个集群中所有分区和副本的状态
1、监听broker相关的变化
2、监听topic相关的变化
3、从Zookeeper中读取获取当前所有与topic、partition以及broker有关的信息并进行相应的管理
4、更新集群的元数据信息，同步到其他普通的broker节点中

Leader
partition中的Leader副本，提供读写服务，并且同步数据给Follower副本

Follower
partition中的Follower副本，不提供读写服务，用于备份Leader副本中的数据，与Leader是一主多从关系

AR（Assigned Repllicas）
partition中的所有副本集合

ISR（In-Sync Replicas）
与leader副本保持一定程度同步（replica.lag.time.max.ms时间内有同步）的副本集合（ISR中的第一个副本就是Leader副本），ISR是AR的子集
Leader副本负责维护和跟踪ISR集合中所有的follower副本的滞后状态，当follower副本落后太多或者失效时，leader副本会吧它从ISR集合中剔除

OSR（Out-Sync Relipcas）
与leader副本同步滞后过多的副本集合，AR = ISR + OSR

LEO（Log End Offset）
标识当前日志文件中下一条待写入的消息的offset。LEO 的大小相当于当前日志分区中最后一条消息的offset值加1。

HW（High Watermark）
俗称高水位，它标识了一个消息偏移量（offset），消费者只能拉取到这个offset之前的消息。
HW为ISR中所有副本的最小LEO

LW（Low Watermark）
俗称低水位，AR集合中最小的Log Start Offset

同步发送
消息发送后，producer等到broker回应后，才能继续发送下一个消息

异步发送
发出数据后，不等borker响应，发送下数据包
注：有一个异步发送回调接口（SendCallback）来处理返回信息

单向发送（Oneway）
只发送请求,不等待应答，效率最高

顺序发送（OrderProducer）
顺序发送比较复杂，支持局部顺序消息，要保证发送端，服务端，消费端顺序保持一致

集群消费（Clustering）
相同Consumer Group每Consumer实例协作  分摊消息

广播消费（Broadcasting）
相同Consumer Group的每Consumer实例接收全量的消息

拉取式消费（pull）
Consumer主动从Broker服务器拉消息

推动式消费（push）
Broker收到数据，主动推送给消费端，实时性比较高，底层同样是pull

存储字符串、整数、浮点数。
应用场景：
1 缓存
如：热点数据缓存（如报表，热点新闻等），对象缓存，全页缓存。 可提升热点数据访问速度
2 数据共享分布式
String 类型， Redis 分布式独立服务，可多应用间共享 如：分布式 Session
3 分布式锁
String 类型 setnx 方法，不存时，才添加成功，返回 true
4 全局 ID
int 类型，INCRBY，原子性（incrby userid 1000）（分库分表场景，一次性拿一段）
5 计数器
INT 类型，INCR 方法。如：文章阅读量，微博点赞数，允许一定延迟，先写 Redis ,定时同步到 数据库

键值对,无序散列表。value 是字符串，不能嵌套其他类型。
hset key name tx
应用场景：
1 存储对象类型数据
如对象或表的数据，比 String 节省 key 空间，便于集中管理
2 购物车
key：用户 id；field：商品 id；value：商品数量。
+1：hincr。-1：hdecr。删除：hdel。全选：hgetall。商品数：hlen。

存储有序字符串（从左到右），元素可重复。可充当队列和栈角色。
lpush queue a
应用场景：
1、 用户消息时间线 timeline
List 是有序，可用来做用户时间线
2、 消息队列
List 提供两个阻塞弹出：BLPOP/BRPOP，置超时时间。
BLPOP：BLPOP key1 timeout 移出,获取列表第一元素， 列表没有元素会阻塞列表，等待超时,发现可弹出元素为止。
BRPOP：BRPOP key1 timeout 移出,获取列表最后一元素， 没有元 素，会阻塞列表,直到等待超时，发现可弹出元素为止。
队列：先进先出：rpush blpop，左头右尾，右进队列，左出队列。
栈：先进后出：rpush brpop。

String 类型无序集合，最大存储数量 2^32-1（40 亿左右）。
sadd myset a b c d e f g
应用场景：
1 抽奖:随机获取元素
spop mykey
2 点赞、签到、打卡
这条微博的 ID 是 t1001，用户 ID 是 u3001。
用 like:t1001 来维护 t1001 这条微博的所有点赞用户。
点赞了这条微博：sadd like:t1001 u3001
取消点赞：srem like:t1001 u3001
是否点赞：sismember like:t1001 u3001
点赞的所有用户：smembers like:t1001
点赞数：scard like:t1001
比关系型数据库简单许多。
3 商品标签
用 tags:i5001 来维护商品所有的标签。
sadd tags:i5001 画面清晰细腻
sadd tags:i5001 真彩清晰显示屏
sadd tags:i5001 流畅至极

4 商品筛选
获取差集
sdiff set1 set2
获取交集（intersection ）
sinter set1 set2
获取并集
sunion set1 set2
筛选商品，苹果的，iOS 的，屏幕在 60-624 之间的，屏幕材质是 LCD 屏幕
sinter brand:apple brand:ios screensize:60-624 screentype:lcd
5 用户关注、推荐模型

子主题

RDB触发规则

bgsave流程

fork()

CopyOnWrite

AOF文件格式

开启策略

重写策略

bgRewriteAof流程

定时过期（主动）
-- 设key过期时间，同时，为该key创建定时器，让定时器在key过期时间来临前，对key进行删除
对内存友好、对cpu不友好(新增定时器，消耗cpu资源)

惰性过期（被动）
-- key过期，不删除，通过key获取value,检查是否过期，过期，则删除，返回null。
对cpu友好、对内存不友好(无查询，长期占用内存资源)；get，setnx时，先检查key是否过期，过期，则先删除，再操作

定期过期
-- 每隔一段时间（默认100ms），扫描expires 字典(默认20)key，并清除其中已过期的 key
该策略是折中方案

• 遍历每个数据库（默认16个）
• 随机获取当前库设置过期时间key，已过期，删除，默认循环20次
• 判断定期删除操作，是否已经达指定时长，已达到，直接退出
• 定期删除程序中全局变量，currentdb记录下个将要遍历的库

LRU策略
建议使用All-keys Lru

LFU策略

随机策略

TTL策略

noeviction策略（默认）

Redis的LRU

主从数据是如何同步的？
1、slave连上master后（stocket长连接），会发送一个PSYNC命令给master请求复制数据
2、master通过bgsave来生成rdb文件，并在开始生成文件的时候，将后面的写命令都缓存到buffer中
3、rdb文件生成好后，master将文件send到slave
4、slave收到rdb文件后，先清空自己的旧文件，再将新的rdb内容加载到内存中
5、master发送buffer，slave执行buffer中的写命令
6、master通过stocket长连接，将写命令持续发到slave中，保持数据一致

服务下线判断
1、Sentinel 默认以每秒钟 1 次的频率向 Redis 服务节点发送 PING 命令
2、如果在down-after-milliseconds 内都没有收到有效回复，Sentinel 会将该服务器标记为下线（主观下线）
3、Sentinel 节点会继续询问其他的 Sentinel 节点，确认这个节点是否下线，如果多数 Sentinel 节点都认为 master 下线，
master 才真正确认被下线（客观下线），这个时候就需要重新选举 master。

Sentinel 集群的 Leader 选举（Raft算法）
1、master 客观下线触发选举
2、每个sentinel每次选举都会自增配置纪元(选举周期)，每个纪元中只会选择一个sentinel（先到先得）的leader
3、超过一半的sentinel选举某sentinel作为leader
注：sentinel是没有主从是分的，只是在客观下线后，有个leader选举，leader来处理故障转移

故障转移
1、选出 Sentinel Leader 之后，由 Sentinel Leader 从所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器
2、让其它从服务器改为从新的主服务器复制数据
3、将原主服务器也改为从新的主服务器复制数据

这么多从节点，选谁成为新的主节点？
1、如果与哨兵断开连接时长的比较久，超过了某个阈值，就直接失去了选举权
2、如果拥有选举权，那就看谁的优先级高（replica-priority 100），数值越小优先级越高
3、优先级相同，就看谁从 master 中复制的数据最多（复制偏移量最大），选最多的那个
4、复制数量也相同，就选择进程 id 最小的那个

数据怎么相对均匀地分片？
1、hash取模：节点变化后，需要对所有数据进行重新分布
2、一致性hash：解决节点变化后，全部数据都要重新分布的问题。引入虚拟节点，解决数据分布不均匀问题
3、hash slot：对 key 用 CRC16 算法计算再%16384，得到一个 slot的值
注意：key 与 slot 的关系是永远不会变的，会变的只有 slot 和 Redis 节点的关系

怎么让相关的数据落到同一个节点上？
-- 在 key 里面加入{hash tag}即可。Redis 在计算槽编号的时候只会获取{}之间的字符串进行槽编号计算
如：127.0.0.1:7293> set a{qs}a 1

客户端连接到哪一台服务器？访问的数据不在当前节点上，怎么办？
-- 客户端操作的key不在当前连接的Redis服务器上，会返回一个MOVED，且含有Key所有服务器地址，重定向连接新服务器即可
如：127.0.0.1:7291> set qs 1
(error) MOVED 13724 127.0.0.1:7293
Jedis 等客户端会在本地维护一份 slot——node 的映射关系，大部分时候不需要重定向，所以叫做 smart jedis（需要客户端支持）。

新增或下线了 Master 节点，数据怎么迁移（重新分配）？
-- 需要把原有的 slot分配给新的节点负责，并且把相关的数据迁移过来
如：redis-cli --cluster add-node 127.0.0.1:7291 127.0.0.1:7297
redis-cli --cluster reshard 127.0.0.1:7291

Redis集群选举原理分析
当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，
从而存在多个slave竞争成为master节点的过程，其过程如下：
1、slave发现自己的master变为FAIL
2、将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST信息
3、其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack
4、尝试failover的slave收集master返回的FAILOVER_AUTH_ACK
5、slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)
6、slave广播Pong消息通知其他集群节点

生产环境部署情况？
1、集群部署，3主3从，32G 内存+ 8 核 CPU + 1T 磁盘，redis只占用10g
2、用户数据，商品数据，库存数据

服务提供者启动时会将自己的服务信息（如接口名、版本号、IP地址、端口号等）注册到注册中心。
服务消费者在启动时或需要时向注册中心订阅所需的服务，从注册中心获取可用的服务提供者列表。

提供者实现了服务接口并对外暴露服务，通过Dubbo框架将其服务注册到注册中心。

消费者引用服务接口并通过注册中心发现和调用远程服务，Dubbo会根据配置创建代理对象，隐藏了网络通信和协议转换等细节。

监控中心用于收集统计信息，如服务调用次数、耗时等，便于运维人员对系统性能进行监控和优化。

配置层允许开发者以集中化的方式管理服务的元数据信息，包括接口定义、服务版本、路由规则、负载均衡策略等。

提供者启动时将服务信息发布到注册中心，消费者则订阅相应的服务，注册中心负责通知消费者的变更情况。

消费者通过本地代理对象发起远程服务调用，Dubbo基于指定的协议（如dubbo、rmi、http等）进行远程通讯。

在消费者端，Dubbo支持多种负载均衡策略，如随机、轮询、最少活跃调用数、一致性Hash等，确保请求能均匀地分发给多个服务提供者实例。

如果服务提供者发生故障，Dubbo能够通过不同的容错模式（如快速失败、失败安全、失败自动恢复等）保证服务调用的健壮性。

Dubbo采用SPI（Service Provider Interface）扩展机制，使得开发者可以自定义过滤器、适配器、序列化方式等多种功能模块。

支持TCP、HTTP等不同网络传输协议。

支持Hessian2、JSON、Java原生序列化等序列化方式，实现跨语言调用的可能性。

通过集群层的支持，Dubbo能够处理多实例的路由和负载均衡，实现服务的高可用。

通过调用 SpringApplication.run(Application.class, args) 启动应用。

初始化 SpringApplication 类实例，并设置其基础属性如主配置类等。

加载系统属性和命令行参数，合并成应用的运行环境。

从多个来源读取配置，包括：application.properties 或 application.yml 文件、Profile特定的配置文件、命令行参数、系统属性等。

注册并初始化 ApplicationContextInitializer 和 ApplicationListener 实现类。

从META-INF/spring.factories中加载并注册所有的ApplicationContextInitializer实现。
执行所有自定义的初始化器来进一步定制上下文。
使用ClassPathScanningCandidateComponentProvider进行组件扫描，找出需要管理的bean定义。

根据当前环境和已有的Bean定义情况，自动检测并配置合适的Spring Beans。
检查spring-boot-autoconfigure模块下的META-INF/spring.factories中的EnableAutoConfiguration条目，按需启用相应的自动配置类

创建 ApplicationContext 的子类（通常是 AnnotationConfigServletWebServerApplicationContext），然后刷新上下文以完成Bean的创建和初始化过程。
在此过程中，会执行@PostConstruct注解的方法，以及初始化所有的单例Bean。

如果是web应用，Spring Boot将根据配置自动启动嵌入式的Tomcat、Jetty或Undertow服务器。

调用ApplicationRunner和CommandLineRunner接口的实现类，这些类在应用完全启动后可以执行一些初始化逻辑。

Spring Boot的核心特性是其智能的自动配置机制。当Spring Boot启动时，会根据项目中引入的依赖库和类路径中的Bean定义，自动配置相关组件并初始化它们。这意味着无需大量的XML配置或注解，就可以快速搭建出一个具备基本功能的Spring应用。

Spring Boot提供了一系列预定义的起步依赖（Starters），这些依赖模块以group ID org.springframework.boot 开头，并且通常命名为 spring-boot-starter-xxx。通过引入合适的starter，可以一次性导入一组兼容且功能相关的依赖包，如数据库连接、Web服务、安全性等。

Spring Boot内嵌了Tomcat、Jetty或Undertow等Servlet容器，使得开发人员不再需要单独部署服务器环境，只需运行Spring Boot应用的主类即可启动一个独立运行的Web应用程序。

Spring Boot Command Line Interface (CLI) 提供了一种命令行工具，可以通过脚本编写快速创建和运行Spring Boot应用，特别适合快速原型开发。

Spring Boot Actuator包含一系列生产就绪的监控和管理端点，可以用来查看应用信息、健康状况、审计日志、JVM指标等，对运维管理和故障排查极其有用。

Spring Boot支持通过application.properties或application.yml文件进行集中化的配置管理，同时提供了属性绑定和外部化配置等功能，便于在不同环境中切换配置。

Spring Boot提供了标准的父级POM（Maven Project Object Model），简化了Maven项目的构建配置，统一了版本管理和依赖管理。

通过使用@SpringBootApplication注解标记的Java类作为应用的入口点，该注解包含了@Configuration、@EnableAutoConfiguration和@ComponentScan三个注解的功能，使得整个Spring Boot应用能够被正确地引导和自动配置。

Spring Boot为HTTP客户端请求提供了RestTemplate以及响应式编程模型下的WebClient，方便微服务之间的通信调用。

优点:1、就算其中一台机器宕机了，其他几台机器照样可以接收请求
缺点：1、机器正好注册，没同步，宕机，新注册服务，客户端还是调用不了

优点：
1、节点间数据一致，客户端获取数据都是一样
缺点：
1、一台机器宕机，集群会进行选举，选举过程，服务对外不可用
2、宕机半数以上，所有服务都不可用，无法产生master
3、机器是偶数台，防止脑裂，导致整个服务不可用

sentinel基于信号量隔离

Hystrix基于信号量、线程池

基于响应时间、失败比率

基于失败比例

滑动窗口

滑动窗口（RxJava）

支持多种数据源

支持多种数据源

多个扩展点

插件形式

支持

支持

基于QOS,基于关系

不支持

支持慢启动，匀速器模式

不支持

支持

不支持

可配置规则，秒级监控，机器发现

不完善

servlet,spring cloud dubbo ,grpc

servlet,spring cloud netflix

Spring Cloud Gateway 是一个基于Spring框架和Project Reactor构建的微服务API网关。它作为Spring Cloud生态体系的一部分，承担着客户端请求路由、过滤以及与后端服务交互的核心作用

Spring Cloud Gateway提供了一种声明式的路由配置方式，允许用户根据路径、HTTP方法、Header、Query参数等规则来定义路由规则。
每个路由都会关联一个或多个过滤器，这些过滤器会按照一定的顺序对经过该路由的请求进行处理

过滤器是Gateway实现功能扩展的关键组件，包括预处理器（Pre-filter）、路由过滤器（Route Filter）、后处理器（Post-filter）等类型。
过滤器链是在请求到达网关时执行的一系列操作，如身份验证、限流、熔断、日志记录、请求转换等。内置了多种过滤器，同时也支持自定义过滤器以满足特定业务需求。

Spring Cloud Gateway基于Reactor项目实现了异步非阻塞的网络通信模型，能够有效提高系统在高并发场景下的性能表现。

Gateway可以通过集成服务注册中心（例如Eureka、Consul），自动获取并更新服务实例列表，从而实现动态路由和负载均衡。
当客户端请求到达时，Gateway通过匹配预先定义的路由规则找到目标服务，并转发至可用的服务实例。

客户端发起请求到Spring Cloud Gateway。
Gateway首先根据路由配置找到匹配的路由及其对应的过滤器链。
然后依次执行过滤器链中的各个过滤器，每个过滤器都可以决定是否继续传递请求给下一个过滤器或者直接返回响应给客户端。
最终，经过所有过滤器处理后的请求被发送到下游服务，待收到响应后再经由过滤器链逆序执行后处理逻辑，并将最终响应返回给客户端。

Spring Cloud Gateway可以整合OAuth2、JWT等认证机制，在网关层实现安全性控制。
同时，它可以与Zipkin、Sleuth等工具集成，实现全链路跟踪和分布式监控，方便问题定位和性能分析。

优点

缺点

优点

缺点

聚集索引表中只有一个，非聚集索引可有多个

聚集索引是物理上连续存在，非聚集索引逻辑上连续，并非物理上

聚集索引是索引组织形式，索引键值逻辑顺序决定表数据行的物理存储顺序，非聚集索引是普通索引，对数据列创建相应索引，不影响整表物理存储顺序

二叉树的数据结构来描述的，聚簇索引叶节点就是数据节点。非聚簇索引的叶节点仍然索引节点，有一个指针指向对应数据块

查询速度上来说，聚集优于非聚集

插入数据来说，非聚集要比聚集快

唯一索引等值查询
- 当查询记录存在，临键锁退化成记录锁
select * from t_index where id = 16 for update;
加锁范围：(8, 16] -> 16
- 当查询的记录是不存在的，临键锁退化成间隙锁
select * from t_index whereid = 10 for update;
加锁范围：(8, 16] -> (8, 16)

唯一索引范围查询

select * from t_index where id >= 8 and id < 10 for update;
加锁范围：(4, 8] -> 8   && (8, 16)

非唯一索引等值查询

非唯一索引范围查询

MVCC + 悲观锁
MVCC解决读写冲突，悲观锁解决写写冲突

MVCC + 乐观锁
MVCC解决读写冲突，乐观锁解决写写冲突

事务对数据进⾏修改未提交，另⼀个事务访问数据，还没有提交，另⼀个事务读到是“脏数据“

事务读取数据时，另⼀个事务也访问了该数据，第⼀个事务修改数据后，第⼆个事务修改数据。第⼀个事务内修改丢失，丢失修改。

事务内两次读到的数据,属性是不⼀样的情况，因此称为不可重复读。

幻读与不可重复读类似。事务（T1）读取⼏⾏数据，事务（T2）插⼊⼀些数据。后查询中，事务（T1）发现不存在的记录，称为幻读。
注：不可重复读和幻读区别： 不可重复读重点修改多次读取⼀条记录,某些列的值被修改，幻读的重点在于新增或者删除，⽐如多次读取,发现记录增多减少

不建议使用在线上系统

JVM 同步规范:
监视器m解锁，对后续加锁同步
 volatile变量v写入，后续线程，对v读同步
启动线程与线程操作同步。
属性写，默认值（0， false，null）对其线程同步。(创建对象前，对象属性默认值，程序启动时，默认值，初始化来创建)
 T1 操作，T2 发现T1 结束( T2 通过 T1.isAlive() 或 T1.join() 来判断 T1 是否已终结)
 T1 中断 T2，T1 中断，其他线程发现 T2 被中断，同步（抛出 InterruptedException 异常，调用 Thread.interrupted 或 Thread.isInterrupted ）

两个操作用 happens-before 确定执行顺序，操作 x happens-before 操作 y (记作: hb(x,y))，前操作于后操作可见。
 同线程操作 x ，操作 y， x 先于 y ，hb(x, y)
解释: 单线程代码，顺序执行
对象构造方法最后一行指令， happens-before 于 finalize() 第一行指令。
解释: 构造函数先于 finalize （）
操作 x ，操作 y 构成同步，记 hb(x, y)。
解释: 是 synchronization order 规则
hb(x, y) 和 hb(y, z)，推断出 hb(x, z)

线程 a 进 synchronized 前， synchronized 对共享变量操作，后续持同监视器锁(monitor)（读锁，共享锁）线程 b 可见。
synchronized 保障变量可见性:
线程获取监视器锁，才 synchronized 代码块，进入代码块，从主存中重新读取共享变量值，退出代码块时，线程写缓冲区中数据，刷到主内存。
Java对象可作为锁， synchronized 实现同步基础：
普通方法，锁实例对象(synchronized method)
静态方法，锁类 class 对象(synchronize static method, synchronized(Obj.class))
同步方法块，锁括号里面对象(synchronized(this), synchronized(obj))

对象头

monitor 对象(监视器锁),是 MarkWord 重量级锁指向，每对象存在 monitor 与之关联, 当monitor 被某线程持有后，处于锁定状态。
monitor是由ObjectMonitor实现的，其主要数据结构如下:  ObjectMonitor中有两个队列，_WaitSet 和 _EntryLis，用来保存ObjectWaiter对象列表( 每个等待锁的线程都会被封装成ObjectWaiter对象).
ObjectMonitor() {
    _header       = NULL;
    _count        = 0; //记录个数
    _owner        = NULL; // 指向持有锁线程
    _WaitSet      = NULL; // 处于wait状态线程，会加入到_WaitSet
    _EntryList    = NULL ; // 处于等待锁block状态线程，会加入到列表
}
多线程访问一段同步代码，先会进 _EntryList 集合
线程获取到对象 monitor ,把monitor的owner设当前线程,monitor计数器count加1
线程调用 wait() ，将释放持有monitor，owner恢复为null，count减1, 线程进 WaitSet集合,等待被唤醒
当前线程执行完毕,释放monitor(锁)并复位变量的值，线程进入获取monitor(锁)

同步代码块
public void syncTask(){
     //同步代码库
     synchronized (this){
         doSomething....
     }
 }
对同步代码块，实现是monitorenter和monitorexit指令，其中monitorenter指向同步代码块开始位置，monitorexit指明同步代码块结束位置。执行到moniterenter指令，获取monitor。
monitorenter // 进入同步方法
........   // 执行逻辑
monitorexit // 退出同步方法块
同步方法
public synchronized void syncTask(){
       doSomething......
  }
方法同步是隐式，通过字节码指令来控制，在方法调用和返回操作中。JVM从方法常量池的方法表结构(method_info Structure) 的 ACC_SYNCHRONIZED 访问标志，是否同步方法。当方法调用时，指令检查方法 ACC_SYNCHRONIZED 访问标志，设置了，去获取monitor

无锁

偏向锁

轻量级锁

重量级锁

锁升级

锁优化

以单例模式的 double check 检查问题， 看一下如下单例的写法:
public class Singleton {
    private static Singleton instance = null;
    private Singleton() {
    }
    public static Singleton getInstance() {
        if (instance == null) { // 1. 第一次检查
            synchronized (Singleton.class) { // 2
                if (instance == null) { // 3. 第二次检查
                    instance = new Singleton(); // 4
                }
            }
        }
        return instance;
    }
}
复制
这种写法是有问题的， 假设有两个线程 a 和 b 调用 getInstance() 方法
假设 a 先运行， 首先到步骤 4 处。instance = new Singleton() 这句代码首先会申请一段空间，然后将各个属性初始化为零值(0/null)，执行构造方法中的属性赋值[1]，将这个对象的引用赋值给 instance[2]。在这个过程中，[1] 和 [2] 可能会发生重排序。
此时，线程 b 刚刚进来执行到步骤 1，就有可能会看到 instance 不为 null，然后线程 b 也就不会等待监视器锁，而是直接返回 instance。问题是这个 instance 可能还没执行完构造方法（线程 a 此时还在 4 这一步），所以线程 b 拿到的 instance 是不完整的，它里面的属性值可能是初始化的零值(0/false/null)，而不是线程 a 在构造方法中指定的值。
想解决这个问题， 使用 volatile 关键字修饰 instance 即可

另外： 如果对象所有的属性都被 final 关键字修饰， 那么不需要加 volatile 也可以保证不发生重排序。

lock()：获取锁并阻塞等待
unlock()：释放锁
tryLock()：尝试非阻塞地获取锁
tryLock(long time, TimeUnit unit)：限时等待获取锁
lockInterruptibly()：可中断的锁请求

ReentrantLock 基本用法
可重入性原理
公平锁与非公平锁的区别和设置
Condition 对象的使用
await() 方法
signal() 和 signalAll() 方法

读写锁的基本原理
ReadLock（读锁）和 WriteLock（写锁）
提高并发性能的场景分析

正确锁定和解锁的顺序
避免死锁策略
锁定模式的选择与应用
使用 try-with-resources 结构自动释放锁资源

原理

AQS 核心数据结构

基础方法与机制

AQS 的公平与非公平策略

基于 AQS 的并发工具类

自定义同步组件

AQS 的高级特性

AQS 性能调优

实战应用与案例分析

疑难解答与最佳实践

自旋锁与自适应自旋
锁粗化与锁消除
轻量级锁与偏向锁的工作机制

处理 InterruptedException
锁竞争激烈时的监控与诊断

使用 Lock 解决生产者-消费者问题
多线程环境中确保数据一致性
分布式系统中的 Lock 实现及其挑战

Lock 与 synchronized 关键字的比较
根据应用场景选择合适的锁实现
进一步学习和探索的方向

内存屏障四大分类：（Load 代表读取指令，Store代表写入指令）

内存屏障类型        使用场景                                    描述
LoadLoad 屏障     Load1; LoadLoad; Load2        在Load2要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
StoreStore 屏障    Store1; StoreStore; Store2      在Store2写入执行前，保证Store1的写入操作对其它处理器可见
LoadStore 屏障    Load1; LoadStore; Store2       在Store2被写入前，保证Load1要读取的数据被读取完毕。
StoreLoad 屏障    Store1; StoreLoad; Load2       在Load2读取操作执行前，保证Store1的写入对所有处理器可见。
为了实现volatile的内存语义，Java内存模型采取以下的保守策略:
在每个 volatile 写操作的前面插入一个 StoreStore 屏障
在每个 volatile 写操作的后面插入一个 StoreLoad 屏障
在每个 volatile 读操作的后面插入一个 LoadLoad 屏障
在每个 volatile 读操作的后面插入一个 LoadStore 屏障

volatile 修饰符适用于以下场景：某个属性被多个线程共享，其中有一个线程修改了此属性，其他线程可以立即得到修改后的值。
volatile 属性的读写操作都是无锁的，它不能替代 synchronized，因为它没有提供原子性和互斥性。因为无锁，不需要花费时间在获取锁和释放锁上，所以说它是低成本的。
volatile 只能作用于属性，我们用 volatile 修饰属性，这样 compilers 就不会对这个属性做指令重排序。
volatile 提供了可见性，任何一个线程对其的修改将立马对其他线程可见。volatile 属性不会被线程缓存，始终从主存中读取。
volatile 提供了 happens-before 保证，对 volatile 变量 v 的写入 happens-before 所有其他线程后续对 v 的读操作。
另 volatile 可以使得 long 和 double 的赋值是原子的

corePoolSize（核心线程数）
maximumPoolSize（最大线程数）

workQueue（工作队列类型，如LinkedBlockingQueue、SynchronousQueue等）

keepAliveTime（非核心线程空闲存活时间）
TimeUnit（keepAliveTime的时间单位）

ThreadFactory（用于自定义线程创建逻辑的工厂接口）

RejectedExecutionHandler（当队列满且无法添加新线程时的拒绝策略）

默认行为：异常会被UncaughtExceptionHandler捕获，若没有设置则默认打印堆栈跟踪信息
可通过自定义RejectedExecutionHandler处理因线程池饱和导致的任务拒绝异常

Eden（默认8/10）

Survivor0（默认1/10）

Survivor1（默认1/10）

程序代码普遍存在引用赋值，强引用关系还存在，不会回收掉被引用的对象

有用，非必须对象。被软引用关联的对象，内存溢出前，会把这些对象列进回收范围，进行二次回收，这次回收仍无足够的内存， 才会抛出内存溢出异常。

非必须对象，比软引用弱，弱引用关联的对象，只能生存到下次垃圾收集。下次垃圾收集器开始，都会回收掉被弱引用关联的对象

“幽灵引用”或者“幻影引用”，对象是否有虚引用，不会生存时间构成影响，无法通过虚引用取得对象实例。对象被收集器回收时收到一个系统通知

对象自身运行时数据(mark word)

类型指针

时数组，还有记录数组长度数据

句柄访问好处，reference存储稳定句柄地址，对象移动（垃圾收集标记，复制，移动对象的行为）只会改变句柄实例数据指针，reference本身不被修改

直接指针访问速度更快，节省一次指针定位时间开销，对象访问Java中非常频繁，这类开销积少成多，是可观的执行成本。

HotSpot虚拟机用直接指针来进行对象访问

对象不会逃逸线程外，可将对象在栈上分配，对象占用的内存随栈帧出栈而销毁，这样一来，垃圾收集压力降低很多

线程同步是耗时过程，逃逸分析能够确定变量不会逃逸出线程，无法被其他线程访问，变量读写不会有竞争， 同步措施可安全地消除掉。

一个数据是基本数据类型，不可拆分，称之为标量。把Java对象拆散，将其成员变量恢复为原始类型来访问，过程称为标量替换。假如逃逸分析能够证明对象不会被方法外部访问，且可以被拆散，可不创建对象，直接创建若干成员变量代替，让对象成员变量在栈上分配和读写

暂停所有其他线程(STW)，记录gc roots直接能引用对象，速度很快

GC Roots关联对象，遍历引用链过程， 耗时长，无需停顿用户线程， 可与垃圾收集线程并发运行

修正并发标记期间，用户程序运行，标记变动部分，会STW

开启用户线程，GC线程，对未标记区域做清扫。新增对象会被标记为黑色不做任何处理(见下面三色标记算法详解)

重置GC过程中标记数据

暂停所有其他线程(STW)，记录gc roots直接能引用对象，速度很快

GC Roots关联对象，遍历引用链过程， 耗时长，无需停顿用户线程， 可与垃圾收集线程并发运行

修正并发标记期间，用户程序运行，标记变动部分，会STW

复制算法，将region存活对象复制另一个region中，不会像CMS很多内存碎片，需整理一次，G1用复制算法回收，几乎不会太多内存碎片。

不会立即生效，不可控，不建议使用

大对象空间分配，长期存活对象，进老年代，老年代放不下，会触发Full GC

方法区由永久代实现，永久代空间不足 Full GC

年轻代GC后，仍有大量对象存活，需要老年代进行分配担保，把Survivor无法容纳对象,送入老年代
1、minor gc前，jvm先检查，老年代连续可用空间,，是否大于新生代对象总大小（包含垃圾对象），大于直接minor gc，不会触发full gc
反之，看是否开启老年代，空间担保机制和是否允许冒险。未开启，直接full gc；开启了，判断老年代连续可用空间，是否大于minor gc后进入老年代对象的总大小，如果大于，则冒险进行minor gc，否则，则进行full gc

cms并发标记和并发清理期间，有新垃圾产生，老年代没有足够空间.

jvm内存太小，所需内存太大，创建对象时，分配空间就会抛出这个异常
1、可适当调整-Xms和-Xmx两个jvm参数
2、提高请求执行速度，垃圾回收越早越好

加载的类太多或者引用第三方JAR。
设置-XX:MetaspaceSize（初始空间大小）和-XX:MaxMetaspaceSize（最大空间），触发FULL GC

-XX:MaxPermSize=128m
-XXermSize=128m

1、调高-Xss（线程栈大小）
2、减少递归调用

1、NIO框架用ByteBuffer中的allocateDirect()时，及时clear内存
2、-XX:MaxDirectMemorySize=128m

Java 进程98%时间垃圾回收，恢复不到2%堆空间，最后连续5个(编译时常量)垃圾回收如此。
1、使用 -Xmx 增加堆大小
2、使用 -XX:-UseGCOverheadLimit 取消 GC 开销限制
3、修复应用程序中的内存泄漏

一个线程空间大小是有限制的，线程空间满后，出现异常。
增加线程栈大小。-Xss2m

1、减少线程数量。
2、线程数量不能减少情况，设置-Xss减小单个线程大小。以便能生产更多的线程。