关于mq:MQ面试问题整理

我的项目中为什么应用 MQ

长处

1. 解耦 <br/>
   同一块业务的相干能力被很多个我的项目须要，后续也有极大可能会被其余我的项目须要。将该局部能力解耦，通过 MQ 进行音讯的对立解决。若有其余我的项目或业务须要相干性能，则对此进行订阅，解决相干业务。缩小我的项目间接依赖。<br/>
2. 异步 <br/>
   大型项目相干合作人员，参加团队越来越多，我的项目之间的关联越来越深。造成整个链路特地长，且问题排查不容易。<br/>
3. 削峰 <br/>
   对于局部业务，在某些工夫点，可能因为刹时申请过大，造成所有申请间接拜访至数据库对数据库造成压力，从而影响我的项目原有业务。个别 MySQL 数据库的解决能力在 2k 次 /s，MQ 的顶峰解决能力 1w+。能无效的解决 <br/>
   <!– more –>

毛病

零碎可用性升高

因为新减少了 MQ，因为 MQ 的可用性、可靠性会造成零碎可用性的额外负担。<br/>

1. 可用性问题如何解决 <br/>
   不同的 MQ 对此的解决方案不一样。
   ActiveMQ
   Zookeeper及多个 activeMQ, 批改长久化为性能更好的LevelDB 替换掉默认的 KahaDB.<br/>
   长处：简略实现了可用性。<br/>
   毛病：每次理论可用的 MQ 只有一个，一旦有一个 MQ 呈现问题，相干的音讯就会失落。<br/>

RocketMQ

• 单 master 模式，一旦呈现问题，就会整个服务不可用。个别不会间接生产应用，适宜集体学习；
• 多 master 模式，多个 master 节点组成集群。单个 master 呈现问题不影响。长处：所有模式中性能最高的。毛病：单个 master 节点宕机期间，未被生产的音讯在节点复原之前不可用，音讯实时性就受到影响。留神：应用同步刷盘可保障音讯不失落，同时 topic 绝对应的 queue 应该散布在集权中各个 master 节点，而不是只在某一个 master 节点上；
• 多 master 多 slave 异步复制模式，在多 master 模式下，每个 master 节点至多都有一个对应的 slave;<br/>
  master 节点可读可写，slave 只可读 不可写。长处：在 master 宕机时，消费者能够间接从 slave 读取音讯，音讯实时性不会受到影响，性能简直与多 master 一样。毛病：应用异步复制可能造成音讯失落问题。
• 多 master 多 slave 同步双写，同上一种模式相似，区别在于 master 与 slave 之间的数据同步形式。长处：同步双写的同步模式能保证数据不失落。毛病：发送单个音讯时长会比拟长，性能会比拟差；
  同步刷盘，异步刷盘的区别：在于多 master 之间的数据同步写入磁盘模式。

理论利用中的举荐把 Master 和 Slave 设置成 ASYNC_FLUSH 的异步刷盘形式，主从之间配置成 SYNC_MASTER 的同步复制形式，这样即便有一台机器出故障，依然能够保证数据不丢。

2. 可靠性问题如何解决 <br/>
   引入 MQ 造成的数据可靠性问题，或者如何解决音讯失落问题？整个 MQ 的链路中，可能存在音讯失落的地位仅有三个，一个是生产端，一个是 MQ 本身，最初一个就是上游的消费者。<br/>
   不同的 MQ 对此解决方案均不一样，需别离剖析。

ActiveMQ
生产端
程序在每次发往 MQ 的音讯后，可接管到 MQ 对其的 Ack 响应，

零碎复杂度进步

减少了 MQ，引入了音讯是否会反复生产，音讯失落问题。<br/>

数据一致性

引入 MQ 之后，繁多事务会被分拆为多个事务。引入了分布式事务一致性的问题。<br/>

MQ 如何解决反复生产问题

幂等校验

• 上游不能反复下发 <br/>
  程序本人保障不反复创立音讯，应用业务事务进行管制。<br/>
• 上游不能反复生产 <br/>
• 将音讯信息入库，应用数据库、Redis 进行音讯存储。有音讯过去应用惟一主键进行存储，每次进行校验是否存在，不存在持续解决，否则依据业务进行疏忽或更新；<br/>
• 将音讯信息入库，依据业务进行惟一主键束缚，若有反复数据，则会报惟一主键抵触，也插入不了；
• 如果仅是 redis 的 set 操作，则无需解决。即时反复也不影响;

MQ 如何解决音讯失落问题

http://yannis.club