MQ随记（1）
为什么使用 MQ？
-
解耦
一个系统或者模型，调用多个系统或者模块，互相调用非常复杂，维护也很麻烦，但是当不需要同步调用情况时，用MQ解耦是一个选择。
各个业务系统在未使用MQ时，在需要相互传输数据时，耦合性就会很高，从而造成相互合作比较麻烦，使用MQ可以降低耦合性，从而只关心自己的业务。
-
异步
互联网用户等待时间一般要求200ms以内。
当系统后台操作执行时间较长，系统反应时间很慢从而影响到了客户的体验。当使用MQ后，可以提升系统的响应时间，相应的复杂操作可以由后台执行无需等待。
-
削峰
当数据量一瞬间非常大时，如果后台涉及到使用sql，大于5000次/s可能就会造成系统宕机，所以需要使用MQ进行防止此类情况发生，高峰期过后MQ中堆积的数据也会很快被消费掉。
使用MQ可能会存在的问题
-
系统的可用性降低
当MQ故障，整个系统就会崩溃。
-
系统的复杂性变高
引入MQ导致系统考虑的问题增多。
-
一致性问题
MQ的技术选型
现在可供选择的MQ类型有ActiveMQ、RabbitMQ、RocketMQ、Kafka。
相关区别如下表格:
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级 | 万级 | 10万级 | 10万级 一般配合大数据类的系统来进行实时数据计算，日志采集等场景 |
| topic数量对吞吐量的影响 | topic可以达到几百，几千的级别，吞吐量会小幅度下降，这个是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic | topic从几十个到几百个的时候，吞吐量会大复度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。 | ||
| 时效性 | ms | 微妙 | ms | ms |
| 可用性 | 高，基于主从架构实现高可用性 | 高，基于主从架构实现高可用 | 非常高，分布式架构 | 非常高 |
| 消息可靠性 | 有较低的概率丢失数据 | 经过参数优化可以做到0丢失 | 经过参数优化可以做到0丢失 | |
| 功能支持 | MQ领域的功能极其完备 | 基于erlang开发，所以并发行非常好，性能好，延迟低 | MQ功能较为完善，还是分布式的，扩展性好 | 功能比较简单，主要支持简单的MQ功能，在大数据领域是事实上的标准 |
| 优劣势总结 | 优点：非常成熟，功能强大，在业内曾大量公司以及项目中使用。缺点：社区内以及国内应用越来越少，维护频率很低，几个月一次。主要用于解耦和异步，较少用于大规模吞吐的场景。 | 优点：erlang语言开发，性能好，延迟低。吞吐量过万，开源提供的管理界面非常棒，社区比较活跃，每个月都会发布几个版本。 缺点：erlang开发，国内鲜有几个公司可以对erlang源码级别研究和定制。 | 优点：阿里出品java系的，可以阅读源码并定制，社区活跃度一般，文档相对简单。缺点：万一这个技术被抛弃，社区放弃更新，需要自身具备当出现bug时候可以主动修复的实力。 |
不推荐使用activeMQ，因为没有经过大规模吞吐量场景的验证，社区也不是很活跃。
越来越多公司在使用RocketMQ，确实不错，但是需要考虑万一社区抛弃的风险，使用RabbitMQ，社区活跃人员为散户，不会黄掉.
如何实现高可用性
RabbitMQ
普通集群模式：
- 可能会在rabbitMQ集群内部产生大量的数据传输。
- 可用性几乎没有保障。
镜像集群模式：
每个节点都会存储全部queue信息。可以保证高可用性。
当一个节点宕机，可以在其他节点消费或生产到消息。
如何配置镜像集群模式：
rabbitMQ有控制台，在控制台增加一个策略，镜像集群模式策略，指定的时候可以要求数据同步到所有节点，也可以要求同步到某些节点。
Kafka
多个broker组成，每个broker是一个节点；创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。
这就是天然的分布式消息队列，就是一个topic的数据，分散放在多个机器上，每个机器就放一部分数据。
实际上rabbitmq之类的，并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群，HA的机制而已，无论怎么玩，rabbitmq一个queue的数据都是放在一个节点内，镜像集群下，也是每个节点都放在这个queue的完整数据。
kafka0.8后提供了HA机制，就是replica副本机制，每个partition的数据都会同步到其他机器，形成自己多个replica副本。然后所有replica会选举一个leader出来，然后生产和消费和这个leader打交道，然后其他副本就是follower。读的时候就直接读leader数据即可。
如果一个broker宕机了，没事，那么broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来。继续读写这个leader就可以了。这个就是高可用性。
