JAVA技术路线

1、基本数据类型

2、包装类

3、泛型

1、final

2、static

3、volatile

4、synchronized

5、transient

1、封装

2、继承

3、多态

4、抽象类

5、接口

6、内部类

1、final finally finalize的区别

2、utf-8编码中的中文占几个字节；int占几个字节

3、静态代理和动态代理的区别，什么场景使用

4、数组在内存中如何分配

5、说说对Java注解的理解

6、说说对Java反射的理解

7、说一下泛型原理，并举例说明

8、String StringBuffer StringBuild的区别

9、String.intern()方法

10、String为什么要设计成不可变的

11、String在堆栈中的存储

12、深拷贝和浅拷贝的区别

1、OSI七层模型

2、TCP/IP四层模型

1、TCP和UDP

2、三次握手

3、四次挥手

4、TCP可靠传输机制

5、TCP粘包/拆包问题

1、HTTP发展

2、HTTP常见状态码

3、GET与POST的区别

4、HTTP与HTTPS的区别

5、Cookie、Session、Token区别

1、常见网络攻击

2、常见优化手段

1、TCP和UDP的区别？

2、TCP三次握手和四次挥手的过程？

3、HTTP和HTTPS的区别？

4、GET和POST的区别？

5、Session和Cookie的区别？

6、DNS解析过程？

7、从输入URL到页面显示发生了什么？

8、HTTP状态码的含义？

9、TCP如何保证可靠性？

10、HTTPS的加密原理？

11、TCP拥塞控制算法？

12、WebSocket与HTTP的区别？

13、CDN的工作原理？

14、如何排查网络连接问题？

15、网站访问慢的可能原因？

16、如何防御DDoS攻击？

17、HTTPS为什么安全？

List

Set

Queue

HashMap

HashTable

TreeMap

Collection 是接口，Collections 是工具类

1. 触发时机：当元素数量超过容量×加载因子时触发，比如默认容量16，加载因子0.75，元素超过12个就扩容<br>2. 扩容过程：创建2倍大小的新数组（16→32），遍历旧数组所有元素重新分布，对于链表和红黑树分别处理<br>3. 性能优化：JDK1.8通过(hash &amp; oldCap)快速判断元素新位置：结果为0：保持原位置不变，结果为1：新位置=原位置+旧容量

HashMap 使用链地址法解决哈希冲突，相同哈希值的元素组成链表。JDK 1.8 引入了红黑树优化，当链表长度超过8且数组容量≥64时，链表转为红黑树，将查询性能从O(n)提升到O(log n)；当节点数少于6时，再转回链表

理论上任何类都可以作为 Map 的 key，但要求它正确重写了 hashCode() 和 equals() 方法。因为 HashMap 在定位元素时先根据 hashCode() 确定桶位置，再通过 equals() 判断键是否相等。若使用可变对象或未重写这两个方法，可能导致无法正确查找或重复存储相同逻辑键。实际开发中常用 String、Integer 这类不可变类作为 key

1、HashMap 线程不安全，HashTable 方法带有 synchronized 是线程安全的，但性能差<br>2、HashMap 允许 null 键和值，而 HashTable 不允许<br>3、HashMap 在 JDK 8 之后引入了红黑树优化，查询效率更高<br>4、HashTable 是过时类，建议使用 ConcurrentHashMap 替代

HashMap 基于哈希表实现，插入、查询效率更高，平均是 O(1)，但是无序；TreeMap 基于红黑树实现，键是有序的，支持范围查询，但性能略低，O(log n)，如果我不需要顺序、只关注性能，会用 HashMap；如果需要按照 key 排序，或者做区间查询（比如获取所有 key 小于某值的元素），就会用 TreeMap

Hashtable 是通过在方法上加 synchronized 实现线程安全的，锁的粒度很大，所以并发性能低。ConcurrentHashMap 是在 JDK7 中引入的，它使用分段锁机制（Segment）或在 JDK8 后使用 CAS + synchronized 局部加锁，实现了高效的并发访问

HashMap 是非线程安全的，在多线程环境下可能会造成数据不一致甚至死循环。<br>ConcurrentHashMap 是线程安全的 Map 实现，JDK7 采用分段锁机制（Segment），JDK8 改进为 CAS + synchronized 的局部加锁，提升了并发性能。<br>两者的底层结构类似，都是数组 + 链表 + 红黑树，但 ConcurrentHashMap 不允许使用 null 键或值

LinkedHashMap 是 HashMap 的子类，内部通过一个双向链表维护元素的插入顺序或访问顺序，它常用于需要保持插入顺序遍历的场景，以及实现 LRU 缓存

JDK 1.7 中，HashMap 扩容使用 链表头插法。多线程同时向同一个桶插入元素时，扩容过程中链表节点可能形成循环引用，导致 CPU 自旋死循环。<br>JDK 1.8 改为 尾插法 + 红黑树，扩容时保持链表顺序，避免了死循环问题，但多线程仍然可能造成数据不一致。

遍历时修改集合会抛出 ConcurrentModificationException

空间与时间的平衡：<br>- 加载因子小：空间利用率低，哈希冲突少<br>- 加载因子大：空间利用率高，哈希冲突多<br>0.75是数学计算和实验得出的最优值

1. 设置合适的初始容量，避免频繁扩容<br>2. 使用String、Integer等不可变对象作为key<br>3. 重写hashCode()和equals()方法<br>4. 在已知元素数量时，提前指定容量

HashMap 是基于数组 + 链表/红黑树实现的哈希表。<br>put 操作时，先通过 hash 计算桶下标，再插入链表或红黑树。<br>当链表长度超过阈值时，JDK8 会转红黑树优化查找效率。当元素数量超过负载因子阈值时，会进行扩容，容量翻倍。<br>get 操作通过 hash 定位桶，然后遍历链表或红黑树查找，平均时间复杂度 O(1)，最坏 O(log n)。<br>JDK7 使用链表头插法，扩容多线程可能死循环；JDK8 改为尾插法 + 红黑树，避免死循环，同时提高性能。

ConcurrentHashMap 是线程安全、高并发的哈希表。<br>JDK7 使用 Segment 分段锁：每个 Segment 是一个小 HashMap，读操作无锁，写操作锁住 Segment，提高并发性能。<br>JDK8 改为 数组 + 链表/红黑树 + CAS + synchronized 局部锁：<br>读操作无锁（volatile 保证可见性）,写操作先 CAS，失败才同步锁住桶,链表长度 ≥ 8 且容量 ≥ 64 → 红黑树优化,扩容采用多线程协助，链表拆分到新桶。<br>相比 JDK7，JDK8 并发性能更高，线程安全机制更细粒度，避免了分段锁的限制

HashMap 的容量必须是 2 的幂，是为了配合 (n-1) &amp; hash 位运算快速定位桶下标。这样可以保证哈希值均匀分布，减少冲突，同时扩容时只需简单调整链表位置，提高性能。

TreeSet 底层是 红黑树，它是一种自平衡的二叉搜索树。插入元素时，TreeSet 会根据 自然顺序（Comparable） 或 自定义比较器（Comparator） 确定节点位置，并通过红黑树旋转和变色保持平衡。因为红黑树的中序遍历是 有序的，所以 TreeSet 遍历时可以保证元素顺序。同时，红黑树保证查找、插入、删除操作的时间复杂度为 O(log n)。

1、继承Thread类创建线程

2、实现Runnable接口创建线程

3、通过Callable和Future创建线程

4、线程池

新建(new thread)

就绪（runnable）

运行（running）

阻塞（blocked）

等待（waiting）

超时等待（timed_waiting）

终止（terminated）

1、newFixedThreadPool（固定数目线程的线程池）

2、newCachedThreadPool（可缓存线程的线程池）

3、newSingleThreadExecutor（单线程的线程池）

4、newScheduledThreadPool（定时及周期执行的线程池）

1、corePoolSize

2、maximumPoolSize

3、keepAliveTime

4、unit

5、workQueue

6、threadFactory

7、handler

1、提交任务，先判断核心线程数是否已满，未满则创建核心线程直接执行；<br>2、核心线程满时，将任务放入阻塞队列等待；<br>3、阻塞队列满时，尝试创建非核心线程执行任务；<br>4、超过最大线程数时，执行拒绝策略；<br>5、线程执行完成后，会循环从队列获取任务执行，非核心线程空闲超过 keepAliveTime 会被回收。

1、LinkedBlockingQueue

2、ArrayBlockingQueue

3、SynchronousQueue

4、PriorityBlockingQueue

1、AbortPolicy

2、CallerRunsPolicy

3、DiscardPolicy

4、DiscardOldestPolicy

倒计时锁存器，线程等待计数完成

可循环的屏障，线程到达屏障后继续

控制同时访问资源的线程数量

ThreadLocalMap 的 key 为 弱引用，value 为强引用

如果线程长时间不回收或忘记 remove()，可能导致内存泄漏

数据库连接管理

用户会话管理

事务管理

避免加锁

当一个线程修改 volatile 变量后，其他线程立即可见<br>

底层实现

volatile 会在 JMM（Java Memory Model）中形成 happens-before 规则

底层实现

防止编译器和 CPU 对指令进行重排序

volatile 对单次读写是原子操作

对复合操作（i++、count += 1）不是原子操作

需要结合 锁（synchronized/Lock）或原子类（AtomicInteger） 保证

1、状态标记

2、轻量级同步

3、双重检查锁（DCL）

4、计数器/标志位

1、乐观锁 vs 悲观锁

2、公平锁 vs 非公平锁

3、可重入锁（递归锁）

4、独占锁（排他锁） vs 共享锁

1、使用方式

2、底层原理

3、锁升级过程

这是一个显式锁，提供了比 synchronized 更丰富的功能

核心实现

核心方法

核心实现

规则

应用场景

如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是用 CLH 队列锁实现的，即将暂时获取不到锁的线程加入到队列中

1、状态（state）

2、CLH同步队列

3、模板方法模式

1、获取锁（lock() -&gt; acquire(int arg)）

2、释放锁（unlock() -&gt; release(int arg)）

JMM（Java Memory Model） 是 Java 虚拟机规范的一部分，定义了 Java 程序中线程如何访问共享内存，以及共享变量的可见性、原子性和有序性，是 解决多线程并发问题的理论基础

1、主内存

2、工作内存

3、线程间交互

1、原子性

2、可见性

3、有序性

Happens-Before：保证前一个操作的结果对后一个操作可见

常用规则：<br>1、程序顺序规则：同一个线程内，代码按顺序执行<br>2、监视器锁规则：解锁 Happens-Before 加锁<br>3、volatile 变量规则：写 Happens-Before 读<br>4、线程启动规则：Thread.start() Happens-Before 线程运行<br>5、线程终止规则：线程结束 Happens-Before 其他线程检测到结束<br>6、传递性：如果 A HB B 且 B HB C，则 A HB C

保证多线程顺序执行的核心思路是将并行转为串行或可控序列<br>1、Thread.join()：简单但失去并行性<br>2、单线程线程池：生产环境推荐<br>3、CompletableFuture：函数式风格，适合异步任务链<br>4、CountDownLatch/CyclicBarrier：精确控制执行时机<br>5、阻塞队列：生产者消费者模式<br>6、Lock + Condition：最细粒度的控制

1、什么是死锁

2、产生死锁的必要条件

3、如何避免

默认情况下，线程池的核心线程不会被回收，即使空闲也会一直存活。如果希望核心线程在空闲一定时间后也被销毁，可以调用allowCoreThreadTimeOut(true) 方法。这样核心线程在空闲超过 keepAliveTime 后也会被回收。一般在任务波动较大的场景下开启，以节省系统资源。

线程池在创建后，默认是没有线程的，只有在第一次提交任务时才会创建线程。如果希望线程提前创建，可以使用 prestartCoreThread() 或 prestartAllCoreThreads() 方法来预热线程池。预热可以减少首次任务提交时的延迟，在高并发或低延迟系统中非常实用。

一个都不用，只用自定义的

execute() 用于提交 Runnable 任务，没有返回值，也无法捕获异常；submit() 用于提交 Runnable 或 Callable 任务，会返回一个 Future，可通过它获取结果或异常；底层上，submit() 会把任务封装成 FutureTask，再调用 execute() 执行。一般需要获取任务执行结果或处理异常时使用 submit()，否则用 execute() 更轻量。

在线程池中，可以通过 shutdown() 或 shutdownNow() 来关闭线程池，shutdown() 是优雅关闭，不再接收新任务，但会执行完已提交的任务；shutdownNow() 是强制关闭，会中断正在执行的任务并清空队列。<br>实际开发中推荐先调用 shutdown()，再配合 awaitTermination() 等待线程池结束，超时后再调用 shutdownNow() 以确保资源释放。

sleep() 用于让当前线程暂停一段时间，不释放锁，可中断；<br>join() 用于让当前线程等待另一个线程执行完毕，可中断；<br>yield() 是一种让出 CPU 执行权的提示，不释放锁，不可中断，执行效果由调度器决定。

1、核心线程数

2、最大线程数

3、队列类型

4、keepAliveTime

5、拒绝策略

- 实现：JVM内置 vs JDK实现<br>- 使用：自动释放 vs 手动释放<br>- 功能：基础同步 vs 丰富功能（尝试锁、公平锁等）<br>- 性能：相当，不同场景各有优势

作用：<br>- 保证可见性：修改立即对其他线程可见<br>- 禁止重排序：防止指令重排优化<br><br>原理：<br>- 内存屏障：写操作后插入StoreLoad屏障<br>- 缓存一致性：MESI协议保证缓存一致性

核心参数：<br>- corePoolSize：核心线程数<br>- maximumPoolSize：最大线程数<br>- workQueue：工作队列<br>- handler：拒绝策略<br><br>工作原理：<br>1. 核心线程处理任务<br>2. 队列满时创建新线程（≤最大线程数）<br>3. 队列和线程都满时执行拒绝策略

原理：<br>- 每个线程维护ThreadLocalMap<br>- key为ThreadLocal的弱引用<br>- value为强引用<br><br>内存泄漏：<br>- key被GC回收，value无法访问<br>- 解决方案：使用后调用remove()

- state状态变量<br>- CLH队列管理等待线程<br>- 模板方法模式，子类实现tryAcquire/tryRelease<br>- ReentrantLock、Semaphore等基于AQS实现

1、加载

2、验证

3、准备

4、解析

5、初始化

1、什么是双亲委派机制

2、为什么要用双亲委派机制

BootstrapClassLoader（加载核心类库）

ExtensionClassLoader（加载扩展类库）

AppClassLoader（加载应用类）

自定义ClassLoader（自定义逻辑）

栈

本地方法栈

程序计数器

堆

方法区（元空间）

1、Error

2、Exception

1、jvisualvm

2、arthas

3、jconsole

4、MAT（Memory Analyzer）

1、堆设置

2、垃圾收集器设置

3、垃圾回收统计信息

4、并行收集器设置

5、并发收集器设置

6、高级调优参数

1、引用计数法---无法解决循环引用问题

2、可达性分析算法

1、标记清除

2、复制

3、标记整理

4、分代收集

1、强引用

2、软引用

3、弱引用

4、虚引用

1、新生代

2、老年代

3、整个堆

JVM 使用 可达性分析算法来判断对象是否可以被回收，从 GC Roots 出发进行搜索，如果一个对象到 GC Roots 之间没有任何引用链可达，则认为它是“垃圾对象”。常见的 GC Roots 包括：栈中引用的对象、静态变量、常量池引用、JNI 引用等。不可达对象会被标记并在两次标记后回收，如果对象在 finalize() 中重新被引用，可以“复活”一次，否则最终被 GC 清除。

栈中引用的对象、静态变量、常量池引用、JNI 引用等

在 JVM 中，对象“不可达”意味着它不再被 GC Roots 引用，因此具备被 GC 回收的条件，但这并不代表一定会马上回收。<br>回收时机取决于：<br>GC 是否被触发（堆空间是否紧张）；<br>对象是否在 finalize() 中复活；<br>当前使用的垃圾收集器策略。<br>所以，不可达对象只是“可回收”，不是“立即回收”。

1、当我们执行 java MainClass 时，JVM 会首先通过类加载器读取字节码文件，并生成 Class 对象，把类信息加载到方法区；<br>2、接着进入链接阶段，包括验证字节码、准备静态变量、解析符号引用；<br>3、然后进行初始化阶段，执行父类 → 子类的静态变量赋值和静态代码块；<br>4、初始化完成后，JVM 在方法区找到 main 方法，为主线程创建栈帧，并通过执行引擎逐条执行字节码；<br>5、期间，堆、栈、PC 寄存器、本地方法栈和 GC 协同工作管理对象和线程；<br>6、main 方法执行完毕后，线程栈销毁，JVM 结束程序。

在 JVM 中，类的加载由类加载器完成，默认遵循双亲委派模型。如果我们需要按特定方式加载类，比如从网络、加密文件或自定义路径中加载，就可以通过继承 ClassLoader 并重写 findClass() 方法来实现自定义类加载器。实现时，findClass() 会先读取类的字节码，然后调用 defineClass() 把字节数组转换为 Class 对象。这种机制常用于热部署、插件化框架和版本隔离等场景。

逃逸分析是 JVM JIT（即时编译器）在运行时对对象引用范围进行分析的技术，用于判断一个对象是否会被外部方法或线程访问。

如果逃逸分析发现某个对象不会被外部访问，那么 JVM 会不在堆中创建对象，而是直接在栈上分配内存。

G1 垃圾回收器是一种面向服务端的低延迟、高吞吐量的 GC。它将整个堆划分为多个大小相等的 Region，不再严格区分年轻代和老年代。GC 会优先回收“垃圾最多”的 Region，这也是它名字的由来——Garbage First。

G1 的回收过程包括年轻代 GC、并发标记、混合回收和整理阶段。它基于标记-整理算法，避免了内存碎片，并且可以通过 MaxGCPauseMillis 参数控制停顿时间。相比 CMS，G1 支持并行、并发、可预测停顿和压缩整理，是 JDK9 以后的默认回收器。

常用 JVM 调优参数包括内存设置（-Xms/-Xmx）、GC 选择（-XX:+UseG1GC）、性能优化（-XX:+DoEscapeAnalysis）和诊断日志（-XX:+PrintGCDetails、-XX:+HeapDumpOnOutOfMemoryError）。<br>实际调优时重点是合理分配堆内存、控制 GC 停顿时间、开启必要日志和监控

线上出现 OOM 时，首先查看日志确认是哪种类型的 OOM。然后通过 JVM 参数 -XX:+HeapDumpOnOutOfMemoryError 获取堆快照，使用 MAT 或 VisualVM 分析对象分布，定位大对象或泄漏链。同时结合 jstack 分析线程情况，排查死循环或资源未释放的问题。常见原因包括缓存过大、线程过多、类加载器泄漏或直接内存未释放。最后根据原因优化代码、限制缓存、释放资源或调整 JVM 内存参数。

Java 内存泄漏的本质是对象不再使用但仍被引用，导致 GC 无法回收。<br>常见原因包括：静态集合持有引用、ThreadLocal 未清理、缓存无限增长、监听器未注销、资源未关闭、类加载器或定时任务泄漏等。<br>排查时通常通过 -XX:+HeapDumpOnOutOfMemoryError 导出堆快照，用 MAT 或 VisualVM 分析引用链，定位无法回收的对象并优化代码逻辑。

Minor GC 只回收新生代（Eden、Survivor），触发频繁、耗时短，采用复制算法；<br>Full GC 回收整个堆（新生代 + 老年代 + 元空间），耗时长，对系统性能影响大，通常在老年代空间不足或调用 System.gc() 时触发。<br>因此，我们在调优时通常重点是减少 Full GC 的发生频率，以保证系统吞吐量和响应时间。

首先，JVM 会检查类是否已被加载（未加载则触发类加载）；<br>然后在堆中为对象分配内存（采用指针碰撞或空闲列表）；<br>接着对内存空间初始化为零值，保证成员变量有默认值；<br>随后设置对象头，包括哈希码、锁信息和类型指针；<br>最后调用构造方法 &lt;init&gt;() 进行初始化，返回对象引用。<br>通常对象在堆中创建，引用存储在栈中。

栈是线程私有的，用于存储方法调用和局部变量，分配快，自动释放。堆是线程共享的，用于存储对象实例和数组，由 GC 管理，生命周期较长。栈中存的是对象引用，堆中存的是对象本身。

方法区/Metaspace：存放类信息、常量、静态变量，线程共享。<br>堆：存放对象实例和数组，线程共享，由 GC 管理。<br>栈：线程私有，用于方法调用和局部变量，每个方法对应一个栈帧。<br>本地方法栈：线程私有，执行 native 方法。<br>程序计数器：线程私有，记录当前字节码执行位置。

定位高CPU进程：top（Linux）或任务管理器，找到占用高的Java进程PID

查看线程CPU占用：top -Hp &lt;pid&gt;或ps -mp &lt;pid&gt; -o THREAD,tid,time，找到高CPU的线程ID（十进制）

转换线程ID为十六进制：printf "%x\n" &lt;pid&gt;

导出线程栈：jstack &lt;pid&gt; stack.log，或用kill -3 &lt;pid&gt;

查找对应线程栈：在栈日志中搜索十六进制线程ID，分析线程执行的方法

常见原因：死循环、频繁GC（GC线程高）、正则表达式回溯、序列化/反序列化热点、资源竞争导致自旋等

检查内存使用：free -m或top查看系统内存；jstack -gc &lt;pid&gt;查看JVM堆内存使用情况

分析GC情况：jstat -gcutil &lt;pid&gt; 1000观察老年代占用、Full GC次数以及耗时。频发Full GC且内存无法释放说明内存泄露或配置不足

生成堆Dump：jmap -dump:live,format=b,file=heap.hprof &lt;pid&gt;（注意可能触发GC）

分析Dump：使用MAT、Visual VM或JProfiler，定位大对象、泄露对象（如集合未释放、ThreadLocal未清理、缓存无边界等）

检查非堆内存：jstat -gc &lt;pid&gt;看Metaspace、CodeCache；jcmd &lt;pid&gt; VM.native_memory（需开启NMT）检查Native内存

常见原因：堆内存配置过小、内存泄漏、大对象频繁进入老年代、Metaspace泄露、直接内存（Direct Buffer）未释放

jmap：jmap -dump:live,format=b,file=heap.hprof &lt;pid&gt;（live参数先触发Full GC，只转存活对象）

jcmd：jcmd &lt;pid&gt; GC.heap_dump /path/to/heap.hprof（推荐，执行时影响较小）

自动生成：JVM启动参数：-XX:+HeapDumpOnOutOfMemoryError - XX:HeapDumpPath=/Path，在OOM时自动生成

Visual VM/JConsole：通过图形界面连接，执行“堆 Dump”操作

arthas：heapdump /path/to/heap.hprof （Alibaba诊断工具）

JMX：通过MBean com.sun.management:type=HotSpotDiagnostic调用dumpHeap方法

理论上可以尽量降低Full GC频率，但完全消除通常很难。可以通过一下方式极大减少甚至避免Full GC

选择合适GC回收器：G1、ZGC、Shenandoah等可并发处理，避免Stop-The-World的Full GC（但极端情况仍可能发生）

合理设置堆大小：避免老年代过早填满。给老年代足够空间容纳长期存活对象

减少大对象分配：大对象直接进入老年代，若频繁分配会快速填满老年代。优化对象大小，使用对象池

调整晋升阈值：-XX：MaxTenuringThreshold让对象在Survivor区多停留几次，减少过早晋升

控制元空间大小：避免类加载器过多导致Metaspace Full GC

使用并发回收器：G1可配置-XX:MaxGCPauseMillis等，让GC尽量并行发生

注意：Full GC仍然可能因Concurrent Mode Failure、元空间扩容、System.gc()、大对象分配失败等原因触发，但通过精细调优可使其几乎不可发生

选择合适的GC算法

避免Full GC：通过ZGC/Shenandoah的并发处理，尽量减少或消除Full GC

优化分配对象

调整GC参数

监控与日志

硬件配合

原因

提高查询效率

加快排序和分组

优化聚合查询

保证唯一性

1、主键优先

2、高频查询字段

3、选择性高的字段

4、避免过多索引

5、小字段优先

1、B-tree

2、B+tree

3、Hash

4、bitmap（位图索引）

密集索引（聚簇索引）

稀疏索引

一个索引包含多个列，例如 (a, b, c)

查询条件必须从索引最左边的列开始连续使用，才能利用索引。

LIKE、OR、函数操作等可能导致索引失效

MyISAM 不支持事务和聚簇索引，表级锁，适合读多写少

InnoDB 支持事务、行级锁、主键聚簇索引，支持外键，适合高并发和写操作

行锁

页锁

表锁

分区锁

共享锁

排他锁

悲观锁

乐观锁

显示锁

隐式锁

事务是最小执行单位，要么全部执行成功，要么全部不执行

转账操作：从账户A扣款，到账户B，如果中间失败，全都回滚

事务执行前后，数据库必须保持一致状态

账户总金额不变，余额不能出现负值

并发事务之间互不干扰

事务A未提交，事务B看不到A的修改

事务提交后，数据永久保存在数据库中

系统崩溃后，已提交的转账记录依然存在

读取最新数据，通常会加行级锁（X-lock），用于修改操作（UPDATE、DELETE）或 SELECT … FOR UPDATE，保证读取的数据最新并防止写冲突。

通过 MVCC 实现，读取事务开始时的数据快照，不加锁，避免脏读和不可重复读，高并发性能好，默认 SELECT 使用快照读。

Read uncommitted（读未提交）

Read committed（读已提交）

Repeatable read（可重复读）

Serializable（串行化）

1、脏读

2、不可重复读

3、幻读

MVCC：通过多版本快照解决脏读和不可重复读

间隙锁（Gap Lock）：解决幻读

行级锁（Row Lock）：用于当前读的写操作

redo日志

MySQL 主从复制通常基于 二进制日志（binlog） 实现

主库（Master）流程

从库（Slave）流程

1、异步复制数据丢失

2、从库执行失败

3、网络延迟

4、主库崩溃未持久化 binlog

1、读写分离

2、备份与容灾

3、数据分析/报表

4、扩展高可用集群

将数据按规则拆分到 多个数据库实例。<br>每个库可以包含一个或多个表。

常见策略<br>

优点

缺点

将单表拆分成 多个物理表，放在同一个库或不同库中。

1、垂直拆分

2、水平拆分

优点

缺点

应用层路由

中间件路由

代理层

mycat

sharingjdbc

1、动态开启（MySQL 5.7+）

2、修改配置文件

1、收集慢SQL

2、分析 SQL 执行计划

3、确认索引使用情况

4、分析慢 SQL 的瓶颈

1、函数操作

2、隐式类型转换

3、前缀模糊匹配

4、组合索引顺序不当

5、OR条件跨列

6、数据量太小或选择性太低

1、索引优化

2、SQL重写

3、分库分表

4、缓存

5、表结构优化

1、单列索引：对高频查询的 user_id、order_id 列添加索引，减少全表扫描

2、复合索引：针对 WHERE user_id=? AND status=? 的查询建立联合索引，遵循最左前缀原则

3、覆盖索引：在查询字段全部包含在索引中，避免回表，如 SELECT user_id, status

4、索引列优化：避免函数操作、类型转换，保证索引生效，例如使用范围查询替代 DATE(created_at)

5、索引整理：删除冗余或低选择性索引，减少写入开销

6、前缀索引：对大文本列如 username 使用前缀索引，加速模糊查询

语法检查：检查 SQL 语法是否合法<br>语义分析：检查表、列、权限是否存在<br>生成解析树（Parse Tree）

查询重写：如视图展开、子查询优化<br>选择执行计划：<br>&nbsp; &nbsp; &nbsp; &nbsp; 判断是否使用索引<br>&nbsp; &nbsp; &nbsp; &nbsp; 选择最优 join 顺序<br>&nbsp; &nbsp; &nbsp; &nbsp; 生成 执行计划（Execution Plan）

存储引擎层执行：<br>&nbsp; &nbsp; &nbsp; &nbsp; InnoDB：通过 Buffer Pool 读取数据页<br>&nbsp; &nbsp; &nbsp; &nbsp; 检查索引：使用 B+ 树/哈希索引定位数据<br>&nbsp; &nbsp; &nbsp; &nbsp; 事务控制：读写操作记录 Redo/Undo Log<br>锁机制：加行锁/表锁，保证事务隔离

将查询结果返回给客户端<br>对 DML 操作，提交事务后写入 Redo Log 和 Binlog

Redo Log 是 InnoDB 存储引擎的一种事务日志，用于保证 事务的持久性（Durability）。<br>属于 物理日志，记录数据页的修改操作（物理页级别）。

Undo Log 用于 事务回滚 和 MVCC 多版本并发控制。<br>记录事务修改前的数据状态。

Binlog 是 MySQL 全局事务日志，用于 主从复制 和 数据恢复。<br>属于 逻辑日志，记录 SQL 语句或事务操作。

回表是指在 MySQL 使用索引查询数据时，如果索引中不包含查询需要的所有列，就需要通过索引记录找到主键，再去聚簇索引中读取整行数据的操作。<br>

InnoDB 聚簇索引的主键索引叶子节点存储整行数据，辅助索引叶子节点只存索引列和主键列，所以使用辅助索引查询非索引列时会回表。<br>

回表会增加 I/O，降低查询性能，优化方法包括：使用覆盖索引、复合索引设计、避免 SELECT * 查询以及优化表结构等。

MySQL 查询缓存是服务端内存缓存，用于缓存 SELECT 查询结果，提高重复查询性能。但它存在以下弊端：<br>1、写操作会导致缓存失效，写多读少场景收益有限；<br>2、内部使用全局锁，增加锁竞争，高并发下性能下降；<br>3、只对完全相同的 SQL 生效，参数化或别名不同可能不命中；<br>4、大表频繁更新导致缓存命中率低。<br>5、查询缓存适合读多写少、SQL 稳定、结果集不大的场景。<br>在 MySQL 8.0 中，查询缓存功能被移除，推荐使用 应用层缓存或中间件缓存 来替代。

1、前提

2、方法

建议平时建立 全量备份 + 增量备份 + Binlog 保存 的策略，并定期演练恢复流程

当订单表越来越大导致查询缓慢，可以从以下几个方面优化：<br>1、索引优化：建立合理单列索引、复合索引和覆盖索引，避免全表扫描和回表；<br>2、SQL 优化：避免 SELECT *，大表分页使用范围查询，批量操作分批处理；<br>3、分库分表：水平拆分（按用户或订单号）、垂直拆分（大字段单独拆表）、必要时分库；<br>4、缓存优化：应用层缓存热点数据，物化视图或汇总表减少实时计算；<br>5、分区表：按时间或范围分区，减少查询扫描数据量。

对于千万级单表，传统 LIMIT offset, size 分页性能差，因为 MySQL 需要扫描前 offset 行。优化方法包括：<br>1、基于索引的范围分页：利用索引列范围查询代替 OFFSET，例如 WHERE id &gt; last_id LIMIT size；<br>2、Keyset 分页：用上一页最后一条记录作为下一页起点；<br>3、物化分页表或临时表：提前计算主键，分页只扫描索引或临时表；<br>4、分区表分页：按时间或逻辑分区，减少扫描数据量；<br>5、业务层优化：限制最大页数，或采用“加载更多”方式。

唯一索引和普通索引的查询性能几乎相同，因为都基于 B+ 树结构，查询路径一致。唯一索引唯一的区别是写入时需要额外进行一次唯一性检查，所以写入性能会略低于普通索引。因此唯一索引并不比普通索引快，甚至写入场景下会更慢。

索引不是越多越好。索引可以加快查询，但是会增加写入开销、占用更多存储空间，也会让优化器难以选择最优执行计划，甚至造成执行计划错误。因此，索引应根据查询场景按需设计，优先给高选择性的查询条件、排序字段、JOIN 字段建立索引，同时避免对低选择性、高频更新的列建立索引。

大表优化一般从结构、索引、SQL、架构、缓存几个层面进行。首先对表结构进行规范化处理，通过字段精简、冷热分离、垂直拆分、水平分表降低单表大小；其次优化索引，避免低选择性索引和多余索引；再通过 SQL 优化（如覆盖索引、分页优化、JOIN 优化）降低扫描量；对高频查询数据使用 Redis 缓存，对历史数据进行归档；架构上使用读写分离、分库分表来进一步扩容；最后还可以优化 InnoDB 参数，比如增大 Buffer Pool、开启压缩、优化 redo/undo log。这样可以全面提升大表的性能。

避免多线程上下文切换开销

避免锁竞争

内部操作大部分是内存级的，速度够快

RDB/AOF 后台持久化是多进程/多线程

Redis 6.0 后网络 I/O 采用多线程处理

1、多线程读取 socket 数据<br>2、主线程执行命令<br>3、多线程回写结果到客户端

缓存、计数器

对象存储、哈希表

队列、消息流

唯一集合、标签

排行榜、延迟队列

1、geospatial

2、hyperloglog

3、bitmap

统计、地理位置、消息队列

在指定时间间隔生成内存快照

文件紧凑、恢复快

但可能丢失最近一次快照后的数据

记录每条写命令

更安全，丢失数据少

文件大，恢复慢，但可以 rewrite 压缩

无硬盘复制是 Redis 在主从同步时 不再把 RDB 写到磁盘，而是主节点 直接把 RDB 数据通过网络发送给从节点。<br>这样可以避免磁盘 IO 的瓶颈，提高复制速度。

大量缓存同一时刻过期 → 引起数据库压力暴增

解决

访问的数据 DB 和缓存都不存在 → 导致每次都打 DB

解决

单个热点 key 过期，瞬间大量并发访问

解决

工作原理

哨兵组件的功能

哨兵的选举过程

工作原理

优点

cluster故障恢复是怎么做的

1、从节点发送 psync<br>2、主节点发送 RDB 快照<br>3、主节点实时复制写命令到从节点

全量复制是把整个 RDB 发给从节点

全量成本高

增量复制是根据复制偏移量用 backlog 补齐缺失命令

增量轻量快速

Redisson 提供分布式锁、可重入、watchdog 自动续期等，使用非常简单

Redisson 的默认策略是“watchdog”：如果你在不指定过期时间的情况下调用 lock.lock()，客户端会自动续期直到 JVM 断开或显式 unlock()，更安全

1、在 5 个独立 Redis 实例上同时尝试加锁（每次请求用相同 key 和不同实例）<br>2、取得过半（≥3）节点的锁且总耗时小于 TTL，视为加锁成功<br>3、释放时在所有节点上删除自己的锁（同样需校验 value）

提升对单点故障和分区的容忍性

Redis 官方作者和社区对 RedLock 的严格正确性（在网络极端分区下）有争议。RedLock 复杂，部署成本高，且并非在所有场景都必要。生产常见选择是：单实例 + 正确 TTL + Lua 解锁 + Redisson 或者在强一致性需求下使用 Zookeeper / etcd

Redis&nbsp;强调速度和可用性，Zookeeper&nbsp;强调强一致和协调性

高性能缓存或轻量级分布式锁 → Redis<br><br>分布式协调、Leader 选举、强一致配置 → Zookeeper

每隔 N 毫秒随机抽取一部分 key，检查是否过期<br>效率高，但抽取策略复杂

访问 key 时才进行过期判断 → 补充删除<br>优点：省 CPU<br>缺点：会积累大量过期 key

只删除已设置过期时间的 key，按 LRU

删除 TTL 最小的

随机删部分 TTL key

删除所有 key 按 LRU（最常用）

随机删 key

按访问频率 LFU 删除（Redis4.0+）

不删除数据，写入报错（默认）

删除最近最少使用的 key<br>Redis 实现是“近似 LRU”，不是严格 LRU

删除访问频率最低的 key<br>适合热点数据明显的场景<br>Redis 维护一个访问计数（8bit counter，衰减）

大 key 问题：<br>查询的数据量过大（String、List、Hash、ZSet 等）<br>例如 LRANGE mylist 0 -1 直接返回上万条数据

慢命令（O(n) 操作）：<br>List、Set、ZSet 遍历/排序<br>Hash 大对象频繁操作

过期/淘汰导致阻塞：<br>大量过期 key 被定期删除<br>内存淘汰策略触发（LRU/LFU）

网络延迟：<br>大量数据返回时，占用带宽<br>客户端阻塞或 pipeline 不合理

避免锁和上下文切换

内存操作快速

事件驱动（IO 多路复用）

原子操作保证

当 Redis 内存达到 maxmemory 时，如果策略是 noeviction，会拒绝写入；如果配置了淘汰策略，会按 LRU、LFU、TTL 等策略淘汰 key；同时大 key 或批量删除可能导致延迟抖动。应对方法包括合理配置 maxmemory、选择合适淘汰策略、优化数据结构、分片扩容以及业务降级。

Redis 延时任务通常用 有序集合 ZSET 存储任务，score 为任务执行时间戳，value 为任务信息；通过 轮询或定时扫描 ZSET 查找到期任务执行，并用 ZREM 删除；在 分布式环境 下结合 分布式锁 避免重复消费，高并发时可通过 分片队列、分页拉取、或推送到工作队列（List/Stream） 优化性能，同时可使用 Redisson 的 RDelayedQueue 封装延时逻辑。

固定窗口

滑动窗口

令牌桶 / 漏桶算法

1、什么是大key

2、大key的影响

3、如何找到大key

4、大key的治理

Redis 缓存命中率通常在 90%–99% 左右，但实际取决于访问模式、TTL 设置、缓存容量和淘汰策略，通过合理 TTL、热点缓存、预热、LRU/LFU 策略和监控可以提高命中率

原因

解决方案

表示一个网络连接（如 Socket）

处理 I/O 事件的循环线程，负责读写事件、任务执行

管道，按顺序处理 I/O 数据，通过 Handler 链处理数据

数据处理逻辑（Inbound / Outbound）

高性能缓冲区，替代 ByteBuffer，支持池化和零拷贝

EventLoop

EventLoopGroup

BossGroup

WorkerGroup

1、客户端连接到服务器 → BossGroup 的某个 EventLoop 接收连接<br>2、创建 Channel，并注册到 WorkerGroup 的 EventLoop<br>3、WorkerGroup 的 EventLoop 循环处理：<br>读事件：触发 Pipeline 中的 InboundHandler<br>写事件：触发 Pipeline 中的 OutboundHandler<br>任务队列：处理提交到 EventLoop 的异步任务

每个 Channel 的 I/O 都绑定到单个 EventLoop

保证线程安全：<br>Channel 内部操作无需加锁<br>Handler 内部逻辑在同一线程顺序执行

一个 EventLoop 可管理多个 Channel → 减少线程开销<br>

通过多 EventLoop 分布负载多个 Channel → 高并发<br>

WorkerGroup 的线程数量通常设置为 CPU 核心数 × 2

Netty 是一个基于 NIO（非阻塞 IO） 的高性能、异步事件驱动网络通信框架，封装了 Java 原生 NIO 的复杂性，支持 TCP/UDP 通信，广泛用于 RPC、消息队列、高性能 HTTP/Socket 服务。

Netty 封装了 NIO Selector、Buffer 等底层 API，提供 事件驱动模型、ChannelPipeline、ByteBuf、Future/Promise 等高级抽象，简化了网络编程，同时优化了性能和扩展性。

Channel：表示一个连接<br>EventLoop：负责 I/O 事件处理<br>EventLoopGroup：EventLoop 线程池<br>ChannelPipeline：事件处理管道<br>ChannelHandler：业务处理逻辑<br>ByteBuf：高性能缓冲区，支持零拷贝与池化

Netty 使用 BossGroup + WorkerGroup：<br>BossGroup：接收连接<br>WorkerGroup：处理读写事件<br>每个 Channel 绑定 单个 EventLoop，顺序执行 I/O，保证线程安全，一个 EventLoop 可管理多个 Channel，减少线程切换和锁竞争，长耗时任务需异步 offload 避免阻塞 I/O

Pipeline：数据流向的处理链<br>InboundHandler：处理入站数据（读取、解码、业务）<br>OutboundHandler：处理出站数据（编码、发送）

特点：<br>链式顺序处理<br>可插拔 Handler，提高扩展性<br>长耗时任务异步处理，避免阻塞 I/O

高性能缓冲区，替代 ByteBuffer<br>支持 读写索引分离<br>零拷贝：slice、duplicate、composite<br>池化内存：减少对象创建，降低 GC 压力<br>支持堆内存和直接内存

1、异步非阻塞 I/O

2、线程模型优化

3、Pipeline + Handler 链式处理

4、ByteBuf 池化与零拷贝

5、网络传输优化

6、高并发与扩展性

使用 ByteBuf 池化与零拷贝<br>Pipeline 拆分编码/解码与业务逻辑<br>Boss/Worker 数量合理配置（CPU 核心 × 2）<br>异步 offload 耗时任务<br>批量写入 / 异步 flush 提高吞吐<br>调整 TCP 参数优化延迟和连接处理

1、生命周期

2、作用域

3、依赖注入三种方式

4、自动装配模式

Bean创建流程关键方法

1、AbstractApplicationContext.refresh()：容器刷新入口

2、AbstractApplicationContext.finishBeanFactoryInitialization()：初始化单例Bean

3、DefaultListableBeanFactory.preInstantiateSingletons()：预实例化单例

4、AbstractBeanFactory.getBean()：获取Bean入口

5、AbstractAutowireCapableBeanFactory.createBean()：创建Bean实例

1、通过三级缓存机制解决Setter和字段注入的循环依赖

2、一级缓存存放完整Bean，二级缓存存放早期暴露Bean，三级缓存存放单例工厂

3、在Bean实例化后、属性填充前，将早期引用暴露到三级缓存

4、构造器循环依赖无法解决，因为实例化阶段就需要完整依赖

1、切面（Aspect）

2、连接点（Joinpoint）

3、通知（Advice）

4、切点（Pointcut）

5、引入（Introduction）

6、织入（Weaving）

1、Before

2、AfterReturning

3、AfterThrowing

4、After (Finally)

5、Around

1、JDK动态代理

2、CGLIB代理

代理创建流程

1、AbstractAutoProxyCreator.wrapIfNecessary()：判断是否需要代理

2、AbstractAutoProxyCreator.createProxy()：创建代理

3、DefaultAopProxyFactory.createAopProxy()：选择JDK或CGLIB代理

4、JdkDynamicAopProxy/CglibAopProxy：具体代理实现

1、REQUIRED

2、REQUIRES_NEW

3、NESTED

4、SUPPORTS

5、NOT_SUPPORTED

6、NEVER

7、MANDATORY

事务拦截器

1、TransactionInterceptor：事务方法拦截

2、TransactionAspectSupport.invokeWithinTransaction()：事务处理核心

3、PlatformTransactionManager：事务管理器抽象

BeanFactory、ApplicationContext

Bean的singleton作用域

AOP动态代理

JdbcTemplate、TransactionTemplate

事件驱动机制

1、客户端发起请求

2、DispatcherServlet（前端控制器）

3、HandlerMapping（处理器映射器）

4、HandlerAdapter（处理器适配器）

5、Controller（控制器）

6、ViewResolver（视图解析器）

7、View 渲染

8、响应返回客户端

1、简化配置

2、快速启动

3、自动装配

4、生产就绪

@Configuration

@EnableAutoConfiguration

@ComponentScan

条件化装配 + Starter依赖 + 配置属性

1、扫描所有jar包的META-INF/spring.factories文件，加载其中注册的自动配置类

2、对这些配置类进行条件判断，比如检查类路径是否存在特定类、容器中是否已有相关Bean等

3、只有满足所有条件的配置类才会生效，创建对应的Bean并加入Spring容器

举例

封装重复的JDBC代码

SQL写在XML中，与Java代码解耦

自动将ResultSet映射为Java对象

支持多种参数传递方式

mybatis-config.xml

Mapper.xml

SqlSessionFactoryBuilder

SqlSessionFactory

SqlSession

Executor

MappedStatement

Configuration

&lt;if&gt;、&lt;choose&gt;、&lt;when&gt;、&lt;otherwise&gt;。<br><br>&lt;where&gt;、&lt;set&gt;、&lt;trim&gt;。<br><br>&lt;foreach&gt;

#{}：预编译，占位符，防止 SQL 注入<br>

${}：直接拼接，可能有安全风险

resultType：直接映射 Java 对象

resultMap：复杂字段映射（关联、嵌套）

一对一、一对多映射

一级缓存

二级缓存

MyBatis允许对四大对象进行拦截

应用

一对一/一对多关系映射时，可以设置懒加载

只有真正访问关联对象时才触发查询

默认使用JDBC事务管理器

支持与Spring事务管理器整合

Resources → XMLConfigBuilder → Configuration<br>→ SqlSessionFactoryBuilder → DefaultSqlSessionFactory → DefaultSqlSession

配置加载：解析mybatis-config.xml和所有Mapper.xml文件<br>配置对象构建：创建Configuration对象，包含所有配置信息<br>工厂创建：通过SqlSessionFactoryBuilder创建SqlSessionFactory

<br>

sqlSession.getMapper() → MapperRegistry → MapperProxyFactory → MapperProxy&nbsp;<br>→ 调用方法 → MapperMethod → MappedStatement&nbsp;→ <br>Executor（CachingExecutor → BaseExecutor → Simple/Reuse/BatchExecutor）→&nbsp; StatementHandler → ParameterHandler → JDBC → ResultSetHandler → Java 对象返回<br>

会话创建：从工厂获取SqlSession（包含数据库连接和事务）<br>代理获取：通过动态代理获取Mapper接口实例<br>方法转发：代理对象将方法调用转为SqlSession的方法调用<br>执行器处理：Executor先检查两级缓存，未命中则查询数据库<br>语句执行：StatementHandler创建PreparedStatement，ParameterHandler设置参数<br>结果映射：ResultSetHandler将ResultSet转换为Java对象<br>资源清理：关闭SqlSession释放连接

生产者和消费者不需要知道彼此的存在

生产者发送消息后无需等待处理

应对流量高峰，避免系统崩溃

消息被一个消费者消费后即被移除

消息被多个消费者消费

高吞吐、分布式、持久化，适用于大数据领域

基于AMQP协议，消息可靠，支持多种消息模式

阿里开源，分布式，高吞吐，适用于金融领域

1、topic

2、partition

3、offset

4、broker

5、producer

6、consumer

7、consumer group

Producer -&gt; Broker -&gt; Consumer

一个典型的Kafka集群包含多个Broker，一个Topic有多个Partition，每个Partition可以有多个副本（Replica），分布在不同的Broker上

1、集群管理（Broker 的注册与存活检测）

2、Controller 选举

3、Topic、分区、副本等元数据管理

4、分区 Leader 选举

5、Consumer Group 的位移管理（早期版本&lt; 0.9 版本）

1、作用

2、核心功能

3、发送模式

4、工作流程

1、作用

2、核心功能

3、消费流程

4、消费模型特性

Topic → Partition → Segment（日志段）

每个分区是一个有序、不可变的追加日志

1、高性能

2、副本机制

3、ISR（In-Sync Replica，同步副本集合）

4、选举流程

1、生产端

2、broker端

3、消费端

1、broker

2、producer

3、consumer

4、queue

5、exchange

6、binding

7、routing key

1、Simple模式（简单队列）

2、Work Queue模式（工作队列）

3、Publish/Subscribe模式（发布订阅）

4、Routing模式（路由模式）

5、Topics模式（主题模式）

6、RPC模式（远程过程调用）

1、生产者确认机制

2、消息持久化

3、消费者确认机制

1、TTL（Time-To-Live）过期时间

2、死信队列（DLX）

3、延迟队列

4、优先级队列

5、惰性队列

1、定位

2、特点

3、应用场景

1、NameServer

2、Broker

3、Producer

4、Consumer

5、Topic

6、Queue

7、Message Key / Tag / DelayLevel

1、消息发送模式

2、消息消费模式

3、消息可靠性机制

4、消息顺序性保证

5、延迟消息/定时消息

6、NameServer元数据管理

1、集群与高可用

2、顺序消息实现

3、事务消息

4、消息过滤

5、消息回溯 / 消费重放

6、流量控制与限速

Persistent（持久节点）

Ephemeral（临时节点）

Sequential（顺序节点）

客户端与 ZK 连接的状态

包含 sessionId、状态、超时时间

心跳维持会话，过期自动清理临时节点

一次性事件通知机制

事件类型

类似文件系统树形结构

ZNode 存储数据（最大 1MB）

支持顺序访问与节点版本管理

Leader：处理写请求并广播事务

Follower：处理读请求并同步数据

Observer（可选）：只读节点，不参与投票，降低延迟

保证强一致性

流程

Zxid：全局唯一事务 ID，用于保证顺序

每个节点投票给自己或 zxid 最大节点

多数票节点成为 Leader

异常触发重新选举，保证集群可用

使用 临时顺序节点

客户端创建节点 → 序号最小者获取锁

监听前序节点变化 → 释放/重试

使用临时顺序节点

序号最小节点成为主节点

使用 ZNode 存储服务信息、配置信息

Watch 实现数据变化通知 → 动态更新

ZNode 树形结构实现服务注册与发现

支持动态变更与事件通知

奇数节点 → 避免平票<br>Leader 异常 → 触发重新选举<br>Follower 异步同步 Leader 状态

自动重连<br>Watch 一次性通知 → 需重新注册

使用 Zxid 保证事务线性顺序<br>多数节点 ACK 后提交 → 保证强一致性

避免单节点子节点过多 → 减少 ZooKeeper 读写压力<br>使用 Observer 节点 减轻 Leader 写负载<br>批量事务提交 → 减少同步开销<br>客户端会话超时设置合理<br>数据压缩减少网络和存储开销

Leader Election 使用临时顺序节点保证公平<br>客户端/节点重连 → 重新参与选主

Barrier（屏障）：控制多个节点同步启动<br>Queue（队列）：分布式任务排队处理<br>Group Membership（组成员管理）：动态加入/离开通知

与 Kafka、HBase、Dubbo 等框架集成<br>提供 选主、配置管理、服务发现、锁机制

持久节点、临时节点、顺序节点，可组合如临时顺序节点

使用 Zab 协议，Leader 提交事务，多数 Follower ACK 后生效

每个节点投票给自己或 zxid 最大节点，多数票节点成为 Leader，Follower 同步数据

一次性事件监听，触发后需重新注册，可监听节点创建、删除、数据和子节点变化

临时顺序节点实现公平锁，序号最小者获取锁，监听前序节点变化

奇数节点集群，Leader 异常触发重新选举，客户端自动重连并重新注册 Watch

全局唯一事务 ID，用于保证事务顺序和线性一致性

Observer 节点减轻 Leader 压力、批量事务、避免大子节点、合理会话超时、数据压缩

基于 Lucene 的分布式搜索引擎<br>支持 全文检索、结构化搜索、分析聚合<br>特点：分布式、高可用、近实时（Near Real-Time）

Index（索引）：逻辑上的数据库

Type（类型）：ES 7.x 之后已废弃

Document（文档）：JSON 格式存储数据

Field（字段）：文档中的属性

Shard（分片）：索引水平拆分的最小单元

Cluster（集群）：由多个节点组成，协同工作

Node（节点）：集群中的单台服务器

String/Text/Keyword：全文/精确匹配

Numeric：integer、float、long

Date/Boolean

Object/Nested

指定 mapping（字段类型、分析器）<br>

指定 settings（分片数量、分词器等）

定义字段类型和属性

支持 analyzer（分词器）

Nested 与 Object 区别：Nested 支持嵌套文档独立查询

Match Query：全文搜索

Term Query：精确匹配

Range Query：范围查询

Bool Query：组合查询（must, should, must_not）

Aggregations（聚合）：统计分析

from/size 分页，深分页使用 scroll API 或 search_after

sort 排序，注意字段类型和多字段排序

索引被拆分成若干 primary shard + replica shard

分片路由：通过文档 _id hash 映射到分片

副本分片：提高查询性能和高可用性

Master 节点：负责分片分配、节点加入/退出

数据节点：存储和查询分片

协调节点：请求分发、聚合结果

副本分片保证节点故障时可用

Master 节点选举采用 Zen Discovery

Elasticsearch 不可变存储

更新本质是 标记旧文档删除 + 新文档写入

删除操作为 lazy delete，通过 merge 合并段文件

分词器选择：ik_smart/ik_max_word

字段类型优化：Text + Keyword 区分全文和精确匹配<br>

倒排索引：高效存储和检索

使用 nested query 保证嵌套文档查询正确

Object 类型在多值嵌套时可能出现笛卡尔积问题

Metrics Aggregation：sum, avg, min, max

Bucket Aggregation：terms, histogram, date_histogram

Pipeline Aggregation：bucket 之间的统计分析

合理分片和副本数量

使用 doc_values 提升排序/聚合性能

避免深分页 → 使用 scroll API / search_after

Bulk 批量操作减少网络开销

设置合理 refresh_interval，减少 segment merge 影响

集群扩容：增加节点，自动重新分片

集群监控：使用 _cat/indices, _cluster/health

热数据 / 冷数据分层存储

Elasticsearch 为 Near Real-Time (NRT)

文档写入 → refresh → 可搜索

可通过手动 refresh 或降低 refresh_interval 提升实时性

基于 Lucene 的分布式搜索引擎，支持全文检索、分析和聚合，高可用、近实时。

主分片（Primary）负责写入，副本分片（Replica）用于高可用和查询分担读压力。

通过副本分片、Master 选举、集群自动感知节点故障。

Elasticsearch 不可变存储，更新为 标记旧文档删除 + 新文档写入，段文件 merge 后回收空间。

将文本拆分为词条，用于倒排索引，影响全文检索精度和效率。

避免使用 large from/size，使用 scroll API 或 search_after。

Object 会 flatten 导致笛卡尔积，Nested 独立存储嵌套文档，查询更精准。

Metrics（sum/avg/min/max）、Bucket（terms/histogram/date_histogram）、Pipeline（bucket 间分析）。

合理分片、副本、批量写入、doc_values、调整 refresh_interval、避免深分页。

倒排索引是一种存储 词条 → 文档列表 的数据结构，用于快速检索包含指定关键词的文档。

正向索引存文档 → 词条，适合顺序读取；倒排索引存词条 → 文档列表，适合快速全文搜索。

Elastic Stack（ELK）的一部分，开源数据收集、处理、传输工具，支持从各种来源收集数据 → 统一解析、过滤 → 输出到 Elasticsearch、文件、Kafka 等

统一采集：支持日志、事件、指标等多种来源

实时处理：Near real-time 数据处理

可扩展：通过插件处理各种数据格式

日志采集与分析

系统监控指标收集

数据清洗、结构化处理

Input（输入）

Filter（过滤/处理）

Output（输出）

Logstash 处理的最小数据单元

由 字段（Field）+元数据（Metadata）+时间戳（@timestamp） 组成

Input Plugins：file、beats、kafka、jdbc 等

Filter Plugins：grok、mutate、date、json、ruby、geoip

Output Plugins：elasticsearch、file、kafka、stdout

input {<br>&nbsp; file { path =&gt; "/var/log/syslog" start_position =&gt; "beginning" }<br>}<br><br>filter {<br>&nbsp; grok { match =&gt; { "message" =&gt; "%{SYSLOGTIMESTAMP:timestamp} %{DATA:host} %{GREEDYDATA:msg}" } }<br>&nbsp; date { match =&gt; ["timestamp", "MMM&nbsp; d HH:mm:ss", "MMM dd HH:mm:ss"] }<br>}<br><br>output {<br>&nbsp; elasticsearch { hosts =&gt; ["localhost:9200"] index =&gt; "syslog-%{+YYYY.MM.dd}" }<br>&nbsp; stdout { codec =&gt; rubydebug }<br>}

用于结构化解析日志文本

常见模式：%{IP}, %{NUMBER}, %{WORD}, %{GREEDYDATA}

支持自定义正则模式

通过 if/else 条件分支处理不同事件

if [status] == "error" {<br>&nbsp; mutate { add_tag =&gt; ["error"] }<br>}

Logstash 支持多线程处理事件

pipeline.workers 控制 filter/output 并行线程数

避免 Logstash 宕机丢数据

事件写入磁盘 → 重启后可恢复处理

合理配置 pipeline.workers → CPU 核心数

调整 batch.size → 每批处理事件数量

使用 codec 压缩/解码数据减少 CPU 消耗

使用 Persistent Queue 避免内存压力

多 input → 多 output 分流

条件语句决定事件流向

Mutate：字段修改、重命名、删除

Ruby：复杂数据处理

KV：解析 key=value 格式日志

Aggregate：合并多条事件数据

数据收集、清洗、处理、传输到目标系统，如 Elasticsearch。

Input → Filter → Output。

用于日志文本解析，将非结构化日志转为结构化字段。

设置 pipeline.workers 多线程处理，调整 batch.size，使用 Persistent Queue。

避免 Logstash 宕机或内存压力丢失事件，事件可持久化磁盘。

grok、mutate、date、geoip、kv、ruby、aggregate。

Filebeat 轻量级日志采集 → 发送到 Logstash；Logstash 负责复杂解析和输出。

多线程 workers、调整 batch.size、使用 codec、持久队列、减少复杂正则。

1、核心特性

2、设计原则

3、微服务 vs 单体架构

1、CAP定理

2、BASE定理

核心关系

通俗理解

核心公式

1、核心作用

2、主流组件对比

3、Nacos核心原理

4、Eureka核心考点

1、核心作用

2、主流组件对比

3、OpenFeign核心原理

4、关键配置

1、核心作用

2、主流组件

3、核心原理

4、核心负载均衡策略

1、核心作用

2、核心概念

3、主流组件对比

4、Sentinel核心内容

5、熔断 vs 降级

1、核心作用

2、主流组件对比

3、Nacos config核心原理

1、核心作用

2、主流组件对比

3、Gateway核心原理

1、中间件

2、数据层

3、部署

1、高可用微服务架构设计（全组件）

2、微服务拆分依据（DDD/业务边界）

3、秒杀场景高并发/高可用设计、统一鉴权体系设计

4、多环境配置隔离、服务平滑升级/灰度发布

1、微服务调用超时

2、服务雪崩

3、网关请求堆积排查

从网关-&gt;服务-&gt;数据层逐步定额我i，结合监控/链路工具（SkyWalking、Prometheus）

分布式系统中网络分区不可避免（网络故障、机房断电），舍弃P则沦为单体，所以P必留，只能在C和A中选择

BASE是CAP的延伸补充，CAP指出三者不可兼得，BASE给出落地思路，舍弃强一致选AP，通过三要素实现最终一致性，适配多数业务

联系

区别

基于两种底层协议；<br>1、AP：Distro协议（分片存储+异步复制），高可用，舍强一致，适服务发现；<br>2、CP：Raft协议（主节点选取），强一致，舍部分可用，适配置中心；可自由切换

服务发现核心需求是高可用，而非强一致；<br>实例下线客户端短暂获取，可通过熔断降级规避故障；<br>若服务发现不可用，整个调用崩溃，影响更大

1、至少准备3个节点（奇数，便于Raft选举）；<br>2、同集群名称，不同节点ID；<br>3、配置MySQL持久化；<br>4、配置节点间通信地址，实现同步；<br>5、启动节点，自动组成集群，支持故障转移

1、扫描@FeignClient接口；<br>2、创建JDK动态代理；<br>3、代理注入容器；<br>4、代理解析注解获取请求头信息；<br>5、发HTTP请求；<br>6、响应反序列化；<br>7、集成LoadBalancer实现负载均衡

1、全局配置，对所有远程调用生效<br>2、单个服务配置，仅对指定服务生效<br>生产建议核心服务单独配置，避免全局影响

内置集成SpringCloud LoadBalancer（替代Ribbon）；<br>流程：1、通过服务名从注册中心取实例列表；2、按负载均衡策略选实例；3、转发请求，完成负载均衡

核心是请求分发+实例选择；<br>流程是取实例列表，按策略选实例，转发请求；<br>目的是均匀分配算法，提升吞吐量，避免单点过载

默认轮询；原理是取实例列表后，按顺序依次分发、循环往复，无状态，无需记录调用情况，通用场景首选

1、实现ReactorLoadBalancer&lt;ServiceInstance&gt;接口，重写choose方法（定义选择逻辑）；<br>2、在choose方法中按业务规则选实例；<br>3、配置类注入容器，替换默认策略；<br>4、（可选）为指定服务单独配置

责任链模式，顺序-&gt;构建调用链路-&gt;统计集群指标-&gt;日志记录-&gt;统计流量指标-&gt;权限控制-&gt;系统保护-&gt;限流-&gt;熔断降级-&gt;业务逻辑

3种条件：1、慢调用比例：耗时超阈值比例&gt;=阈值，请求数&gt;=5；2、异常比例：异常率&gt;=阈值，请求数&gt;=5；3、异常数：异常数&gt;=阈值，请求数&gt;=5；<br>状态流转：闭合（正常）-&gt;打开（熔断，10秒）-&gt;半开（尝试恢复，成功闭合、失败打开）

核心属性：value（资源名，必填）、fallback（业务异常/超时/熔断兜底）、blockHandler（限流/系统保护兜底）等；<br>区别：<br>1、触发场景：fallBack对应业务异常等，blockHandler对应限流等；<br>2、异常类型：fallback接收Throwable，blockHandler接收BlockException

多层防护：<br>1、熔断：断开故障服务调用；<br>2、降级：配置兜底逻辑，快速返回；<br>3、限流：核心接口设阈值，避免洪峰；<br>4、隔离：信号量隔离，避免资源占用；<br>5、缓存：高频接口缓存，减少远程调用；<br>6、重试：非核心接口合理重试；<br>7、监控：实时监控，提前发现异常。

核心长连接+推模式，拉模式兜底；<br>流程：1、客户端与服务端建立长连接；<br>2、配置修改，服务端主动推送；<br>3、客户端自动刷新；<br>4、长连接断开，定时拉取，保证最终一致。

三级隔离（命名空间+分组+数据ID）：<br>1、命名空间：dev/test/prod，客户端配置指定；<br>2、分组：按服务模块分组，客户端配置指定；<br>3、数据ID：服务名-环境.yml，客户端配置指定；实现不同环境、服务配置隔离

作用：标记需动态刷新Bean，配置修改后重新创建Bean，无需重启，加载新配置；原理：基于Spring自定义作用域，配置刷新时销毁旧Bean、创建新Bean，新Bean加载最新配置

从高到低：<br>1、Nacos远程配置；<br>2、客户端bootstrap.yml；<br>3、客户端application.yml；<br>4、系统环境变量；<br>5、命令行参数；<br>核心配置放Nacos，本地放客户端特有配置（端口）

1、路由：基本单元，定义转发规则，由ID、URL、断言、过滤器组成，负责转发符合条件的请求；<br>2、断言：匹配请求条件，基于Spring EL表达式，只有符合条件才能转发；<br>3、过滤器：拦截处理请求/响应，分全局和局部，实现鉴权、限流，责任链模式执行。

1、客户端发送请求；<br>2、匹配路由断言；<br>3、前置过滤器处理；<br>4、转发请求到目标服务器；<br>5、服务器返回响应；<br>6、后置过滤器处理；<br>7、返回响应给客户端。

核心从Nacos动态获取路由规则，无需重启；<br>1、搭建Nacos，配置JSON格式路由规则（ID、URL、断言、过滤器）；<br>2、Gateway引入Nacos依赖，配置Nacos地址；<br>3、Gateway监听Nacos路由配置变化，自动更新路由规则；<br>4、无需重启Gateway，即可实现路由新增、修改、删除

分布式系统是将一个完整的业务拆分为多个子任务，部署在堕胎独立的网络节点上，通过网络协同完整计算的系统，核心解决集中式系统的单点瓶颈、扩展能力差、容错性弱问题

核心特征

CAP是分布式系统的基础定理，任何分布式系统只能同时满足其中两项，核心结论：分区容错性P是必选项，只能在CP和AP之间权衡

CP 系统：牺牲可用性保证强一致性，典型案例：ZooKeeper、Etcd、HBase、分布式数据库

AP 系统：牺牲强一致性保证可用性，典型案例：Eureka、Nacos AP 模式、Cassandra、大部分互联网业务系统

面试误区：CAP 不是永久放弃某一项，而是网络分区发生时，在 C 和 A 之间做取舍，分区恢复后可通过数据同步恢复一致性

BASE 是对 CAP 中 AP 方案的补充，核心思想是牺牲强一致性，换取系统的高可用性和可扩展性，保证数据最终一致性，是大规模分布式微服务系统的首选准则。

BA 基本可用

S 软状态

E 最终一致性

最终一致性常见模型：读己之所写、会话一致性、单调读、单调写、因果一致性

核心对比：ACID 是数据库事务的强一致性准则，BASE 是分布式系统的柔性一致性准则，二者是对立统一的关系。

网络不可靠、时钟不一致、节点故障、数据一致性、并发安全、负载均衡、服务治理、可扩展性、故障排查、容灾备份。

提案（Proposal）、提议者（Proposer）、接受者（Acceptor）、学习者（Learner）、法定人数（Quorum，过半节点）、任期号（Term，单调递增，解决脑裂）。

核心角色

核心流程

核心变种

面试要点

Raft 的设计目标是易理解、易实现，将一致性问题拆分为领导选举、日志复制、安全性三个子问题，是 Etcd、Consul、云原生组件的核心算法。

核心角色

核心流程

ZAB（ZooKeeper Atomic Broadcast）原子广播协议，专为 ZK 设计，核心保证集群事务的顺序一致性和崩溃恢复能力

核心阶段

选主规则

核心概念

核心定位

核心优势

核心原理：利用 Redis 单线程特性，通过原子命令保证互斥性，是高并发场景首选。

正确基础实现：SET lock_key unique_value NX PX 30000

NX：仅 key 不存在时设置成功，保证互斥<br>PX：设置过期时间，防止客户端崩溃导致死锁<br>unique_value：客户端唯一标识，防止误删其他客户端的锁

安全释放锁

进阶生产级特性<br>

缺点

优点

生产级落地

核心原理

实现流程

优点

缺点

悲观锁实现

乐观锁实现

优点

缺点

核心原理

优点

缺点

分为刚性事务（强一致性） 和柔性事务（最终一致性） 两大类，互联网微服务场景以柔性事务为主。

2PC（两阶段提交）

3PC（三阶段提交）

基于 BASE 理论，牺牲强一致性换取高可用和高性能，是微服务场景的核心选型。

TCC（Try-Confirm-Cancel）

SAGA 模式

事务消息（RocketMQ/Pulsar 原生支持）

本地消息表 + 消息队列

最大努力通知

<br>

分布式缓存的核心作用是降低数据库访问压力、提升系统响应速度、支撑高并发流量，主流实现为 Redis，核心分布式架构包括：主从复制、哨兵 Sentinel、Redis Cluster（官方分片集群）、Codis（代理层分片）。

缓存穿透

缓存击穿

缓存雪崩

核心矛盾

主流方案：Cache Aside Pattern（旁路缓存，读多写少首选）

其他方案

核心作用

2、主流 MQ 选型对比

1、消息的可靠性投递（不丢失）

2、消息的重复消费与幂等性

3、消息的顺序性

4、消息积压问题（线上故障高频场景题）

5、高频补充考点

可用性 SLA，核心衡量标准

核心辅助指标

冗余备份与故障转移

隔离设计（防止故障扩散，避免雪崩）

限流、熔断、降级

通过 Term 任期号 + 过半投票机制，旧 Leader 无法获得过半投票，无法提交日志，发现新 Leader 的更大 Term 后自动降级为 Follower。

Raft 强 Leader 设计，流程拆分清晰，易理解易实现；Paxos 无强 Leader，理论通用但落地难度大。

一次性触发，触发后需要重新注册；事件通知可能丢失，需客户端兜底；无法递归监听子节点变更。

Leader 宕机时，集群进入选主阶段，期间不对外提供写服务，甚至暂停读服务，牺牲可用性保证数据一致性。

全量数据存储在内存中，内存容量有限；设计目标是存储小体量元数据，不适合大文件；写性能随集群节点数增加而下降。

两个命令非原子操作，SETNX 成功后客户端崩溃，EXPIRE 未执行，会导致锁永久不释放，引发死锁。

通过唯一标识记录锁持有者和重入次数，获取锁时判断归属，重入则次数 + 1，释放时次数 - 1，归零才真正释放锁。

锁必须绑定客户端唯一标识，释放时先校验归属，且校验和删除必须是原子操作。

同步阻塞导致性能差、并发低；<br>TM 单点故障会导致整个系统不可用；<br>跨服务网络不可靠易引发数据不一致；<br>长事务会占用数据库连接，引发数据库性能瓶颈。

柔性事务无法实现数据库级别的隔离性，需通过业务层面实现，比如乐观锁、悲观锁、资源预留、状态机控制、串行化执行等。

本地缓存兜底、热点 key 拆分多副本分摊压力、接口级限流、大促前提前预热

缓存污染是指冷数据占用缓存内存，导致热点数据被淘汰，解决方案：采用 LRU/LFU 淘汰算法、合理设置 TTL、过滤冷数据、避免缓存大对象

标准架构：浏览器缓存 → CDN → 网关缓存 → 服务本地缓存（Caffeine/Guava） → 分布式缓存（Redis） → 数据库，层层拦截流量，保护底层资源

底层服务故障导致上层服务级联故障，整个系统不可用。防止手段：隔离、熔断、降级、限流、超时控制、合理的重试策略、多副本高可用、资源隔离

无状态服务水平扩容，多实例多机房部署

有状态服务多副本集群部署，自动故障转移

全链路隔离设计，防止故障扩散

完善的限流、熔断、降级机制

超时、重试、幂等性全链路控制

可观测性体系与分级告警，故障自愈能力

数据备份与灾备方案，保证数据不丢失

<br>

记录上次生成 ID 的时间戳，时钟回拨时，要么等待时钟追上，要么抛出异常，要么通过序列号兜底、机器 ID 扩容，主流框架均已实现该优化

Token 机制（先获取 Token，请求时校验并删除 Token，保证仅一次请求有效）、唯一键 + 去重表、数据库唯一约束、乐观锁、分布式锁、状态机幂等

全链路限流：前端限流、网关限流、服务层限流、分布式限流

流量削峰：消息队列异步化下单，将瞬时流量削平

库存安全：Redis 预扣库存 + 数据库最终扣减，乐观锁 / 分布式锁保证不超卖

热点处理：热点 key 本地缓存兜底、库存提前预热、隔离设计

高可用保障：熔断降级、关闭非核心功能、多级缓存、多机房部署

一致性保障：事务消息 / TCC 保证订单与库存的最终一致性

先通过监控大盘，查看接口的错误率、耗时、流量、饱和度，确认是整体超时还是个别请求，是否有报错

通过分布式链路追踪，根据 TraceID 定位超时环节，确认是 RPC 调用、数据库、缓存、外部服务，还是服务本身的问题

查看对应服务的日志，排查异常、报错、慢 SQL、慢调用堆栈

查看服务器、中间件的指标，CPU、内存、磁盘 IO、网络、数据库连接池、缓存命中率、线程池状态

定位根因后针对性解决，比如优化慢 SQL、修复缓存击穿、扩容服务、降级非核心功能、修复依赖服务故障

K8S是开源的容器编排引擎，用于自动化部署、扩缩容和管理容器化应用，核心目标是实现应用生命周期的声明式管理和自动化运维

自愈能力、弹性扩缩容、声明式API、基础设施无关、服务发现与负载均衡、滚动更新/回滚、资源隔离与调度优化

Pod

Node

Namespace

Label

Annotation

Selector

负责集群全局决策、调度、状态管理、故障响应

kube-apiserver

etcd

kube-scheduler

kube-controller-manager

cloud-controller-manager

负责运行容器化应用，管理Pod生命周期、网络、存储，上报节点和Pod状态

kubelet

kube-proxy

容器运行时（CRI）

1、ReplicaSet（RS）

2、Deployment

3、StatefulSet

4、DaemonSet

5、Job

6、CronJob

解决Pod IP动态变化的问题，实现服务的固定访问入口、负载均衡与服务发现

1、Service

2、Ingress

3、Ingress Controller

4、CoreDNS

配置资源

存储资源

生命周期阶段

生命周期关键环节

三大健康检查探针

kube-scheduler 核心职责是为未调度的 Pod 选择最优节点，分为三个核心阶段：预选阶段→优选阶段→绑定阶段。<br>

核心阶段

影响调度的核心配置

K8S 网络模型核心是IP-per-Pod，每个 Pod 有独立 IP，Pod 之间直接通信，无需 NAT，网络扁平化。<br>

1、四大网络通信场景<br>

2、CNI 插件对比

3、kube-proxy 三种工作模式

requests

limits

Pod 的 QoS 等级<br>

验证请求者的身份，确认 “你是谁”。K8S 不管理普通用户账户，仅管理 ServiceAccount（Pod 使用的服务账户）。<br>

常用认证方式：X509 客户端证书（管理员 / 组件常用）、ServiceAccount Token（Pod 访问 apiserver 使用）、OIDC（企业 SSO 对接）、Bearer Token、Webhook Token 认证。<br>

验证已认证的用户是否有权限执行对应操作，确认 “你可以做什么”，RBAC（基于角色的访问控制） 是默认启用、最常用的模式。<br>

RBAC 核心 4 个资源对象<br>

apiserver 的请求拦截器，在请求经过认证、授权之后，写入 etcd 之前执行，实现配置修改、合规校验、安全管控。<br>

Mutating Admission Webhook（变更型）：修改请求内容，如注入 Sidecar、设置默认资源 requests/limits。<br>

Validating Admission Webhook（验证型）：校验请求合法性，不符合规则则拒绝，如禁止 root 用户运行、禁止使用 latest 镜像。<br>

执行顺序：先执行所有 Mutating Webhook，再执行所有 Validating Webhook。<br>

网络策略（NetworkPolicy）：Namespace 级资源，定义 Pod 之间的网络访问规则，实现三层 / 四层网络隔离，默认集群内 Pod 全通，可通过 NetworkPolicy 实现白名单管控。<br>

Pod 安全标准（PSS）：替代已废弃的 PodSecurityPolicy（PSP），分为 Privileged（特权级）、Baseline（基线级）、Restricted（受限级）三个安全等级，实现 Pod 运行时的安全管控。<br>

Pod Security Context：Pod / 容器级安全配置，定义运行用户、权限、Capabilities、Seccomp 等，实现容器最小权限运行。<br>

镜像安全：私有镜像仓库、镜像签名验证、漏洞扫描、镜像拉取策略 Always。<br>

etcd 安全：TLS 加密通信、数据加密、访问控制、定期备份。<br>

1、排障核心命令

2、运维核心命令

主流部署方式：kubeadm（官方推荐，生产 / 测试通用）、二进制部署（可控性高，学习用）、云厂商托管集群（ACK/TKE/EKS，生产环境主流）、minikube/kind（本地测试）。<br>

集群高可用核心<br>

etcd 备份与恢复

监控体系：Prometheus + Grafana 是事实标准，核心组件：node-exporter（节点指标）、kube-state-metrics（K8S 资源指标）、metrics-server（资源指标 API，用于 HPA/kubectl top）、Alertmanager（告警管理）。<br>

日志体系：主流 EFK 栈（Elasticsearch + Fluent Bit + Kibana），生产环境常用 DaemonSet 方式采集节点容器日志。<br>

HPA（水平 Pod 自动扩缩容）：自动调整 Pod 副本数，基于 CPU / 内存、自定义业务指标（QPS、请求延迟）、外部指标实现自动扩缩容，是最常用的弹性方案。<br>

VPA（垂直 Pod 自动扩缩容）：自动调整 Pod 的 CPU / 内存 requests/limits，适用于无法水平扩缩容的有状态应用。<br>

CA（集群自动扩缩容）：自动调整集群节点数量，Pod 无法调度时自动扩容节点，节点利用率低时自动缩容，云环境常用。<br>

CRD（自定义资源定义）：扩展 K8S API，自定义新的资源类型，让自定义资源和原生资源一样支持声明式管理、版本控制、RBAC 权限。<br>

Operator：封装了应用运维最佳实践的控制器，由CRD + 自定义控制器组成，持续监听自定义资源的状态，执行应用的部署、扩缩容、备份、升级、故障恢复等运维操作，实现复杂应用的全生命周期自动化管理。<br>

常用 Operator：Prometheus Operator、MySQL Operator、Redis Operator、Kafka Operator。<br>

CRI（容器运行时接口）：K8S 定义的容器运行时标准接口，kubelet 通过 CRI 与容器运行时通信，解耦 kubelet 和容器运行时。<br>

OCI（开放容器倡议）：定义容器镜像和运行时的行业标准，runc 是 OCI 运行时规范的参考实现。<br>

服务网格 Service Mesh：以 Istio 为代表，通过 Sidecar 模式代理服务流量，提供流量管理、安全、可观测性、限流、熔断、灰度发布等能力，无需修改业务代码。分为控制面（Istiod）和数据面（Envoy Sidecar）。<br>

GitOps：基于 Git 的持续交付模式，将集群期望状态存储在 Git 仓库，通过 Argo CD/Flux CD 自动同步到集群，实现声明式、可审计、可回滚的应用交付。<br>

集群管理平台：Rancher、KubeSphere，降低 K8S 使用门槛，提供多集群管理、可视化界面、DevOps、微服务治理等能力。<br>

1、解决紧密耦合的容器协同问题，主容器+Sidecar可共享网络和存储，无需端口映射即可本地通信；<br>2、实现原子调度，避免跨节点调度导致的协同失败；<br>3、统一生命周期管理，同Pod容器同步创建、销毁。

Namespace是逻辑隔离而非物理隔离。可隔离：资源配额、RBAC权限、资源命名唯一性；不可隔离：节点、底层网络（默认跨Namespace Pod互通，需NetworkPolicy限制）、PV、集群级资源。

1、用户通过kubectl/API客户端提交Pod/Deployment创建请求到kube-apiserver；<br>2、apiserver执行认证-&gt;授权-&gt;准入控制，验证请求合法性，通过后将资源对象写入etcd；<br>3、apiserver返回创建成功给客户端，etcd完成数据持久化；<br>4、kube-scheduler通过watch机制，监听到未绑定节点的Pod；<br>5、scheduler执行调度流程：预选阶段过滤不符合要求的节点-&gt;优选阶段对剩余节点打分排序，选出最优节点-&gt;绑定阶段将Pod与目标节点绑定，信息写入apiserver并持久化到etcd；<br>6、目标节点的kubelet通过watch机制，监听到调度到本节点的Pod；<br>7、kubelet通过CRI接口调用容器运行时，拉取镜像、创建并启动容器，执行init容器-&gt;主容器的初始化流程；<br>8、kubelet执行Pod健康检查（StartupProb-&gt;LivenessProbe/ReadinessProbe），确认容器正常运行；<br>9、kubelet将Pod状态更新到apiserver，持久化到etcd；<br>10、若Pod关联了Service，EndPointSlice控制器更新对应EndpointSlice，kube-proxy根据规则更新节点转发规则，完成服务访问配置。

ConfigMap通过volume挂载到Pod时，kubelet会定期同步ConfigMap内容，更新后自动更新挂在目录中的配置文件，应用监听文件变化即可实现热更新。不支持热更新的场景：环境变量挂载、subPath挂载、不可变ConfigMap

共给（静态/动态）-&gt;绑定-&gt;使用-&gt;回收

Retain（保留，需管理员手动清理）、Delete（删除，PVC删除后PV和数据自动删除）、Recycle（已废弃）

RWO（单节点读写）、ROX（多节点只读）、RWX（多节点读写）、RWOP（单Pod读写，K8S 1.27+ 稳定）

普通用户给人 / 外部客户端使用，全局跨 Namespace，由外部身份系统管理；ServiceAccount 给 Pod 内程序使用，Namespace 级，由 K8S 管理，通过 Token 认证，自动挂载到 Pod。

1、第一步：执行kubectl describe pod &lt;pod名称&gt;查看 Events 字段，90% 的问题可在此定位。<br>2、调度失败常见原因：节点资源不足、亲和性 / NodeSelector 不匹配、污点与容忍不匹配、端口冲突、PVC 绑定失败。<br>3、镜像拉取失败常见原因：镜像名称 / 标签错误、私有仓库未配置 imagePullSecret、节点网络无法访问镜像仓库、拉取超时。<br>4、其他原因：Namespace 的 ResourceQuota 已满。

1、第一步：kubectl describe pod查看退出码、退出原因（如 OOMKilled）。<br>2、第二步：kubectl logs &lt;pod名称&gt; --previous查看上一次启动的日志，定位应用崩溃原因。<br>3、常见原因：OOMKilled（内存超过 limits）、启动命令 / 配置错误、健康检查失败、应用程序崩溃、容器启动后立即退出、权限不足。

1、第一步：进入 Pod 内本地访问，排除应用本身问题（如仅监听 127.0.0.1、端口配置错误）。<br>2、第二步：检查 ReadinessProbe 是否成功，失败会导致 Pod 被从 Service 后端移除。<br>3、第三步：检查 Service 的 Selector 是否匹配 Pod 的 Label，EndpointSlice 是否有对应的 Pod IP 和端口。<br>4、第四步：检查 Pod 网络连通性、NetworkPolicy 是否限制访问、kube-proxy 是否正常运行、iptables/ipvs 规则是否正确。<br>5、第五步：集群外访问需检查 NodePort/LoadBalancer/Ingress 配置、防火墙是否放行。

1、第一步：登录节点，检查基础环境：磁盘是否满、内存 / CPU 是否耗尽、网络是否通、时间是否同步。<br>2、第二步：检查 kubelet 是否正常运行，查看 kubelet 日志journalctl -u kubelet -f定位报错。<br>3、第三步：检查容器运行时（containerd）是否正常运行，crictl ps是否可正常执行。<br>4、第四步：检查节点与 apiserver 的网络连通性、内核参数是否正确、Swap 是否关闭、是否有节点压力污点。

K8S 分为控制平面和工作节点。<br>控制平面是集群大脑，包含：kube-apiserver（集群唯一入口，API 服务，认证授权）、etcd（集群唯一持久化存储，保存所有集群状态）、kube-scheduler（Pod 调度，选择最优节点）、kube-controller-manager（运行各类控制器，实现状态调谐）、cloud-controller-manager（对接云厂商基础设施）。<br>工作节点负责运行应用，包含：kubelet（节点代理，管理 Pod 生命周期，上报状态）、kube-proxy（实现 Service 的负载均衡和网络转发）、容器运行时（CRI，管理容器生命周期，如 containerd）。

核心区别是 Deployment 用于无状态应用，StatefulSet 用于有状态应用，具体差异：<br>1. 网络标识：Deployment 的 Pod 名称、IP 随机；StatefulSet 的 Pod 名称固定，通过 Headless Service 提供固定 DNS 域名。<br>2. 存储：Deployment 的 Pod 共享存储；StatefulSet 通过 volumeClaimTemplates 为每个 Pod 创建独立 PVC，Pod 重建存储不变。<br>3. 部署更新：Deployment 并发创建 / 更新；StatefulSet 有序部署、有序删除、有序更新，支持分区更新。

1. StartupProbe：检测容器是否启动完成，仅在启动时执行，成功后停止，失败重启容器，适用于慢启动应用，避免被 Liveness 误杀；<br>2. LivenessProbe：检测容器是否存活，持续执行，失败重启容器，实现自愈，适用于检测应用死锁、崩溃；<br>3. ReadinessProbe：检测容器是否可以处理请求，持续执行，失败则切断流量，适用于避免将流量转发到无法处理请求的 Pod。

RBAC 是基于角色的访问控制，核心 4 个组件：<br>1. Role：Namespace 级，定义 Namespace 内的权限集合；<br>2. ClusterRole：集群级，定义集群级 / 跨 Namespace 的权限集合；<br>3. RoleBinding：Namespace 级，将 Role/ClusterRole 绑定到用户 / ServiceAccount，仅在当前 Namespace 生效；<br>4. ClusterRoleBinding：集群级，将 ClusterRole 绑定到用户 / ServiceAccount，全集群生效。

Operator 是封装了应用运维最佳实践的控制器，由 CRD + 自定义控制器组成。<br>CRD 是扩展 K8S API，自定义新的资源类型，定义应用的期望状态；<br>Operator 的自定义控制器持续监听 CRD 的状态，执行应用的部署、升级、备份、故障恢复等运维操作，实现应用的全生命周期自动化管理，将当前状态调谐到期望状态。