使用queue替代pub-sub检测数据丢失/被盗的机制是什么？

《软件架构基础》第33页“权衡分析”章节中，对比了投标生产者（bid producer）向3个消费者（投标捕获、投标追踪、投标分析）发送信息的两种方案：方案1（图2-8）采用发布-订阅（pub-sub）模式，方案2（图2-9）为每个消费者配置独立队列。书中指出：pub-sub的主题可被任意访问，存在数据访问与数据安全风险；而队列模式中发送至队列的数据仅能被指定消费者获取，若恶意服务（rogue service）监听队列，对应服务将无法收到投标数据，系统会立即发送数据丢失（及潜在安全入侵）告警。

• 如何检测对应服务未收到投标数据，从而发送数据丢失/安全入侵告警？
• 是否是因为目标服务拥有恶意服务不具备的密钥，当消息被取出但未用正确哈希确认时，即可判定数据被未授权服务获取？

一、检测服务未收到数据的常见手段 #

• 消息消费确认（ACK）机制：主流队列服务（如RabbitMQ、ActiveMQ）都内置了ACK机制。生产者发消息后，队列会把消息标记为待确认状态；只有指定消费者处理完消息并返回合法ACK，队列才会删除该消息。如果超时没收到ACK，队列直接触发数据丢失告警，同时还能把消息重发或者转入死信队列。要是恶意服务抢了消息却不返回合法ACK，就会触发这个告警。
• 生产-消费计数比对：生产者端统计发往对应队列的消息总数，消费者端统计成功接收处理的消息数，监控系统实时对比两者的差值。如果连续几个统计周期差值都超过阈值，就判定数据没被正常接收，触发告警。
• 消费者活跃度监控：盯着指定消费者的在线状态和消息处理速率。如果消费者长时间没处理消息，或者处理速率远低于生产者的发送速率，系统就会触发异常告警，排查是不是有恶意服务抢占了消息。

二、关于密钥哈希验证的说明 #

这种方式是额外的安全增强手段，不是基础的未接收检测逻辑：

• 目标服务持有专属密钥，生产者发消息时会用这个密钥生成消息签名（比如HMAC哈希）。消费者收到消息后，用自己的密钥验证签名是否合法；验证失败的话，会拒绝处理并触发安全告警。
• 恶意服务就算能监听队列抢消息，也拿不到密钥生成合法签名，队列会因为收不到合法ACK触发数据丢失告警，同时消费者端的签名验证失败记录，能进一步佐证是安全入侵而非普通的消息丢失。但核心的未接收检测还是依赖ACK机制和计数比对，密钥验证是用来区分“没收到”和“收到但非法”的情况，精准定位问题类型。

内容的提问来源于stack exchange，提问作者Jack Peng