测验：异步队列对接

以下哪项对 exactly-once（恰好一次）的解释最准确？

• 把“至少投递一次”与“接收方去重”结合，使结果看起来只处理了一次
• 由消息代理保证消息只投递一次的功能
• 只有网络稳定时才能成立的投递方式
• 改为同步发送消息即可自动实现

如何正确理解消息代理的顺序保证？

• 整个主题都保证全局顺序
• 顺序由消费者数量决定
• 按时间戳排序总能恢复原始顺序
• 只在分区（或队列）内保证顺序，因此应把需要保持顺序的业务单位作为分区键

把 JSON 格式损坏的消息送入重试逻辑，会发生什么问题？

• 重试时代理重新发送原文，问题会自行恢复
• 超过重试上限后，代理会自动删除该消息
• 每次重试都会积累解析对象，增加消费者内存
• 该消息会持续失败，并阻塞后续正常消息

为什么消费者应把“业务处理”和“处理历史记录”放在同一事务中？

• 一次提交即可完成，减少往返并提高吞吐量
• 合并后事务日志只记录一次，体积更小
• 分开执行会出现“业务已处理但历史未记录”，重试时造成重复
• 稍后操作历史表会长时间持锁，拖慢其他消费者

目录式队列通过 inbox → processing 的 mv 防止并发消费，原理是什么？

• 执行 mv 时，内核会自动锁定目标文件
• 操作系统按到达顺序逐一处理同一文件的请求
• 移动时文件权限会改变，其他进程无法打开
• 同一文件系统内 rename 是原子操作，只有成功的进程能取得该消息

防止发送方尚未写完文件就被消费者取走，标准做法是什么？

• 延长消费者运行周期，为传输完成留出时间
• 预先规定文件大小，只在达到该大小时取走
• 先用临时名称写入，完成后改名，或同时创建完成标记（.ok）
• 由发送方压缩后发送，文件只有完成后才能打开

为什么队列积压（consumer lag）告警采用“连续 10 分钟增长”，通常比“超过 1000 条”之类的绝对值更好？

• 存在批量流入时瞬时大幅积压是正常的，趋势更能反映异常
• 绝对值标准在分区数变化时需要重新计算，难以维护
• 频繁触发阈值告警会增加告警系统自身负载
• 代理上报的积压数误差大，不适合作为绝对值