为何AWS SQS非FIFO队列NumberOfMessagesDeleted大于NumberOfMessagesSent

你对两个指标的基础定义理解是正确的，出现删除数大于发送数的情况，通常是遗漏了SQS的以下特性和计数规则：

• 至少一次投递带来的重复删除计数
  非FIFO SQS默认提供至少一次投递保障，当消息的可见性超时到期后还未被删除，就会重新投递给其他消费者。同一条消息可能被多次投递、多次处理、多次调用删除接口，每一次成功的DeleteMessage调用都会让NumberOfMessagesDeleted计数+1，和消息本身的入队次数无关。比如同一条消息被投递3次，3次都被消费者成功删除，就会产生1次发送计数、3次删除计数。
• 删除操作的计数规则不校验消息有效性
  只要DeleteMessage或DeleteMessageBatch接口调用成功，不管你传入的Receipt Handle对应的消息是否还存在、是否已经被删除过，都会计入NumberOfMessagesDeleted。哪怕你用已经过期的Receipt Handle调用删除接口且返回成功，也会新增一次删除计数。
• 死信队列隐式删除计数
  当消息的最大接收次数达到阈值，被SQS自动移动到死信队列时，SQS会对原队列的这条消息执行隐式删除操作，该操作也会计入原队列的NumberOfMessagesDeleted指标。
• 统计边界对齐问题
  你可以先核对两个指标的统计逻辑是否完全一致：比如是否都使用Sum聚合、统计的时间区间是否完全对齐、是否包含了队列创建前同名队列的残留指标数据。

你可以辅助查看NumberOfMessagesReceived指标做验证：正常情况下NumberOfMessagesDeleted一定会小于等于NumberOfMessagesReceived的总和，如果符合这个规律，基本可以判定是重复投递导致的计数差。

内容的提问来源于stack exchange，提问作者Eugene Kim