Java基础之《mq》

一、你的项目中有哪些地方用到mq
1、使用mq异步发送优惠券
2、使用mq异步发送短信
3、使用mq异步扣库存（秒杀）
总之将执行比较耗时的代码操作，交给mq异步实现接口
4、贷款项目
使用mq异步审核贷款金额
用户提交自己的信息，后台根据用户的信息，计算贷款的金额
他会拿你的信息去很多接口查下：名下有没有公司+5w，名下有没有房产+5w，花呗信用分+5w
最后计算出贷款金额后，发送短信通知

主流mq有rabbitmq、kafka、rocketmq
activemq没必要学了
kafka和rocketmq思想本质比较相似，rabbitmq与他们的整个架构模型区别较大
如果是电商或者抗高并发，建议用kafka或者rocketmq

二、为什么需要使用mq——mq架构的特性
1、异步处理（多线程和mq）
多线程：缺点是消耗cpu资源，适合于小项目
2、mq和队列模型比较相似
请求发送到生产者
生产者发送一个msg到mq的队列
消费者从mq服务端拉取到消息
3、实现解耦
同步执行：落库、发送短信、发送优惠券，是在同一个jvm中执行的
异步mq：发送短信和发送优惠券是在单独的一个jvm，和会员服务落库是完全分开的。如果会员服务宕机了，消费者照样可以发送短信
4、流量削峰（mq可以实现抗高并发）
单个线程执行时间很长，那么高并发情况下，请求都阻塞在队列里。mq可以让单个线程执行的时间大大减少
贷款 app
用户端----提交用户信息：学历、蚂蚁信用分等
-----------------------------------------------
服务端----先将用户数据插入数据库中----10毫秒
单独封装msg消息投递到我们mq异步计算贷款金额
-----------------------------------------------
调用第三方接口
蚂蚁信用分 > 700分 +5w
调用企业信息网接口 名下有公司 +5w
调用学历接口 本科 +5w

三、mq与多线程实现异步的区别
1、多线程方式实现异步可能会消耗到我们的cpu资源，可能会影响到我们业务线程执行，会发生cpu竞争的问题
2、mq方式实现异步是完全解耦，适合于大型互联网项目
3、小的项目可以使用多线程实现异步，大项目建议使用mq实现异步

四、mq如何避免消息堆积的问题
1、产生背景
生产者投递消息的速率与我们消费者消费的速率完全不匹配
2、生产者投递消息的速率 > 消费者消费的速率
导致我们消息会堆积在mq服务器中，没有及时的被消费者消费，所以就会产生消息堆积的问题
3、注意的是：rabbitmq消费者消费我们的消息，如果成功的话，消息会被立即删除
kafka或者rocketmq消息消费如果成功的话，消息是不会立即被删除
4、解决办法
A、提高消费者消费的速率（对我们的消费者实现集群）
    10万条消息，消费者每次只取一条消息消费
B、消费者应该批量式获取消息，减少网络传输的次数
    每次取10条或者100条消息
5、对kafka或rocketmq将消息理解为就是我们的日志，根据offset去获取消息

五、mq如何保证消息不丢失
1、mq服务器端
消息持久化到硬盘（刷盘）
2、生产者
ACK机制（消息确认机制），发送msg消息给mq服务器端，mq服务器端如果能够成功的将消息刷盘到硬盘存放的话，那么它会及时的响应一个应答
确保我们的消息投递到mq服务器端
3、生产者投递消息，mq宕机了如何处理
如果mq服务器端宕机了，producter会把msg消息记录在redis、mysql中，用定时任务重发
4、消费者
必须确认消费成功
rabbitmq中：确认后才会将该消息删除
rocketmq或者kafka中：确认后才会提交offset
5、死信队列属于备胎队列

六、mq如何保证消息顺序一致性问题
产生背景：
mq服务器集群或者mq采用分区架构模型存放消息，每个分区对于一个消费者消费消息
1、大多数项目是不需要保证mq消息顺序一致性的问题，因为它本身是异步的。只有在一些特定的场景可能会需要，比如mysql与redis实现异步同步数据
先投递insert
再投递update
再投递delete
分区1拿到insert
分区2拿到update
分区3拿到delete
消费者1先拿到delete，消费者2拿到update，消费者3拿到insert
2、所有消息需要投递到同一个mq服务器，同一个分区模型中存放，最终被同一个消费者消费，核心原理：设定相同的消息key，根据相同的消息key计算hash存放在同一个分区中
一个topic主题下，区分不同的tag
3、如果保证了消息顺序一致性有可能降低我们消息消费的速率
4、解决办法
指定相同的消息key
核心办法：消息一定要投递到同一个mq，同一个分区模型，最终被同一个消费者消费
根据消息key计算%分区模型

七、mq如何保证消息幂等性问题
1、消费者获取消息，如果消费消息失败，mq服务器则会间隔的形式实现重试策略
2、怎么知道消息消费成功还是消费失败
如果消费失败了，消费者会发送一个通知给mq服务器端，mq服务器端会重试
每个msg都有一个全局唯一id
查询id在数据库是否已经存在
3、重试过程中，需要保证业务幂等性问题，保证业务不能够重复执行
4、我们可以通过全局的消息id，提交查询如果该业务逻辑已经执行过，则不会重复执行
5、我们也需要在数据库的db层面需要保证幂等性问题，唯一主键约束，乐观锁等

八、mq与redis如何保证数据一致性问题
方案1：直接删除redis缓存（适合于小项目）
修改mysql数据
清除redis缓存
方案2：基于mq异步同步更新（代码量大）
更新mysql
投递msq消息
消费者异步同步到redis中
方案3：基于canal框架订阅binlog同步（重点）
canal服务器端（伪装成mysql从节点）订阅到binlog文件
当我们mysql主节点binlog文件发生了变化，则会给canal服务器
canal客户端监听canal服务器端，canal服务器将binlog文件转化成json格式给mq
消费者订阅我们mq实现异步的形式将数据同步给redis
1、jvm --- redis --- mysql
1）jvm先查询redis，redis没有，查询mysql
2）mysql有数据，再存到redis中
2、redis是副本数据，通过思想：最终一致性，只要是做数据同步不可能是实时同步的（网络抖动）
1）mysql从 --订阅binlog文件--> mysql主
2）mysql从 <--同步binlog文件-- mysql主
3、两个思想
强一致性：不允许有脏读（分布式领域中不可能）
最终一致性：短暂的数据延迟
4、产生背景
在分布式领域中同步数据，很难保证强一致性策略，都是采用最终一致性思想
短暂的数据延迟是允许的，但是最终数据要保证一致性
一般延迟10-30毫秒