06 - 数据中间件与异步任务工程篇

核心定位：MySQL 数据建模、Redis 高性能缓存与分布式协调、消息队列削峰与可靠消费、对象存储全生命周期管理。

Q1: 系统中 MySQL 的核心表结构是如何设计的？请重点说明会话、消息、知识文档、Agent 任务表的结构与索引。

回答（求职者口吻）：
我们在 MySQL 中设计了一套支撑多租户、高并发与严格审计的核心关系模型：

知识库文档元数据表 (kb_document)：
- 字段包含：id, tenant_id, org_id, domain_type (公开/私有/案例), doc_name, file_hash (防重复上传), file_url, publish_date, effective_date, status (待解析/已入库/已废止), ragflow_dataset_id, created_at。
- 核心索引：联合索引 idx_tenant_domain_status(tenant_id, domain_type, status) 支撑业务检索过滤；唯一索引 uk_tenant_hash(tenant_id, file_hash) 防止文件重复提交。
会话与消息表 (chat_session & chat_message)：
- chat_session：id, tenant_id, user_id, title, summary, last_active_at。
- chat_message：id, session_id, user_id, role (user/assistant/system), content, tokens_used, citations (JSON 存储溯源卡片元数据), feedback_status (点赞/点踩), created_at。
- 核心索引：idx_session_created(session_id, created_at DESC) 支撑多轮历史按时间倒序精准高效拉取。
Agent 任务与步骤表 (agent_task & agent_task_step)：
- agent_task：id, tenant_id, user_id, goal, status (PLANNING/RUNNING/SUCCESS/FAILED), total_steps, result_url, total_tokens, duration_ms。
- agent_task_step：id, task_id, step_index, tool_name, input_params (JSON), output_data (JSON/TEXT), status, cost_ms。
- 核心索引：idx_task_step(task_id, step_index) 保证按步骤有序推进。

Q2: 随着会话消息量和审计日志剧增，单表达到数千万级别时，MySQL 层面你们做了哪些优化？

回答（求职者口吻）：
政务问答每天会产生海量问答记录与审计日志。为了保障 MySQL 的高并发读写与长期稳定性，我们采取了“冷热数据分层 + 定期归档 + 读写分离”的组合策略：

热点数据走 Redis 缓存：
- 用户最近 7 天内的活跃会话与上下文消息完全缓存在 Redis 中，90% 以上的小程序端会话读取直接命中缓存，不击穿至 MySQL。
冷热归档与时间分区（Partitioning & Archiving）：
- 针对 chat_message 和 audit_log 这类时间强相关的流水型表，采用按月范围分区（RANGE PARTITIONING BY created_at）。
- 设立自动化归档脚本（通过定时离线任务批量扫描）：将超过 6 个月的历史冷数据归档迁移至专用的离线分析库或大容量列存/ES 中，然后通过 ALTER TABLE ... DROP PARTITION 秒级释放物理磁盘碎片，避免大表 DELETE 产生昂贵的事务锁和 Undo 膨胀。
主从读写分离：
- 业务核心写操作走 MySQL 主库，Web 管理端的复杂报表查询、知识审计日志多条件筛选走只读从库，彻底隔离后台统计查询对前台核心问答的性能影响。

Q3: 详细讲讲 Redis 在你们 AI 系统中的应用场景（除了基础 Token 缓存，还承担了哪些分布式协调与限流任务）？

回答（求职者口吻）：
Redis 在我们系统中扮演了“超高速状态总线与分布式协调中心”的关键角色：

滑动会话与快速上下文缓存（List / Hash）：
- session:{id}:messages 采用 Redis List 存储最近 5 轮高频对话，提供毫秒级的上下文加载，极大缩短 RAG 首字生成延迟。
基于 Redlock / SetNX 的并发互斥锁：
- 会话防并发乱序：SET lock:session:{id} token NX EX 15，防止用户快速连续点击发送导致模型同时生成冲突。
- 文档入库单例消费：保证同一大文件分片解析任务在集群中只有一个 Worker 在处理。
高精度滑动窗口接口限流（ZSet）：
- 针对大模型昂贵 API，使用 Redis ZSet 实现基于时间戳的滑动窗口限流器（如：限制某科室 1 分钟内最多发起 30 次复杂对比请求），有效防范接口刷量和欠费。
Agent 实时进度发布与订阅（Pub/Sub）：
- 调度节点将 Agent 步骤推进状态投递至 Redis Channel，负责维持用户 SSE 长连接的网关节点订阅该 Channel 并即时下发，实现长任务与前端长连接的优雅解耦。

Q4: 在文档上传解析入库、以及 Agent 长流程任务中，为什么必须引入消息队列？如何做异步解耦与削峰填谷？

回答（求职者口吻）：
文档解析与复杂 Agent 对比是典型的“高计算密集、长执行耗时（几秒到数分钟）、易受网络波动影响”的操作。如果采用同步 HTTP 调用，客户端连接会被长时间挂起，服务器线程池迅速被占满耗尽，极易引发服务雪崩。

基于消息队列（RabbitMQ / Kafka）的解耦与削峰设计：
1. 文档解析削峰（Ingestion Queue）：
- 用户在 Web 管理端批量上传 20 份红头公文，Go 后端仅校验文件合法性、计算 MD5、上传 MinIO 后，立即向前端返回“已提交入库任务，正在后台解析中”，并将带有任务 ID 的消息推入 doc_ingestion_queue。
- 独立的解析 Worker 集群根据自身的 CPU/GPU 算力水位，以恒定速率拉取消息，调用 RAGFlow 进行解析与向量化，彻底平滑流量尖峰。
2. Agent 离线报告生成（Agent Task Queue）：
- 针对耗时极长的深度研究报告生成，任务入队后由后台 Worker 推进状态机，执行完成后写回对象存储并发送系统通知，保障 API 网关层的高吞吐与轻量化。

Q5: 异步任务处理中，如何保证消息的可靠投递与消费？面对网络抖动或服务重启，如何做到不丢消息且消费幂等？

回答（求职者口吻）：
为了实现金融级的消息可靠性与幂等性，我们构建了“生产者确认 + 持久化存储 + 手动 ACK + 业务唯一键去重”的端到端闭环：

生产端可靠投递（Publisher Confirm & Local Message Table）：
- 开启 MQ 的 Publisher Confirm 机制，确保消息真正写入 MQ Broker 磁盘并收到 ACK。对于核心任务，配合“本地消息表”模式：在本地 MySQL 事务中与业务数据一同写入 task_event 表，后台补偿线程兜底补发未 Confirm 的消息。
Broker 端持久化：
- 队列与消息均声明为 Durable / Persistent，防止 MQ 节点重启导致内存消息丢失。
消费端手动 ACK（Manual Acknowledgment）：
- 禁用消费端的自动 ACK。Worker 必须在文档全部解析完成、向量索引写入成功且业务状态更新为 SUCCESS 后，才显式向 Broker 发送 basic.ack。若处理途中 Worker 崩溃，MQ 会自动将消息重新分发给其他健康节点（Redelivery）。
消费幂等性保证（Idempotency）：
- 每个任务带有全局唯一 task_id。Worker 在消费前，首先使用 Redis SET lock:task:{id} 1 NX EX 300 抢占执行权；
- 随后检查 MySQL 中该任务的状态。若已经是 SUCCESS 或 PROCESSING，则直接忽略跳过并 ACK，杜绝因网络重试导致同一份文档被重复解析入库多次。

Q6: 对象存储（MinIO / OSS）在系统中承担了什么角色？原始文档、切片与生成的简报是如何做生命周期与安全管理的？

回答（求职者口吻）：
对象存储作为非结构化数据的底层容器，与业务服务紧密协同：

分桶物理隔离（Bucket Isolation）：
- gov-raw-docs：存放用户上传的原始 PDF/Word 文件，设置严格的内网只读权限，严禁公网直连。
- gov-parsed-artifacts：存放 OCR 过程图片、版面分析中间产物。
- gov-export-reports：存放 Agent 生成的最终 Word/PDF 简报。
预签名临时 URL（Pre-signed URL）安全访问：
- 系统中所有文件访问均不直接暴露底层存储路径，而是通过 Go 后端基于 STS/AKSK 生成带有短期时间戳签名（有效期默认 15 分钟）的临时访问 URL。即使链接被外泄，过期后即刻失效。
生命周期自动清理（Lifecycle Rules）：
- 为 gov-parsed-artifacts 和临时导出的中间简报配置 MinIO 生命周期规则，创建超过 7 天的文件自动标记过期并物理清理，有效节约政务私有云宝贵的磁盘存储。

Q7: 针对多租户场景下的缓存穿透、缓存击穿与缓存雪崩，你们系统是如何防御的？

回答（求职者口吻）：
我们在 Redis 接入层建立了体系化的防御工程：

防缓存穿透（Cache Penetration - 查询完全不存在的数据）：
- 空值缓存与短期 TTL：若用户反复查询不存在的文档 ID 或无结果的 Query，将空结果（NULL 占位符）写入 Redis 并设置 60 秒的极短过期时间。
- 布隆过滤器（Bloom Filter）：在网关层前置加载有效 doc_id 和 session_id 的布隆过滤器，未命中的非法 ID 直接拦截，根本不访问底层存储。
防缓存击穿（Cache Breakdown - 热点 Key 突发过期）：
- 对超级热门的公开政策法规（如当年的“政府工作报告”、“最新营商环境条例”），设置逻辑永不过期，由后台定时任务异步刷新，或在回源更新时使用互斥锁（Mutex Lock），只允许一个请求去查库，其余等待。
防缓存雪崩（Cache Avalanche - 大量 Key 同一时间集中过期）：
- 在为 Key 设置过期时间时，必须在基础 TTL（如 2 小时）上附加一个随机扰动值（Random Jitter，如 + 0~600 秒），打散过期时间点，防止整点时刻并发流量瞬时砸向 MySQL。

Q8: 当业务人员在 Web 管理端更新或删除了某份政策文档时，MySQL、Redis、MinIO 与 RAGFlow 向量库的一致性是如何保证的？

回答（求职者口吻）：
分布式环境下跨多个异构系统的强一致性成本极高，我们采用了“最终一致性（Eventual Consistency）+ 补偿重试状态机”的设计：

删除操作标准流转链路：
- 第一步（软删除与状态标记）：业务人员点击删除，MySQL 将该文档记录标记为 status = 'DELETING'（软删除），前端立刻不可见。
- 第二步（失效缓存）：立即清除 Redis 中该文档的元数据缓存及关联知识域版本号（让后续检索跳过）。
- 第三步（异步投递清理事件）：向 MQ 投递 doc_delete_event，由后台清理 Worker 异步调用 RAGFlow 删除对应的向量 Dataset 分块，并删除 MinIO 中的物理文件。
- 第四步（状态闭环）：确认底层存储与向量索引全部清除完毕后，将 MySQL 状态正式置为 status = 'DELETED'。
异常补偿保障：
- 若删除 RAGFlow 向量库时发生网络超时，Worker 自动重试；若重试超限，进入人工告警表。调度定时任务扫描处于 DELETING 超过 30 分钟的异常记录进行二次补偿清理，确保不会残留“幽灵数据”。

Q9: 消息队列在消费超长耗时任务（如超大 PDF 解析需要 3 分钟）时，如何处理心跳超时、消息重复消费与死信队列？

回答（求职者口吻）：
超长任务是消息队列处理中最容易踩坑的场景：

心跳超时与连接断开（Heartbeat Timeout）：
- 很多 MQ（如 RabbitMQ/Kafka）若单条消息处理时间超过了 max.poll.interval.ms 或消费者心跳超时，Broker 会误认为该 Worker 已死，触发 Rebalance 并将消息重新分发给其他 Worker，导致任务被无限重复并发执行。
- 解法：我们将“MQ 消费协程”与“实际解析工作协程”解耦。消费协程仅负责接收消息并下发给内部工作池，同时独立维持与 MQ 的长连接心跳；或者对超大文件预先在前端/网关层按页数切片，拆分为多个小任务并行投递。
重试次数上限与死信队列（Dead Letter Queue - DLQ）：
- 若某份损坏的 PDF 导致解析引擎每次都抛出不可恢复的 Fatal 异常，设置最大重试次数为 3 次。
- 超过 3 次失败后，消息被路由至专用的死信队列（DLQ），防止损坏任务永久阻塞正常消费队列。运维人员可在 Web 管理端查看死信任务的错误堆栈并人工介入。

Q10: 生产环境中，Redis 和 MySQL 的连接池参数是如何调优的？遇到过连接耗尽问题吗？

回答（求职者口吻）：
连接池是后端吞吐量的生命线。我们在实战中针对高并发场景做了细致调优：

MySQL 连接池（GORM / database/sql）调优：
- SetMaxOpenConns(100)：根据 MySQL 实例规格与后端 Pod 数量综合计算，防止总连接数超过 MySQL 的 max_connections 导致 Too many connections 报错。
- SetMaxIdleConns(20)：保持适当的空闲连接，避免高频创建和销毁 TCP 握手开销。
- SetConnMaxLifetime(1 * time.Hour)：设置连接最大生命周期，防止内网防火墙或负载均衡器静默切断长连接导致应用层拿到已关闭的坏连接（broken pipe）。
Redis 连接池（go-redis）调优：
- PoolSize(120)，MinIdleConns(20)，IdleTimeout(5 * time.Minute)。
真实排障经验（连接耗尽案例）：
- 曾在线上遇到过因第三方大模型接口响应缓慢，导致业务 Goroutine 挂起，且在事务内进行了远程 HTTP 调用，长事务未提交导致 MySQL 数据库连接池被迅速占满。
- 排查与根治：通过 pprof 排查 Goroutine 堆栈，发现是代码规范漏洞。我们立即重构：坚决推行“严禁在数据库事务中进行任何网络 RPC 或外部 HTTP 调用”，所有外部调用必须在事务开启前或提交后完成，彻底解决了连接池耗尽问题。

Q11: 简历中在网关管控项目中使用了 PostgreSQL，而在政务小灵通中使用了 MySQL，你们在技术选型时是如何权衡 PostgreSQL 与 MySQL 的？

回答（求职者口吻）：
我们在两个不同业务形态的项目中分别选型 PostgreSQL 与 MySQL，是基于各自的数据特征与查询模式做出的深度架构匹配：

为什么在边缘网关与控制面项目选型 PostgreSQL：
- 复杂半结构化策略与 JSONB 索引（GIN Index）：网关的路由策略、设备上报的异构网络探针数据包含大量动态嵌套属性。PostgreSQL 的 JSONB 是二进制解析存储，支持创建 GIN（通用倒排索引），能够以 $O(1) \sim O(\log N)$ 极速查询嵌套字段（如 WHERE probe_data @> '{"loss_rate": 0.05}'），而 MySQL 的 JSON 处理能力和索引灵活性明显弱于 PG；
- 时序与空间地理数据扩展（TimescaleDB / PostGIS）：边缘探针涉及海量时间序列数据，PG 配合 TimescaleDB 扩展插件原生支持超表（Hypertables）自动按时间分区与连续聚合计算；同时 PostGIS 插件极大简化了分支网关的地理坐标拓扑计算。
为什么在政务 AI 应用中以 MySQL 为主：
- 政务传统系统对 MySQL（信创环境如 TDSQL、OceanBase、达梦对 MySQL 兼容度高）的运维生态成熟，政务会话与业务模型是标准的固定结构关系型数据，使用 MySQL 结合 GORM 开箱即用，团队上手和交付阻力最小。

Q12: 深入底层原理：PostgreSQL 与 MySQL (InnoDB) 在 MVCC 多版本并发控制与更新机制上有何本质区别？PG 的 Vacuum 机制是做什么的？

回答（求职者口吻）：
PostgreSQL 和 MySQL 虽然都支持 ACID 和 MVCC，但底层物理实现哲学截然相反：

InnoDB（回滚段 Undo Log 模式）：
- 原地更新（In-Place Update）：数据页中只保留最新版本的记录行。旧版本数据被剥离并写入独立的 Undo Log（回滚段） 形成单向版本链；
- 优势：没有行碎片与写放大，主表体积紧凑；缺点是长事务会导致 Undo Log 空间膨胀，大事务回滚开销较高。
PostgreSQL（追加多版本 Tuple 模式 - Append-Only）：
- 多版本行内存储（Multi-Tuple Storage）：当执行 UPDATE 时，PG 并不原地修改，而是直接在数据页中插入一条全新的行记录（Tuple），并在旧 Tuple 的元数据头中记录 t_xmax（删除该行的事务 ID），将旧行标记为死元组（Dead Tuple）；
- 核心痛点与 VACUUM 机制：
- 大量更新和删除会在表中产生大量死元组，造成“表膨胀（Table Bloat）”并浪费磁盘与索引扫描性能；
- VACUUM（垃圾回收器）：后台的 autovacuum 守护进程定期扫描并清理死元组占用的空间，将空间标记为空闲以供后续新行复用；VACUUM FULL 则会对表进行物理重写并锁表释放操作系统磁盘。