redis红锁
问题：
在redis集群中；如果请求一个分布式锁成功；但slave还没有复制同步这个锁，master宕机了；再次去加锁的时候会从继任了master的原slave上申请加锁，也会成功。导致同一个锁被获取了不止一次。
解决：
对集群的每个节点进行加锁，如果大多数（N/2+1）加锁成功了，则认为获取锁成功。
Redisson实现了红锁；但是它对每个加锁的实现，不能保证每个锁落在不同的master上。不建议使用
直接使用Redisson的普通锁即可。
为什么要使用MQ
1、分布式系统下可以实现异步处理业务，削峰填谷的功能；
2、实现消费者和生产者之间的解耦；——系统解耦
MQ应用场景
应用场景1：当后台系统对数据进行添加、删除、修改后，将会发送一个消息，接收到此消息的微服务可执行对应业务。如：更新ElasticSearch的数据，更新动态，支付状态检查
应用场景2：用户登录、注册时，向用户发送短信验证码。
MQ如何保障发送消息可靠
简易快速容易实现的做法：
1、开启生产者重试机制；
2、启用生产者发送消息后确认机制（ConfirmCallback)
理论上更可靠方案（一般不那么搞）：
- 把消息数据写入数据库，用状态码来控制消息发送状态。
- 开启定时任务，间隔3秒，查询未发送的消息。
- 调用消息生产者，发送消息到MQ中间件。
- 消息生产者，设置confirmCallback确认回调对象，判断ack
-- true: 消息发送成功，修改消息发送状态为: 已发送。
-- false: 消息发送失败。定时任务重发
MQ如何保障消费消息可靠
比较现实和常见的做法：
1、消费者确认机制
2、设置失败重试机制
3、重试失败后投递到其它交换机再处理
4、主动查询业务（兜底方案）
理论上方案：
- 接收到消息后，直接存入数据库（消息幂等的处理）。
- 定时任务定时扫描数据库未处理消息。
