InnoDB 按锁粒度分类

表级锁：锁住整张表，粒度最大、开销小、并发低。
行级锁：锁住单行/多行记录，粒度最小、开销大、并发最高。
页级锁：锁住数据页，粒度介于表锁和行锁之间。

最常用：行级锁（InnoDB 默认主打，支撑高并发事务）。

MySQL 慢查询日志默认是关闭（OFF）的，不会自动记录慢 SQL

存储过程：把一堆 SQL 语句打包好，提前编译存在 MySQL 服务器里，给它起个名字，以后直接调用名字就能一次性执行完。

即数据库的脚本

EFK 架构三大组件全称与作用

EFK 分别对应

E：Elasticsearch
F：Fluentd
K：Kibana

各自作用

1. Fluentd（采集层 F）

负责：收集、过滤、转发日志

从服务器/容器/应用 采集日志
做清洗、过滤、格式化
转发给 Elasticsearch
👉 定位：日志搬运工+预处理

2. Elasticsearch（存储检索层 E）

负责：存储 + 检索 + 分析日志

接收 Fluentd 发来的日志
分词、索引、持久化存储
提供快速搜索、聚合统计
👉 定位：日志数据库+搜索引擎

3. Kibana（可视化层 K）

负责：展示、图表、告警

连接 Elasticsearch
做日志查询、仪表盘、折线图、饼图
日志检索、故障排查、监控告警
👉 定位：日志可视化看板

总结

Fluentd 收日志 → Elasticsearch 存和搜日志 → Kibana 看图查日志

顺带区分下 ELK：
ELK 是 Logstash 代替了 Fluentd，Fluentd 更轻量、适合容器/K8s，所以现在多用 EFK。

EFK 看的是「日志内容」，链路追踪看的是「请求流程」EFK 只能看零散日志，看不出一次请求跨了哪些服务、耗时卡在哪；链路追踪专门干这件事。

线程池好处

降低资源消耗
避免频繁创建、销毁线程，复用已有线程，减少系统开销。
提高响应速度
任务来了不用新建线程，直接用空闲线程立马执行，不用等待创建线程的时间。
便于统一管理
统一控制线程数量、排队策略、拒绝策略，防止无限创建线程导致系统宕机。

重定向 vs 请求转发

1. 本质区别

请求转发：服务器内部跳转，只发1次请求
重定向：浏览器两次请求，服务器告诉浏览器重新发新地址

2. 地址栏变化

转发：地址栏不变
重定向：地址栏变成新URL

3. 数据是否保留

转发：共享同一个 request 域对象，参数不丢
重定向：两次独立请求，原 request 数据丢失

4. 访问范围

转发：只能跳本项目资源
重定向：可以跳任意网站、外部地址

总结

转发是服务器内部偷偷走一遍，地址不变、数据还在；
重定向是让浏览器再发一次请求，地址变了、数据重置。

页表 vs TLB

页表：操作系统放在内存里，用来把虚拟地址翻译成物理地址的映射对照表；
TLB：CPU内部的高速缓存，缓存页表常用映射，专门加速地址翻译的硬件小快表。

MCP（Model Context Protocol）上下文拆分的标准模块（五大核心）：

System Instructions（系统指令）：模型行为与能力的顶层设定。
User Context（用户上下文）：用户偏好、目标、历史交互。
Memory（记忆）：短期对话记录 + 长期用户画像/知识。
Resources（资源）：RAG文档、文件、数据库等外部数据。
Tools（工具）：可调用的函数/API定义与执行结果。

系统指令 + 用户上下文 + 记忆 + 资源 + 工具。

链路追踪里 Span 和 Trace 分别代表什么？

概念	含义	类比
Trace	整条完整请求链路，一次客户端请求从头到尾跨所有服务的全过程，全局唯一 `TraceID`	一整趟快递物流全程
Span	链路里的每一小段，一个服务、一个接口、一次数据库调用就是一个 Span，有自己 `SpanID`、耗时、起止时间	每一个中转站的一段运输环节

HTTP 301 vs 302 核心区别

1. 含义

301 永久重定向：资源永久搬家，以后永远用新地址
302 临时重定向：资源暂时挪一下，下次还可以访问旧地址

2. 浏览器缓存

301：浏览器会缓存，下次直接跳新地址，不请求旧地址
302：不缓存，每次都要先请求旧地址，再收到跳转

3. SEO 搜索引擎

301：权重转移到新URL
302：权重保留在旧URL，不传递

4. 适用场景

301：域名更换、页面永久下线、旧地址彻底废弃
302：登录跳转、临时活动页、临时维护、登录后跳首页

总结

301永久搬家带缓存、传权重；302临时跳转不缓存、不留权重。

幻读

一、什么是幻读

幻读：一个事务两次范围查询，中间被别的事务插入/删除了新数据，导致前后查到的行数不一样，像“凭空多了/少了一行”，就叫幻读。

例子：
事务A：查 id between 1 and 10，查出3条
事务B：插入一条 id=5 并提交
事务A：再查同范围，变成4条 → 多出一行，就是幻读

区别脏读、不可重复读：

脏读：读到别人未提交的数据

不可重复读：同一行内容变了（被更新）

幻读：行数变了（被插入/删除）

二、InnoDB 怎么解决幻读

隔离级别
InnoDB 默认 RR 可重复读，靠 MVCC 解决了大部分幻读（普通快照读）。
间隙锁 + 临键锁（Next-Key Lock）
如果是当前读（select … for update / update / delete）：
InnoDB 用 临键锁 = 行锁 + 间隙锁
锁住整个范围区间，禁止其他事务在这个区间插入新数据，彻底杜绝幻读。

总结

幻读：范围查询时，其他事务插入/删除，导致前后查询行数不一致。
InnoDB 靠 MVCC 解决快照读幻读；靠间隙锁+临键锁解决当前读幻读。

MVCC 就是多版本并发控制，InnoDB 靠它实现不加锁也能高并发读，读的是数据历史快照版本，不用等写事务释放锁。

MySQL InnoDB 四个隔离级别由低到高

读未提交（Read Uncommitted）
读已提交（Read Committed）
可重复读（Repeatable Read）👉 InnoDB 默认
串行化（Serializable）

对应问题解决（速记）

读未提交：有脏读、不可重复读、幻读
读已提交：解决脏读，还有不可重复读、幻读
可重复读：解决脏读、不可重复读，普通快照读解决大部分幻读
串行化：全部解决，但并发最低、性能最差

redis数据类型

五大基础类型
String 字符串：最常用，存字符串、数字、JSON
List 列表：双向链表，有序可重复，做队列、栈
Set 集合：无序、不可重复，去重、交集并集
Hash 哈希：类似 Map，存对象字段，适合存用户信息
ZSet 有序集合：带分数排序、不可重复，排行榜场景
三种特殊类型
Geospatial 地理位置：经纬度、附近的人
Bitmap 位图：签到、状态标记、超省内存
HyperLogLog：基数统计，统计 UV、去重访问量

限流，熔断，降级

限流
作用：挡流量，防止请求太多把系统压垮只允许固定数量请求进来，多余的直接拦住。例子：景区限制同时入园人数，超了就排队 / 提示稍后再试。场景：秒杀、活动高峰，防突发流量。
熔断
作用：下游服务崩了，立刻断开，不继续调用检测到依赖服务超时、报错率太高，直接切断调用，避免连锁拖垮自己。等下游恢复了再慢慢尝试恢复调用。例子：你打电话给别人一直占线，不再反复拨号，过一会再打。
降级
作用：系统扛不住时，放弃非核心功能，保核心业务流量大或资源不足时，关掉不重要的功能，返回兜底默认数据。例子：APP 高峰期关闭商品详情推荐、关闭积分签到，只保下单、支付核心流程。

分布式事务：一次业务操作，涉及多个数据库、多个微服务，要保证要么全部成功提交，要么全部失败回滚，不能一半成功一半失败，这就是分布式事务。

分布式事务常见解决方案

1. 本地消息表（可靠消息最终一致性）

思路：
本地业务 + 消息记录在同一个本地事务提交，再由定时任务轮询发消息，下游处理完成后回写状态。
特点：简单、接地气、成本低；适合电商订单、支付场景。

2. 事务消息（RocketMQ/Kafka 事务消息）

思路：
半消息预发 → 本地事务执行 → 提交/回滚消息 → 下游消费。
特点：不用自己建本地消息表，中间件封装好，业界主流。

3. TCC 补偿事务（Try-Confirm-Cancel）

三段式：

Try：资源检查、预冻结
Confirm：确认提交
Cancel：回滚补偿
特点：强一致性、高可用；但代码侵入大、开发量大、要写补偿回滚逻辑。

4. SAGA 模式

思路：长事务拆分，每个子事务配一个逆向回滚事务，某步失败就依次逆向补偿。
特点：适合长流程、跨多服务事务；最终一致，不保证强实时一致。

5. Seata AT 模式（最常用）

思路：
基于全局事务 + 分支事务 + undo log，一阶段提交快照、二阶段批量提交/回滚。
特点：无侵入、开发简单，微服务项目首选；中间件托管分布式事务。

6. 最大努力通知

思路：
业务完成后异步通知下游，失败就定时重试，保证最终能收到。
特点：适用于对账、支付结果通知等允许短暂不一致的场景。

本地消息表、MQ事务消息、TCC、SAGA、Seata AT、最大努力通知。

要简单：用本地消息表 / MQ事务消息
微服务省事：Seata AT
要强一致高可靠：TCC
长流程业务：SAGA
对账回调：最大努力通知