天天向上

Sync的实现就是基于monitor 管程，monitor 对象中有owner，WaitSet，EntryList。线程会进入monitor 对象中，查看owner 是否有值，如果没有，则会写入自己的线程id。如果有，则证明已经有线程拿到了锁。就会去EntryList中等待，进入阻塞状态。持有锁的线程如果调用了wait 方法，则会进入WaitSet中，进入等待状态。等出了WaitSet，又会进入EntryList中阻塞

同

异

读屏障:
保证在该屏障之后,对共享变量读取,加载的是主存中最新数据

写屏障:
保证了在该屏障之前,对共享变量的改动都同步到主存中.不修改顺序

AbortPolicy:丢弃任务并抛异常

DiscardPolicy:丢弃任务，但是不抛异常

DiscardOldestPolicy:丢弃队列最老的任务，然后把当前任务加入队列

CallerRunsPolicy:由调用线程处理该任务

在Java内存模型中，synchronized规定：线程在加锁时， 先清空工作内存→在主内存中拷贝最新变量的副本到工作内存 →执行完代码→将更改后的共享变量的值刷新到主内存中→释放互斥锁。

仅限于当前线程

不传递

线程间数据隔离

ThreadLocalMap

单线程、线程内部

仅限于父子线程

父线程到子线程

线程间数据隔离

ThreadLocalMap+继承关系

父子线程间

可跨线程、跨线程池

跟随线程池、手动传递

线程间数据隔离，但支持跨线程数据传递

ThreadLocalMap+TtlRunnable

异步、多线程

可跨线程、跨线程池

跟随线程池、手动传递

线程间数据隔离，但支持跨线程数据传递

ThreadLocalMap+Transmitter

异步、多线程

原始文档

正常索引(正排索引)

倒排索引

代表查询，搜索 类似于SQL的select关键字

叶子查询

复合查询

代表聚合，类似于SQL的group by 关键字，对查询出来的数据进行聚合 求平均值最大值等

对搜索出来的结果中的指定字段进行高亮显示

指定字段对查询结果进行排序显示，类比SQL的order by关键字

对查询结果分页，类似于SQL的limit关键字

后置过滤器，在聚合查询结果之后，再对查询结果进行过滤

total

hits数组

max_score

执行整个搜索请求耗费了多少毫秒

部分告诉我们在查询中参与分片的总数，以及这些分片成功了多少个失败了多少个。正常情况下我们不希望分片失败，但是分片失败是可能发生的。如果我们遭遇到一种灾难级别的故障，在这个故障中丢失了相同分片的原始数据和副本，那么对这个分片将没有可用副本来对搜索请求作出响应。假若这样，Elasticsearch 将报告这个分片是失败的，但是会继续返回剩余分片的结果。

查询是否超时。默认情况下，搜索请求不会超时。如果低响应时间比完成结果更重要，你可以指定 timeout 为 10 或者 10ms（10毫秒），或者 1s（1秒）。在请求超时之前，Elasticsearch 将会返回已经成功从每个分片获取的结果。
应当注意的是 timeout 不是停止执行查询，它仅仅是告知正在协调的节点返回到目前为止收集的结果并且关闭连接。在后台，其他的分片可能仍在执行查询即使是结果已经被发送了。

- 标记清除算法的效率不算高
- 在进行 GC 的时候，需要停止整个应用程序，用户体验较差
- 这种方式清理出来的空闲内存是不连续的，产生内碎片，需要维护一个空闲列表

- 没有标记和清除过程，实现简单，运行高效
- 复制过去以后保证空间的连续性，不会出现“碎片”问题。

- 此算法的缺点也是很明显的，就是需要两倍的内存空间。
- 对于 G1 这种分拆成为大量 region 的 GC，复制而不是移动，意味着 GC 需要维护 region 之间对象引用关系，不管是内存占用或者时间开销也不小

- 消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM 只需要持有一个内存的起始地址即可。
- 消除了复制算法当中，内存减半的高额代价。

- 从效率上来说，标记-整理算法要低于复制算法。
- 移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址
- 移动过程中，需要全程暂停用户应用程序。即：STW

为每一个线程预先分配一块内存，JVM在给线程中的对象分配内存时，首先在TLAB分配，当对象大于TLAB中的剩余内存或TLAB的内存已用尽时，再采用CAS进行内存分配。

CAS 是乐观锁的一种实现方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。

标量替换：用标量值代替聚合对象的属性值

栈上分配：对于未逃逸的对象分配对象在栈而不是堆

同步消除：清除同步操作，通常指 synchronized

有时候使用CMS容易OOM,可以试试删掉CMS参数,使用默认1.8默认的

各种IO流

构建

使用(可使用任意数量装饰器)

存在耦合,一个处理日志/性能/事务的类为什么要实现业务接口（Command）呢?

如果别的业务模块，没有实现Command接口，但是也想利用日志/性能/事务等功能,就没办法

共享元素

包装类、缓存、池化技术

在父类（BaseCommand）中已经把那些“乱七八糟“的非功能代码都写好了， 只是留了一个口子（抽象方法doBusiness()）让子类去实现。

子类变的清爽， 只需要关注业务逻辑就可以了。
调用也很简单，例如：
BaseCommand  cmd = ...  获得PlaceOrderCommand的实例...
cmd.execute();

父类会定义一切： 要执行哪些非功能代码， 以什么顺序执行等等
子类只能无条件接受，完全没有反抗余地。
如果有个子类， 根本不需要事务， 但是它也没有办法把事务代码去掉。

对应协议

角色:电商平台 OR 商家

应用层就像在特定城市特定大厦特定房间内的某一个用户，应用层之间的通讯就像两个不同用户之间发送的信，这个信是点对点的，从一个用户（某一主机内特定应用程序）到另外一个特定用户（另一主机内特定应用程序）。一个主机（大厦）内可能有很多应用程序（客户），我们如何区分它们呢，实际生活中我们用房间号，在电脑内部区分不同应用程序我们用端口号

对应协议

角色:快递公司

用户写好了信，需要给信套上信封，并且写好发件人所在大厦，和收件人所在大厦，实际生活中的大厦完全可以类比为我们的计算机和服务器

对应协议

角色:

邮件准备好了，他首先会被送到本城市的快递公司，并且被打包，包裹上会写着源是重庆快递公司，目的是沈阳快递公司，但是重庆快递公司发现它不能直接发货到沈阳，需要通过北京快递公司进行中转。所以虽然目的是沈阳，但是他首先把这个包裹发给了北京。某个城市的快递公司就像IP协议，要抵达目的IP，需要查询路由表，如果发现目的地址不是直连就需要找下一跳。通过了解快递公司的工作，我们了解到IP协议是逐跳工作的。每一跳（路由器）根据目的IP地址查询下一跳，并且最终转发到目的地。

数据链路层

物理层

HTTPS 和其他网络协议使用TLS 来进行加密 ，它是SSL 的现代化版本。

TLS 1.3 是TLS 协议的最新版本

SNI

开头为0

7位网络号

24位主机号

开头为10

14位网络号

16位主机号

开头为110

21位网络号

8位主机号

开头为1110

28位组播地址

开头为1111

28位留待后用

停车场号

停车位号

比如掩码为16,那么11000000.10101000.00000000.00000000;后面16为可变

比如掩码为18,那么11000000.10101000.00000000.00000000;后面14为可变

IP为192.168.0.0,掩码位16.那么可用65534个IP(192.168.0.0为网络初始,192.168.255.255为广播)

IP为192.168.31.170/20

10.0.0.0--10.255.255.255

172.16.0.0--172.31.255.255

192.168.0.0--192.168.255.255

我们想要用户的应用来访问，计算机就必须要通过对外暴露的一些接口，才能访问到，从而间接的实现对内核的操控，但是内核本身上来说也是一个应用，所以他本身也需要一些内存，cpu等设备资源，用户应用本身也在消耗这些资源，如果不加任何限制，用户去操作随意的去操作我们的资源，就有可能导致一些冲突，甚至有可能导致我们的系统出现无法运行的问题，因此我们需要把用户和内核隔离开

内核空间

用户空间

我们的应用程序也好，还是内核空间也好，都是没有办法直接去物理内存的，而是通过分配一些虚拟内存映射到物理内存中，我们的内核和应用程序去访问虚拟内存的时候，就需要一个虚拟地址，这个地址是一个无符号的整数

慢在了 等待 和 拷贝

服务端代码示例

阻塞、单进程

多进程、但创建线程耗费大量的资源(系统开销大)

还有改进的多线程

定义:通过 I/O 事件分发，当内核数据准备好时，再以事件通知应用程序进行操作

3.0 : Select模型

4.0 : epoll模型

阻塞IO（Blocking IO）

非阻塞IO（Nonblocking IO）

IO多路复用（IO Multiplexing）

信号驱动IO（Signal Driven IO）

异步IO（Asynchronous IO）

对比

特点

缺点

单 Reactor单线程

单 Reactor多线程

主从Reactor多线程

首先我要知道我的 IP 以及对方的 IP

通过子网掩码判断我们是否在同一个子网

在同一个子网就通过 arp 获取对方 mac 地址直接扔出去

不在同一个子网就通过 arp 获取默认网关的 mac 地址直接扔出去

A发送数据包首先会到交换机，此时交换机会顺便记录下A的MAC地址

交换机将数据包转发到所有端口

之后只有目标机器会给相应，这是交换机就会记录下相应的机器MAC地址与端口

是通过以太网内各节点之间不断通过交换机通信，不断完善起来的

这就可以引申出路由器

我收到的数据包必须有目标 MAC 地址

通过 MAC 地址表查映射关系

查到了就按照映射关系从我的指定端口发出去

查不到就所有端口都发出去

网络层（IP协议）本身没有传输包的功能，包的实际传输是委托给数据链路层（以太网中的交换机）来实现的。

事先规划好网络，再根据规划的网络烧录，定好的MAC地址

引申出新的规则：IP地址

A 给 C 发数据包，怎么知道是否要通过路由器转发呢？

A 如何知道，哪个设备是路由器？

路由器怎么知道，收到的这个数据包，该从自己的哪个端口出去，才能直接（或间接）地最终到达目的地 C 呢

刚才说的都是 IP 层，但发送数据包的数据链路层需要知道 MAC 地址，可是我只知道 IP 地址该怎么办呢？

我收到的数据包必须有目标 IP 地址

通过路由表查映射关系

查到了就按照映射关系从我的指定端口发出去（不在任何一个子网范围，走其路由器的默认网关也是查到了）

查不到则返回一个路由不可达的数据包

MAC 地址表是通过以太网内各节点之间不断通过交换机通信，不断完善起来的。

路由表是各种路由算法 + 人工配置逐步完善起来的。

arp 缓存表是不断通过 arp 协议的请求逐步完善起来的。

优化性能，减少延迟

当客户端发送请求时带上 Connection: keep-alive（或在 HTTP/1.1 中默认隐含），它是在告诉服务器：“请在处理完这个请求后，不要关闭我们的 TCP 连接，我可能很快还要用它发送其他请求。”

告诉浏览器“收到这个内容后，你是应该直接打开它（inline），还是把它当作一个文件下载下来（attachment），并且我建议你下载时叫这个名字（filename）”

指示客户端尝试在浏览器窗口内显示内容（如果它能处理该内容类型）

一个 image/jpeg 图片通常直接显示在页面中。

一个 text/html 页面直接渲染。

一个 application/pdf 文件，如果浏览器有 PDF 插件，可能会在浏览器标签页内打开。

指示客户端应该将内容视为附件，强制弹出“另存为”对话框让用户下载文件，而不是尝试在浏览器内显示它。这是实现文件下载功能的关键。

通常与 filename 参数一起使用，为下载的文件提供一个建议的名称：Content-Disposition: attachment; filename="report.pdf"

并非5Ghz穿墙能力更差。5GHz信号的波长要比2.4GHz信号的要短，而波长越短的电磁波穿透力就越强。但因为频率越高消耗在穿透上的能量越大，导致信号浪费，设备接受到的反而是反射衍射过来的信号。2.4Ghz下，衍射和反射比5Ghz要多，因此设备接受到的信号反而强。

www.google.com的响应时间过长

XXX拒绝了我们的连接请求

连接被重置

ip.src_host==192.168.100.20

过滤发起地址ip

过滤目标地址ip

过滤源或目的地址

如果抓的包有很多种协议类型，可以输入 tcp 回车只看tcp 协议的包

ip.src_host==192.168.100.20 and http

tcp.port == 4980

tcp.port == 4542 or tcp.port == 4528

tcp.port in {80 443 8080}

tcp.flags.ack == 0

tcp.flags.syn == 1

http.request.method == “GET”

http.request.method == “POST”

tcp.segment_data contains “202005190001”

报文类型，8代表请求，0代表应答

为0，表示为回显应答成功

表示认证这个ICMP报文是否被篡改过。校验完整性

表示校验的结果，Good代表没问题

表示标识符ID

表示序列号

具体发送到数据包，当然肯定是通过加密的。

边缘节点加速指的是通过部署在各地的边缘节点服务器（Edge Node）来为用户提供更近、更快的服务访问路径。

用户访问内容时，不再从远程主服务器获取数据，而是从“离用户更近”的边缘节点获取。

这些边缘节点通常由 CDN（内容分发网络）提供。

你在中国访问一个美国网站，原本需要跨越太平洋才能获取资源

静态内容（可缓存）

图片、JS、CSS、视频等

是

靠边缘缓存服务器

通常可集成在CDN/全站加速等平台中

动态加速指的是对动态内容（无法缓存）进行传输优化，通过智能路由、协议优化、链路选择等手段加快访问速度。

不缓存，而是优化实时交互数据的传输路径。

接口请求、API调用、数据库查询等不能预缓存的内容传输。

TCP协议优化（如TCP握手优化）

智能选路（选最优链路）

重传机制优化

一个APP请求接口 api.example.com/user/info，每次请求内容都不同（动态的），这就不能用CDN缓存。

动态内容（不可缓存）

登录、支付、搜索、接口请求等

否

靠智能路由/协议优化

“边缘”是相对“中心”来说的。

传统网站或服务通常部署在中心服务器（如北京、上海、美国AWS），所有用户访问时都得连到这个中心机房。

而边缘节点服务器就是部署在多个地理位置（如成都、广州、郑州、东京、硅谷等）的“小型中继服务器”

更靠近用户（网络上更近，物理上也可能更近）

更快地响应请求

减少跨省/跨国访问所产生的延迟与丢包

内容缓存

就近响应请求

链路优化

安全防护

边缘计算

中心服务器

边缘节点服务器

你订购商品时，商品从总部发货很慢，从离你最近的仓库先发货就快多了

边缘节点服务器就是部署在离用户更近的服务器节点，它通过缓存内容或优化请求传输，来实现“加速、稳定、安全”的访问体验。 它是 CDN、边缘计算、动态加速的基础设施。

缓存静态资源

就近响应

流量分担

抗攻击（如DDoS）

HTTPS优化

CDN 的核心就是通过边缘节点加速内容的访问。

所以“边缘节点加速”可以理解为“CDN 提供的主要能力之一”。

传统 CDN 擅长加速静态内容，但对动态请求无能为力。为了解决这一问题，CDN厂商陆续推出了：
 • 全站加速（Whole Site Acceleration）
 • 动态加速（Dynamic Acceleration）
 • 全球加速、GA、DCDN（Dynamic CDN）

这些功能都是在CDN网络基础上，使用智能路由、链路调度等技术，对动态请求也进行加速。

主页上的图片、商品信息页等走 CDN缓存 + 边缘节点加速；

登录、加入购物车、支付等操作请求走 动态加速（全站加速）；

所有这些能力可能都在一个“CDN服务平台”上由同一个厂商（如阿里云CDN、腾讯云CDN、Cloudflare）提供。

MacOS 10.13后启用

netcat

nc -vc 192.168.1.100 8080

2>/dev/null 是为了忽略没有权限的错误信息。

less your.log

less +G your.log

less 配合搜索非常好用（输入 /关键字 回车，然后按 n 继续查找）

与vi相比，less只读，启动更快，更安全

less +F your.log

tail -f your.log

tail -n 200 -f your.log

可以实时

不方便暂停查看

基本支持翻页，查旧日志

不支持搜索

lsof -i -P -n | grep java

说明：

示例

netstat -tunlp | grep java

ps -ef | grep java

很多 Java 项目在启动命令里会写

用途

用法

用途

特点

用法

用途

特点

用法

用途

用法

nslookup  xxx.com

dig

traceroute xxx.com

tracepath xxx.com

mtr xxx.com

查看/管理ARP缓存表

示例

主要有：Shift + Alt + 鼠标拖动

Shift + Option + 鼠标拖动

如:long a=0l; --> long a=0L;字母l应该大写为L,醒目易懂

public static final int t=new Random().nextInt();这样就会常量变变量

nt i=80;
String s=String.valueOf(i<100?90:100);
String s1=String.valueOf(i<100?90:100.0);
System.out.print(s.equals(s1)); //false

public class MainTest {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        System.out.println(PriceTool.calPrice(12, 1)); // 1
    }
}
 
class PriceTool {
    public static int calPrice(int price, int discount) {
        return 1;
    }
    public static int calPrice(int price, int... discount) {
        return 2;
    }
}

null没有类型

java5开始引入 import static ,其目的是为了减少字符输入量，提高代码的可阅读性。

本地的方法和属性会被使用。因为编译器有最短路径原则，以确保本类中的属性、方法优先

如果要变更一个被静态导入的方法，最好的办法是在原始类中重构，而不是在本类中覆盖。

因为反序列化时构造函数不会执行。JVM从数据流中获取一个object对象，然后根据数据流中的类文件描述信息查看，发现时final变量，需要重新计算，于是引用person类中的name值，而此时JVM又发现name竟然没有赋值，不能引用，于是不再初始化，保持原值状态。

固定间隔重试（Fixed Interval Retry）

线性退避（Linear Backoff）

指数退避（Exponential Backoff）

指数退避加抖动（Exponential Backoff with Jitter）

梳理要涉及哪些变更，影响面是哪些

有没有做到数据与接口兼容性

思考要不要做灰度，灰度策略是啥

确认上下游接口是否准备好

先进行DDL(增加字段时不要加非空约束，否则会对之前有影响)，建MQ，再发布代码

先发布服务提供方，再发布服务调用方

自底向上，数据存储层，微服务层，网关层，UI

比如方法名不太优雅,调整后上线也可能故障,可能是别人的二方包,调用方会找不到该方法

能否平滑兼容

历史数据要不要迁移

流量能否抗住

一致性要求高不高

性能爬坡、缓存预热

同时去执行新逻辑与老逻辑，然后将处理结果做比较，及时发出告警

老逻辑执行完以后将出参入参保存下来，可以通过MQ或者数据库；然后异步进行流量回放，再进行观察与告警

首先是使用top命令定位系统中消耗较高的进程id

再使用jstack命令结合 | 管道符可以快速定位消耗较高的代码行。这是还可以使用grep命令过滤关键字

thread -i 3000 -n 5

排查方法具体执行耗时

1.利用BeanPostProcessor接口中postProcessBeforeInitialization与postProcessAfterInitialization方法在Bean初始化前后,统计初始化耗时

2.利用底层探针，例如arthas的trace命令统计每个方法耗时

3.手动debug

1.数据库初始化耗时->a.数据库连接池初始化；b.获取数据库元数据初始化

2.因为分库分表都需要将以上初始化

a.数据库连接池初始化(设置Druid中asyncInit为true,进行懒加载)

b.获取数据库元数据初始化(将ColumnMetaData等数据变为JSON。存储在本地,直接读取文件;在工程中定义同样的包名类名,就可以把里面覆盖掉)

1.如果本地启动容器不想注册到注册中心,可以实现BeanPostProcessor接口,重写postProcessBeforeInitialization方法,将ProviderConfig中register字段set为false;
2.以上代码还应该进行环境隔离.利用@Conditional(TestEnvirChangCondition.class)指定环境;在TestEnvirChangCondition中实现Condition接口,重写matches方法.conditionContext.getEnvironment().getProperty(keyName,Boolean.class,defaultValue);
2.1建议使用 Spring 原生 Profiles 来区分集成测试环境
a. 在 DataSourceDefinitionProcessor 和 NotRegister 标注 @Profile("unittest")
 b. 在具体测试类中标注 @ActiveProfiles("unittest")

补充关于 Spring Bean 生命周期 SPI BeanPostProcessor 接口为什么不是一个很好的统计 Bean 耗时时间，主要原因在于一个 Bean 可能被多个 BeanPostProcessor 处理，所以需确保统计 BeanPostProcessor 的postProcessBeforeInitialization 必须是第一个调用，
同时，确保它的 postProcessAfterInitialization 是最后一个执行，显然这是矛盾的。

Spring 5.3 提供了 StartupStep API，它能够统计部分 Bean 和 IoC 容器耗时，但是还是不完整，估计作者也感受到了难度。其他类似需求相关实现开源代码
核心实现代码：https://github.com/microsphere-projects/microsphere-spring-projects/blob/main/microsphere-spring/microsphere-spring-context/src/main/java/io/github/microsphere/spring/context/event/
Bean 生命周期核心：BeanEventListener.java     
Bean 耗时统计：BeanTimeStatistics.java   
单元测试：BeanTimeStatisticsTest.java

如果在业务表中使用 is delete 字段来标记逻辑删除，査询时需要附加 is_delete=false 的条件，这会增加数据库的査询成本，尤其是数据量大的情况下，可能导致索引失效、查询性能下降。

业务表承担的是核心业务功能，通常会有很高的读写需求。如果删除的数据一直存在，业务表的体量会持续增大，不仅会影响查询效率，还会对数据存储和维护带来压力。

宽表化归档数据

也可以利用MQ，尝试异步方案

为了保证数据能够落地到归档表，并且独立事务，还做了额外操作的。不同的是采用了延迟归档。删除还是先逻辑删除，物理删除会放到后面操作。后续通过延迟的消息队列，落地到归档表（数据直接复制或者拿消息队列的数据写入）。归档表写入完数据后，才去物理删除数据。业务数据库和归档库在上述操作中没有事务的联系，异步的。

扫完商品，确认生成订单，生成一个唯一的订单流水号，再利用订单号做幂等

基础的支付知识，超时了，这笔单就当做失败，丢队列里面发起撤销操作就好了，外加补偿撤销（因为队列是不可靠的）。

那么，为什么不是重试而是撤销回滚？

支付宝端：
    a、可做幂等的情况下：
        1、有订单ID：可以直接通过订单ID判断是否为重复扣款。
        2、没有订单ID：可以通过扫码枪的唯一标识+IP+请求参数（如扣款金额+扣款账户，甚至商品清单等其他参数）+一定时间内（如3分钟内）判断是否为重复扣款。
    b、不可做幂等的情况下：
        1、可以增加其他通知渠道：比如微信在断网使用付款码的情况下，交易完成用户手机会收到一条扣款成功的短信。
        2、支付宝服务端每日定时对账。
        3、当新的扣款动作来时，是否可以关闭之前正在处理的订单。
用户端：
    1、在被要求二次扫码前可以先看看自己的账单是否扣款成功。
    2、可以先让后面排队的人先付款，等几分钟后在让商家确定自己的订单是否扣款成功。
    3、在二次扫码前要求商家关闭之前的订单。
    4、在发现重复扣款时，及时与支付宝客服和商家联系。

总之理论上是会发生重复扣款的现象，但自己在现实生活中经常被二次扫付款码，也并没有出现重复扣款的现象，那具体支付宝怎么做的咱也不知道，仅仅是揣测。

这个是面试。实际中，几乎不会出现这种问题。在京东遇到过，重复支付的问题，第二天就原路回退了。一般情况都会在第二天进行对账，然后修复错误扣款，或者直接说平台方负责错误款项。

属于"无个性化"数据

种类

属于个性化/高频写数据

种类

优化的关键前提

静态页面处理需要几毫秒

动态页面处理需要几百毫秒

git cherry-pick  <commitHash>

git cherry-pick  <HashA> <HashB>

回到操作前

不回到操作前

公共分支合并代码使用merge

私有分支需要拉去新代码可以用rebase

可以保留初始commit的创建时间

效果上,可以简单理解为:多次的Cherry pick

将会将当前分支的 HEAD 指针、暂存区和工作目录重置到前一个提交的状态，并丢弃所有未提交的更改。这样做相当于将当前分支向后移动一个提交。

--hard 参数表示重置模式为“硬重置”

HEAD~1是指向当前所在分支的最新提交的引用。~1 表示向上移动一个提交。因此，HEAD~1 表示当前分支的上一个提交。

hsperfdata_root，  tomcat.************.8080,(结尾是项目的端后)  tomcat-docbase.*********.8080

Multipart（form-data）的方式处理请求时，默认就是在第二个目录下创建临时文件的

CentOS7 定时清理临时文件目录的服务

重启服务，但是只能根据服务器的策略维持几天(如果这期间没有发生变化的文件或目录)

手动把缺失的目录建出来

更新SpringBoot的版本

手动设置Tomcat目录

ArrayList(底层实现是数组，线程不安全，查找修改速度快，增删慢)

LinkedList(底层实现是链表，线程不安全，查找修改速度慢，增删可能也慢)

线程安全的List：Collections.synchronizedList(List< T> list)

CopyOnWriteArrayList

vector(底层实现是数组，线程安全，无论增删改查都慢)

Stack

HashSet(底层实现使用hash算法，乱序，不可重复)

LinkedHashSet

TreeSet(底层实现二叉树，一般用于排序)

TreeMultiset

HashMultiset

先进先出,类似喝酒没有吐;入口和出口在不同边

特性

LinkedHashMap(底层使用链表法存储键)

ConcurrentHashMap

特性

特性

Properties

同

异

如方法返回值为boolean,Spring返回Boolean。直接返回Spring结果可能会为null。所以应该使用Boolean.TRUE.equals(result)判断

第一代

第二代

第三代

当传递基本数据类型，比如原始类型（int、long、char等）、包装类型（Integer、Long、String等），实参和形参都是存储在不同的栈帧内，修改形参的栈帧数据，不会影响实参的数据

当传递的引用类型，形参和实参指向同一个地址的时候，修改形参地址的内容，会影响到实参。当形参和实参指向不同的地址的时候(比如重新new了对象)，修改形参地址的内容，并不会影响到实参

jmap -dump:format=b,file=/path/to/dumpfile.hprof <PID>

-XX: +HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/jdk/dump

比如父类返回Number，子类返回Integer类型

惰性执行

流水线像是描述你想干什么，而不是你怎么干。不像传统for循环，每步都得手动维护索引

不可变

因为内部链式消费，一旦顺序错了，结果可能就完全变了。比如limit放在filter前后

key

type☆

key_len☆

rows☆

filtered

extra☆

分析优化器执行计划

默认关闭

索引相关

表相关

语句相关

IO相关

Innodb相关

SHOW ENGINE INNODB STATUS

条件中有or

函数计算

类型转换

不等

联合索引

表中数据量较少时，不会走索引，而是全表查询

使用like后面紧跟着%，如‘%XXX’

1.字段的数值有唯一性的限制

2.频繁作为 WHERE 查询条件的字段

3.经常 GROUP BY 和 ORDER BY 的列

4.UPDATE、DELETE 的 WHERE 条件列

5.DISTINCT 字段需要创建索引

6.多表 JOIN 连接操作时，尽量不要超过 3 张，对WHERE 条件创建索引，对用于连接的字段创建索引，并且类型必须一致

7.使用列的类型小的创建索引

8.使用字符串前缀创建索引

9.区分度高(散列性高)的列适合作为索引

10.使用最频繁的列放到联合索引的左侧

11.在多个字段都要创建索引的情况下，联合索引优于单值索引

1. 在where中使用不到的字段，不要设置索引

2. 数据量小的表最好不要使用索引

3. 有大量重复数据的列上不要建立索引

4.避免对经常更新的表创建过多的索引

5.不建议用无序的值作为索引

6.删除不再使用或者很少使用的索引

7.不要定义冗余或重复的索引

组成

注意事项

面试题

用于全文本搜索，能够高效地处理文本查询

InnoDB和MyISAM存储引擎都支持全文索引

可以在CHAR、VARCHAR或TEXT类型的列上创建

全文索引的创建和维护可能会占用较多的存储空间，并且在频繁更新文本数据时会影响性能，因为每次更新都需要重新构建或调整 全文索引

B+树索引

哈希索引

全文索引

R-Tree索引

聚集索引

非聚集索引

主键索引(PRIMARY KEY)

唯一索引(UNIQUE)

普通索引(INDEX 或 KEY)

全文索引(FULLTEXT)

空间索引(SPATIAL)

单列索引

联合索引

只查询需要的字段，减少数据传输量

查询字段全走索引，减少回表查询

SELECT * FROM tableName WHERE id > #{lastBatchMaxId} [其他条件] ORDER BY id [ASC|DESC](这里一般选用ASC排序) LIMIT ${size}

重点感觉是id > #{lastBatchMaxId}

一般的分页方案使用的LIMIT offset,size需要先查询，后截断。而本方案每次查询都是最终的结果集

可广泛应用于各种批量查询、数据同步、数据导出以及数据迁移等等场景

理想情况

必须知道前一页id的位置在哪里

可以达到常数级别

场景

先通过内连接子查询，只关联出来id

大概能够提升30%~70%

己知的生产环境中使用单表存储数据可以达到10亿条

原始方案

有效缩小磁盘扫描范围

提供数据库并行处理能力

适合场景

问题

适合场景

问题

范围分表容易扩容，但存在尾部热点问题

Hash分表极难扩容，建议改为一致性Hash，但迁移难度较大

热备份、多活、故障切换、负载均衡、读写分离

主从延迟

主从同步数据不一致(主从数据复制方式)

提升并发

可能会遇到幻读问题

已解决

已解决

已解决

(MVCC)基本解决

已解决

已解决

已解决

1.事务A开启事务

2.事务B开启事务，将id=1的记录name值(王麻子)改为了李四

3.事务A将id=1的记录name值改为张三，并提交

4.事务B进行回滚，此时name值又变为王麻子

此时从事务A的角度来看，发生了脏写

1.事务A，B各开启了个事务

2.事务B开启事务，将id=1的记录name值(王麻子)改为了李四，还没提交

3.事务A去查询id=1的记录，如果读到name的值为李四，而事务B稍后进行了回滚，那么事务A相当于读到了一个不存在的数据

此时从事务A的角度来看，发生了脏读

删除变少，不算幻读(算 不可重复读)

会有trx_id

creator_trx_id为当前事务id

没有trx_id

creator_trx_id为0

row_id

trx_id

roll_pointer

多版本体现

并发控制，管理由Read View来

是事务A在使用MVCC机制进行快照读操作时产生的读视图。

当事务启动时，会生成数据库系统当前的一个快照，InnoDB为每个事务构造了一个数组，用来记录并维护系统当前活跃事务的ID(“活跃"指的就是，启动了但还没提交)。

组成

规则

举例

获取时机

在MVCC情况下，事务A先开启事务，然后普通 select 一个不存在的值，比如id = 3；这时候是查不到的

然后事务b开启事务insert一个id等于3的记录。接着事务A去update id = 3的记录，再去select id = 3，就可以查出那条记录

另外一种场景是事务A先普通select，然后事务B插入一条数据并提交，这时事务A再来个当前读 select for update就也能查出刚才插入的记录

SELECT * FROM user LOCK IN SHARE MODE

SELECT ... for update

update

insert

delete

库存扣减

领取任务

抢红包/抢号段

保证一次只处理一个订单

1.表级S锁、X锁

2.意向锁

3.自增锁

4.MDL锁(元数据锁)

1.记录锁

2.间隙锁

3.临键锁

4.插入意向锁

实现

优点

缺点

适用场景

实现

优点

缺点

适用场景

新增时死锁

修改时死锁

不论是表锁还是行锁，都是在事务执行过程中生成的，哪个事务生成了这个锁结构，这里就记录这个事务的信息。

此锁所在的事务信息在内存结构中只是一个指针，通过指针可以找到内存中关于该事务的更多信息，比方说事务id等。

对于行锁来说，需要记录一下加锁的记录是属于哪个索引的。这里也是一个指针。

表锁结构和行锁结构在这个位置的内容是不同的

表锁特有结构

行锁特有结构

这是一个 32 位的数，被分成了lock_mode、lock_type和rec_lock_type三个部分

锁的模式（lock_mode）

锁的类型（lock_type）

行锁的具体类型（rec_lock_type）

为了更好的管理系统运行过程中生成的各种锁结构而设计了各种哈希表和链表

如果是行锁结构的话，在该结构末尾还放置了一堆比特位，比特位的数量是由上边提到的n_bits属性 表示的。

InnoDB数据页中的每条记录在记录头信息中都包含一个heap_no属性，伪记录Infimum的 heap_no值为 0 ，Supremum的heap_no值为 1 ，之后每插入一条记录，heap_no值就增 1 。锁结构最后的一堆比特位就对应着一个页面中的记录，一个比特位映射一个heap_no，即一个比特位映射到页内的一条记录。

Innodb_row_lock_current_waits：当前正在等待锁定的数量；

Innodb_row_lock_time：从系统启动到现在锁定总时间长度；（等待总时长）

Innodb_row_lock_time_avg：每次等待所花平均时间；（等待平均时长）

Innodb_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；

Innodb_row_lock_waits：系统启动后到现在总共等待的次数；（等待总次数）

查询正在被锁阻塞的sql语句

查询所有锁的情况

查询锁等待情况

读-读情况，即并发事务相继读取相同的记录。读取操作本身不会对记录有任何影响，并不会引起什么问题，所以允许这种情况的发生。

写-写情况，即并发事务相继对相同的记录做出改动。

在这种情况下会发生脏写的问题，任何一种隔离级别都不允许这种问题的发生。所以在多个未提交事务相继对一条记录做改动时，需要让它们排队执行，这个排队的过程其实是通过锁来实现的。这个所谓的锁其实是一个内存中的结构，在事务执行前本来是没有锁的，也就是说一开始是没有锁结构和记录进行关联的

当一个事务想对这条记录做改动时，首先会看看内存中有没有与这条记录关联的锁结构，当没有的时候就会在内存中生成一个锁结构与之关联。比如，事务T1要对这条记录做改动，就需要生成一个锁结构与之关联

在锁结构里有很多信息，为了简化理解，只把两个比较重要的属性拿了出来: trx信息:代表这个锁结构是哪个事务生成的。 is_waiting :代表当前事务是否在等待。 当事务T1改动了这条记录后，就生成了一个锁结构与该记录关联，因为之前没有别的事务为这条记录加锁，所以is_waiting属性就是false，我们把这个场景就称之为获取锁成功，或者加锁成功，然后就可以继续执行操作了。 在事务T1提交之前，另一个事务T2也想对该记录做改动，那么先看看有没有锁结构与这条记录关联，发现有一个锁结构与之关联后，然后也生成了一个锁结构与这条记录关联，不过锁结构的is_waiting属性值为true ,表示当前事务需要等待，我们把这个场景就称之为获取锁失败，或者加锁失败

在事务T1提交之后，就会把该事务生成的锁结构释放掉，然后看看还有没有别的事务在等待获取锁，发现了事务T2还在等待获取锁，所以把事务T2对应的锁结构的is_waiting属性设置为false，然后把该事务对应的线程唤醒，让它继续执行，此时事务T2就算获取到锁了。

几种说法

读-写或写-读，即一个事务进行读取操作，另一个进行改动操作。这种情况下可能发生脏读、不可重复读、幻读的问题。

各个数据库厂商对SQL标准的支持都可能不一样。比如MySQL在REPEATABLE READ隔离级别上就已经解决了幻读问题。

如查询语句使用了not in 那么内外表都进行全表扫描，无法用到索引；

而not exists的子查询依然能用到表上的索引。所以无论哪个表大。用not exists都比not in要快。

看某个值是否存在集合里面，可以是静态列表，也可以是子查询

像是在好友列表里找人，看看他在不在列表里

先将子查询的结果集执行出来，缓存好，然后再和外层的每一行去比较

适合子查询数据量小，且外层表有索引的场景

判断一个子查询有没有结果，有结果就为true

像是在门口喊人，有人吗？有人就行，不关心那个人是谁

短路特性

适合外层表数据量小且子查询有索引的场景

确定mysql具体的占用内存大小，通过命令: cat/proc/Mysql进程ID/status 查看。重点看VmRSS参数

查看当前配置的pool_size

查看performance schema内存占用量:show engine performance schema status;

排査MySQL为当前session会话分配的内存

排查当前临时表占用内存情况

1.继续加大内存(如果参数调无可调时选择);

2.修改减小innodb_buffer_pool_size参数(牺牲一定innodb性能);

3.排查消耗内存的慢SQL，及时优化;

4.检査相关session参数是否设置合理，比如join_buffer_size、query_cache_size是否设置过大;

5.使用gdb回收内存碎片(生产环境谨慎操作)

6.对MySQL进程配置jemalloc内存管理模块;

7.配置读写分离，将读操作应用到从库，减少对主库的影响;

1.确定mysql CPU占用

2.查看mysql 当前连接

3.确定是否存在异常语句

1.优化 SQL，从逻辑上优化 SQL，降低 SQL 复杂度，降低 MySQL 执行成本

2.对 where、join、max()、min()、order by、group by 等子句用到的字段，创建相应的索引。

3.二级索引的正确使用。

4.参数优化

5.检查 MySQL 连接数当前使用是否超过限制,如果超出限制，而且之前的连接没有得到释放，那新的连接肯定会连接不到，造成连接延迟，影响效率。

6.MySQL的 timeout 参数设置问题

但是仔细详细这其中存在设计问题，不应该用VARCHAR(100)字段排序呀

字段声明大小影响排序内存估算

排序性能受字段宽度制约

文件排序模式差异 

单路 vs 双路排序 —— 小字段可走单路排序，全字段加载进内存高效；大字段需双路，增加 IO 开销

不是「能存多少」的问题，而是「会影响系统如何处理数据」——字段过大埋下隐性性能陷阱

索引排序

filesort文件排序

比如是否允许为NULL，如果允许，需要有一个字节存放是否为NULL。

VARCHAR本身还需要使用 1 到 2 个额外字节来存储数据的实际长度

latin1这样单字节的字符集

但是MyISAM在备份方面不太行

这句SQL可能会异常:Error Code: 1292. Truncated incorrect DOUBLE value: '_fix' 0.016 sec

将字符串 "_fix" 附加到 request_id 字段时，而 MySQL 默认将 request_id 字段视为数值类型（如 INT、FLOAT、DOUBLE 等），因为它正在尝试执行数值加法操作（request_id + "_fix"）。

在 SQL 中，你不能直接将字符串和数值相加，除非数值被显式地转换为字符串。在你的情况下，你需要确保 request_id 在与字符串 "_fix" 连接之前被转换为字符串

update test_db.idempotent_request_tab set request_id = CONCAT(request_id, '_fix') where id = 1000;

SHOW VARIABLES LIKE '%slow query log%';

如果slow query log的值为OFF，则表示未开启慢査询日志功能。

需要修改/etc/my.cnf文件，将如下两个参数设置为对应的值

重启MySQL服务。

使用mysqldumpslow

mysqldumpslow [-a] [-d] [-g] [-s order-type] [-t] [log file ...]

1.假设条件

2.计算过程

3.实际估算

CREATE（创建）

ALTER（修改）

DROP（删除）

TRUNCATE（清空表）

INSERT（插入）

UPDATE（更新）

DELETE（删除）

GRANT（授予权限）

REVOKE（收回权限）

COMMIT（提交事务）

ROLLBACK（回滚事务）

SAVEPOINT（设置保存点）

基于属性注入(常用)

基于 setter 方法注入（较少见）

基于构造器注入（Spring 官方推荐）

环绕-->before/after-->afterThrow/afterReturn(afterThrow和afterReturn只会执行一个)

aroudBefore...
before...
add....
aroudAfter...
after...
afterReturn...

before...
after...
afterThrow...

aroudBefore...
before...
aroudAfter...
after...
afterReturn...

1.创建前准备
2.创建实例
3.依赖注入
4.容器缓存
5.销毁实例

口诀

1.Bean容器找到Spring配置文件中Bean的定义；

2.构造方法推断(执行无参构造方法,创建Bean)

3.Bean容器利用java 反射机制实例化Bean；

目的

4.Bean容器为实例化的Bean设置属性值；

注入@Resource @Autowired @Value

目的

5.如果Bean实现了BeanNameAware接口，则执行setBeanName方法；

6.如果Bean实现了BeanClassLoaderAware接口，则执行setBeanClassLoader方法；

7.如果Bean实现了BeanFactoryAware接口，则执行setBeanFactory方法；

8.如果Bean实现了ApplicationContextAware接口，则执行setApplicationContext方法；

9.如果加载了BeanPostProcessor相关实现类，则执行postProcessBeforeInitialization方法；

10.如果Bean定义初始化方法（@PostConstruct注解执行、配置init-method、实现了InitializingBean接口），则执行定义的初始化方法；

11.如果加载了BeanPostProcessor相关实现类，则执行postProcessAfterInitialization方法；

当要销毁这个Bean时，如果自定义了销毁方法（@PreDestroy注解执行、配置destroy-method、实现了DisposableBean接口），则执行定义的销毁方法。

loC 容器中只有唯一的 bean 实例。Spring 中的 bean 默认都是单例的，是对单例设计模式的应用。

每次获取都会创建一个新的 bean 实例。也就是说，连续 getBean() 两次，得到的是不同的 Bean 实例。

每一次 HTTP 请求都会产生一个新的 bean(请求 bean)，该 bean 仅在当前 HTTP request 内有效

每一次来自新 session 的 HTTP 请求都会产生一个新的 bean(会话 bean)，该 bean 仅在当前 HTTP session 内有效。

每个 Web 应用在启动时创建一个 Bean(应用 Bean)，该 bean 仅在当前应用启动时间内有效。

每一次 WebSocket 会话产生一个新的 bean。

xml方式

注解方式

应用场景

根据过滤器在 web.xml 中的注册顺序来确定的

主要用于 Servlet 容器层面的请求处理，可以对 URL、HTTP 请求参数等进行拦截和处理

由拦截器在配置文件中声明的顺序决定的

主要用于 Spring MVC 层面的请求处理，可以拦截和处理 Handler 方法的调用。

例如验证用户身份、记录访问日志等

preHandle

postHandle

afterCompletion

依靠引入"中间态(已经实例化还没初始化的半成品)"的概念

过程:
A实例化，未初始化。放入三级缓存中
A属性注入过程中，依赖B。发现B没有
B实例化，未初始化。放入三级缓存。
B属性注入过程中，发现依赖A。会依次从一级到三级找；从三级缓存中取出A注入，并且将A放入二级缓存，删掉三级中的A。
B初始化完成执行完其他流程得到一个完整的Bean，并且将B直接放入一级缓存中。
A继续完成B的属性注入，执行完其他流程形成一个完整的Bean，放入一级缓存

1.scope=prototype 类型的循环依赖(原型多例导致)

2.无法解决构造函数注入(添加@Lazy解决)

3.被 @Async 增强的 Bean 的循环依赖
普通的 AOP 代理都是通过 AbstractAutoProxyCreator 来生成代理类的，其实现了 SmartInstantiationAwareBeanPostProcessor，而@Async 标记的类是通过 AbstractAdvisingBeanPostProcessor 来生成代理的，其没有实现

构造函数注入导致的循环依赖

涉及非单例作用域(如prototype)的循环依赖

涉及到AOP代理或多个后置处理器(BeanPostProcessor)的循环依赖

对于那些不需要在应用程序启动时立即初始化的Bean，可以使用@Lazy注解。这将使Bean在第一次被请求时才初始化，而不是在容器启动时。

Spring官方推荐

@RequiredArgsConstructor

构造函数注入不能解决所有类型的循环依赖，尤其是当两个Bean在构造函数中互相依赖时，Spring将无法解决这种循环依赖，因为构造函数在
Bean初始化之前调用，此时Bean还未被创建。

构造函数注入代码示例

@RequiredArgsConstructor在循环依赖时会启动失败，但这正是它的优势——早期暴露设计问题，促使你写出更健康的代码

开启基于注解的缓存，使用 @EnableCaching 标注在 SpringBoot主启动类上

定义

参数

与@Cacheable不同的是使用@CachePut标注的方法在执行前不会去检查缓存中是否存在之前执行过的结果，而是每次都会执行该方法，并将执行结果以键值对的形式存入指定的缓存中。

标注在需要清除缓存元素的方法或类上。当标记在一个类上时表示其中所有的方法执行都会触发缓存的清除操作；allEntries是否需要清除缓存中的所有元素。当指定allEntries为true时，Spring Cache将忽略指定的key。需要清除所有的元素，这比单独清除元素更高效

可让我们在一个方法或者类上同时指定多个Spring Cache相关的注解。其拥有三个属性：cacheable、put和evict，分别用于指定@Cacheable、@CachePut和@CacheEvict

@Autowired
@Inject
@Reference
@Resource

@Bean
@Component
@Qualifier
@Primary
@Controller
@RestController
@Service
@Repository

@RequestMaping
@RequstParam
@RequestBody
@PathVariable

@Transactional
@Configuration
@Aspect
@ScanScope
@Value

@Order 控制加载顺序,越小越先加载

@Scope(作用域,如:单例,原型,请求,会话等)

1.在`main`方法中，我们调用`SpringApplication.run0`方法，这实际上是Spring Boot应用程序的启动入口。
2.`SpringApplication'类负青整个Spring Boot应用的启动过程。在`run0方法内部，首先会创建一个`SpringApplication'实例。
3.在创建`SpringApplication`对象后，会进行一系列的设置，包括读取命令行参数、设罟主类、设环境等。
4.SorinaApplication`会调用"initializeRunlisteners0方法，初始化监听器，这些监听器会监听Spring Boot应用的启动过程中的不同阶段。5.`SpringApplication`会调用`prepareEnvironment0方法，用来准备Spring Boot的运行环境，包括读取系统属性、配置文件等。
6.随后，'SpringApplication`会调用`createApplicationContext0方法，创建`ApplicationContext实例。默认情况下，如果是web应用，则创建`AnnotationConfigEmbeddedWebApplicationContext;非web应用则创建`AnnotationConfigApplicationContext.
7.创建完`ApplicationContext之后，`SpringApplication“会注册一些默认的Bean，例如`CommandLineRunner、ApplicationArguments等。
8.`SpringApplication`接下来会调用`prepareContextLoader0)方法，准备`ContextLoader，它负责加载配置类和初始化自动配置。9.`SpringApplication^会调用`refreshContext0方法，刷新ApplicationContext，在这个过程中，Spring loC容器开始加载和初始化Bean。
10.在`ApplicationContext刷新完毕后,`SpringApplication会执行`calRunners0方法，调用"ApplicationRunner和`CommandlineRunner接口的实现类，这些类可以在应用启动后执行自定义的逻辑。
11.最后，`SpringApplication会发布`ApplicationReadyEvent事件，表明Spring Boot应用已经启动完成并准备好接收请求,
12.如果是Web应用，嵌入式服务器(如Tomcat、Jetty或Undertow)会在`ApplicationContext'刷新完成后启动。

本身是一个依赖聚合，包含了一系列的常用依赖

SpringBoot的“约定大于配置”

自动配置Auto-Configuration机制

@SpringBootApplication(标记当前类为引导启动类（加载很多启动配置）)

1.添加依赖：在项目中引入所需的starter依赖。

2.应用启动：SpringBoot应用启动，触发自动配置机制。

3.扫描classpath

4.加载配罟类：根据spring.factories文件中的声明，加载自动配置类。

5,条件判断：使用条件注解(如@ConditionalOnClass)决定哪些自动配置类生效。

6.创建和配置Bean:将符合条件的配置类中定义的Bean创建并添加到Spring容器。

spring-boot-starter-web:提供了构建Web应用程序所需的一切，包括Spring Web MVc，Tomcat(作为默认的嵌入式Serviet容器)，以及对Thymeleaf模板引擎的支持。
spring-boot-starter-data-jpa:用于集成JPA(Java Persistence AP!)和数据库访问。它包括了JPA的实现(如Hibemnate)，事务管理，以及Spring Data JPA的扩展.
spring-boot-starter-security:为Spring Security提供了自动配置，使你能够轻松地为Web应用添加认证和授权功能。
spring-boot-starter-test:提供了一组测试相关的依赖，包括JUnit,Hamcrest、Mockito、Spring Test以及Tomcat或Jetty的嵌入式容器。
spring-boot-starter-aop:引入了Aspect]的依赖，支持面向切面编程。
spring-boot-starter-validation:基于JSR 303或JSR 349(Hibernate Validator)的验证框架，用于数据验证。
spring-boot-starter-amgp:用于与AMOP (Advanced Message Queuing Protocol)消息队列(如RabbitMO)集成,
spring-boot-starter-cache:支持常见的缓存抽象，如Ehcache、Caffeine和Redis.

CommandLineRunner

ApplicationRunner

配置文件的加载

缓存预热

数据库的初始化等等操作

外面的check是为了性能考虑，加锁是消耗资源的，可以避免不必要的加锁，第二个是保证正确性的。当然，当你check的成本高于加锁成本或者并发很高，大部分都会有冲突的情况可以考虑不要最外面的check

比如并发情况下，对本地某个文件添加一行，你用jvm的synchronized锁，但是check依赖本地文件的读取是否写入这行，这种情况下check成本就远高于加锁成本了

外层check的通过的概率如果很高的话，也是可以去掉check的，比如两台机器定时整点同时写db一条数据，两台机器本地时间误差很小的情况下，很大概率在同一时间检查是没有这条数据的，这种可以考虑去掉

与Nginx相比,Gateway优势

出现端口被占用或没开放端口

将应用程序的业务逻辑、用户界面(UI)和控制逻辑解耦(分离)，分派给三个不同的角色，从而提高代码的可维护性、可复用性和可扩展性。

职责

特点

例子

说明

职责

特点

例子

职责

特点

例子

怎么响应用户请求

DispatcherServlet 是 Spring MVC 的核心入口，本质上就是一个 HttpServlet

是Servlet接口的一个抽象实现类，专门用于处理HTTP协议的请求。

每个接口都需要对应一个servlet对象，然后从HttpRequest中解析参数,处理后，再将响应写入到HttpResponse

有很多重复代码

通过前端控制器设计模式和注解驱动的编程模型，实现了高度简化和集中化的请求处理机制

关键组件

请求流程

核心优势

首先，你需要定义自己的事件类，通常继承自ApplicationEvent类。

在需要发布事件的地方，使用ApplicationEventPublisher接囗来发布你定义的事件。通常，ApplicationContext实现了ApplicationEventPublisher接口，所以你可以从Spring容器中注入ApplicationEventPublisher。

要监听事件，你需要创建一个事件监听器，实现ApplicationListener接口，或者使用@EventListener注解

如果使用@Eventlistener注解，Spring会自动检测并装配事件监听器。但是，如果你实现Applicationlistener接口，你需要确保监听器被Spring管理，通常是通过@Component或其他类似的注解。

如果你想异步处理事件，可以在配置类上添加@EnableAsync注解，并确保你的事件处理器方法也标注了@Async注解。

定义

实现原子性的关键，是当事务回滚时能够撤销所有已经成功执行的sql语句

实现方式

执行事务前后，数据保持一致

一致性是事务追求的最终目标

实现方式

数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致(并发访问数据库时，一个事务不被其他事务所干扰)

锁 和 MVCC 保证隔离性

实现方式

事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失

实现方式

强制性的

嵌套

嵌套事务的方法抛异常，但父事务捕获，则回滚到保存点，父事务继续

嵌套事务的方法抛异常，父事务不捕获，则整个父事务都回滚

保存点

NESTED和REQUIRED_NEW的区别

NESTED和REQUIRED的区别

默认值，表示使用底层数据库的默认隔离级别。

大部分数据库通常是ISOLATION_READ_COMMITTED

该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。

该级别不能防止脏读，不可重复读和幻读，因此很少使用该隔离级别。比如PostgreSQL实际上并没有此级别

该隔离级别表示一个事务只能读取另一个事务已经提交的数据。

该级别可以防止脏读，这也是大多数情况下的推荐值

该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。

该级别可以防止脏读和不可重复读

所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

但是这将严重影响程序的性能。

通常情况下也不会用到该级别

当Spring中设置的隔离级别与数据库设置不一致时，以Spring设置的隔离级别为准。

@Transactional

TransactionTemplate的execute方法

优点

长事务指的是执行时间较长的数据库事务，通常持续时间超过几秒甚至几分钟

可能涉及大量数据的读写

通常包含复杂的业务逻辑或多个操作步骤

可能跨越多个业务流程

复杂的数据处理逻辑

大量数据的批处理操作

与外部系统的交互

网络延迟或I/O瓶颈

不恰当的事务边界设计

锁定资源时间长，影响并发性能

增加死锁风险

可能导致数据库连接池耗尽

影响系统的响应时间和吞吐量

在分布式系统中可能导致数据不一致

1)事务拆分

2)异步处理

3)批处理优化

4)提高硬件性能

5)使用补偿事务

6)乐观锁

7)重新设计

尽量避免长事务，保持事务简短和聚焦

仔细设计事务边界，确保只包含必要的操作

使用合适的隔离级别

定期监控和分析长事务，找出优化机会

在应用层实现超时机制，避免事务无限期挂起

使用数据库监控工具识别长事务

分析事务日志，找出耗时较长的操作

使用性能分析工具定位瓶颈

static

final

事务注解基于ThreadLocal存储上下文，如果线程一变，事务就断了

SpringBoot

Spring

@Transactional(rollbackFor = BusinessException.class)

抛了SqlException、DuplicateKeyException等异常。而BusinessException是我们自定义的异常，报错的异常不属于BusinessException，所以事务也不会回滚。

因为doOtherThing方法出现了异常，没有手动捕获，会继续往上抛，到外层add方法的代理方法中捕获了异常。所以，这种情况是直接回滚了整个事务，不只回滚单个保存点。

怎么样才能只回滚保存点呢？

调用方写入数据后,再调用因为Feign能感知到调用失败,所以会抛异常,这种情况就能回滚;调用后调用方才写入数据报错,被调方无法感知到,所以数据不会回滚

在这种情况下，严格来说，仍然存在分布式事务的问题，尽管风险可能比连接不同数据库的情况要小。原因如下：
1.服务隔离: 尽管两个服务连接同一个数据库，但它们仍是独立的应用程序，可能运行在不同的进程或服务器上。
2.网络因素: 跨应用调用涉及网络通信，可能出现网络延迟、中断等问题。
3.并发控制: 两个服务可能同时访问相同的数据，需要考虑并发控制问题。
4.失败恢复: 如果其中一个服务在事务过程中失败，需要有机制来保证数据一致性。

应该需要引入本地事务

可能存在,但不一定。这取决于您的具体应用场景和设计：
a)如果应用需要保证对两个数据库的操作在逻辑上是一个原子操作(要么全部成功,要么全部失败),那么就需要使用分布式事务；
b)如果应用对两个数据库的操作是相互独立的,不需要保证强一致性,那么就不需要使用分布式事务。

事务信息绑定在线程上

事务是线程级局部变量，不是跨线程共享资源

1. 通过 AOP 代理创建一个事务；

2. 将这个事务信息（Connection、事务状态等）放入当前线程的 ThreadLocal；

3. 方法执行完毕后，提交或回滚；

4. 最后清理掉 ThreadLocal。

Java的动态代理

CGLib

含义

实践

延伸出

节点状态

领导选举

日志复制

本地消息表

第一代

第二代

第三代

幂等性

TCC模型 和 Saga模型

可以理解为无论里面外面炸，都会回滚

可以理解为事件里面炸，外面不管也不回滚；外面炸，里外都会回滚

格式

特点

简介

特征

应用场景

面试题

特点

简介

特征

应用场景

简介

特征

应用场景

底层实现

Geolocation的简写形式，代表地理坐标

底层使用ZSET

根据概率推算

string结构实现

会过滤重复元素

数据量小还是可以精确统计

数据量大，会有小于0.81％的误差

查看符合模板的所有key

注意

删除一个或多个指定的key

判断key是否存在

给一个key设置有效期,有效期到期时该key会被自动删除

查看一个key的剩余有效期

-1

-2

查看编码

SET

GET

MSET

MGET

INCR

DECR

INCRBY

INCRBYFLOAT

SETNX

SETEX

LPUSH key element ...

LPOP key

RPUSH key element ...

RPOP key

LRANGE key star end

BLPOP和BRPOP

HSET key field value

HGET key field

HMSET

HMGET

HGETALL

HKETS

HVALS

HINCRBY

HSETNX

HDEL key field[field...]

SADD key member ...

SREM key member ...

SCARD key

SISMEMBER key member

SMEMBERS

SINTER key1 key2 ...

SDIFF key1 key2 ...

SUNION key1 key2 ...

ZADD key score member

ZREM key member

ZSCORE key member

ZRANK key member

ZCARD key

ZCOUNT key min max

ZINCRBY key increment member

ZRANGE key min max

ZRANGEBYSCORE key min max

ZDIFF

ZINTER

ZUNION

添加一个地理空间信息，包含：经度（longitude）、纬度（latitude）、值（member）

计算指定的两个点之间的距离并返回

将指定member的坐标转为hash字符串形式并返回

返回指定member的坐标

指定圆心、半径，找到该圆内包含的所有member，并按照与圆心之间的距离排序后返回。6.2以后已废弃

在指定范围内搜索member，并按照与指定点之间的距离排序后返回。范围可以是圆形或矩形。6.2.新功能

与GEOSEARCH功能一致，不过可以把结果存储到一个指定的key。 6.2.新功能

向指定位置（offset）存入一个0或1

获取指定位置（offset）的bit值

统计BitMap中值为1的bit位的数量

操作（查询、修改、自增）BitMap中bit数组中的指定位置（offset）的值

获取BitMap中bit数组，并以十进制形式返回

将多个BitMap的结果做位运算（与 、或、异或）

查找bit数组中指定范围内第一个0或1出现的位置

可以合并每天的结果,统计该月的数据

场景

同步阶段

场景

只更新slave与master存在差异的部分数据

同步阶段

注意点

在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO

Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO

适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步

限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

Redis v4.0：引入多线程异步处理一些耗时较旧的任务，例如异步删除命令unlink

Redis v6.0：在核心网络模型中引入 多线程，进一步提高对于多核CPU的利用率

1.完全基于内存操作，读写效率高(持久化是fork子进程与Linux系统，页缓存技术)

2.单线程操作，避免了频繁的上下文切换。频繁切换会影响系统性能

3.合理高效的数据结构

4.采用了非阻塞IO多路复用机制。采用epoll模型

引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣

将缓存与数据库操作放在一个事务

利用TCC等分布式事务方案

缓存Key同一时间大量失效或者Redis服务宕机，大量请求直接达到数据库，DB瘫痪

1.随机失效时间

2.平均分布在集群不同节点

3.不设置失效时间

4.跑定时任务,定时刷新

5.给缓存业务添加降级限流策略

6.给业务添加多级缓存

利用缓存与DB都没有的数据，如id=-1，直接穿透缓存打到数据库，一般属于恶意攻击

1.参数合法性校验

2.无论查出什么都缓存(缓存空对象,空字符串)

3.使用布隆过滤器

4.拉黑相关IP

一个被高并发访问并且缓存重建业务较复杂的key突然失效了，大量该Key请求打到数据库

1.分布式锁,单体用互斥锁

2.永不失效（逻辑过期）

更新数据库时让缓存失效，查询时再更新缓存

每次更新数据库都更新缓存，无效写操作较多

什么是双写?

先更新数据库，再删除缓存（推荐方案）

先删除缓存，再更新数据库

先更新数据库，再更新缓存

延时双删

异步更新

写缓存失败的情况

在Redis执行时，耗时超过某个阈值的命令

查询慢查询日志长度

读取n条慢查询日志

清空慢查询列表

数据丢失问题

故障恢复问题

并发能力问题

存储能力问题

Redis Cluster采用的是类一致性哈希算法实现节点选择的

Cluster会分成了16384(2的14次方) 个Slot（槽位），哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中

具体执行过程分为两大步

每个Redis节点负责处理一部分槽位

利用setnx的互斥性；利用ex避免死锁；释放锁时判
断线程标示

不可重入、无法重试、锁超时失效

利用Redis中Hash结构，key为锁，field为线程id，value为上锁次数，记录线程标识和重入次数；

锁一次就+1，释放锁就-1，为零则删除锁

watchDog延续锁时间

利用信号量控制锁重试等待

Redis宕机引起锁失效问题

多个独立的Redis节点，必须在所有节点都获取重入锁，才算获取锁成动

运维成本高、实现复杂

比如页号xx、偏移量ywy写入了'zzz'数据

执行save命令

执行bgsave命令

Redis停机时

触发RDB条件时

save ""

比如对某个数据进行了add语句操作

always

everysec

no

bgrewriteaof

会在触发阈值时自动去重写AOF文件

redis.conf配置

1.由于Redis在写入日志之前，不对命令进行语法检查，所以只记录执行成功的命令，避免出现记录错误命令的情况

2.而且在命令执行后再写日志不会阻塞当前的写操作。

安全性要求较高的业务,如分布式锁、库存、订单流水，另外单独redis实例，再去做持久化

持久化频率不高，可能间隔60秒，甚至更长。这期间命令可能会丢失。数据安全性不能保证

百分比

文件大小

Background  rewrite

追求性能：yes

追求数据安全性：no

fork极限情况下，内存可能会翻倍

建议单机多实例

fork和rewrite消耗比较高

比如ES也是CPU密集型

1.引入spring-boot-starter-data-redis依赖

2.在application.yml配置Redis信息

3.注入RedisTemplate

注意点

利用Redis存储，不受限于JVM内存上限

基于Redis的持久化机制，据安全性有保证

可以满足消息有序性

无法避免消息丢失(POP命令，取出并销毁。当取了消息但还没处理就宕机,则消息丢失)

只支持单消费者

SUBSCRIBE channel[channel] : 订阅一个或多个频道

PUBLISH channel msg : 向一个频道发送消息

PSUBSCRIBE pattern[pattern]: 订阅与pattern格式匹配的所有频道(开头的P就是pattern)

采用发布订阅模型，支持多生产、多消费

不支持数据持久化

无法避免消息丢失

消息堆积有上限，超出时数据丢失

XADD users * name jack age 21

XREAD COUNT 1 STREAMS users 0 | $

XREAD COUNT 1 BLOCK 0 STREAMS users $

消息可回溯

一个消息可以被多个消费者读取

可以阻塞读取

有消息漏读的风险(缺点)

命令

遵循基本格式：[业务名称]:[数据名]:[id]

长度不超过44字节

不包含特殊字符

可读性强

避免key冲突

方便管理

更节省内存

Key本身的数据量过大

Key中的成员数过多

Key中成员的数据量过大

单个key的value小于10KB

对于集合类型的key，建议元素数量小于1000

网络阻塞

数据倾斜

Redis阻塞

CPU压力

MEMORY USAGE key

String类型

集合类型

redis-cli -a 密码 --bigkeys

scan扫描

第三方工具

网络监控

问题

解决方案

大key治理

使用压缩算法

存储一个User对象，我们有多种存储方式

假如有hash类型的key，其中有100万对field和value，field是自增id，这个key存在什么问题？如何优化？

解决方案

注意事项

如MSET或Pipeline这样的批处理需要在一次请求中携带多条命令，而此时如果Redis是一个集群，那批处理命令的多个key必须落在一个插槽中，否则就会导致执行失败。

在Redis的默认配置中，如果发现任意一个插槽不可用，出于数据完整性考虑，使整个集群都会停止对外服务

可以设想一下，如果有几个slot不能使用，那么此时整个集群都不能用了，我们在开发中，其实最重要的是可用性，所以需要把如下配置修改成no，即有slot不能使用时，我们的redis集群还是可以对外提供服务

cluster-require-full-coverage no

集群节点之间会不断的互相Ping来确定集群中其它节点的状态。(因为没有哨兵节点)

Ping携带的信息

集群中节点越多，集群状态信息数据量也越大，10个节点的相关信息可能达到1kb，此时每次集群互通需要的带宽会非常高，这样会导致集群中大量的带宽都会被ping信息所占用，这是一个非常可怕的问题，所以我们需要去解决这样的问题

解决方案

BigKey或者集群批处理使用了相同的hash_tag，可能会导致数据倾斜。使得部分节点负担过重，部分过轻

节点选择

读写判断

插槽判断

有关这个问题咱们已经探讨过了，当我们使用批处理的命令时，redis要求我们的key必须落在相同的slot上，然后大量的key同时操作时，是无法完成的，所以客户端必须要对这样的数据进行处理，这些方案我们之前已经探讨过了，所以不再这个地方赘述了。

lua和事务都是要保证原子性问题，如果你的key不在一个节点，那么是无法保证lua的执行和事务的特性的

在集群模式是没有办法执行lua和事务!!!

单体Redis（主从Redis）已经能达到万级别的QPS，并且也具备很强的高可用特性。如果主从能满足业务需求的情况下，所以如果不是在万不得已的情况下，尽量不搭建Redis集群

rename-command

是Redis最主要的部分，存储Redis的键值信息。主要问题是BigKey问题、内存碎片问题

Redis主进程本身运行肯定需要占用内存，如代码、常量池等等;这部分内存大约几兆，在大多数生产环境中与Redis数据占用的内存相比可以忽略。

一般包括客户端缓冲区、AOF缓冲区、复制缓冲区等。客户端缓冲区又包括输入缓冲区和输出缓冲区两种。这部分内存占用波动较大，不当使用BigKey，可能导致内存溢出。

类型

查看内存分配的情况

查看key的主要占用情况

Redis进程自启动以来消耗内存的峰值

Redis使用其分配器分配的总字节数，即当前的总内存使用量。

Redis启动时消耗的初始内存

复制积压缓冲区的大小

主从复制中所有从节点的读写缓冲区大小

除从节点外，所有其他客户端的读写缓冲区大小

AOF持久化使用的缓存和A0F重写时产生的缓存

业务数据库的数量。

overhead.hashtable.main

overhead.hashtable.expires

数值=startup.allocated+replication.backlog+clients.slaves+clients.normal+aof.buffer+db.X

当前Redis实例的key总数

当前Redis实例每个key的平均大小

计算公式

纯业务数据占用的内存大小。

纯业务数据占用的内存比例

计算公式

当前总内存与历史峰值的比例

计算公式

内存的碎片率

Redis中保存的Key是字符串，value往往是字符串或者字符串的集合。字符串是Redis中最常用的一种数据结构。

Redis没有直接使用C语言中的字符串，因为C语言字符串存在很多问题

Redis构建了一种新的字符串结构，称为简单动态字符串（Simple Dynamic String）

例子

Redis是C语言实现的，其中SDS是一个结构体(Java中的类)

SDS之所以叫做动态字符串，是因为它具备动态扩容的能力

优点

IntSet是Redis中set集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有序等特征

结构

为了方便查找，Redis会将intset中所有的整数按照升序依次保存在contents数组中

升级

总结

Redis是一个键值型（Key-Value Pair）的数据库，我们可以根据键实现快速的增删改查。而键与值的映射关系正是通过Dict来实现的

内存中分散，不连续

组成

当我们向Dict添加键值对时，Redis首先根据key计算出hash值（h），然后利用 h & sizemask来计算元素应该存储到数组中的哪个索引位置。我们存储k1=v1，假设k1的哈希值h =1，则1&3 =1，因此k1=v1要存储到数组角标1位置。

扩缩容

总结

是一种特殊的“双端链表” ，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作, 并且该操作的时间复杂度为 O(1)

结构

问题

特性

ZipList问题

结构示意图

源码

配置项

总结

定义

示意图

总结

Redis中的任意数据类型的键和值都会被封装为一个RedisObject，也叫做Redis对象

源码

五种数据结构

什么是redisObject

String

List

Set

ZSet

Hash

单线程

多线程

客户端（client）向服务端（server）发送一条命令

服务端解析并执行命令，返回响应结果给客户端

Redis Serialization Protocol

版本

在RESP中，通过首字节的字符来区分不同数据类型，常用的数据类型包括5种

public class Main {

    static Socket s;
    static PrintWriter writer;
    static BufferedReader reader;

    public static void main(String[] args) {
        try {
            // 1.建立连接
            String host = "192.168.150.101";
            int port = 6379;
            s = new Socket(host, port);
            // 2.获取输出流、输入流
            writer = new PrintWriter(new OutputStreamWriter(s.getOutputStream(), StandardCharsets.UTF_8));
            reader = new BufferedReader(new InputStreamReader(s.getInputStream(), StandardCharsets.UTF_8));

            // 3.发出请求
            // 3.1.获取授权 auth 123321
            sendRequest("auth", "123321");
            Object obj = handleResponse();
            System.out.println("obj = " + obj);

            // 3.2.set name 虎哥
            sendRequest("set", "name", "虎哥");
            // 4.解析响应
            obj = handleResponse();
            System.out.println("obj = " + obj);

            // 3.2.set name 虎哥
            sendRequest("get", "name");
            // 4.解析响应
            obj = handleResponse();
            System.out.println("obj = " + obj);

            // 3.2.set name 虎哥
            sendRequest("mget", "name", "num", "msg");
            // 4.解析响应
            obj = handleResponse();
            System.out.println("obj = " + obj);
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            // 5.释放连接
            try {
                if (reader != null) reader.close();
                if (writer != null) writer.close();
                if (s != null) s.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    private static Object handleResponse() throws IOException {
        // 读取首字节
        int prefix = reader.read();
        // 判断数据类型标示
        switch (prefix) {
            case '+': // 单行字符串，直接读一行
                return reader.readLine();
            case '-': // 异常，也读一行
                throw new RuntimeException(reader.readLine());
            case ':': // 数字
                return Long.parseLong(reader.readLine());
            case '$': // 多行字符串
                // 先读长度
                int len = Integer.parseInt(reader.readLine());
                if (len == -1) {
                    return null;
                }
                if (len == 0) {
                    return "";
                }
                // 再读数据,读len个字节。我们假设没有特殊字符，所以读一行（简化）
                return reader.readLine();
            case '*':
                return readBulkString();
            default:
                throw new RuntimeException("错误的数据格式！");
        }
    }

    private static Object readBulkString() throws IOException {
        // 获取数组大小
        int len = Integer.parseInt(reader.readLine());
        if (len <= 0) {
            return null;
        }
        // 定义集合，接收多个元素
        List<Object> list = new ArrayList<>(len);
        // 遍历，依次读取每个元素
        for (int i = 0; i < len; i++) {
            list.add(handleResponse());
        }
        return list;
    }

    // set name 虎哥
    private static void sendRequest(String ... args) {
        writer.println("*" + args.length);
        for (String arg : args) {
            writer.println("$" + arg.getBytes(StandardCharsets.UTF_8).length);
            writer.println(arg);
        }
        writer.flush();
    }
}

# 格式: # maxmemory <bytes> #例如: maxmemory 1gb

在学习Redis缓存的时候我们说过，可以通过expire命令给Redis的key设置TTL（存活时间）

可以发现，当key的TTL到期以后，再次访问name返回的是nil，说明这个key已经不存在了，对应的内存也得到释放。从而起到内存回收的目的

有两个问题需要我们思考

当Redis内存使用达到设置的上限时，主动挑选部分key删除以释放更多内存的流程。

系统配置

Redis会在处理客户端命令的方法processCommand()中尝试做内存淘汰

源码

策略

策略选择

执行步骤

生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可

状态判断法

业务判断法

一旦消息投递到队列，队列则会向生产者发送一个通知，如果设置了消息持久化到磁盘，则会等待消息持久化到磁盘之后再发送通知。生产者在发送完消息后不会等待回应，所以confirm机制性能相对比事务机制高。还会伴有超时机制。

RabbitMQ 的消息默认存放在内存上面，如果不特别声明设置，消息不会持久化保存到硬盘上面的，如果节点重启或者意外死掉，消息就会丢失。
要想做到消息持久化，必须满足以下三个条件，缺一不可。

消费端消费完成后通知服务端，服务端才把消息删除。不自动，改手动

可能是没有收到确认，重复发送

临时扩容

消息生产者，就是向 Kafka broker 发消息的客户端。

消息消费者，向 Kafka broker 取消息的客户端。

由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。

所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个broker 可以容纳多个 topic。

可以理解为一个队列，生产者和消费者面向的都是一个 topic。

为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。

一个 topic 的每个分区都有若干个副本，一个 Leader 和若干个Follower。

每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 Leader。

每个分区多个副本中的“从”，实时从 Leader 中同步数据，保持和Leader 数据的同步。

Leader 发生故障时，某个 Follower 会成为新的 Leader。

JDK自带的序列化器太重

Kafka单分区内的数据有序，原因是In Flight Requests，默认每个broker缓存五个请求，当出现乱序时会自动排序。

日志是按照稀疏索引的方式存储的，每往log文件写入4kb数据，就会往index文件写入一条索引。且保存的是相对的offset，避免占用过多的空间。

顺序读写

Page Cache

Kafka使用了零拷贝技术，也就是直接将数据从内核空间的读缓冲区直接拷贝到内核空间的 socket 缓冲区，然后再写入到 NIC 缓冲区，避免了在内核空间和用户空间之间穿梭

用户态（User Mode）：当进程在执行用户自己的代码时，则称其处于用户运行态。

内核态（Kernel Mode）：当一个任务（进程）执行系统调用而陷入内核代码中执行时，我们就称进程处于内核运行态，此时处理器处于特权级最高的内核代码中执行。

为什么分内核态和用户态？

通过对GroupId进行Hash得到那台服务器的coordinator ，coordinator负责选出消费组中的Leader ，并且协调信息。真正存储消费记录的是 _consumer_offsets_partition 。

开启事务 ，以及幂等性

生产者端 -> 集群

集群 -> 消费者

消费者-> 框架(数据库)

读写分离是指生产者发送到Leader副本，消费者从Follower副本读取

1.延时问题：数据从leader副本到follow副本是需要过程的，从网络>主节点内存 ->主节点磁盘 -> 网络 -> 从节点内存 -> 从节点磁盘，比较耗时不适合对实时性要求高的应用。

2.负载均衡：读写分离，很大一部分原因是怕同一个节点负载过大。但是kafka通过分区的负载均衡，天然的就均衡了各个broker的压力。

生产端：ack设置为-1，保证消息同步到follower副本。发送消息方式设置为同步或者异步，做好失败回滚措施

broker端：页缓存pagecache设置直接刷盘模式，确保不会有消息在页缓存中的时候宕机。

消费端：关闭消息自动提交，改为手动提交。避免消息没消费完就提交了offset导致消息丢失

总得来说，要保证严格的可靠性，就会失去很大的可用性，这是一个平衡的过程。

我们都知道，消息的消费速度取决于消费者的速度，在消费速度不变的情况下，增加分组内消费者的个数，能倍速的提高消费速度。而消费者的个数又受限于分区个数，消费者个数超过分区数后，再提高消费者个数就没有意义。

 为了能够再提高临时的速度，我们还可以设置临时topic在临时主题中，去加大分区数，将所有原消费者直接将消息再次投递到临时topic中，进行更大规模消费群的消费。这是一个取巧的方案，适合解决临时大量消息的堆积。

在一定条件下，分区数的数量是和吞吐量成正比的，分区数和性能也是成正比的。但是超过了限度后，不升反降。

客户端/服务器端需要使用的内存就越多

文件句柄的开销

越多的分区可能增加端对端的延迟

降低高可用性

查看当前服务器中的所有 topic

创建 first topic

查看 first 主题的详情

修改分区数

删除 topic(需要配置信息)

查看操作生产者命令参数

发送消息

查看操作消费者命令参数

消费消息

在消息发送的过程中，涉及到两个线程，main线程和sender线程

在jvm的内存中开辟了一块缓存空间叫RecordAccumulator（消息累加器），用于将多条消息合并成一个批次，然后由sender线程发送给kafka集群。

消息在生产过程会调用send方法然后经过拦截器经过序列化器，再经过分区器确定消息发送在具体topic下的哪个分区，然后发送到对应的消息累加器中。并且每个队列和主题分区都具有一一映射关系。消息在累加器中，进行合并，达到了对应的size（batch.size）或者等待超过对应的等待时间(linger.ms)，都会触发sender线程的发送。

分区的好处

发送消息分区策略

自定义分区器

生产者提高吞吐量

数据可靠性

数据去重

消息事务

消息顺序

核心参数

架构图

组成

Zookeeper在Kafka中扮演了重要的角色，kafka使用zookeeper进行元数据管理

一个broker 一般就是一台服务器吗？会不会一个broker 在多台服务器或者多个broker 在一台服务器上呢

AR

ISR

kafka中涉及多处选举机制，容易搞混

每个broker都有唯一的brokerId，他们在启动后会去竞争注册zookeeper上的Controller结点，谁先抢到，谁就是broker leader。而其他broker会监听该结点事件，以便后续leader下线后触发重新选举。

节点服役和退役

作用

默认副本1个，生产环境通常配置为2个，个别公司设置为3个

分类

名词概念

Leader选举流程

Leader和Follower故障处理细节

分区副本分配

生产经验

文件存储机制

文件清理策略

快速读写的原因

replica.lag.time.max.ms

auto.leader.rebalance.enable

leader.imbalance.per.broker.percentage

leader.imbalance.check.interval.seconds

log.segment.bytes

log.index.interval.bytes

log.retention.hours

log.retention.minutes

log.retention.ms

log.retention.check.interval.ms

log.retention.bytes

log.cleanup.policy

num.io.threads

num.replica.fetchers

num.network.threads

log.flush.interval.messages

log.flush.interval.ms

auto.create.topics.enable

不存在说消费者A将消息消费走了，消费者B就读不到了

互不影响

PULL

PUSH

老版本

新版本

为了提高自己的消费能力

消费某一个主题或者某一分区的数据

注意事项

可以将消费者组当成一个独立的消费者，是一个整体，分工明确

消费者组原理

消费者组初始化流程

消费者组详细消费流程

生产经验

offset位移

流程图

流程图

独立消费者

消费者组

bootstrap.servers

key.deserializer 和 value.deserializer

group.id

enable.auto.commit

auto.commit.interval.ms

auto.offset.reset

offsets.topic.num.partitions

heartbeat.interval.ms

session.timeout.ms

max.poll.interval.ms

fetch.min.bytes

fetch.max.wait.ms

fetch.max.bytes

max.poll.records

heartbeat.interval.ms

session.timeout.ms

max.poll.interval.ms

partition.assignment.strategy

场景说明

服务器台数选择

磁盘选择

内存选择