Redis

单线程模型

核心

• Redis 是“核心执行单线程 + 周边能力多线程/子进程”的模型。

缺点

• 大 Key、慢命令、Lua 脚本、阻塞命令都会卡主线程，导致延迟抖动。

什么不是单线程

• 多线程

• unlink - 异步删除

• AOF - fsync

• 网络socket IO（小包很多，网络读写开销大）

• 多进程

• bgsave - RDB

• bgrewriteaof - AOF重写

性能 - 为什么快

• 基于内存，CPU 不是主要瓶颈

• 数据结构实现简单高效

• IO多路复用epoll

• 单线程执行命令，没有锁竞争、线程切换成本低

缓存异常与治理

• 大 Key - String value > 1KB | 集合 > 5k元素 总和 > 100MB

异常 - 穿透 | 击穿 | 雪崩 | 热key | 大key | 一致性

击穿与热key治理

• 逻辑过期 + 互斥重建（DB限时）| 本地缓存 | 拆分热点key（读时聚合，写时分散）

雪崩治理

• TTL抖动 + 限流降级 + 预热 + 高可用（主从 哨兵）+ 本地缓存

穿透治理

• 参数校验（订单号长度，商品id格式）+ 限流（IP，用户） + BloomFilter + 空值缓存（TTL可短些）

一致性治理

• 延迟双删 | CDC/MQ

IO多路复用

• select | poll | epoll

数据结构

• String | List | Set | Hash | Zset

• 底层实现 listpack(7/ziplist(

• SDS 压缩列表 跳表 复杂度

• 应用场景 排行榜

大热key

• 大key

• 热key

• 治理

数据淘汰

• lru lfu

集群

• 脑裂

持久化

• AOF AOF膨胀 AOF重写

• RDB

• 混合

应用

• 分布式锁（Redisson实现原理，红锁替代）

• 布隆过滤器（误判率）

• 一致性（双删，CDC）

• lua原子执行业务逻辑（读 判断 写）| Redis 事务：解决“多条命令一起执行”

MySQL

逻辑SQL顺序

• FROM -> ON -> JOIN -> WHERE -> GROUP BY -> HAVING -> SELECT -> DISTINCT -> ORDER BY -> LIMIT

• from on join 表形成

• where 筛选

• group by 分组 having 分组筛选

• select 结果集

• distinct去重 order by 排序 limit 限制

变长字段格式

• compact（旧，留768） | dynamic（新）

页碎片、分裂、合并

• 索引非自增（二级索引） | 更新变长字段 - 插入中间 - 页分裂

• 删除 - 有效数据低于阈值 - 相邻页合并

• 逻辑删除 - 更新is_deleted字段，查询带字段
• 避免了 B+ 树结构的破坏和页合并；保留了历史数据供审计。
• 依然是更新操作（可能引发页分裂）；表会无限膨胀，查询越来越慢；导致二级索引体积庞大。
• 适合数据量不会随时间无限增长的核心业务表。

• 冷热数据分离 / 定期归档（Archiving）
• 定时任务在业务低峰期（如凌晨 3 点），把 3 个月前的老数据批量 INSERT INTO 历史表，然后从原表中批量 DELETE。
• 配套动作： 批量 DELETE 产生大量碎片后，必须定期（如每周/每月）执行 OPTIMIZE TABLE table_name;（或 ALTER TABLE table_name ENGINE=InnoDB;）。
• 原理： OPTIMIZE TABLE 会锁表（虽然现阶段有 Online DDL，但仍有开销），然后重新整齐地编排整张表的数据，重建 B+ 树，回收所有碎片空间。

• 使用表分区（Partitioning）
• 做法： 针对日志、流水、订单等按时间无限增长的数据，不采用传统的 DELETE，而是按月或按天建分区表（Partition Table）。
• 如何删除？ 当需要清理一年前的数据时，直接执行 ALTER TABLE drop PARTITION p_202201;。
• 直接在文件系统层面删掉对应的底层 .ibd 数据文件。瞬间完成，不产生任何碎片，不触发页合并，不影响其他分区的 B+ 树结构

存储引擎

• InnoDB vs MyISAM（事务不完整）

事务

ACID

• A - undo log + 2PC(redo|bin)

• C - 一致性实现 A/I/D + 约束 + 正确业务逻辑共同保证

• I - 隔离性实现 MVCC + 锁

• D - redo log WAL + doublewrite（恢复半写入页） + 落盘fsync（bin|redo）

隔离级别

• （RU RC RR Serializable 脏读 不可重复 幻读 - MVCC + gap/nextkey锁索引）

• 锁 2PL 行锁 间隙锁 Next-Key锁

MVCC

• 一行数据留多个版本，读历史版本减少快照读与写冲突；

• 行隐藏信息：最后修改trx_id，undo log指针

ReadView

• 快照读时，事务提交与活跃状态的快照，决定当前事务可见版本

• min [active] max

WAL

• 内存更新页，日志落盘后commit，随后刷盘

• 随机写改顺序写，延迟数据页刷盘（结合doublewrite保障刷盘完整，先顺序写doublewrite，落盘，然后根据doublewrite(LSN redo log更新）落实际位置，查checksum确认是否需要）

• 性能更高 更安全

索引

SQL调优

join分析

SQL 查询性能急剧降低，可能有什么原因

• SQL 突然变慢，先看计划有没有变，再看是不是被锁住了。

• 看慢查询日志
• Query_time
• Lock_time
• Rows_examined

1. 跑 EXPLAIN / EXPLAIN ANALYZE
• 看有没有全表扫描
• 看估算行数和实际行数差异

2. 看锁
• SHOW ENGINE INNODB STATUS
• performance_schema

3. 看统计信息
• 必要时 ANALYZE TABLE

4. 看资源
• CPU / IO / Buffer Pool / 连接数

explain -id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra

• type - 访问方式 - const（唯一索引常量比较） | eq_ref（唯一索引等值join） | ref（索引常量比较） | range（范围比较）| index（全索引） | all（全表）

• possible_keys - 索引候选

• key - 索引

• key_len - 索引长度 - 联合索引

• rows - 预估扫描行数

• filtered - 过滤留存百分比

• extra - Using index | index condition | where | filesort | temporary | join buffer

• type - key - key_len - rows - extra

• 用 EXPLAIN FORMAT=TREE 或 EXPLAIN ANALYZE 把 join 结构打印成树（推荐）：对 Nested loop join：Nested loop 节点下

• 第一个 child 是驱动表（outer input）

• 第二个 child 是被驱动表（inner input，通常是 index lookup）

• 驱动表通常 loops=1

• 被驱动表 loops≈驱动表实际输出行数（或按块/批次）

日志

• bin log - Server 层、偏逻辑、用于主从复制/恢复

• undo log - MVCC，事务回滚

• redo log - InnoDB 层、偏物理、用于崩溃恢复 innodb_flush_log_at_trx_commit

• 2PC - InnoDB redo log prepare | MySQL Server binlog | InnoDB redo log commit

• 崩溃恢复 prepare [binlog] commit

• group commit

JVM

内存模型/运行时数据

• 线程独占：栈（HotSpot合并native）PC 线程共享：堆 方法区（旧永久代在堆里内存受限，元空间实现动态）

JVM调优

• 堆大小

• 直接内存

类加载生命周期

• 加载（Loading） → 链接（Linking：验证、准备、解析） → 初始化（Initialization） → 使用（Using） → 卸载（Unloading）

• 加载 - 1. 通过类的全限定名获取二进制字节流 2.将字节流转成运行时数据结构 3.在堆中生成一个 java.lang.Class 对象

• 链接 - 验证：确保这个类的字节码是合法、安全、符合 JVM 规范的，不会危害虚拟机。 准备：为类变量（也就是 static 变量）分配内存，并设置默认零值。解析：把常量池中的符号引用，替换成直接引用。解析可以在初始化之后按需进行，也就是延迟解析。

• 只有“主动使用”类时才会初始化。常见触发条件：

双亲委派

• 防重复 防篡改

• Bootstrap → Platform → Application → 自定义

• 类加载机制 流程

• 类加载器层次

• 打破双亲委派(SPI - JDBC|SLF4j ContextClassLoader，热部署热更新，新的cl加载新版本旧的类与cl一起回收，Tomcat多版本依赖）

• findClass() | getParent().loadClass() // 业务类/插件类优先自己加载（child-first）

GC

CMS G1 ZGC

GC Roots

• 活跃线程栈帧中的局部变量引用 - Object obj

• 已加载类的静态字段引用 - static

• JNI 引用 - native (Object obj)

• 活跃线程对象 - new Thread().start()

• 监视器锁相关引用 - synchronized(obj)

• JVM 内部保留引用 - 常量池

GC算法

• Young - 复制

• Old - 标记清除 | 标记整理

• Mixed

GC种类

• CMS G1 ZGC

• 分代理论 各自特点 算法 是否STW

• 读写屏障

手撕

• 多线程交替打印ABC

• 反转区间链表 x2

• 环形链表

• 链表反转

• topK x2

• 并发安全单例模式

• LRU - ttl

• 课程表（拓扑排序）

• 出现次数超过一半的数字

• 岛屿数量

• 合并两个有序数组 x2

• 最接近的三数之和

• LRUCache

1. 一道回溯 已知元素：1 2 3 4，查出所有形如这样的组合：1 12 123 124 1234 13 134 14 2 23 234 24 3 34 4

• 二叉树高度

• 删除链表的倒数第 N 个结点

• 反转二叉树（迭代和层序遍历）

JUC

逃逸分析

• 对象会不会逃出当前方法？return | 字段赋值 | 传参其他方法保存 | 集合

• 会不会被别的线程访问，那就属于线程逃逸。

• 用于锁消除（如果某个锁对象根本不会被别的线程看到，那加锁就没意义，可以去掉。）

• 标量替换（如果一个对象不会逃逸，JVM 甚至可能连对象都不真创建，直接把它拆成几个普通变量用。）

• 栈上分配

JMM

• 哪些重排序是允许的

• volatile、synchronized、final 各自提供什么保证

• happens-before 成立时，线程间应该看到什么结果

• 1）编译器/JIT 会重排

• 2）CPU 会乱序执行

• 3）多核各自有缓存

Synchronized

锁升级

• JVM 根据锁竞争强度，动态选择“偏向线程、CAS 自旋、阻塞唤醒”三种不同成本的同步方式。

• 适合单线程反复进入

• 对象头记录线程ID

• 同一线程重入几乎零成本

• 线程栈创建 Lock Record（旧mark word）

• CAS 抢锁

• 抢不到先自旋

• 膨胀为 ObjectMonitor（重入次数 | owner | 阻塞队列 | wait队列）

• 线程阻塞挂起

• 涉及上下文切换，用户内核态转换，成本最高

作用

• 实现原理 - monitorenter monitorexit ACC_SYNCHRONIZED字节码 信息存在对象头的Mark Word（hashCode | GC年龄 | 偏向线程ID | 栈帧LockRecord指针 |ObjectMonitor指针）

• 方法锁 this（实例）/class（static） 自定义锁控制粒度+封装

对比volatile

• volatile的happens-before： volatile写 - 类似monitorexit | volatile读 - 类似monitorenter，最后写，最先读，保障其他变量的可见性

• volatile：可见性 + 有序性

• synchronized：可见性（同锁的happens before） + 有序性 + 原子性（复合操作count++) + 互斥

• 双重检查单例（DCL）里必须给 instance 加 volatile，因为第一次 if (instance == null) 是在锁外读的；只靠 synchronized，这个锁外读没有和初始化线程建立 happens-before，可能读到半初始化对象

对比ReentrantLock

• 超时、可中断、公平、多个条件队列时选 Lock

CAS

• 自旋锁 - 空转浪费CPU

• ABA问题 - +时间戳，版本号等单调序列区分

AQS框架

ThreadLocal

• 弱引用Key - 内存泄露

• 应用场景 - MDC，用户信息

• 用完一定 remove()，最好放在 finally 里。

• 每个 Thread 对象内部都有一个 ThreadLocalMap。

• ThreadLocal 作为 key，线程隔离的数据作为 value。

线程池

线程的三种创建方式

• 继承 Thread

• 实现 Runnable

• 实现 Callable + Future/FutureTask/ExecutorService

Runnable 和 Callable 区别？

• Runnable 无返回值，不能抛受检异常；

• Callable 有返回值，可抛异常。

参数与流程

• 参数 - 核心 最大 时间 单位 队列 拒绝策略 线程工厂

• 流程 - 核心 → 队列 → 最大 → 拒绝

• 设置考虑 - 1 + W/C（W-等待，DB RPC Lock 阻塞 IO | C- CPU火焰图 Arthas）

• N = Ncpu × Ucpu × (1 + W/C)。这个公式的推导逻辑是：一个线程并不是一直在用 CPU，它在一个任务周期里只有 C/(W+C) 的时间真正占用 CPU。为了让 CPU 达到目标利用率，就需要更多线程去填补等待时间，于是推导出 1 + W/C 这个放大系数。

• 拒绝策略 - CallerRuns Abort Discard DiscardOldest

• 阻塞队列 - ArrayBlockingQueue可控

• 拒绝时打日志、埋点、告警

• 必要时落库 / 发 MQ / 延迟重试 / 降级补偿

任务异常如何捕获

• execute submit

• 方式 1：任务内部自己 try-catch

• 方式 2：submit + Future.get()

• 方式 3：重写线程池 afterExecute() - 统一日志;统一告警;对 execute/submit 都能兜底

数据结构

• ConcurrentHashMap 并发原理 1.7 Segment 1.8 不支持null key/value，无法从返回值稳定地推断状态，get containsKey中间可put remove

• HashMap非并发安全 | ConcurrentHashMap - put覆盖数据 1.7头插成环

设计模式

• 代理 AOP的动态代理 - cglib jdk

• 策略 支付

• 单例 Bean 双重校验

• 工厂 三层 循环依赖

• 模板 AQS

JDK

• 值传递 引用传递 - 值传递，基本类型，对象引用

• 面向对象 封装 继承|组合 多态

21新特性

异常

受检异常（Checked Exception）

• IOException

• SQLException

• ClassNotFoundException

• try-catch 捕获，或者

• 在方法上 throws 声明继续往外抛

非受检异常（Unchecked Exception）

• NullPointerException

• ArithmeticException

• IllegalArgumentException

IO

• BIO AIO NIO

数据结构

HashMap

• 底层 - 数组 链表 红黑

• put：算 hash 扰动 高 16 ^ 低 16 → 定位桶(n - 1) & hash → 无冲突直接放→有冲突链表追加；当64链表长度8时可能树化→扩容容量一般按 2 倍扩，阈值 = capacity * 0.75

Spring

bean生命周期

1. 实例化

2. 依赖注入

3. Aware 回调

循环依赖

IOC

• 控制反转：对象的创建、依赖组装、生命周期管理不再由你 new，而是交给容器（Spring IoC 容器）完成；你只“声明”依赖关系。

IoC 容器做什么

• 扫描/注册 Bean | 实例化 Bean、注入依赖（DI） | 生命周期回调（Aware、BeanPostProcessor、init/destroy） | 织入增强（AOP 代理通常也发生在创建阶段）

• DI（依赖注入）是 IoC 的实现方式 - 构造器注入 | Setter/字段注入，可循环依赖

AOP

• 把“横切逻辑”（日志、监控、事务、权限、重试、限流…）从业务逻辑里剥离出来，以统一方式织入

• Spring AOP 是基于代理（proxy-based）的运行时 AOP（不是AspectJ编译期织入）。

• 代理方式：基于接口JDK动态代理 基于继承CGLIB

两个常见坑

1. 自调用失效：同一个类内部 this.xxx() 调用不会走代理，@Transactional/@Cacheable 可能不生效解决：拆到别的 bean；或通过 AopContext.currentProxy()

2. final 类/方法：CGLIB 不能覆盖 final 方法（某些增强无法应用）。

循环依赖

• @Lazy延迟拿对象，启动时先不形成硬依赖

• 拆成第三个 Bean，把公共逻辑抽出去，A/B 都依赖 C，不再互相依赖

• 字段/Setter 注入 + allow-circular-references，让 Spring 走三级缓存兜底

自动装配

• 核心链路：
• @SpringBootApplication
• → 包含 @EnableAutoConfiguration
• → 导入 AutoConfigurationImportSelector
• → 加载候选自动配置类
• → 根据条件注解决定是否生效
• → 注册 Bean

• Spring Boot 3
• 候选自动配置类主要来自META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
• 老版本常问的是 spring.factories，要区分开。

• 自动装配的核心不是“自动”，而是条件装配
• 典型条件：
• @ConditionalOnClass
• @ConditionalOnMissingBean
• @ConditionalOnProperty
• @ConditionalOnWebApplication

• 一句话总结
• Spring Boot 自动装配 =“把一堆可能需要的配置类先准备好，再根据当前 classpath、配置项、已有 Bean 按条件决定装不装。”

注解

• 原理

• 常用注解

其他

1. 讲讲 HashMap 的扩容机制，还有 ConcurrentHashMap 的原理和线程安全是怎么保证的？

2. 注解的实现原理是啥？

3. 一个类调用自己内部类上的注解，这个注解会生效吗？

4. 遇到高并发页面访问，有哪些解决方案？

Web

输入 URL 到显示网页，发生了什么

• 浏览器解析 URL → 协议、域名、端口、路径、参数 查缓存

• 浏览器缓存、DNS 缓存、可能还有 Service Worker / HSTS DNS 解析域名 -> IP

• 建立连接发送请求

TCP | UDP

• TCP - 面向连接 | 可靠传输 | 有序 | 有重传、确认、流量控制、拥塞控制 | 面向字节流

• UDP - 无连接 | 不保证可靠 | 不保证顺序 | 没有重传/确认 | 面向报文

OS

进程、线程、协程

• 区别

死锁

• 条件

• 避免

1. 3. 抽象类和接口的应用场景

1. 4. 如何设计银行存取款和转账业务的具体实现，除了加锁还有什么？

2. 5. 本地测试没问题，上线之后出问题了，怎么排查是哪方面的问题

3. 6. 索引优化

1. 🔍 慢查询定位与优化 线上遇到过慢查询吗？怎么定位问题的？怎么优化的？

2. 📂 MySQL索引建立原则 一般你们怎么建Mysql索引，基于什么原则，遇到过索引失效的情况么，怎么优化的？

3. 🔄 自增ID设计 你们建表会定义自增ID吗？为什么？自增ID用完了怎么办？

4. 📝 MySQL写入流程 介绍一下Mysql写入数据的流程，越详细越好。

5. 💾 Redis持久化策略 Redis线上的持久化策略是怎么样的？你们是多久同步一次的？

6. 📊 Redis Set与ZSet Redis的Set有了解过么？底层的数据结构是怎么样的？和Zset有啥差别？

7. ⏳ Redis崩溃与数据恢复 系统在11:05 设置一个值，并给出5分钟的过期时间，系统刚刚Set完之后redis集群崩溃，11:11分系统重启成功，那么Redis中Set的值是否还存在？

8. 📦 消息队列模型对比 项目中用到的消息队列的消息模型是怎么样的？Kafka、RabbitMQ有啥区别么？

9. 🚀 消息队列必要性 项目中这些场景不用队列行不行？会有什么问题吗？

10. 🔍 Kafka高吞吐与一致性 Kafka一致性、可靠性，为什么能做到高吞吐，消息积压怎么处理，如何保证消费有序？

11. 🛠️ RPC调用流程 RPC框架调用的流程是怎么样的？讲一下核心步骤。

12. 🔥 热榜功能设计 一个热榜功能怎么设计，怎么设计缓存，如何保证缓存和数据库的一致性？

13. 🎨 工厂模式实现 写一个工厂模式。

14. 💡 四则运算求值 口述算法，四则运算表达式怎么求值。

16. 前后端如何交互

17. 服务之间如何交互

18. 登录业务怎么做的

19. 高并发怎么做的

20. mysql索引依然很慢怎么办

21. MySQL的一页怎么在Redis里面

22. 从前端url到显示的整个流程

23. jvm回收策略，设置过参数吗？

24. spring的自动装配等注解

25. springAOP

26. 乐观锁分布式锁讲一讲

27. 实习时遇到的项目难点如何解决？

28. 实习时遇到的同事压力甚至刁难如何应对？

29. 库存不足怎么解决的

30. 还有更好的办法吗

31. 分库分表的思路

32. 为什么会有缓存击穿的问题？如何解决

33. ArrayList扩容机制，存在哪些问题

34. contains方法的执行原理

35. 多线程你平时怎么使用

36. mysql清空一张表有几种方式

37. 遍历分页查询一个非常大的表，有几种比较快的

38. 联合索引怎么用

39. 强制使用索引的关键字

40. 乐观锁的sql

41. 用redis做分布式锁一般怎么用

42. hashmap是怎么执行contains的

43. 16 多线程场景下，主线程需要同步所有子线程执行结果需要怎么做

44. 写sql语句的注意事项

45. mysql的事务特性

• ==和 equals 的区别 - 常见字符串操作集合有哪些，有什么区别 - hashmap 底层 - set list map 区别，顺序和能否元素重复 - nio bio aio 区别 - bio：同步阻塞 IO 模型，对 于 IO 读写操作必须阻塞在一个线程中完成 - nio：同步非阻塞 IO 模型，NIO中引入了Channel（通道）和Buffer（缓冲区）的概念。面向缓冲区的读取和写入，都是与Buffer进行交互，多用于高并发高负载的网络 - aio：异步非阻塞 IO 模型，基于事件和回调机制实现，IO 处理后会直接返回不会阻塞，当后台操作结束后，操作系统通知相应线程进行后续处理 - 保证线程安全的集合 - currenthashmap - vector - CopyOnWriteArrayList - 读操作不加锁，写操作加锁 - ConcurrentLinkedQueue - 非阻塞队列，通过 cas 实现线程安全 - BlockingQueue - 实现类ArrayBlockingQueue(容量不可变)、LinkedBlockingQueue（单向链表容量可变）、PriorityBlockingQueue - sleep 和 wait 的区别 - spring 中 bean 的作用域 - 异常的类型 - 1/0 什么异常 ArithmeticException

1. （项目相关）动态刷新线程池有什么需要注意的吗

2. 创建一个线程要多少内存

3. 如果是虚拟线程的话，做动态线程池设置参数要考虑什么

4. Redis怎么设计更新与失效策略

5. 缓存与数据库的一致性设计方案

6. 说一下延迟双删

7. ES 的倒排索引

8. 给定一个关键词进行ES查询，结果不好，怎么优化查询

MQ

消息异常

丢失

项目

• 防止超卖 - 条件更新原子SQL

• 当系统真正去执行“超时取消订单”这个逻辑时，需要校验哪些事情才能最终取消？

• 你的项目中使用了延迟队列来实现订单超时取消，相比于轮询方案，它的优点在哪里？

• 轮询方案除了增大数据库压力外，还有什么缺点？

• 如果用 Redis 实现互斥锁，具体可以使用什么命令？ 使用 SET NX 命令实现分布式锁会有什么弊端？（涉及主从一致性等问题）

snowflake

• 1 bit 符号位

• 41 bits 时间戳差值 69年

• 10 bits workerId 1024节点

• 12 bits sequence 4096/ms/节点

• (timestamp，workerId，sequence）

• 时间不能倒退、节点不能撞号、同一毫秒内序号不能溢出

• 回拨幅度很小，比如 <= 5ms 或 <= 10ms，那就直接等待到 lastTimestamp。

• 回拨较大：直接报错，不发号，报警，把节点摘掉

• 预留回拨标识位

dubbo

• 长连接复用

• 二进制协议/高效序列化

TCC

• 三个幂等 - “重复调用”；空回滚和悬挂 - “乱序调用”。

AI

架构

Transformer

• 自注意力 - 并行计算；长距离建模；

• QKV - 视频查询案例

• d_k - 方差缩放，稳定梯度

MOE

• 少量推理计算增加，增大模型总参

• 门控计算token与各个FFN部分权重决定激活

• 训练损失带负载均衡

训练流程

Pretraining

• 无监督文本块进行next token predication

• 数据清洗与配比

• Scale - 参数 数据量

SFT

• 对话对文本，指令遵循，QA（仅对A loss）

• 关注数据质量 多样性

• 小学习率

DPO

• 不需Reward Model

• CE优化好坏对，对基模KL约束

• 数据靠同prompt好坏配对（网页app要求用户反馈），控制排版与长度

LoRA微调

• 冻结原始权重，只在特定层旁路训练低rank矩阵，降低优化状态显存占用

• 推理部署可以将权重加回去

蒸馏 (Distillation)

• 能力迁移 - 多黑盒蒸馏，调优秀模型API获取生成结果（回答，思维链）作GT来SFT学生模型

推理优化

量化

• 降低存储体积，提高读取速度

KV Cache

• 旧上下文内容的prefill复用

• GQA（多q共享kv）降低显存

• 拆kv为块减少碎片

响应优化

WebSocket与SSE

• SSE - HTTP单向长连接，支持文本流推送

• 可短线重连（Last-Event-ID）

工程实现

回复中断

• 发TCP RST

多租户

• 前缀匹配

断线重连

• 自动重连带上SSE last-event-id

• 一致性哈希打到同一台机器

1. Transformer

• 核心：Self-Attention 建模 token 间关系

• 优势：并行强、长依赖好、可扩展

• 瓶颈：长序列 O(n2)
O(n2)O(n^2)

• 追问点：RoPE、PreNorm、FlashAttention、GQA

2. MoE

• 核心：总参数大，但每个 token 只激活少数 expert

• 一般替换 FFN，不替换 attention

• 难点：Router、负载均衡、all-to-all 通信

• 优势：提高容量；缺点：工程复杂

3. Pretraining

• 核心：海量语料自监督学习，下一个 token 预测

• 重点：数据清洗、去重、tokenizer、scaling law

• 作用：决定模型能力天花板

4. SFT

• 核心：把基础模型变成“会按指令回答”的助手

• 数据比量更重要

• 重点：assistant loss、多轮格式、行为一致性

5. DPO

• 核心：用 chosen/rejected 做偏好优化

• 相比 RLHF/PPO 更简单稳定

• 难点：偏好数据质量、beta、reference model

6. LoRA

• 核心：冻结原模型，只训练低秩增量

• 优点：省显存、省参数、适合多任务

• 拓展：QLoRA

7. 量化

• 核心：低比特表示，省显存和带宽

• PTQ vs QAT

• 不一定一定更快，依赖硬件和 kernel

8. KV Cache

• 核心：缓存历史 K/V，避免重复计算

• 主要加速 decode，不是 prefill

• 难点：显存占用、长上下文、调度管理

9. WebSocket / SSE

• SSE：单向，适合文本流

• WebSocket：双向，适合实时交互

• 流式输出优化的是体验，不是模型本体速度

1. 2. Object类有哪些方法

2. 3. 责任链模式使用场景

3. 4. 线程池怎么使用？

4. 5. 线程池，实现1加到100

项目复盘

核心流程

• 交易主链先用一次性买入 Token + Redis+Lua 做高并发前置预扣

• 本地事务沉淀订单事实，并通过 Outbox + Canal CDC + RocketMQ 顺序消息，把 Redis 预扣收敛成数据库库存与订单状态事实

• CONFIRM 之后分成两条主分支：
• 支付成功链用 Seata AT 统一收敛订单、支付、库存与持仓，再在事务提交后触发上链；
• 超时/取消链用 RocketMQ 事务消息驱动关单与库存回补，最后再靠对账、补偿与限流把整条链治理收口。

流程

入口filter

• 放filter消费一次性token防请求重放（redis lua get del）→ 幂等身份放threadlocal

预扣减

• /trade/buy → 预扣减（redis Hash流水幂等，藏品id作Key，一次token作Field，Value为流水json字符串 String库存 校验流水 校验库存 扣减库存 记录流水）

建单

• 幂等or成功就本地事务建单（订单主表unique(buyer_id, token)，订单流水unique(order_id, stream_type, sourceEventId) ，outbox unique(event_no - 订单id+事件类型)，buyer_id为分片（outbox与订单）键，撞了查单），返回订单id

• CDC回调relay，定时兜底扫，发MQ（orderId顺序键串行重复投递）

确认

• 消费者校验订单状态，create推进/paid补齐confirm

• 插库存流水unique(collection_id, order_id, stream_type)，扣DB可售库存

• 查订单，跑状态机，启事务插订单流水unique(order_id, stream_type, sourceEventId)，CAS改订单状态

支付

• /trade/pay → 插新支付单to_pay unique(biz_type, biz_id)，幂等冲突查单按状态返回 → 支付渠道取url，推进状态paying

• 支付回调 → 支付单paid状态+渠道+渠道流水幂等重复通知（不同的走退款）→ 推进订单支付状态 → 增加已售DB库存 + 建持仓 → 支付单更新状态 → aftercommit上链（定时任务兜底）

退款

• 落推款单 → 调外部渠道 → 回调推进退款单

超时关单（？）

• 定时任务 → 事务消息 → 回补DB 回补Redis

• 限流 → 幂等插unique(biz_id, biz_type, out_biz_id)操作记录 → 调用上链 → 更新操作表状态

• 定时查询 → 重试/成功发MQ → 改持仓状态

选型

• redis + lua 而不是 分布式锁 → 避开 rtt开销 与 服务器阻塞

• 减小redis压力 1.拦无效流量 - 本地缓存标识位 2.库存分片（多个key）3.削峰填谷（网关Sentinel限流，MQ排队）

• 主路径 Canal：NEW/RETRY -> SENDING -> SENT；失败：SENDING -> RETRY/DEAD，并 ack 位点

• fallback 路径：NEW/RETRY/(超时 SENDING) -> SENDING -> SENT/RETRY/DEAD

• NEW 不是“准备发”，而是“这条订单事实已经提交成功，并且存在一条待传播事件”；只要还没确认发到 MQ，它就可以一直停在 NEW。

• SENDING 不是最终业务状态，也不是主路径事务状态；它只是 fallback 补发时的抢占中间态，相当于“这条 outbox 先被某个 worker 领走处理了”。

• RETRY 不是主路径每失败一次都马上改出来的，而是 fallback 补发时明确失败后，才进入 RETRY 并带上下一次重试时间。

关单回补

• redis lua反向操作

• 是否还在售，是否价格无变化

• | 步骤 | 域/动作 | 业务幂等键 | 流水幂等键（落库/落Redis） | 兜底裁决点 | |------|--------|------------|----------------------------|------------| | 0 | 一次性买入 Token 消费（网关/交易入口） | tokenKey | - | Redis GET+DEL（一次性） | | 1 | Redis 预扣（Lua decrease） | buyRequestId（token 中的幂等号） | Redis Hash field = buyRequestId（inventory:stream:{goodsId}） | HEXISTS 判重 | | 2 | 建单（insert-first） | (buyerId, buyRequestId) | trade_order.identifier = buyRequestId | 订单表唯一约束（buyerId+identifier） | | 3 | 建单流水（CREATE） | buyRequestId | (orderId, CREATE, buyRequestId) | 订单流水唯一约束（orderId+type+identifier） | | 4 | Outbox 事件落库（订单事务内） | eventNo = orderId:ORDER_CREATED | outbox.event_no = eventNo | outbox 唯一约束（event_no） | | 5 | relay/CDC 投递 MQ | eventNo + orderKey | 消费侧靠各自流水键吸收 | 重投 + 消费幂等 | | 6 | 扣减可售库存（trySale，DB） | orderId | (collectionId, orderId, TRY_SALE) | 库存流水唯一约束 + 条件更新（saleable>=qty） | | 7 | 订单确认（CONFIRM） | orderId | (orderId, CONFIRM, orderId) | 订单流水唯一约束 + 状态机/条件更新 | | 8 | 生成支付链接（payUrl） | payDedupKey = bizNo+payerId+payChannel | pay_order.pay_dedup_key | 支付单唯一约束（pay_dedup_key） | | 9 | 支付成功回调入账 | payCallbackId 或 payChannel#channelStreamId | pay_order / pay_order_stream | 渠道流水唯一约束 + 状态判断 | | 10 | 推进订单已支付（PAY->PAID） | payChannel#channelStreamId | (orderId, PAY, payChannel#channelStreamId) | 订单流水唯一约束 + 状态机 | | 11 | 最终占用库存与建持仓（confirmSale） | orderId | (collectionId, orderId, CONFIRM_SALE) | 库存流水唯一约束 | | 12 | 链上触发（afterCommit） | outBizId = heldCollectionId 或 orderId | chain_operate_info 幂等键 | 过程表唯一约束（biz_id+biz_type+out_biz_id） | | 13 | 链结果回写持仓（INIT->ACTIVED） | operateInfoId/txHash | held_collection 状态推进键 | 状态机 + 幂等更新 | | 14 | 持仓激活驱动订单完结（FINISH） | heldCollectionId | (orderId, FINISH, heldCollectionId) | 订单流水唯一约束 | | 15 | 超时关单（TIME_OUT） | orderId | (orderId, TIME_OUT, orderId) | 订单流水唯一约束 + 状态机 | | 16 | 用户取消关单（CANCEL） | orderId | (orderId, CANCEL, orderId) | 订单流水唯一约束 + 状态机 | | 17 | 关单回补库存（DB+Redis） | orderId | (collectionId, orderId, CANCEL_SALE) + Redis 回补 Lua 流水 | 库存流水唯一约束 + Lua 幂等 | | 18 | 对账/补偿任务 | diffKey（按场景） | 复用以上各流水键 | 所有补偿动作都必须幂等化 |

改进

• 前端刷新详情页 - 请求一个一次性token

• 下单一次 - 请求一个一次性token - 置灰跳转等待order_id轮询状态

• 移除一次性token在预扣减的分布式锁 → 每个请求都吃一次rtt → 重复请求实际走不到（一次性token在filter处lua脚本get del，不会用到第二次）

• redis预扣减流水 - 原版Field：buyerId + "" + identifier + "" + itemCount;

• itemCount 拼进幂等键，语义被放大

• value 里重复塞 identifier，但没有分片路由键buyer_id → Redis 孤儿预扣对账时，只拿 identifier 查订单会广播

• field = identifier，Redis 幂等裁决最干净

• value 冗余 buyerId，对账可按 (buyerId, identifier) 单点路由

• 和订单唯一键 unique(buyer_id, identifier) 完全收敛

• 不再把 itemCount 拼进幂等键

临时

• 责任链

• 模板方法

• 策略 + 工厂

• 建造者

• Facade（门面）

• 状态机

• 观察者 / 事件监听

• 代理 / AOP

• 过滤器链

• 🎯 核心作答：
1. 先对 key 做 hash 扰动。
2. 如果 table 还没初始化，先初始化。
3. 根据下标找到桶：
• 桶为空：直接插入；
• 桶不空：判断是否同 key；
• 同 key：覆盖旧值；
• 不同 key：链表尾插或红黑树插入。
4. 若链表长度达到树化条件，执行树化。
5. 插入后 size++，超过阈值则扩容。

• 💡 关键概念展开：
• JDK8 扩容是 2 倍扩容。
• 节点迁移时不需要重新算完整 hash，只需要看：
• 留在原索引；
• 或移动到 原索引 + oldCap。

• ⚡ 追问预判：
• 追问1：key 相同是怎么判断的？ -> 先比较 hash，再比较 == 或 equals()。
• 追问2：为什么 JDK8 用尾插？ -> 避免 JDK7 头插在并发扩容下形成环链问题。