高并发系统设计：如何保证消息仅仅被消费一次

消息丢失

• 丢失场景主要包含三个：从生产者写入消息队列的过程；消息在消息队列中的存储场景；消息被消费者消费的过程。
  
• 在消息生产的过程中丢失消息：可能是生产者推送消息时发生了网络抖动，这种情况重试2-3次即可；
• 也可能是消息到达了消息队列，暂存在缓冲区中，然后机器宕机，但是消息队列还没来得及刷盘（一般刷盘策略是达到一定时间或积累了一定消息数量）。更改刷盘策略可能会造成较大性能影响，而且宕机概率不高，有点得不偿失。
• 可以考虑以集群方式部署消息队列，通过多个副本备份数据。
• 以kafka为例：
• 在消费的过程中存在消息丢失：比如网络抖动，消费者没接受到消息，这种情况需要重试；或者处理消息前就更新了消费进度，但是处理失败了，这种情况要等处理完成后在更新消费进度。

重复消费

• 从上面的场景中可以看出，为了避免消息丢失，要付出两方面的代价：一方面是性能损耗，一方面是可能存在的重复消费。性能损耗可能还可以接受，但是消息被重复消费就会造成业务错误。
• 我们无法做到完全避免消息重复的发生，但是我们可以做到消息消费的幂等
• 生产过程的幂等性，还是以kafka为例。
• 消费过程的幂等性，从通用层来讲，可以记录下消费过的消息id，如果待消费的消息id已经被消费了，就直接丢弃。不过还存在一个问题，消息处理后，还没来的及更新消息状态，就宕机了，那么还是会重复执行。这时候可以引入事务机制，消息状态的更新和业务处理同时成功或同时失败，不过这样处理成本比较高；可以考虑另外一种方式，使用乐观锁，在业务数据上增加版本号字段。更新时版本号一致才更新。`