蚂蚁后端一面：多级缓存、库存容灾与消息选型
本场面试题
- 多实例本地缓存、Redis 与数据库怎样协调一致性？
- 库存预扣后遭遇宕机和持续故障，怎样处理数据丢失？
- 关注集合很大时，怎样计算共同关注？
- 布隆过滤器有哪些限制，怎样选参数和安全重建？
面经与参考答法
蚂蚁后端一面：多级缓存、库存容灾与消息选型
这份发表于 2026 年 5 月的记录自述为蚂蚁一面，技术追问围绕点评类项目。正式岗位与部门未披露；“后端”用于说明本页题目方向。原文开头提到最近在学习 Agent，并不意味着该场面试考察了 Agent，本页不补造这类问题。
面试经历为个人自述，未经企业独立确认。以下短答及示例为编辑教学整理，不代表当事人的现场回答、项目配置或实验结果。
（1）介绍项目架构，并说明为什么这样组织？
关联知识点待核实。
原帖没有披露真实模块、数据所有权、部署和约束。复盘时应从业务目标、关键路径、状态权威与故障边界说明取舍，不能只罗列组件；本页不推测其实际架构，知识关联待补充具体设计后复核。
（2）多实例本地缓存、Redis 与数据库怎样协调一致性？
先确定数据库等权威来源与各层可容忍的陈旧窗口，再说明写入、失效传播和读回填顺序。缓存旁路可以是策略之一，不能仅凭“高并发”就断言它无用或保证一致；本地缓存失联、通知丢失、旧请求回填和热点失效都须处理。按实际不变量选择版本、失效、请求合并或权威校验，并用故障场景验证。
（3）库存预扣后遭遇宕机和持续故障，怎样处理数据丢失？
先区分已持久化业务事实、可恢复缓存与尚未可靠记录的请求，并定义允许的数据损失和恢复时长。库存预扣不能替代持久化订单与幂等处理；恢复要结合备份、日志、水位和对账验证。若关键请求从未进入可靠日志或权威存储，不能承诺凭空重建；持续故障时应停止不安全写入、保护一致性并明确拒绝或降级，而不是无限重试。
（4）为什么选择 Kafka，而不是其他消息系统？
关联知识点待核实。
先给出工作负载与约束，再比较吞吐、持久保留与重放、顺序粒度、消费确认、延迟需求、可靠性和运维成本。Kafka、RocketMQ、RabbitMQ 与 Redis Streams 都需要结合具体版本和配置评估，没有只凭名称即可成立的优胜者。还应说明所选系统不擅长什么，以及业务如何处理重复、失败和积压；原帖没有提供其真实容量与配置。
（5）关注集合很大时，怎样计算共同关注？
先说明集合表示、规模比例与精确性要求。哈希集合可遍历较小集合并做成员查询，有序集合可用双指针，位图或压缩位图适用于可控标识空间与合适分布；大数据还需考虑分片、内存、数据传输和分页结果。布隆过滤器只能做可能成员的预筛选，不能直接作为精确交集。耗时应在真实规模和分布下测量，不能凭粉丝数直接估算。
（6）商户搜索有哪些模式，怎样做到快、稳、准？
关联知识点待核实。
原帖没有列出具体模式、匹配目标、数据更新和排序约束。应先澄清是标识查询、关键词、位置还是其他检索，再根据访问模式评估索引与排序，测量相关性、尾延迟和新鲜度。本页只保留这个设计方向，不推测当事人的引擎或检索方案，也不据此给某个具体搜索技术计热。
（7）布隆过滤器有哪些限制，怎样选参数和安全重建？
标准布隆过滤器在数据和实现一致的前提下可以返回“肯定不在”或“可能在”，存在假阳性，不能直接删除普通位，也不能当精确去重。按预计元素数和目标误判率规划容量与哈希次数，固定实现和版本。重建应从权威数据构造新版本，覆盖构建期间新增数据，校验水位后再切换；覆盖不完整时不能根据阴性结果直接拒绝真实请求。原帖没有公开具体哈希名称和参数。