文章目录
1.谈谈项目中mq的理解
mq一般都是用来异步, 解耦, 消峰用的。
异步操作, 接口是http协议的,在同步调用过程中, 如果接口响应比较慢的情况下, 会导致客户端反应超时, 比如有些业务的接口, 确实执行比较耗时, 那响应时间比较慢
的情况下, 会导致我们的客户端会同步进行阻塞等待, 这种情况下回引发客户端超时, 会使得客户端触发一些重试策略, 在重试策略的过程中, 会导致业务发生重复执行。
所以我们需要去注意一些幂等性问题。我们会把执行耗时的接口使用mq异步实现, 可以提高http协议接口的响应速度, 比如说异步发优惠券, 异步扣库存, 异步发短信。
幂等性问题:
1.基于token
2,锁机制:悲观锁,乐观锁:基于version,分布式锁
3.基于防重表
4.基于数据库唯一Id,redis set防重
5.基于全局请求唯一id
2.mq宕机消息会丢失吗
主流的mq在默认的时间段会将msg持久化到硬盘上, 宕机恢复后, 也会从硬盘恢复过来, 读到内存中
3.消息堆积问题
高并发的情况下很常见, 生产者的生产消息的速率和消费者消费的速率不匹配, 将consumer作为集群形式消费, 每个消费者为批量形式消费, 可以不断横向扩展, 对于consumer不断做集群。进行批量消费。
4.mq的集群如何解决消息顺序执行问题
一般这个问题不用去解决,但是有的场景需要解决,比如Mysql和redis数据同步的过程中, mq进行异步同步.消息的执行顺序需要解决: producer可以设置一个消息key, 相同的业务逻辑设置相同的key, 做hash算法的时候, 会存放在相同的Broker分区中, consumer会在同一个broker中消费。效率会变低, 需要进行broker横向扩展, 提高效率。
5.数据一致性问题
1.先更新缓存后更新数据库
问题:
1.更新缓存后,读取缓存
2.读取数据库的时候失败了
不可取
2.先更新数据库后更新缓存
问题:
1.数据一致性问题
2.数据更新存在时间差
3.业务方面,如果读取数据库的时候更新缓存,不停的更新缓存浪费资源
不可取
3.先删除缓存后更新数据库
问题:
1.数据不一致问题
A删缓存 B读取数据直接读取数据库旧值 B将值写入到缓存 A将值写入到数据库
解决方案：
1.延迟双删,延迟B的删除的时间大于A的写入缓存时间
不可取
4.先更新数据库后删除缓存
有问题,待解决,利用canal和mq
最终一致性是思想:双写, 延迟双删:删两次, 时间点不好控制。
6.canal运行原理
首先启动一个canal的服务器端, 订阅到mysql的master的binlog文件, 当mysql的master的binlog文件发生变化的时候, 会将binlog文件同步到canal的服务器端, 再同步到canal的客户端, cannal客户端将数据同步到redis中, 告诉数据的变化。这个过程一般都是有redis延迟的。
redis的延迟是30s左右。
7.分布式配置中心的原理
客户端会做一个心跳, 每隔一段时间去服务端请求配置文件有无发送变化, MD5的方式进行比对, 如果有发生变化的话, 服务器端的配置文件刷新到本地, 不会立刻生效,因为需要将bean对象重新再ioc容器上加载。所以会有一个客户端在类上有一个注册,就是刷新注解, 然后IOC容器会遍历bean对象,如果类上有加刷新注解的话, 会重新在IOC容器加载, 重新讲配置文件的值给Bean对象的成员属性。
