关于mq:MQ面试问题整理

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

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

RocketMQ

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

	同步复制	异步复制
概念	即等 Master 和 Slave 均写胜利后才反馈给客户端写胜利状态	只有 Master 写胜利，就反馈客户端写胜利状态
可靠性	可靠性高，若 Master 呈现故障，Slave 上有全副的备份数据，容易复原	若 Master 呈现故障，可能存在一些数据还没来得及写入 Slave，可能会失落
效率	因为是同步复制，会减少数据写入提早，升高零碎吞吐量	因为只有写入 Master 即可，故数据写入提早较低，吞吐量较高

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

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

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

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

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

http://yannis.club

我的项目中为什么应用 MQ