理解消息队列的持久性，可靠性，幂等性
持久性
一些下单任务，例如付完钱后异步下单，为啥我们主流都是使用mq来做异步，而不是使用线程池来做异步呢？明明都能做异步
因为如果我们的Java程序宕机了，那么我们的异步任务没完成完，那就直接结束了
如果我们使用mq的话，它是Broker，它有持久化功能，文件可以存储到MQ内部，本地文件持久化
这样子我们就能重试，保证消息消费
可靠性
mq有重试机制，如果消息发送失败的话我们可以重试，而用线程池这种的话要写一对冗余的代码
我们保证消息能成功发送
可靠性体现在三个地方
确保生产者发送给Broker
失败场景：网络波动或者mq宕机等，导致发送不过去
确保Broker发送给消费者
失败场景：网络波动或者mq宕机等，导致发送不过去
确保保证消费者能成功消费到消息
默认:发送到消费者mq就标记消费成功，也就是成功发送到消费者就直接ack
失败场景：我们可能消息队列发送给消费者成功，但是java程序没执行完代码就宕机的，但是此时我的消息队列已经发送消息了，所以它会结束表示成功消费，但是其实我们java程序没运行完，本质上还是消费失败。
所以我们有一个手动ack机制，也就是我们执行完，再返回一个ack告诉消息队列我们发送成功了
不然我们就重试3次（代码要自己写）
我拿RabbitMq举例子，可以看一下我的其他文章
RabbitMq手动ack的超简单案例+Confirm和Return机制的配置和使用_rabbitmq 手动ack-CSDN博客
幂等性
重复消费问题
幂等性就是保证消息的唯一性，防止消息被重复消费
可能因为网络故障波动或者其他原因，导致我们的mq重复发送多次请求给消费者，导致我们的消费者重复消费。
如果是下单那么我们的单号可能有重复的5个，这样子明显是不行的
解决方案
我们要弄消息的唯一ID(唯一标识)
例如把消息的唯一标识改成UUID+时间戳，那么怎么样都不会遇到ID相同的情况
为什么要这样弄呢？
我拿RabbitMq举例子，RabbitMq的消息的唯一ID是通过队列名，交换机名和消息内容生成的。
那我们发送消息内容相同，那么我们的自动生成的ID不就一样了？
所以我们要改一下我们的ID生成策略
然后我们把这个ID存到Redis里面去，每次消费前去判断Redis里面是否存在这个ID。
如果有那么就消费过了，我们不执行，防止重复下单。
如果没有，那么就是我们没消费过，我们直接下单就行了。
这样子就保证了消息的幂等性
这三个性质是共通的，可以延伸到其他的消息队列，例如Kafka和RocketMq