1.为什么要使用 MQ？
异步：批量操作、导入、导出功能耗费时间太长，用户等待时间长。
削峰：开盘大量交易
2.使用 MQ 有什么优点和缺点？
优点：
缺点：
系统可用性降低：
系统复杂性提高：
数据一致性问题：
3.MQ 对比
特性
ActiveMQ
RabbitMQ
RocketMQ
Kafka
万级，吞吐量比 RocketMQ 和 Kafka 要低了一个数量级
万级，吞吐量比 RocketMQ 和 Kafka 要低了一个数量级
10 万级，Rocket 也是可以支撑高吞吐的一种 MQ
10 万级别，这是 kafka 最大的有点，就是吞吐量高；一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 可以达到几百，几千个的级别，吞吐量会有较小幅度的下降<br><br>这是 RocketMQ 的一大优势，可以支撑大量的 topic
topic 从几十个到几百个的时候，吞吐量会大幅度下降；所以在同等机器下，kafka 尽量保证 topic 数量不要过多，如果要支撑大规模 topic，需要增加更多的机器资源延迟在 ms 级以内
MQ 领域的功能及其完备
基于 erlang 开发，所以并发能力很强，性能极其好，延时很低
MQ 功能较为完善，还是分布式的，扩展性好
功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准
非常成熟，功能强大，在也内大量的公司以及项目中都有应用<br><br>偶尔会有较低概率丢失消息<br><br>而且现在社区以及国内应用都越来越少，官方社区现在对 activemq 5.x 维护越来越少<br><br>主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用
erlang 语言开发，性能及其好，延时很低；<br><br>吞吐量到万级，MQ 功能比较完备<br><br>而且开源提供的管理界面非常棒，用起来很好用<br><br>社区相对比较活跃，几乎每个月都会发几个版本<br><br>但是问题也是显而易见的，rabbitmq 确实吞吐量会第一下，这是因为他做的实现机制比较重<br><br>而且 erlang 开发，国内有几个公司有实力做儿郎源码级别的研究和定制？如果说你没这个还顺利的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很柔，基本职能依赖于开源社区的快速维护和修复 bug<br><br>而且 rabbitmq 集群动态扩展会很麻烦。
接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障<br><br>如处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是 ok 的，还可以支撑大规模的 topic 数量，支持复杂 mq 业务场景<br><br>而且又一个很大的优势在于，阿里出品都是 java 系的，我们可以自己阅读源码，定制自己公司的 mq，可以掌控<br><br>社区活跃度想对一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准 JMS 规范走的有些系统要迁移需要修改大量代码<br><br>还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们那公司有技术实力我觉得用 rocketmq 挺好的
kafak 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展<br><br>同时 kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量<br><br>而且 kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略<br><br>这个特性天然适合大数据实时计算以及日志收集
4、如何选择 MQ：
ActiveMQ：
优点：
缺点：
RabbitMQ:
优点：
缺点：
RocketMQ：
优点：
缺点：
Kafka：
优点：
缺点：
结论：
中小型公司优先选用 RabbitMQ，大公司可以使用 RocketMQ，处理大数据选择 Kafka
5、如何保证高可用？
1、RabbitMQ的高可用
单机模式、普通集群模式、镜像集群模式
单机模式：
忽略
普通集群模式：
多台机器上有多个RabbitMQ实例，每个机器启动一个，但是你创建的queue，只会放在其中一个实例上，但是每个实例都同步queue的元数据。等到消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
缺点：
镜像集群模式：
这个才是真正意义上的高可用模式，跟普通集群不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息同步到多个实例的queue里进行消息同步。
优点：
缺点：
如何开启镜像集群模式：
2、kafka的高可用
基本架构：
由多个broker（代理）组成，每个broker是一个节点；创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据
kafka0.8版本之前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读了，没有什么高可用可言了
kafka 0.8以后，提供了HA机制，就是replica副本机制，每个partition的数据都会同步到其他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower，写的时候，leader会负责把数据同步到所有follower上去，读的时候直接读leader上数据即可，只要读写leader，很简单，要是你可以随意读写每个follower，那么就要care数据一致性的问题，系统复杂度太高，很容易出问题，kafka会均匀的讲一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。
这么搞，就有所谓的高可用性了，因为如果某个broker宕机了，没事，那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的 leader即可，这就有所谓的高可用性了。
写数据的时候，生产者就写leader，然后leader将数据落地到本地磁盘，接着其他follower自己主动从leader来pull数据，一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回成功的消息给生产者。
消费的时候，只会从leader去读，但是只有一个消息已经被所有follower都同步成功返回ack 到时候，这个消息才会被消费者读到
6、如何解决消息队列里的重复消费？
关键词：幂等
添加唯一ID，消费的时候存起来，每次消费对比一下
7、如何保证消息的可靠性传输？
RabbitMQ从生产者、MQ、消费者三个维度来保证数据传输的安全
1、生产者
1、使用MQ的事务提交，txselect,txcommit,txrollback
1. 缺点：堵塞、同步
2、使用confirm模式
2、MQ
开启持久化，消息写入之后会持久化到磁盘，开启分为两步
- 发送消息的时候将消息的deliveryMode设置为2，将消息设置为持久化，此时MQ就会将消息持久化到磁盘上去，必须要同时设置两个持久化才行。
- 持久化可以跟生产者的confirm机制配合使用，只有消息被持久化到磁盘之后，才会通知生产者ACK了，所以哪怕是在持久化到磁盘之前，MQ挂了，数据丢了，生产者收不到ack，也是可以自己重发的。
3、消费者
关闭自动ACK，默认为自动ack，通过api来调用
Kafka
生产者
Kafka自身
8、如何保证消息的顺序性
案例：同步MySQL的binlog文件，正常的顺序为增删改，结果同步过去以后编程了删改赠，顺序全部错乱了
RabbitMQ
拆分为多个consumer，每个queue由一个consumer来执行
Kafka
写入一个partition的数据一定是有顺序的，指定一个key将关联的数据写入相同的partition中
消费者中使用内存队列，把相同的key放入同一个内存队列，多线程执行时也是按照队列执行的
