前言：消息中间件 是用来 客户端 与 客户端之间通信的，那么就存在以下两个问题：
- 如何避免消息重复消费（针对consumer）
- 如何保证消息的可靠性投递（针对publisher）
问题2看《消息100%投递的2种方案》
这一文讲问题1：如何避免消息重复消费
上图是消息投递的整个流程，熟悉该流程有助于理解本文
先理解 幂等性 这个概念，有助于后续理解 如何避免消息重复消费
幂等性:
在编程上，指任意多次执行所产生的影响均与一次执行的影响相同。
在数学上，指幂等方法，是可以使用相同的参数重复执行，并获得相同结果的函数。不用担心重复执行会对系统造成改变。
避免消息重复问题上，就是要实现类似 幂等方法 的功能，使消费者即使多次消费了同样的信息，结果也只跟消费了1次消息的结果一样，不会对业务造成影响。
下面用一个实际场景来举例幂等性的实现：
场景1：秒杀活动（如双十一，春节高铁买票）
用count表示库存
比如库存100，卖一件库存减1，减到0就不能再减，sql如下
update 表名 set count = count -1
但如果库存只剩1，这时候刚好有2个请求同时上来，这时候再去减库存，
库存可能变为-1，这就出现了超卖行为，在业务上是不允许的，如何解决？
可以通过加1个版本号（version）来解决
原先的步骤是直接减库存，加 version 后，改成 先查询 version 号，再执行减库存操作，sql如下：
update 表名 set count = count -1 , version = version + 1 where version = 1
这样当并发请求发送来时，由于版本号被更新，后续的版本号找不到，
就不会执行减库存操作，用加 version 的方法来实现类似乐观锁的效果
