Daily Study

更新: 4/1/2026 字数: 0 字 时长: 0 分钟

Daily Plan

#todo

• 写博客
• [ ]

八股回顾

一些问题1

Go 语言基础：

• GMP 模型调度原理（尤其是 P 和 M 的关系，Goroutine 泄漏怎么排查）。
• Channel 的底层实现，有缓冲和无缓冲的区别。
• Context 的使用场景（超时控制、链路追踪）。

数据库与中间件：

• MySQL 索引失效场景、B+树结构、事务隔离级别（MVCC 原理）。
• Redis 跳表（SkipList）、持久化（RDB/AOF）、分布式锁实现（Redlock）。
• Kafka 消息积压怎么处理？如何保证顺序消费？

网络与系统：

• TCP 三次握手/四次挥手状态机（TIME_WAIT 状态过多的原因及危害）。
• HTTP/2 和 HTTP/3 (QUIC) 的区别（因为 PCG 涉及视频业务，QUIC 很重要）。
• Linux 内核态/用户态的问题，eBPF 原理

一些问题2

针对腾讯实习经历（LLM Agent + 后端）

• 架构设计：请在白板上画一下你搭建的Agent框架架构图。MCP（Model Context Protocol）Server集群是如何设计的？它是如何实现“可插拔”的？
• 状态管理：LangGraph是基于图的状态机，你是如何持久化Agent状态的？如果服务重启，Agent的执行流如何恢复？
• 工程化难题：LLM推理通常延迟较高，作为后端服务，你是如何处理超时（Timeout）和并发请求的？有没有做流式输出（Streaming）？
• 效果评估：你提到“单告警研判准确率90%”，这个指标是如何定义的？Bad Case是如何分析和回流优化的？
• CoT与ReAct：请具体举一个例子，说明Plan-ReAct是如何分解一个复杂的AKSK告警分析任务的？

2. 针对项目经历-2（校园文章协同平台 / Go-zero） 微服务治理：为什么选择Go-zero框架？它的RPC调用链路（zRPC）底层是基于什么实现的？（考察gRPC, Protobuf）。

高并发场景：描述一下你所谓的“高并发场景”具体QPS是多少？在文章点赞或阅读量更新时，如何解决数据库的写压力？（考察Redis缓存策略、Write-back/Write-through、消息队列削峰）。

缓存一致性：当文章内容更新时，如何保证Redis和MySQL的数据一致性？（考察延时双删、Binlog订阅等）。

消息队列：Kafka在项目中具体起什么作用？如果Kafka消费积压了怎么办？如何保证消息不丢失？

3. 针对获奖经历-4（eBPF 容器异常检测） 面试官旁白：大数据平台非常看重底层性能监控，eBPF是加分项。

原理：简单介绍一下eBPF的工作原理。它和传统的Linux内核模块有什么区别？为什么说它更安全、高效？

数据采集：你是通过eBPF hook了哪些内核函数（Syscalls）来构建“业务画像”的？

性能开销：在容器环境下大规模部署eBPF Agent，对宿主机的CPU和内存开销有多大？有没有做过压测？

第二部分：基础技术栈（必问）

1. Go 语言基础 GMP模型：请详细讲一下Go的GMP调度模型。如果一个Goroutine发生了系统调用阻塞，M和P会发生什么？

Context：Context在Go后端开发中有什么作用？它是如何实现跨Goroutine的超时控制和取消的？

内存管理：Go的GC（垃圾回收）是什么算法？三色标记法可能会遇到什么问题（STW, 写屏障）？

Channel：Channel的底层数据结构是什么？向一个已经关闭的Channel发送数据会发生什么？

2. 数据库与存储 (MySQL & Redis) 索引：MySQL的B+树索引为什么比B树更适合做文件索引？聚簇索引和非聚簇索引的区别？

事务：解释一下MVCC（多版本并发控制）是如何实现的？它解决了什么隔离级别下的问题？

Redis：Redis的跳表（SkipList）用于什么场景？为什么ZSet不用红黑树而用跳表？

大数据关联：了解过列式存储（如ClickHouse/HBase）和行式存储（MySQL）的区别吗？（针对大数据方向的衍生问）。

3. 网络与操作系统 网络协议：HTTPS的握手过程是怎样的？RSA和ECDHE算法在密钥交换时有什么区别？

IO模型：什么是IO多路复用？epoll的水平触发（LT）和边缘触发（ET）有什么区别？Go的Netpoller是基于哪种模式？

第三部分：大数据与系统设计（方向匹配） 面试官旁白：虽然你之前的经历偏安全和AI，但你现在投递的是大数据平台，需要展示你对数据流转的理解。

场景题：假设腾讯每天有千亿级的日志数据需要写入，要求低延迟且不丢失，你会怎么设计这个数据接入网关？（考察Kafka, 分区策略, 批处理）。

分布式：如何理解分布式系统中的CAP理论？在你的RAG项目中，向量数据库的数据一致性是如何保证的？

流处理：你的告警降噪系统（项目1）做到了“百万级告警聚合”，这是离线处理还是实时流处理？如果是实时流，如何处理乱序数据（Watermark）？

一些问题3

问题1

问：你的校园文章平台提供了点赞和评论功能。在面对‘爆款文章’突发极高并发点赞时，你的MySQL表结构是如何设计的？如果直接写MySQL扛不住，你引入了Redis，那么如何保证Redis和MySQL之间点赞数据的一致性？

答：面对高并发点赞，直接写 MySQL 会造成严重的行锁热点竞争。我的核心思路是Redis 挡峰 + MQ 异步落库。前台业务直接和基于 Set 数据结构的 Redis 交互，保证低延迟；后台利用 Kafka 极高的吞吐量吸收峰值，消费者通过聚合将成千上万次的零散点赞，合并为低频的批量 DB 写入操作。这样既保证了系统的高可用和响应速度，又通过 Kafka 的可靠投递机制实现了数据的最终一致性。

问： 前台业务直接和基于 Set 数据结构的 Redis 交互，保证低延迟。由于redis是单线程的，如何实现高并发情况下，仍然低延迟，不会阻塞吗

答：Redis 在高并发下不阻塞，是因为它采用了基于 epoll 的 I/O 多路复用模型，消除了网络等待；并且我们的点赞操作（SADD、SCARD）都是基于内存的 O(1) 极速指令，CPU 执行极快。同时，为了保护这个单线程，我们在工程实现上会严格规避 SMEMBERS 这种耗时指令，并对爆款文章的 BigKey 进行 Hash 打散分片，确保单线程永远处于高效的流转状态。

问题2

问：MySQL是如何解决不可重复读（幻读）问题的？请详细描述一下MVCC的实现原理（要求讲清隐藏字段 trx_id、roll_pointer 以及 Read View 的生成机制）。

答：MVCC 的底层是通过数据行的隐藏字段（trx_id、roll_pointer）和 Undo Log 构建的版本链来实现的。在执行查询时，系统会生成一个 Read View。通过比对记录版本的 trx_id 和 Read View 中的活跃事务列表，来决定哪个版本的数据对当前查询可见。在 RR 隔离级别下，事务只在首次查询时生成一次 Read View，后续复用，从而保证了每次读到的数据一致，解决了不可重复读问题。而对于幻读问题，MySQL 是通过 MVCC 解决快照读的幻读，通过 Next-Key Lock 解决当前读的幻读。

问：详细解释一下脏读，可重复读和幻读，RC是如何解决脏读的？

答：

• 不可重复读的重点在于数据被修改（UPDATE/DELETE），在同一事务中读到了不同的值；而幻读的重点在于数据行数的变化（INSERT），在同一事务中读到了之前没见过的‘新行’。两者侧重的 SQL 操作不同，因此底层解决这两种异常所用的锁机制也是不同的（行锁 vs 间隙锁）
• 在 MySQL 的 InnoDB 引擎中，RC（读已提交）隔离级别是通过 MVCC（多版本并发控制） 来解决脏读的。具体的机制是：在 RC 级别下，事务中的每一次快照读（SELECT）都会生成一个最新的 Read View。当查询到某行数据时，系统会提取这行数据隐藏字段中的 trx_id，并与当前 Read View 中的活跃事务列表（m_ids）进行比对。如果发现该 trx_id 属于未提交的活跃事务，说明该数据尚未提交，对当前查询不可见。此时，MySQL 会顺着 Undo Log 的 roll_pointer 回溯，直到找到一个已经提交的历史版本数据并返回。这样就从根本上阻断了读取到未提交数据的可能，彻底解决了脏读。

问：线上系统突然出现大量的慢查询报警，导致数据库CPU飙升，请详细描述你的排查思路和 EXPLAIN 的核心字段。

答：面对突发的 CPU 飙升，我的第一反应是保可用，通过 SHOW PROCESSLIST 找出长时间霸占资源的慢查询并 KILL 掉，或者在微服务网关层做暂时限流。 稳住阵脚后，通过慢查询日志提取高频肇事 SQL，拿到线下用 EXPLAIN 分析执行计划。我主要会看四个指标：首先看 type 是否退化成了 ALL（全表扫描）；其次看 key 确认索引是否因为最左前缀原则、函数计算或隐式转换而失效；接着看 rows 评估扫描量；最后重点盯防 Extra 字段，如果出现了 Using filesort 或是 Using temporary，说明引发了极其消耗 CPU 的内存排序或临时表操作，必须通过调整业务逻辑或优化联合索引来消除它们。索引下推2025-08-26

问题3

问：Redo Log 与 Undo Log： “当你在平台上成功发布了一篇文章（提交事务），MySQL突然宕机了。重启后，MySQL是如何通过日志恢复刚才那条文章数据的？（要求讲清WAL机制、两阶段提交）”

答：当文章成功发布遇到宕机时，MySQL 主要依靠 Redo Log 的前滚能力来恢复未落盘的脏页数据，保障事务的持久性（Crash-safe）。为了确保 InnoDB 的 Redo Log 和 Server 层的 Binlog 数据一致，MySQL 采用了两阶段提交（2PC）。重启恢复时，系统会检查事务的状态：如果 Redo Log 已经是 commit 状态，直接恢复；如果处于 prepare 状态，则去核对 Binlog 是否完整。如果 Binlog 完整则继续提交恢复数据，若不完整则通过 Undo Log 进行回滚。这种机制确保了无论是单机恢复还是主从架构，文章数据都不会产生不一致

问题4

校园平台初期可能数据量不大，但如果推广到全国高校，文章表和评论表达到了单表亿级的数据量，你会如何进行分库分表？分片键（Sharding Key）应该怎么选？分表后怎么解决多维度的查询问题（比如既要按文章查，又要按作者查）

答：面对单表亿级的数据，我的整体策略是：

• 首先，在水平分表之前，一定要先做垂直拆分（将用户库、文章库、评论库在物理实例上隔离开）。然后，针对数据量最大的文章表和评论表进行水平拆分
• 评论表直接以 article_id 作为 Sharding Key。
• 文章表采用分片基因法，将 author_id 的路由信息嵌入到 article_id 中，一套物理分片完美解决双向精准查询。具体做法：
  1. 假设我们按 author_id % 64 进行分表（共有 64 张表）。这意味着 author_id 的二进制最后 6 位决定了数据落在哪张表。这最后 6 位就是“分片基因”。
  2. 在生成 article_id 时（例如使用 Snowflake 雪花算法），我们强制将生成出来的 ID 的最后 6 位，替换成 author_id 的最后 6 位。
  3. 结果： 此时，不论你是对 author_id 取模，还是对 article_id 取模，计算出的分表编号完全一模一样
• 对于超越主键的复杂条件检索，我会借助 Binlog + Kafka 将数据同步至 Elasticsearch，利用异构架构彻底解决多维查询痛点。

问题5

如果引入了主从架构应对高并发读，主库写完文章后，用户立刻刷新页面却看不到自己刚发的文章（主从延迟），在业务层面和数据库层面分别有哪些解决方案？

你在第三个项目中提到了‘日志分析与存储’，如果是百亿级别的海量安全监控日志，你会选择存放在MySQL吗？如果不选，为什么？（引申到ClickHouse、ElasticSearch或HDFS等大数据的对比）

一些问题4

HTTPS/TLS： 微信支付涉及资金，安全是第一位。请详细说明 TLS 1.2 的握手过程。对称加密和非对称加密分别在什么时候使用？

TCP： 为什么会出现 TIME_WAIT 状态？如果服务器出现大量 CLOSE_WAIT 是什么原因？

超时处理： 在支付链路上，如果调用下游接口超时，你是重试还是报错？重试可能导致重复扣款，如何解决？（考察：全局唯一序列号/幂等性）。

GMP 模型： 详细解释 P 的作用，以及 M 陷入系统调用时，P 会发生什么（Hand Off 机制）。

GC： 三色标记法和混合写屏障（Hybrid Write Barrier）的原理。

内存逃逸： 哪些情况会导致变量逃逸到堆上？为什么频繁的逃逸会影响性能？

Channel： 向一个已关闭的 Channel 发送数据/读取数据会发生什么？

MySQL 事务： 支付场景常用 Repeatable Read 隔离级别，它是如何通过 MVCC 和锁解决不可重复读和幻读的？

Redis 分布式锁： 如何实现一个可靠的分布式锁？如果 Setnx 成功后进程挂了怎么办？（过期时间 + Lua 脚本）。

分库分表： 微信支付的交易量级肯定需要分库分表，你会按什么维度分？如何解决跨库查询问题？

一些问题5

leader选举与网络分区

高频问题： Raft如何避免脑裂（Split-Brain，非常见词汇解释：集群因网络故障分裂成多个互相无法通信的区域，导致可能同时选举出多个Leader的现象）？如果出现非对称网络分区，你的系统怎么处理？

经典例子补充： 面试官很可能会用 Etcd（目前最热门的基于Raft的分布式键值存储系统，广泛用于K8s的元数据存储）作为例子，探讨Etcd中的 PreVote 机制如何防止被隔离的节点在网络恢复后引发不必要的重新选举，从而扰乱集群稳定性。

日志复制与状态机

高频问题： 客户端发起一次Write请求，到最终返回Success，Raft集群内部经历了哪些完整的网络与磁盘I/O步骤？如果在这个过程中Leader宕机，数据会丢失吗？

进阶方向： 解释日志截断、冲突解决机制，以及如何实现日志的 Compaction（压缩合并，非常见词汇解释：将历史遗留的冗余或过期日志进行清理和快照生成，以释放磁盘空间并加速节点重启恢复）。

读写性能优化

高频问题： Raft是强一致性协议，所有的读请求如果都走Leader节点的Raft状态机，性能会很差。你是如何优化读性能的？

经典例子补充： 探讨业界标准的读优化方案，例如 ReadIndex 或 Lease Read（租约读）。在Etcd中，ReadIndex机制允许节点在提供读服务前，先向Leader确认自己是否拥有最新的数据，从而在保证线性一致性的同时跳过繁重的日志落盘流程。

存储引擎选型

高频问题： 你的单机KV引擎底层用了什么数据结构？为什么不用B+树而可能选择 LSM-Tree（Log-Structured Merge-Tree，非常见词汇解释：一种专为高吞吐写入设计的底层数据结构，通过将离散的随机写操作在内存中积攒后顺序追加到磁盘，大幅提升写入性能）？

经典例子补充： RocksDB / LevelDB 是目前工业界最经典的单机KV存储引擎。可以对比说明RocksDB是如何通过MemTable、SSTable和多层级Compaction来平衡读放大、写放大和空间放大的。

数据持久化

高频问题： 什么是 WAL（Write-Ahead Logging，预写式日志，非常见词汇解释：数据库在真正修改内存数据前，先将操作以日志追加的形式写入磁盘，以保证系统崩溃时可以通过重放日志恢复数据）？你如何保证WAL的高效落盘（fsync的调用时机）？

GMP调度模型

高频问题： Go的协程调度机制是怎样的？如果你的KV存储中，某个Goroutine在进行耗时的磁盘I/O，会不会阻塞其他协程？

内存管理与GC

高频问题： Go的垃圾回收（GC）采用了什么算法？在构建高吞吐的KV存储时，如何减少GC对系统Latency（延迟）的抖动影响？

实战延伸： 解释 sync.Pool 的原理以及如何在网络包解析或高频对象分配场景中复用对象，以降低堆内存分配压力。

内核机制与网络协议

高频问题： 简单介绍一下 eBPF（Extended Berkeley Packet Filter，非常见词汇解释：一种允许在不修改内核源码的情况下，在Linux内核空间安全、高效地运行用户定义程序的沙盒技术）的工作原理。相比于传统的内核模块（Netfilter/Hook），它有哪些性能优势？

网络I/O模型： 解释 Epoll（I/O多路复用技术）的底层机制（红黑树+双向链表），以及水平触发（LT）和边缘触发（ET）的区别。

性能榨取

高频问题： 在进行网络数据传输或文件落盘时，如何利用 零拷贝（Zero-copy，非常见词汇解释：计算机执行操作时，CPU不需要先将数据从某处内存复制到另一个特定区域，常利用 sendfile 或 mmap 技术节省CPU时钟周期和内存带宽）提升性能？

经典例子补充： Kafka 之所以能达到极高的网络吞吐，关键在于它底层大量使用了操作系统层面的 sendfile 零拷贝技术，将磁盘数据直接推送到网卡缓冲区。

缓存与一致性

高频问题： 引入Redis后，如何保证MySQL与Redis之间的数据一致性？如何处理缓存穿透、缓存击穿和缓存雪崩？

高并发下的解耦与削峰

高频问题： 你的项目中使用了Kafka，Kafka如何保证消息的不丢失和严格顺序消费？

一些问题6

你的系统将每日百万级别告警降噪率做到 95.60%。在实际工程部署中，如何解决海量并发告警写入时的性能瓶颈？

基于 Raft 的分布式 KV 数据库中，如何解决网络分区（Network Partition）导致的脑裂（Split-Brain）问题？Raft 的日志复制过程是如何保证强一致性的？

详细讲述基于 eBPF 的容器异常检测 Agent 的实现过程。eBPF 程序是如何挂载到内核函数的？如何处理 eBPF 收集到的数据传递给用户态程序的性能消耗问题？

腾讯实习中基于 LangGraph 和 MCP 开发了 AKSK-Agent。如果滴滴要利用大模型进行“线上故障根因定位”，由于线上系统日志和拓扑结构极其复杂，你会如何设计这个 Agent 的流转图和工具调用策略？

一些问题7

在你的“校园文章协同平台”中，如果短时间内有大量点赞请求，你如何使用Go的 sync.Mutex 或 channel 来控制并发，避免数据竞争（Data Race）或Goroutine泄露？

MySQL：InnoDB存储引擎的B+树索引结构是怎样的？什么是聚簇索引和非聚簇索引？如果发生慢查询，你如何通过 EXPLAIN 分析执行计划并进行调优？

Redis：详细说明缓存穿透、缓存击穿和缓存雪崩的区别及应对策略。

Kafka：在你的日志收集或系统异步化场景中，如何保证Kafka消息的顺序性？如何防止消息丢失或重复消费？

你使用了Go-zero框架，请描述该框架内部是如何实现服务发现与负载均衡的？高并发场景下，如何保障系统的可用性？

• 经典例子：面对类似“双11”或突发热点文章的流量洪峰，通常需要使用令牌桶（Token Bucket）或漏桶（Leaky Bucket）算法在API网关层进行限流。

一些问题8

Agent 架构设计：你在腾讯实习中提到的 LangGraph 解决的具体痛点是什么？相比于简单的 Sequential Chain，Graph 在处理告警研判时的优势在哪里？

策略推理与执行：在自动化渗透测试中，如何保证 LLM 生成的攻击指令（如 SQLi、XSS）的准确性？如何处理 LLM 的幻觉（Hallucination）问题？

你的“三层递进式”降噪系统中，L1 传统降噪（规则/统计）与 L2/L3 大模型层的分工界限在哪里？如何权衡误报率（FP）与漏报率（FN）？

MCP (Model Context Protocol)：解释一下你构建的 MCP Server 集群是如何实现工具可插拔的

流量分析协议：熟悉哪些网络协议？如何从加密流量（HTTPS/TLS）中识别异常特征？

eBPF 深度应用：你在操作系统大赛中做的 eBPF 容器异常检测 Agent，具体监控了哪些系统调用（Syscalls）？如何定义“异常行为”的基准？

一些问题9

闪购业务的核心技术难点是：瞬时超高并发流量、绝对不能超卖、极端的防刷与限流。现场设计一个扣库存的方案？闪购开始瞬间，如果有千万级请求同时访问同一个商品详情页（Hot Key热点数据），如何防止 Redis 甚至单点网关被击穿？

买菜（生鲜O2O）场景的业务复杂性，买菜业务虽然瞬时并发不如闪购，但其业务链路复杂度极高。LBS（基于位置的服务）与路由，如何高效查询用户周边 3 公里内的可用前置仓？了解 GeoHash 算法原理（将二维经纬度转换为一维字符串进行前缀匹配索引），以及 Redis 的 GEO 数据结构底层实现（本质上是 ZSet）

用户下单、仓库分拣、骑手配送，这个长链路中如果某一步失败（如骑手超时未接单），如何保证库存和资金的回滚？深入复习分布式事务。在跨微服务（订单服务、库存服务、支付服务）场景下，掌握基于 Kafka 的可靠消息最终一致性方案或 TCC（Try-Confirm-Cancel）模型。

你提到用 Kafka 异步落库创建订单。如果消费者拉取了消息，处理到一半 Go 进程 Crash 了，会发生什么？（考察 Offset 提交时机：自动提交 vs 手动提交的坑）。

如果因为网络抖动，同一条扣减库存的消息被消费了两次，怎么保证不重复扣减？（考察消费端幂等性设计，如利用 MySQL 唯一索引或 Redis 防重表）。

Kafka 为什么这么快？（考察对 Zero-Copy 零拷贝、顺序写磁盘、PageCache 的理解）。

既然 map 不安全，那 sync.Map 是如何实现高并发安全的？（考察空间换时间、read map 和 dirty map 的双缓冲分离设计）。

如果你需要在 10 个并发协程中，只要有任意一个协程报错返回了 Error，其他 9 个协程立刻取消执行，你该怎么写？（考察 context.WithCancel 的实战运用，以及 errgroup 扩展包）。

业务中遇到过死锁（Deadlock）吗？Go 中排查死锁或性能瓶颈（CPU 飙升）除了看代码，还会用什么工具？（必须掌握 pprof 的火焰图分析）。

一些问题10

一、 架构全局与并发控制

1. 项目介绍与链路流转

原题：介绍一下你的项目，说一下流程

定制拷问：请分别简述“校园文章协同平台”的核心发布/展示链路，以及你的“分布式 Raft KV 数据库”接收到一次 Client Write 请求后，底层发生 Leader 选举和日志复制的完整流转过程。

2. 核心并发冲突处理

原题：一人一单超卖问题怎么解决的？

定制拷问：在协同平台中，如果多个人同时尝试对同一篇热门文章进行修改保存（并发编辑冲突），或者瞬间涌入一万人对同一篇文章点赞（点赞并发与数据防丢），你在底层是如何保证数据准确性的？引入了什么锁机制或版本控制？

二、 Redis 深度挖掘 (Key 碰撞、热点与分片) 3. 缓存 Key 空间隔离

原题：你说到 redis 用用户 id 做 key，那我多个业务都需要用这个用户 id 怎么办？

定制拷问：在文章平台中，如果既要缓存用户的“基本资料”，又要缓存用户的“点赞列表”和“草稿箱”，这些都强依赖 user_id。在 Redis 中你的 Key 命名规范是如何设计的？底层又是如何实现物理或逻辑隔离的？

4. 针对特定场景的数据结构选择

原题：除了用用户 id 做 key 还有什么方式？

定制拷问：针对“某篇文章的全部点赞用户列表”这种场景，除了把 user_id 放在 Key 里，你会用什么 Redis 数据结构（如 Set、ZSet、Hash）来存储？为什么选这个？

5. 爆款文章的热点 Key (Hot Key) 问题

原题：如果你用业务做 key 用户 id 存入 set 集合，那么此时有一个热点 key 你怎么解决？

定制拷问：假如某位校园红人发了一篇爆款文章，这篇文章的点赞 Set 集合瞬间成了超级热点 Key。不仅 QPS 极高，而且单 Key 体积极大（BigKey）。你怎么预防和解决网关层或 Redis 节点的网卡被打满？

6. 分片集群应对单 Key 写瓶颈

原题：你这里都是写数据可以用主从复制吗... 分片的话你这里 key 只有一个怎么分片呢？

定制拷问：对于上面那个爆款文章的点赞 Set，如果在 Redis Cluster 分片集群下，由于它只是同一个 Key（如 article:999:likes），根据哈希槽（Slot）路由，千万级的并发写压力依然只会落在一个固定的 Redis Master 节点上。你怎么把单一 Key 的写压力打散到多个分片上？（提示：Key 拆分打散机制）。

三、 微服务消息队列与异常流转 7. 核心业务流转设计

原题：你的下单流程是怎么样的？

定制拷问：详细描述一下平台中“发布一篇长文章”的底层完整流程？（要求涵盖微服务鉴权、写库、写缓存、同步/异步消息通知等细节）。

8. 异步消息的可靠性保障

原题：你判断下单资格以后直接返回下单成功，可是如果你消息发送出去消费者因为意外消费失败怎么办呢？

定制拷问：发布文章时，假设你先返回前端“发布成功”，然后通过 Kafka 异步发送消息给下游去做敏感词审核或全文 ES 索引构建。如果下游消费者拿到消息后发生了 OOM 崩溃导致消费失败，这篇文章的索引不就丢失了吗？在 Go-zero 架构下，你怎么保证这种异步流程的最终一致性和防消息丢失？

四、 数据库架构、海量数据与调优 9. 物理外键的争议

原题：外键的作用？

定制拷问：你的文章表（包含 author_id）和用户表之间，有没有建立真实的物理外键（Foreign Key）？在互联网大厂的高并发规范中，为什么通常严禁使用物理外键？

10. 海量流水表的设计与风险

原题：这样设计有什么问题，如果有一亿用户，每个用户一亿流水，这么设计好吗，有数据泄露的风险嘛？

定制拷问：假设你的平台做大了，文章的“阅读流水表”（记录谁在什么时间读了什么文章）暴增到百亿级别。你当初的单库表设计有什么致命隐患？如果要做分库分表，分片键怎么选？

11. 微服务架构下的数据聚合

原题：有外键还需要 join 嘛？

定制拷问：在 Go-zero 中，用户服务和文章服务是分离的。当你想展示“文章列表（带上作者的最新头像和昵称）”时，跨物理库了，显然不能用 JOIN。你的代码是怎么高效地把这两部分数据拼装起来的？

12. 海量数据查询与深度翻页

(原面经中被面试官用“分页查询”怼了，其实面试官是在考察对基础方案的敏锐度，但真正的高级考点在分页之后)

原题：如果查很多很多条数据很慢怎么办？

定制拷问：如果在管理后台查询某个热门标签下的所有文章。最基础的 LIMIT offset, size 分页在翻到第 10 万页时（深度翻页问题），查询效率依然会直线下降。在底层原理上这是为什么？你应该用什么机制（如游标、延迟关联）来优化？

13. 索引失效与底层回表

原题：如果走索引了，查询数据量依然很大，效率依然很低怎么办？

定制拷问：你在文章表给 created_at（发布时间）加上了普通索引，想拉取最近半年的所有文章，发现 EXPLAIN 显示走了索引但依然很慢。你觉得 MySQL 优化器在底层执行时，什么操作消耗了绝大部分的磁盘 IO？（考虑回表、覆盖索引缺失或 Buffer Pool 命中率低）。

14. 极端数据的流式处理

原题：假如查出几个 G 的数据怎么办？

定制拷问：运营要求导出一份包含 500 万条用户行为日志的明细报表。你在 Go 里面如果直接 SELECT * 会查出几个 G 的数据。除了把 Go 进程的内存撑爆引发 OOM，这会对 MySQL 底层产生什么致命影响？你应该用什么技术手段（如流式查询/游标读取）来保护应用和数据库？

15. 分布式并发拦截

原题：你的分布式接口去重为什么要用 setnx 而不是直接用 sql 实现？

定制拷问：由于校园网卡顿，用户手抖连续点击了 5 次“发布同一篇协同文章”。在微服务网关层，你为什么要用 Redis 的 SETNX 做分布式防重处理，而不是直接让请求打到 MySQL，利用数据库的“唯一联合索引”去拦截冲突？