Java知识总结

volatile修饰的变量，修改的之后会立即从工作内存同步到主内存之中；实现其他线程对该变量的可见性

解锁之前必须把变量的值从工作内存传递到主内存

对象的引用是不变的，所以说对所有线程来说都是可见的

不存在内存异常的情况

给栈内存分配128kb

无锁

偏向锁

轻量级锁，重量级锁

Gc标记

1.标记-清除的效率都不高

2.清除会造成很多内存碎片，有可能导致二级gc;

单线程回收，用户线程需要停止

特点

适用场景：

多线程回收，用户线程需要停止

ParNew

新生代并行回收，常和 CMS 搭配

特点

适用场景：

多线程回收，用户线程需要停止

Parallel Scavenge

多线程收集器，目标是提高 CPU 利用率和吞吐量

目标

特点

老年代的单线程垃圾回收，用户线程需停止

算法

特点

适用场景：

老年代多线程回收，用户线程需要停止

目标是提高 CPU 利用率和吞吐量。

Parallel Scavenge 的老年代版本，多线程。

算法

特点

多线程回收，以用户线程暂停时间最短为设计标准

回收的时候，用户线程有一段时间不需要停止

缺点：产生内存碎片，可能会有 “Concurrent Mode Failure”。

算法

特点

优点：

缺点

示意图

很重要的一个特点

将java的堆内存分成2048个大小相同的region块

region大小特点

存储特点

设定region 区域大小

手动设置G1垃圾回收器；JDK9默认就是G1

也会像之前的回收器一样，将内存划分成很多个小的块

小页面

中页面

大页面

统一内存访问

支持非统一内存访问

分配速度很快，收回也很快

标记阶段

回收阶段

重定位

小页面优先回收，中页面，大页面尽量不回收

回收过程示意图

具体过程

当对象的内存地址被转移的时候，刚号在并发阶段应用程序有需要访问这个对象

JVM向应用代码插入一小段代码的技术

相当于有两个操作要一起做的原子操作

1、对已经转移但是还没重定位的对象进行对象的重定位

2、删除对应对象再转发表中的记录的指针的新旧关系

jvm启动预热，如果从未发生过GC，那么就会在堆内存超过10%，20%，30%的时候触发一次GC，来收集GC的数据

ZGC根据近期对象的分配速度以及GC时间，计算当内存占用达到什么样的阈值的时候出发下一次GC

流量平稳的时候，自适应需要堆内存占用达到百分之95的时候才会触发

和固定时间规则类似。

内存已经无法再给新的对象分配内存触发

代码中直接System.gc()触发

元数据区不足时导致触发

ZAllocationSpikeTolerance

ZCollectionInterval

ParallelGCThreads

ConcGCThreads

par new

CMS

PS

PO

top 命令

top -hp命令

jstack

文档加载斤内存中行程的java对象导致内存不足，频繁GC，导致stw时间过长

内存大，然后FGC时间过长,导致用户线程暂停

从PS垃圾回收器，设置成PN+CMS 或者G1回收器

数据计算

数据挖掘

网站

API

GC 占用的时间越少，吞吐量越高

目标

适用场景

典型 GC 选择

目标

适用场景：

典型 GC 选择：

修改java字节码工具类

修改java字节码的工具库

可以直接生成一个类

在已经编译的类里面添加新方法，修改方法

ASM是一个java字节码操作框架

直接生成class文件

拦截java文件被类加载器加载之前修改类

客户端编译器

服务端编译器

概念

过程

缺点

概念

优点

缺点

过程

概念

优点

过程

组件名称

组件功能

用户线程无延迟，就可以拿到IO之后的数据

用户线程处于等待之中需要消耗性能；

无需阻塞等待内核准备数据，这个期间可以做其他的事情；

需要去轮询内核，内核无法以最短的时间把数据复制到用户内存中

内核会把数据复制到用户内存中，减少了用户线程去复制的过程；

非阻塞

阻塞

每一个segment 是继承了ReentrantLock 的 一个HashMap，每一个segment就是一把锁，并发度就是segment数组长度

segment 中维护了  HashEntry[] 数组 

HashEntry[] table
    ├── HashEntry(key1, value1, next -> key2)
    ├── HashEntry(key3, value3, next -> key4 -> key5)
    ├── null
    └── ...

步骤

1、根据key，计算出hashCode；

2、给segement加锁，保证同一时刻只有一个线程修改segement

3、根据hashCode值和hashEntry数组的长度运算，定位到hashEntry数组中具体某一个hashEntry

4、获取到具体的链表，遍历链表查找 key 是否已存在

5、扩容检查，当前segement中元素的个数是否超过扩容条件

6、释放锁

nodes数组的每一个节点相当一个桶（bucket）

桶里存放的数据结构可能有三种：

demo

步骤

get 操作是无锁的

示意图

步骤

扩容的时候单个segment中的，增加了HashEntry元素个数，扩容只是在segment内部做扩容

扩容的时候是全局扩容，每一次扩容hash桶的数量增加一倍，并发度就咱家一倍；

Segment中的HashEntry 元素个数增加，只是在sgement内部做扩容

Entry<K,V>[] table

Entry<K,V>[] table

链表（Entry）

Entry<K,V>

1、计算 hash

2、根据hash值再次计算定位到桶

3、插入数据

4、扩容检查，如果是超过了阈值，外层table数组元素个数翻倍，重新计算每一个桶的位置，做数据迁移

1. 计算哈希值

2. 定位桶

3. 桶判空

4. 遍历链表

Node<K,V>[] table

Node 节点（链表节点）

TreeNode 节点（红黑树节点）

1. 计算哈希

2. 定位桶

3. 插入逻辑

4.扩容检查

1. 计算 hash 定位桶

2. 桶判空

3.桶首节点检查

4.继续查找

比如说当前是16个hash槽，扩容之后就会变成32个hash槽；当前第一个槽位中需要被迁移的数据会迁移到第17个槽位上；也就是以此类推，当前第16个槽位的需要被迁移的数据被迁移到第32个上；

当前实际存储元素的个数超过一定百分比（默认的75%，这个比例可以通过构造函数设置）

1.hash槽没有数据

2.hash槽里面只有一个数据

3.hash槽里面是链表

4.hash槽里面是红黑树

扩容之后的hash槽计算？比如说当前是16个hash，在第1个槽位，在扩容之后，需要迁移的数据就会落在1+16 =17 也就是在第17个槽位上面。

假设扩容因子=1，也就是每一次扩容都前集合的元素个数和当前集合的最大容量相同，无形之中就增加了hash碰撞，hash碰撞之后，就会形成对应的链表过长，红黑树高度过高，这样就会导致在查询的时候耗时过高。

如果扩容引子过小，map集合在存储元素的时候，就会经常发生扩容操作，导致添加元素耗时过高。

0.75是经过很多科学计算之后，平衡了添加和查询操作之后，得出来最佳的数值

key已经存在，需要修改HashEntry对应的value；

key不存在，在HashEntry中做插入

1.获取当前key的hashCode值与value的Code值做异或运算

2.拿到第一步的值，让当前值和当前值的与16做位运算之后的值做异或运算

当前数组的长度（桶的数量）

负载因子，默认 0.75

扩容后的数组长度是扩容前的两倍

单个元素的保留在原来的桶

如果是链表需要拆分成两个链表，一个保留在低位 的桶，一个保存在高位的桶；

JDK1.7 链表头插法

扩容后的数组长度是扩容前的两倍

单个元素的保留在原来的桶

如果是链表需要拆分成两个链表，一个保留在低位 的桶，一个保存在高位的桶；

如果是红黑树，拆分红黑树，一个保留在原来索引位置的桶，一个保留在高位的桶（红黑树不会退化成链表）

JDK1.8 尾插法

加锁指令

解锁指令

当线程竞争锁失败时，会被 阻塞，等待操作系统唤醒，这涉及 用户态 → 内核态切换，开销很大。

避免线程阻塞/唤醒带来的昂贵系统调用

在锁占用时间很短时性能极佳

自旋期间线程不做有用工作，浪费 CPU 时间

如果锁长期被占用，自旋会一直失败 → 白白消耗 CPU

偏向锁:适用于单线程适用锁的情况，如果线程争用激烈，那么应该禁用偏向锁。

轻量级锁：适用于竞争较不激烈的情况(这和乐观锁的使用范围类似)

重量级锁：适用于竞争激烈的情况

StoreStoreBarrier

读操作

StoreLoadBarrier

每次读（针对所有线程），都会从主内存中读取，而不是从工作内存中读取

LoadLoadBarrier

写操作

LoadStoreBarrier

每次写操作，都会将工作内存中的值，刷新到主内存中

新创建的未启动状态的线程

线程准备或者运行中

线程阻塞

未指定时间的线程等待

指定时间的线程等待

线程终止

当前线程进行相应时间的休眠，并且不释放锁对象

当前线程放弃cpu执行权，让其他线程去执行，放弃的时间不确定，可能放弃后，又获得了执行权；

获取当前执行程序的线程

线程可以开始运行

线程真正执行

设置优先级，获取优先级

中断线程

线程加入，抢占cpu执行权

需要将资源的实例化放在try 的小括号里面

不同的编码字符集一个字符所需要的字节个数不一致，1-2个

相对于jdk8可以减少字符串内存空间消耗

ASC
CCC
WWW

b
b
Exception in thread "main" java.util.NoSuchElementException: No value present
    at java.base/java.util.Optional.orElseThrow(Optional.java:382)
    at com.szc.Main.main(Main.java:42)

只在根节点扫描阶段发生stw ,所以停顿事件不会随着堆内存增长和激活对象的增长而增长

定期GC的类型，默认是Full GC，如果设置值了，就会继续上一个或启动一个新的并发周期

需要验证下对应的版本是否有这个方法?

使用统一的api有利于以后对系统化版本的升级

模块外部的代码只能访问该模块导出的包的公共和受保护元素

protected 修饰的元素只能由定义它的类已经它的子类访问

一个事务读到另一个事务 未提交 的修改。

一个事务内 多次读取同一行，结果不同（因为别的事务修改并提交了）。

一个事务在某个范围内查询到的记录数 前后不一致（因为别的事务插入/删除了新行）。

INSERT 操作的 Undo Log

DELETE 操作的 Undo Log

UPDATE 操作的 Undo Log

反向记录sql的操作

记录在物理页上面的数据变更

意向共享锁

意向排他锁

概述

锁单条记录

锁范围（两个索引值之间的间隙（不含端点）
），防止幻读。

记录锁 + 前一个间隙

SELECT ... FOR UPDATE

加上了排它锁，其他事务无法修改这行，直到事务提交或回滚

SELECT ... LOCK IN SHARE MODE

行加共享锁（S锁），其他事务可以读，但不能修改

在数据表中增加一个 version 字段，每次更新时 WHERE version=旧值，更新成功则 version+1，失败则说明被其他事务修改，重试

在数据表中增加 update_time 字段，更新时检查时间戳是否一致，一致则更新，失败则重试

根据主键排序做的索引，特殊的唯一索引

强制让表中某个字段值不能重复

根据某一列字段建立的索引

通过锁定索引记录来实现；锁定某一个索引记录

使用场景

作用

通过索引记录来实现

对一定返回内数据进行加锁，即使这数据不存在也是会加锁

Select * from emp where empid &gt; 100 for update;会对empid大于100的都加上间隙锁，即使记录不存在也会添加

使用场景

作用

相当于一个记录锁+间隙锁

使用场景

作用

插入数据之前，由insert操作设置的一种间隙锁

给数据行加行级锁之前需要取道该表的意向共享锁

给数据行家排他锁之前需要取到该表的意向排他锁

记录后事物执行之后的状态，用来记录未写入 datafile 的已成功的事物更新的数据；

记录对数据页的所有写操作，确保在系统崩溃后能够恢复事务的一致性与完整性

在MySQL宕机时候，还有数据没有写入磁盘，可以通过重做日志重做，从而达到数据的持久化

事物开始的时候就会有日志生成，随着事物的进行的过程中，日志逐渐写入redolog中

当某个事物对应的数据写入 datafile中后，redolog的使命已经完成了，重做日志的空间就会被重用

数据库的每一次修改(insert,update,delete)操作,在落到磁盘之前都会先记录到undolog

记录信息修改之前数据

根据undolog日志做数据库的逆向操作，原来的insert操作变成delete操作，delete变成insert，update变成逆向update

1.主机每次完成实事物提交，完成数据更新之前，都会把变更的数据记录在binlog日志中

2.从机开启一个IO线程去从主机的binlog日志中读取数据，记录到自己的中继日志中；

3.从机开启线程，解析中继日志的事件，并执行，来做数据主从复制

以mysql事件形式记录的是实际执行的sql语句

以MySQL事件形式记录字段前后变化的值

balance 从 400 改回 500

select * from table where ? for update;

select * from table where ? lock in share mode;

insert into table values (…);

update table set ? where ?;

delete from table where ?;

因为修改操作之前，都是先需要查询到目标记录；

CBO

RBO

1.缓存命中率低

2.内存空间宝贵

mysql缓存查询到的数据永远是最新的数据，如果中件表有发生变化，则该缓存相关的数据就会被清空

缓存命中率比较低，最理想的情况下命中率最高13%

缓存工作

缓存相关查询

缓存相关参数

写操作之后强制读主库

场景

其他不敏感的数据，走从库

确保至少一个从库同步到位才返回给客户端，减少丢数据风险。

MySQL 5.7+ 支持多线程复制，按库/按表并行，提高同步速度。

发现延迟大 → 临时切读主库，或扩容从库。

使用 数据库中间件（如 MyCAT、ShardingSphere、ProxySQL） 自动感知主从延迟，动态路由请求。

对于强一致性要求的场景（支付、下单、库存），直接读主库。

1、二进制日志格式不一样

2、字符集，函数，时区处理不一样

子主题

高性能：主库提交事务速度快。

数据可靠性低：主库宕机时，从库可能落后，存在数据丢失风险。

保证主库事务 binlog 至少被一个从库接收，减少数据丢失风险。

性能略低于异步复制，因为提交要等待从库 ack。

1、对原始表加写锁

2、按照原始表和执行语句的定义，重新定义一个空的临时表

3、对临时表进行添加索引（如果有

4、再将原始表中的数据逐条Copy到临时表中

5、当原始表中的所有记录都被Copy临时表后，将原始表进行删除。再将临时表命名为原始表表名

1、对原始表加写锁

2、按照原始表和执行语句的定义，重新定义一个空的临时表。并申请rowlog的空间

3、拷贝原表数据到临时表，此时的表数据修改操作（增删改）都会存放在rowlog中。此时该表客户端可以进行操作的

4、原始表数据全部拷贝完成后，会将rowlog中的改动全部同步到临时表，这个过程客户端是不能操作的

5、再将临时表命名为原始表表名

简单的单表select查询

子主题 1

SUBQUERY

MATERIALIZED

被关联查询的语句；也就是关联查询的union中的第二个语句或者是union后面的select语句

表示关联查询的结果

由M,N两个表关联产生的结果

有N表产生的中间结果集维表

查询的是系统表

单表查询直接命中主键查询

demo

关联查询用到主键索引做为关联字段

demo

关联查询用到了非主键索引作为关联字段

demo

在索引上的范围查询

demo

查询是在所引述中扫描

demo

全表扫描

demo

1.在经常当做查询条件的字段上设置索引

1.反向查询，!=,&lt;&gt; ,not in

2.前模糊查询

3.查询语句中在索引字段上做函数操作

4.关联字段虽然都是索引字段，如果数据类型不一致，走不了索引

5.where后面不带有效查询条件

6.建立联合索引，查询的时候不满足最左原则；

7.查询中对索引字段做运算操作

索引长度限制

索引建立字段选取

索引数量

查询服务器默认缓存区大小

SHOW VARIABLES;

SHOW STATUS；

系统变量和状态信息

key_buffer_size

table_cache

read_rnd_buffer_size

max_connections

thread_cache_size

查询相关

innerDB相关

提高搜索效率

提高读写吞吐量

CREATE TABLE `test_news` (`id` int(11) NOT NULL AUTO_INCREMENT,`title` varchar(100) DEFAULT NULL COMMENT &apos;文章标题&apos;,`content` longtext COMMENT &apos;文章内容&apos;,`channel` int(11) DEFAULT NULL COMMENT &apos;文章频道&apos;,`status` int(11) DEFAULT NULL COMMENT &apos;状态，1正常，0关闭&apos;,`create_time` datetime DEFAULT NULL COMMENT &apos;文章发布时间&apos;,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=513 DEFAULT CHARSET=utf8;

select* from test_news limit 10000，10；

查询每页是10条，查询第10000页的数据；这种查询完全就是没有用到索引；需要扫描到10000条数据，再开始查询

select* from test_news where id &gt;( select id from test_news limit10000,1) limit 10；

解析

select* from test_news a join ( select id from test_news limit10000,10) b on a.id = b.id ；

解析

CREATE TABLE `test_news` (`id` int(11) NOT NULL AUTO_INCREMENT,`title` varchar(100) DEFAULT NULL COMMENT &apos;文章标题&apos;,`content` longtext COMMENT &apos;文章内容&apos;,`channel` int(11) DEFAULT NULL COMMENT &apos;文章频道&apos;,`status` int(11) DEFAULT NULL COMMENT &apos;状态，1正常，0关闭&apos;,`create_time` datetime DEFAULT NULL COMMENT &apos;文章发布时间&apos;,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=513 DEFAULT CHARSET=utf8;

.frm（表结构）

.MYD（数据）

.MYI（索引）

.frm（表结构）

数据和索引存储在共享表空间（ibdata）

按照不同的业务来拆分库表

方式：

优点：

缺点：

按行拆分，把同一张表的数据按某个规则分到不同的库或表中。

方式：

优点：

缺点：

宕机 = 数据库不可用

使用之前做的全量备份恢复数据库

利用 redo log / binlog / undo log 恢复事务未提交或丢失的数据

从最近一次备份 + 增量 binlog 恢复

适合恢复到宕机前的最新状态

在数据库 停止运行的情况下，对整个数据库文件系统进行备份

数据文件状态静态，备份时无需考虑并发事务

恢复简单，直接复制回原路径即可

需要停库，业务不可用

数据库运行中也可以进行备份，在线备份

MySQL：mysqldump、mysqlpump、Percona XtraBackup

支持增量/全量备份

业务不停机

需要考虑备份期间的事务一致性

复杂度高，需要 redo/undo 日志或 binlog 协助保证一致性

在线备份，不影响业务

备份复杂，恢复时可能需要 binlog 回放

容器：存储对象，使用map结构来存储，在spring中一般存在三级缓存，singleionObjects存放完整的bean对象，

1. 扫描/注册 BeanDefinition：读取 XML、注解或配置类，保存 Bean 的元数据。
2. 实例化 Bean：通过反射或工厂方法创建对象。
3. 依赖注入（DI）：把 Bean 所需依赖注入（构造器、Setter、字段）。
4. 初始化 Bean：调用 @PostConstruct、afterPropertiesSet() 或 XML 配置的 init-method。
5. 后置处理：BeanPostProcessor 对 Bean 做增强（如 AOP）。
6. 加入容器缓存：单例 Bean 放入缓存，原型 Bean 每次获取新实例。

Spring AOP 基于代理模式（JDK 动态代理或 CGLIB 动态代理），在方法执行前后织入横切逻辑，实现切面编程

核心机制：通过动态代理，在方法调用的前、后或异常时，执行额外逻辑（Advice）。

AOP（面向切面编程）：把事务、日志、安全校验等通用逻辑抽离出来，不和业务代码耦合。

容器启动时，Spring 解析 @Aspect 注解，生成切面信息。

根据切点表达式，找到需要增强的 Bean。

使用 JDK 或 CGLIB 动态代理 创建代理对象。

方法调用时：

切面（ Aspect）

连接点Uoin point）

通知（Advice）

切点（ Pointcut）

引入（ Introduction

目标对象（Target object

Aop代理

织人(Weaving):

@Import({ 类名.class , 类名.class... })public class TestDemo {}

步骤1：public class Myclass implements ImportSelector { @Override public String[] selectImports(AnnotationMetadata annotationMetadata) { return new String[]{&quot;com.yc.Test.TestDemo3&quot;}; }}

步骤2：@Import({TestDemo2.class,Myclass.class})public class TestDemo { @Bean public AccountDao2 accountDao2(){ return new AccountDao2(); }}

步骤1：public class Myclass2 implements ImportBeanDefinitionRegistrar { @Override public void registerBeanDefinitions(AnnotationMetadata annotationMetadata, BeanDefinitionRegistry beanDefinitionRegistry) { //指定bean定义信息（包括bean的类型、作用域...） RootBeanDefinition rootBeanDefinition = new RootBeanDefinition(TestDemo4.class); //注册一个bean指定bean名字（id） beanDefinitionRegistry.registerBeanDefinition(&quot;TestDemo4444&quot;,rootBeanDefinition); }}

步骤2：@Import({TestDemo2.class,Myclass.class,Myclass2.class})public class TestDemo { @Bean public AccountDao2 accountDao222(){ return new AccountDao2(); }}

ImportSelector接口和ImportBeanDefinitionRegistrar最终都是需要使用@Import 来做实现的导入，才能实现对组件的添加

1、spring 先解析当前事物的属性信息（根据具体的属性判断是否要开启事物）

2、当前需要开启的时候，获取数据库连接，关闭自动提交的功能，开起事物

3、执行具体的sql逻辑

4、在操作过程中，如果执行失败嘞，会通过completeTeanscationAfterThrowing执行回滚操作，然后再通过doRollBack方法来完成具体的事物的回滚操作，最终还是调用的jdbc中的rollbcak方法做回滚操作

5、在操作过程，如果正常，那么通过commitTransactionAfterReturning来完成事物的提交，具体的提交逻辑通过doCommint方法执行实现的时候先获取jdbc链接，然后通过调用jdbc的事物提交方法提交事物；

6、当事物执行完毕之后，需要通过cleanTransactionInfo方法清理事物相关的信息

实际中失效最多的

prototype

singleton

request

session

global session

true

false

懒加载只是针对多例bean才生效；单实例的bean都是提前加载；多实例的bean默认都是懒加载的形式加载，也就是首次需要用到的时候才会加载；

懒加载在第一需要用到这个对象的时候加载；非懒加载就是在环境启动的时候就提前把对象加载；

懒加载可以节约内存，但是不利于提前发现问题；非懒加载，可以提前发现加载的问题；

1.如果懒加载依赖了非懒加载的bean,那么这个懒加载就会失效；

根据类型注入从bean容器中找到UserRepository类型的做注入

根据“userRepo” 这个名称从 bean容器中找到  userRepo bean对象注入

1.字段和setter都生效

1.一个是spring提供的，一个是JDK提供的

2.注解中的属性不一样；

容器检测 A 不在缓存中 → 开始实例化

实例化对象：调用构造器创建 A（尚未注入 B）

将 A 放入 三级缓存 singletonFactories

容器检测 B 不在缓存中 → 开始实例化

B 依赖 A → 查找缓存

查三级缓存获取 A 的 ObjectFactory → 提供早期引用

通过 ObjectFactory 获取 早期 A 对象 → 注入 B

1. B 的属性注入完成 → 放入一级缓存

2. 回到 A → 注入 B 完成

3. A 的初始化完成 → 放入一级缓存

BeanPostProcessor 处理前/后置方法

A、B 都可以正常使用

一级缓存

二级缓存

三级缓存

有循环依赖

无循环依赖

总结

具体过程

图片展示

@Resource是jdk提供的注解

@Autowired

@Resource默认通过byname注入，也就数已通过名称注入，通过的接口名称来做注入；也可以指定byType注入

@Autowired默认是通过byType(也就是类型注入)，也就是默认注入接口的子类；如果接口有多个子类，搭配使用@Qualifier注解指定某一个特定子类

如果接口都只有一个子类，那么没有使用上的区别，如果接口有多个实现类，那么只能用@Autowried 搭配@Qualifier 来使用

什么是ApplicationContext

BeanFactory 的高级子接口，功能更丰富（国际化、事件发布、AOP 支持）。

Spring IOC 容器的顶级接口，定义了 Bean 的获取方式。

Bean 的元信息抽象，保存类名、作用域、依赖等。

IOC 容器就是通过 BeanDefinition 来描述和创建 Bean。

提供 Bean 的属性访问和修改能力，底层基于 Java 的反射和内省机制。

Bean 初始化前后提供扩展能力的接口。

比如 AutowiredAnnotationBeanPostProcessor 用来处理 @Autowired 注解。

在 Bean 实例化之前进行扩展（Spring 解决循环依赖时非常关键）。

用来生成代理对象的核心类，基于 JDK 动态代理 / CGLIB。

AOP 配置的核心抽象，包含了切面、通知、目标对象等信息。

方法拦截器，环绕通知的底层接口。

切面和通知的组合，封装了 “切点 + 通知”。

管理配置文件、属性源（Spring Boot 常用来读取 application.yml）。

事件模型，支持事件驱动开发。

Spring 提供的统一资源访问抽象（支持文件、URL、classpath）。

声明一个类交给 Spring 容器管理（通用组件）。

Web 层控制器（Spring MVC 专用，语义化 @Component）。

Service 层业务逻辑类（语义化 @Component）。

DAO 层持久化类，语义化 @Component，并支持数据库异常转换。

按 类型 自动注入 Bean。

配合 @Autowired，指定 Bean 名称，解决多个同类型 Bean 冲突。

注入配置文件中的属性值。

声明配置类，替代 XML 配置。

声明一个方法的返回对象交由 Spring 管理（常用于第三方类注入）。

指定 Bean 作用域（singleton/prototype/request/session）。

设置 Bean 延迟加载。

定义切面类。

定义方法的切入点执行时机。

当前事务的修改自己可见（即使没提交）。

其他事务在你没提交前是看不到的。

表示是springboot的配置类

开启自动配置注解

去mate-info/spring.factiories文件中加载需要被自动注入的java类

表示要扫描的当前包以及子包下的所有被标记成spring bean对象的java类

@ConditionalOnClass：某个类存在时才生效

@ConditionalOnMissingBean：只有当容器中没有某个 Bean 时才生效

提供了SpringMVC+内嵌了Tbmcat容器

提供了 SpringJPA和Hibernate框架整合

redis数据源整合

solr搜索

mybatis-springBoot整合

/actuator/z里还有端口都是配置文件中配置的

{
    "_links":{
        "self":{
            "href":"http://127.0.0.1:8081/actuator/z",
            "templated":false
        },
        "prometheus":{
            "href":"http://127.0.0.1:8081/actuator/z/prometheus",
            "templated":false
        },
        "beans":{
            "href":"http://127.0.0.1:8081/actuator/z/beans",
            "templated":false
        },
        "caches-cache":{
            "href":"http://127.0.0.1:8081/actuator/z/caches/{cache}",
            "templated":true
        },
        "caches":{
            "href":"http://127.0.0.1:8081/actuator/z/caches",
            "templated":false
        },
        "health-path":{
            "href":"http://127.0.0.1:8081/actuator/z/health/{*path}",
            "templated":true
        },
        "health":{
            "href":"http://127.0.0.1:8081/actuator/z/health",
            "templated":false
        },
        "info":{
            "href":"http://127.0.0.1:8081/actuator/z/info",
            "templated":false
        },
        "conditions":{
            "href":"http://127.0.0.1:8081/actuator/z/conditions",
            "templated":false
        },
        "configprops":{
            "href":"http://127.0.0.1:8081/actuator/z/configprops",
            "templated":false
        },
        "configprops-prefix":{
            "href":"http://127.0.0.1:8081/actuator/z/configprops/{prefix}",
            "templated":true
        },
        "env":{
            "href":"http://127.0.0.1:8081/actuator/z/env",
            "templated":false
        },
        "env-toMatch":{
            "href":"http://127.0.0.1:8081/actuator/z/env/{toMatch}",
            "templated":true
        },
        "loggers":{
            "href":"http://127.0.0.1:8081/actuator/z/loggers",
            "templated":false
        },
        "loggers-name":{
            "href":"http://127.0.0.1:8081/actuator/z/loggers/{name}",
            "templated":true
        },
        "heapdump":{
            "href":"http://127.0.0.1:8081/actuator/z/heapdump",
            "templated":false
        },
        "threaddump":{
            "href":"http://127.0.0.1:8081/actuator/z/threaddump",
            "templated":false
        },
        "metrics":{
            "href":"http://127.0.0.1:8081/actuator/z/metrics",
            "templated":false
        },
        "metrics-requiredMetricName":{
            "href":"http://127.0.0.1:8081/actuator/z/metrics/{requiredMetricName}",
            "templated":true
        },
        "scheduledtasks":{
            "href":"http://127.0.0.1:8081/actuator/z/scheduledtasks",
            "templated":false
        },
        "mappings":{
            "href":"http://127.0.0.1:8081/actuator/z/mappings",
            "templated":false
        },
        "refresh":{
            "href":"http://127.0.0.1:8081/actuator/z/refresh",
            "templated":false
        },
        "features":{
            "href":"http://127.0.0.1:8081/actuator/z/features",
            "templated":false
        }
    }
}

http://127.0.0.1:8081/actuator/z

http://127.0.0.1:8081/actuator/z/prometheus

http://127.0.0.1:8081/actuator/z/beans

http://127.0.0.1:8081/actuator/z/health

http://127.0.0.1:8081/actuator/z/caches/{cache}

http://127.0.0.1:8081/actuator/z/heapdump

http://127.0.0.1:8081/actuator/z/threaddump

http://127.0.0.1:8081/actuator/z/metrics

http://127.0.0.1:8081/actuator/z/scheduledtasks

http://127.0.0.1:8081/actuator/z/mappings

http://127.0.0.1:8081/actuator/z/refresh

http://127.0.0.1:8081/actuator/z/features

如果15分钟之内超过85%的客户端节点都没有正常的心跳信息，那么Eureka就会认为客户端和注册中心发生了网络故障，那么EURKEA就会自动进入自我保护机制

不再从注册列表中剔除长时间没有发送心跳的客户端

继续接受新的服务注册和服务查询，但是这些数据都不会被同步到其他的注册中心；

网络稳定之后，Eureka注册信息才会被同步到其他机器上；

防止因为分区网络，导致心跳信息没有发送或者没有接受到信条信息，而错误的把一个正常服务的机器从服务注册列表中剔除；

1、启动eureka服务集群

2、eureka客户端通过配置的eureka的服务ip,发送ip,端口，还有服务接口信息

3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常

4、服务调用的时候会向注册中心获取服务列表，然后从服务列表中获取具体信息，发送服务

服务注册

服务续约

服务剔除

服务下线

获取注册列表信息

1.客户端拉服务列表，注册中心会从缓存中拿，并不每次都是从服务注册列表中获取；

服务端，客户端缓存

缓存相关配置

2.客户端会缓存服务注册列表；

3.负载均衡器也会缓存服务列表

eureka注册中心本身支持集群化

eureka集群中某一节点挂了，其他节点持续对外提供服务

eureka高可用集群，中注册中心都是对等的，每个注册中心都会把自己的数据同步给其他注册中心；其他注册中心在收到心跳信息的时候会判断是客户端注册信息还是注册中心注册信息，如果是客户端信息那么注册中心就把数据同步到其他注册中心，如果是注册中心的注册信息那么就不做任何操作；

自我保护策略

子主题 6

是携程架构部门研发的分布式配置中心

1、统一管理不同环境，不同集群的配置

2、配置修改实时生效

3、配置版本管理

4、支持灰度发布

5、发布操作审计

6、客户端配置信息监控

7、提供了java和.net原生客户端

8、提供开发平台api

配置管理维度

本地缓存

配置更新基础示意图

配置更新详细示意图

apollo整体设计

1、阿波罗如何保证配置实时更新

2、阿波罗如何保证可用性

子主题

1、配置拉取

2、

启动时从服务端拉配置，写入内存。

Apollo 内部会注册 PropertySources，并且对 Environment 做 动态更新：

当大量的请求请求上层服务，上层服务所依赖的底层服务，在处理请求的时候，无法承受大量的请求，导致底层服务无法快速相应，导致上层服务请求堆积，导致上层服务无法快速处理请求，导致请求堆积，从而导致A服务不可用

由于底层的服务某种原因，导致整个上层服务都不可用，有一种连锁反应

服务熔断，服务降级，服务限流

单位时间内限制对服务器的访问量

在高并发情况下，保护系统不被大量请求导致服务雪崩

底层服务不可用的时候，上层服务直接不再调用这个底层服务，而直接返回一个结果；

隔离上层和底层服务之间的级联影响，避免系统崩溃

服务压力激增的情况下，主动对一些服务不处理或者简单处理，来释放服务器压力，保证服务器核心功能正常运行

保证整个系统核心功能呢个稳定性和可用性

服务熔断是调用链路上的某个服务不可以用引起的；

服务降级从整体负载考虑

熔断是框架层次的处理

降级是业务层次的处理

熔断主要是在客户端进行处理，书写兜底处理

降级需要在服务端进行兜底处理

流量控制

熔断降级

系统负载保护

资源定义

熔断降级

规则

1.对资源显示定义，来标记资源

2.提供可修改规则接口

3.对资源适时统计，流量适时监控

熔断策略

降级策略

降级规则

熔断-降级区别

流量控制角度

控制方式

限流控制规则配置项

限流规则统计项目

系统保护规则

不同点

相同点

@HystrixCommand

hystrix的熔断设计

hystrix的隔离设计

hystrix的超时机制设置

熔断流程

简易工作流程图

无需部署，直接嵌入客户端做为负载均衡器使用

1.调用端引入ribbon的包

1.负载均衡默认算法是轮询

2.通过把负载均衡对象定义成bean修改负载均衡算法

1、轮询策略

2、权重策略

3、随机策略

4、最小连接数策略

5、重试策略

6、可用性敏感策略

7、区域敏感策略

1、ribbon拦截所有的远程调用

2、解析调用路径中的host，获取服务名称

3、根据服务名称获取服务实例列表

4、根据负载均衡策略获取某一个具体的服务ip和端口

3、再通过http请求框架请求服务获取结果

示意图

客户端这边就可以实现这个，避免这个问题；

1.调用端引入feign包

2.调用端定义服务接口

3.用定义的服务接口调用

1.负载均衡默认算法是轮询

配置文件中定义修改后的负载均衡算法

HttpURLConnection

HttpClient

OKHttp

HttpURLConnection

流程图

1、本地接口A调用远程接口B

2、通过接口的动态代理实现了接口B

3、接口B读取解析springMvc相关注解，生成http请求

4、接口B将请求相关信息交给Ribbon对应的负载均衡器

5、负载均衡器生成最终的请求地址

6、交给http组件发送请求

1、启动类启动的时候扫描启动类上的注解@EnableFeignClients

2、这个注解中@EnableFeignClients中还有一个@Import注解，这个注解引入了一个FeignClientsRegistrar类

3、这个类实现了ImportBeanDefinitionRegistrar接口，也就是可以想spring容器中手动注入bean对象

4、FeignClientsRegistrar类中有一个方法registerBeanDefinitions ，做bean相关的操作

5、registerDefaultConfiguration方法，会去读取@EnableFeignClients注解；将这些信息注册到一个 BeanDefinitionRegistry 里面去

5、registerFeignClients方法中有registerFeignClients，和扫描所有@FeignClient注解的类

6、registerFeignClient方法构建bean

流程图

运维复杂、分布式事务难、调用链监控和调试难

服务调用复杂性

事物一致性问题

运维复杂性提高

测试复杂性提高

优点：服务独立部署、技术栈灵活、易于扩展、按需伸缩

1、服务部署灵活性提高

2、技术更加灵活

3、应用性能得到提高

4、简化开发

5、业务边界清晰

5、代码复用性

基于 HTTP/2 协议，支持多路复用、双向流、头部压缩。

使用 Protobuf（二进制序列化），性能比 JSON 更高。

用 Protobuf（二进制格式），体积小、性能高，但可读性差。

默认使用 TCP 长连接，结合自定义的二进制协议（Dubbo 协议），也可以支持 HTTP、gRPC。

更加灵活，主要用于 Java 体系。

支持多种序列化方式（Hessian2、Protobuf、JSON 等），默认 Hessian2（二进制格式）。

概念

特点

gRPC 是 Google 开源的高性能 RPC 框架

概念

每个服务写日志到本地文件（Logback / Log4j2）。

通过 Agent/采集器 收集日志

采集器将日志发送到消息队列或日志存储：

Elasticsearch：全文检索能力强，查询灵活。

Kibana（可视化查询，配合 Elasticsearch）。

或者

日志异常 → 触发告警 → 通知（钉钉、企业微信、PagerDuty）。

结合 Prometheus + Alertmanager，实现指标与日志联动。

应用级指标：QPS、RT、错误率、线程池情况、队列堆积。

系统级指标：CPU、内存、磁盘、网络带宽。

Prometheus + Grafana：常见组合，采集 + 可视化。

Micrometer：Spring Cloud 的指标收集库，支持接入 Prometheus、InfluxDB 等。

防止下游服务故障或高延迟影响整体系统

类似电路熔断，遇到故障自动中断请求，防止故障扩散

当下游服务不可用或响应过慢时，主动降低功能或返回备用结果，保证系统核心功能可用

返回默认值 / 缓存值

比如库存服务不可用时，返回最近一次缓存的库存

简化功能

比如社交应用动态加载失败，显示文字占位而非图片

静态兜底数据

提供固定提示或降级内容

目的：在请求到达后端前就做流量削峰。

方式

目的：把瞬时大量请求缓冲，降低后端瞬时压力。

方式

好处：秒杀瞬时高峰不会直接压到数据库或库存服务。

目的：减少数据库压力，防止超卖。

方式：

好处：大幅减少 DB 访问，防止库存超卖。

目的：在系统压力过大时，快速拒绝部分请求，保护核心服务。

方式：

好处：保证核心秒杀服务可用，不因为非核心请求宕机。

目的：降低数据库压力，提高读取性能。

方式：

好处：快速返回商品信息，减少 DB 请求量。

分库分表：减轻单表压力。

行级锁/乐观锁：避免超卖。

批量更新：将库存更新操作批量处理，降低事务冲突。

网关 + 服务注册发现 + 负载均衡：

异步消息 + 秒杀服务 + 库存服务 + 下单服务：

监控 & 报警：

作用：网络抖动或临时异常时重试，增加成功率

注意：

配合 指数退避（Exponential Backoff） 避免雪崩

设置最大重试次数，防止无限循环

限流：避免下游压力过大

熔断（Circuit Breaker）：下游故障时快速失败，保护系统

降级：提供默认值或缓存数据，保证服务可用

对于非实时业务，可用 异步消息解耦调用

优势：

降低同步调用压力

可重试、持久化，保证最终一致性

确保同一个请求重复调用不会产生副作用

常见方法：

唯一请求 ID

数据库唯一约束

幂等操作接口

记录调用请求、参数、返回值、异常

建议使用 结构化日志，便于搜索和分析

可结合 集中化日志系统（ELK / Loki / Graylog）

收集调用次数、成功率、延迟、异常率

Prometheus + Grafana 是常用组合

跨服务调用链路可视化

常用工具：Zipkin、Jaeger、SkyWalking

利用 Trace ID 追踪请求全链路

每个服务提供 /health 接口

调用方或注册中心定期探测服务健康状态

请求从节点 A 发送到节点 B 的时间不可预测，可能延迟很高

高延迟可能导致服务调用超时、请求堆积

超时设置（Timeout）

异步调用

批量请求

本地缓存 / 最近数据缓存

网络延迟波动大，导致响应时间不稳定

对高可用系统影响更大，可能触发不必要的重试或熔断

指数退避

抖动（Jitter）策略

负载均衡

系统被网络分区（Partition）隔离，节点无法互相通信

CAP 定理表明：在分区发生时，需要在 一致性 和 可用性 之间做权衡

副本机制

Leader / Follower 选举

异步写 / 最终一致性

降级与熔断

重试与补偿

每个服务都得单独管理登录/鉴权，复杂而且不安全。

服务间调用可能会被伪造或越权访问。

1、引入统一的授权服务器（可以用 Keycloak、Auth0、Spring Authorization Server）。

2、用户登录时 → 授权服务器颁发 Access Token（常用 JWT 格式）。

3、前端或 API Gateway 在调用微服务时，把 Token 放到 Authorization: Bearer <token> 请求头里。

4、每个微服务接到请求时

前端用户登录后拿到 Access Token（JWT）。

前端调用 订单服务时带上这个 Token。

订单服务再调用 库存服务时，把同一个 Token 转发过去。

库存服务验证、

好处：能明确知道“是哪个用户在下单”。

缺点：Token 在多个服务间传来传去，可能会暴露过多权限。

授权服务器事先给每个微服务注册一个 Client ID / Secret。

订单服务调用库存服务时，先用 Client Credentials Flow 去授权服务器换一个 Token。

这个 Token 的权限是“订单服务 → 库存服务”。

库存服务验证这个 Token 的合法性后才返回结果。

好处：粒度清晰，每个服务只拿自己需要的权限。

缺点：如果需要传递用户身份信息，还要额外设计。

Access Token 用 JWT 格式，包含签名。

库存服务只要拿到授权服务器公开的 公钥（JWKS endpoint），就能验证签名合法性。

库存服务向授权服务器发请求，调用 introspection endpoint（OAuth2 标准接口）。

授权服务器告诉它：这个 Token 是否有效、属于谁、scope 有哪些。

负责“你是谁”。

处理用户的登录、注册、验证密码、多因素认证（MFA）。

负责“你能做什么”。

发放 Access Token / Refresh Token / ID Token。

Token 里会写明用户角色、scope、权限范围。

统一用户目录（User Directory）。

管理用户 → 角色 → 权限的映射关系。

提供 OAuth2 / OIDC 协议接口给微服务调用。

打包应用（build 镜像）。

运行容器（run）。

提供镜像仓库（Docker Hub）。

管理成百上千个容器的部署、扩容、滚动更新。

提供服务发现、负载均衡。

监控容器健康状态，挂掉了自动拉起来。

一般情况下会有一个微服务应用以及日志收集服务；不会存在两个微服务

Service 提供 Pod 的稳定访问入口

在 K8s 中，Pod 是 短暂的、会随调度变化而重建的

Service 通过标签选择器（Selector）将请求转发到对应 Pod 集合

K8s 自带基本负载均衡（Pod 间流量分发）。

给同一个服务的不同pod会标记成一个组

当请求打到 Service 时，K8s 会自动在组中的 Pod 之间做 负载均衡（通常是轮询）。

Pod 级别

节点级别

容器资源调整

监控：HPA/VPA/CA 监控指标（CPU、内存、请求量、自定义指标）。

判断：指标超阈值 → 触发扩容，低于阈值 → 触发缩容。

执行：

调度：K8s Scheduler 把新 Pod 调度到可用节点。

用户访问量高峰 → CPU 使用率超过 70% → HPA 扩容 Pod 数量 3 → 5

节点资源不够 → Cluster Autoscaler 自动添加节点

高峰结束 → CPU 使用率下降 → HPA 缩容 Pod 数量 5 → 2

空闲节点 → Cluster Autoscaler 回收节点

概念

工作原理

特点

概念

工作原理

特点

概念

工作原理

特点

每个微服务单独 Git 仓库（或 mono repo）

代码 Push 或 Merge Request → 触发 CI/CD

构建镜像

自动化测试

更新 K8s 配置

部署策略

自动回滚

提供了一个服务注册中心、服务发现的客户端，还有一个方便的查看所有注册的服务的界面。 所有的服务使用Eureka的服务发现客户端来将自己注册到Eureka的服务器上

服务客户端，服务之间如果需要相互访问，可以使用RestTemplate，也可以使用Feign客户端访问

Hystrix Dashboard

监控和断路器

客户端的请求都需要先通过网关后，再请求后台服务，通过配置的路由来判断请求需要访问哪个问题，再从注册中心获取注册服务来转发请求

聚合监控平台

SOA依赖消息传递协议在服务之间进行通信

SOA类似单体服务，通常都是共享使用一个数据库

微服务，每一个微服务都有自己业务的服务

虽然都是较小服务组成，但是SOA服务的粒度比较粗，微服务粒度比较小

微服务之间是通过与语言无关的http协议通信

SOA通过SOA上层的ESB，通过消息传递协议进行服务之间通信

微服务的耦合性更低

SOA耦合性更高

左边是SOA，右边是微服务

分布式架构，将打的系统分为多个业务模块，部署到不同机器上，通过接口进行数据交互；

微服务可以部署在同一台机器上也可以分散部署到不同的机器上

全局唯一ID

计数器

sadd sku01 1001 1002 1003 1004

smembers sku01

scard sku01

srandmember sku01 2

spop sku01 2

sadd user1  sku1001 sku1002 sku1003 sku1004

sadd user1  sku1001

sismember user1  sku1001

smembers user1

scard user1

sadd user1 元素1 元素2 元素3 

Sinter user1 user2 

两个集合取交集

key对应的value中有两个元素，并且这两个元素对应的分数是score1, score2

1、采用先更新数据库，后更新缓存的做法

2、更新缓存失败后，捕捉失败的异常，然后发送消息队列，消息队列的消费方做缓存数据的再次更新，并且更新后，将缓存数据和需要被更新的数据做对比，是否保持一致；

并发量非常低

示意图1

示意图2

分布式锁

将数据库数据的更新还有缓存数据封装在一起，使用分布式锁来操作；

以被更新的目标数据的id为key;

子主题

子主题

大key导致占据的缓存空间过大，实际上可能这些大key并没有多少；

解决方式

某些实例分配到的槽位到，相应的得到数据量也会多

解决方式

在hash设置key的时候不要带上画括号

ua脚本的开销非常低

Lua脚本只能保证原子性，不保证事务性，当Lua脚本遇到异常时，已经执行过的逻辑是不会回滚的

将每一个master节点槽位分配均匀

增加节点，迁移槽位

对key中的{}中的内容计算 slot，将热点数据分散

将热点数据拆分成多个key，分散开

每个命令调用次数（keyspace_hits, keyspace_misses）

每个 DB 的 key 数量

绘制 key 或 slot 热点图

配置告警（单 key 访问量过高）

这种肯定不行

这种也不行

这种也不行，如果是一个高频使用的缓存，缓存周期到了也被淘汰了

不能够完全说明这个问题；短期之内使用的比较少，但是整个周期内使用的次数比较多，这种也会被淘汰

单 key 内存占用超过阈值

集合长度超过阈值

小量数据和短字符串优化

内存紧凑，但随机访问慢

数据量大或元素较长时使用

支持快速头尾插入/删除

全是整数且数量少时使用

内存紧凑，支持快速查找

元素多或者包含非整数时

提供 O(1) 查找、添加、删除

小量字段，短字符串

字段多或者字符串长时

支持 O(1) 查找、添加、删除

元素少且短字符串时使用

大量元素或字符串长时使用

哈希表存成员到 score 的映射 → 快速查找

跳表保证按 score 排序 → 支持范围查询

默认淘汰策略

解决方案

1) &quot;google&quot;2) &quot;yahoo&quot;

不能被重复添加

移除 languages 中的ruby元素

移除key的所有元素

获取tool集合长度

判断key为 joe&apos;s_movies 中是否含有&quot;bet man&quot;

往key为page_rank集合中添加数值为10 的google.com 元素

移除指定索引区间的值

移除指定分数区间的值

获取salary集合长度

正序从小到大

整个集合从小到大排序

递减排列

获取salary集合中分数在2000到5000之间的分数

获取salary集合 peter对应的分数

排序按照分数从小到大

排序按照分数从大到小

重新设置 nosql 中指定field对应的数据

将songs 集合中的&quot;Believe Me&quot;元素移动到my_songs

把 source的list集合尾部元素添加到 目标元素的头部；并把值返回给客户端

上一个命令的阻塞版本

MSET date &quot;2012.3.30&quot; time &quot;11:00 a.m.&quot; weather &quot;sunny&quot; OK

HMSET website google www.google.com yahoo www.yahoo.com OK

MGET date time weather

HMGET pet dog cat fake_pet

MSETNX rmdbs &quot;MySQL&quot; nosql &quot;MongoDB&quot; key-value-store &quot;redis&quot;

返回mykey对应的value的长度

返回key对应的field的个数

list集合对应的长度

没有设置存活时间

还存活 10084秒

不绑定route-key;交换机和queue名称一样

把消息发送到绑定了该交换机的所有队列上

不需要指定routeing-key

数据会被发送到指定路由的queue上去

消息会被转发到所有满足route-key的队列，以及bingkey模糊匹配到的队列

交换机名称

是否持久化，true持久化

值集True flase

所有的消费者完成消费后自动删除

ture，所有的消费者消费完成之后，自动删除

值集True flase

Message TTL

Auto expire

Max length

Max length byte

标记当消息发送出去，找不到路由的处理方式

true：消息返回给服务端，服务端可以做后续的处理

false：消息返回服务端，服务端直接删除

单条应答

批量应答

不确认

自动确认

手动确认

1.由于网络原因导致数据丢包

2.交换机的路由没有被队列绑定，消息直接丢失

针对1：

针对2：

丢失原因：客户端在处理消息的时候突然机器挂了，导致消息丢失了；

服务端设置交换机，队列，数据的持久化；服务器宕机后，重启会读取磁盘上的持久化的数据；

问题：由于消息的持久化是一批的持久化，可能宕机了，这一批数据还持久化到磁盘

消息的持久化

1.消费者在处理消息的时候出现异常了，那么这条消息就是没有被正常的消费；如果不采取措施，那么这个消息就会丢失

ack机制

默认是单线程消费

默认是每次拉取一条消息

直接内存访问

能够不经过cpu直接相互直接就能进行数据交互的硬件设备

概述（kafka就是mmap实现方式）

mmap方式，用户态和内核态共享内核态数据缓冲区，数据不需要从内核态复制到用户态空间；用户态发送数据的时候，就直接应用内核态的文件句柄就行（无需把数据从内核态拷贝到用户态，再从用户态拷贝到socket套接字的内核空间）；

数据不需要经历从内核态拷贝用户态；数据直接从DMA设备直接发送对应的做网络传输的DMA设备，由这个设备直接传输数据

read-ahead

write-behind

写操作

读操作

读写都是顺序写入顺序消费，能保持较高的效率

1.读操作不会组阻塞写操作

2.不受内存大小限制

3.线性的读取速度依旧很快

4.相对于内存保存时间更长

删除策略是可以配置

常见删除策略

日志文件中的消息和日志文件本身都会被删除

读操作读取的是要被删除文件的副本

1.topic的每一个分区都会专属的append-only日志文件；

3.每条消息在文件的位置称之为offset（偏移量）

2.属于分区的消息会被追加到日志文件的末尾

概述

日志条目内容

该文件第一条数据偏移量+.kafka

根据保留策略删除日志分段

参数配置log.cleanup.policy = delete

日志删除策略

根据消息的key进行压缩，相同的key的消息，只会保留一个副本；这个key就是业务消息中的key，需要去手动指定这个key对应的是业务中的那个字段

参数设定

压缩过程

同一管理所有的服务器

记录topic的分区信息与对应的服务器节点对应关系

消费者启动的时候，都会去zk创建自己的节点

可以通过zk的配置文件动态感受来自服务器节点的新增减少，来实现相应的负载均衡

zk动态感受消费者新增减少，来合理的实现负载均衡

将分区和消费者id绑定记录到临时节点上

记录每个分区中消费者消费的偏移量会发送给zk，方便在消费者重启之后，或者是重新分配消息分区，能够继续之前的消费

rerplica.lag.time.max.ms=10000

rerplica.lag.max.messages=4000

发送消息的程序异常，导致消息压根没有发送出去

消息发送了，由于中间网络原因，以及服务器接收原因，导致数据服务器没有正常接收到数据

ACk设置=1，主机拿到了数据，从机还没有同步主机数据，这时候主机挂了，从机无法同步主机数据

主机拿到数据，主机就挂了，没有设置相应的从节点，来备份数据；

主机挂了，从机被选为主机，主机中还有部分数据没有被同步到从机

消息在消费的时候，消息消费的自动确认提交偏移量；如果批量的消息有20条，消费到10条消息的时候异常了，那么就会自动提交消息的偏移量是20，也就是会导致后面10条消息是没有被正常消费，也相当于消息丢失；

消息确认机制

概述

消息重试前提条件(两者同时满足才能重试)

消息重试机制参数设置

消息确认机制主要是针对消息发送到服务器正常接收这个过程的处理

消息重试机制，主要是针对消息发送之前生产者内部自己发送消息异常的兜底处理

参数设置：min.insync.replica

参数设置：unclean.leader.election.enable=false 本身默认就是flase

日志文件保存的最长时间

默认是1周时间

日志保存的最长分钟

默认为null

日志保存的最长分钟

默认为null

新分区产生时间,以小时为单位

默认一周

子主题 1

子主题 2

分区最大容量

默认1g

分区等待删除时间

默认60000ms

指定消息的key的序列化类(需要实现Serializer接口)

无默认值

指定消息内容的序列化类(需要实现Serializer接口)

无默认值

batch.size

linger.ms

batch.size和liger.size只要满足一个，消息就会被发送

max.block.ms

request.timeout.ms

max.request.size：

生产者要求领导者在考虑完成请求之前收到的确认数量

默认值1

用途：

值集

生产者发送完消息，接受服务器消息确认的时间

默认值120000ms，120秒

消息发送失败消息重试次数

默认值是int的最大值

消息重新发送中间间隔时间

默认值100ms

消息以怎么的压缩格式进行压缩

值集：“gzip”、“snappy”、“lz4”、“zstd”

关闭空闲连接时间（生产者和服务器最大失联时间）

默认540000

单个连接，可接受的最大未确认数量

默认值5；也就是消息发送需要服务端确认，这个就是在发送消息之前需要确认发送如果没有确认的消息大于等于该参数，那么就会发送失败。

参数修改之后发送通知的类

消息拦截器

发送消息之前消息会被拦截，消息还可以做相应的处理

TCP连接接受方缓冲区大小

默认值：32K

TCP连接发送方缓冲区大小

默认值：128