分布式消息中间件MQ认知

MQ的应用场景

• 服务解耦
• 削峰填谷（大促、秒杀等）
• 异步化缓冲（最终一致性）

MQ应用思考点

• 生产端可靠性投递
• 消费端幂等
• 高可用
• 低延迟
• 可靠性（分片、副本）
• 堆积能力
• 拓展性

RabbitMQ四种集群架构

• 主备模式

warren(兔子窝)，一个主/备方案（主节点如果挂了,从节点提供服务，和ActiveMQ利用Zookeeper做主/备一样)

HaProxy配置

listen rebbitmq_cluster
bind 0.0.0.0:5672 
#配置TCP模式
mode tcp 
#简单的轮询
balance roundrobin
#主节点,每5秒做检查如果失败2次就切换
server bhz76 192.168.11.76:5672 check inter 5000 rise 2 fall 2
#备用节点
server bhz76 192.168.11.76:5672 backup check inter 5000 rise 2 fall 2

• 远程模式

  1. 远距离通信和复制，可以实现双活的一种模式，简称Shovel模式
  2. 所谓Shovel就是我们把消息进行不同数据中心的复制工作，可以跨地域地让两个mq集群互联

• 镜像模式（业界较主流）

  1. 集群模式非常经典的就是Mirror镜像模式，保证100%数据不丢失
  2. 在实际工作中用的最多,并且实现集群非常的简单，一般互联网大厂都会构建这种镜像集群模式

  Mirror镜像队列的特点

  • 高可靠
  • 数据同步
  • 三节点
    
    缺陷：不能支持横向扩展

• 多活模式

  1. 这种模式也是实现异地数据复制的主流模式，因为Shovel模式配置比较复杂，所以一般来说实现异地集群都是使用这种双活或者多活模型来实现的。
  2. 这种模型需要依赖RabbitMQ的federation插件，可以实现持续的可靠的AMQP数据通信，多活模式实际配置与应用非常简单。
  3. RabbitMQ部署架构采用双中心模式(多中心)，那么在两套(或多套）数据中心中各部署一套RabbitMQ集群，各中心的RabbitMQ服务除了需要为业务提供正常的消息服务外，中心之间还需要实现部分队列消息共享
     

Federation插件

Federation插件是一个不需要构建Cluster，而在Brokers 之间传输消息的高性能插件，Federation插件可以在 Brokers或者Cluster之间传输消息，连接的双方可以使用不同的users和virtual hosts，双方也可以使用版本不同的RabbitMQ和Erlang。Federation 插件使用AMQP协议通讯，可以接受不连续的传输

Federation Exchanges，可以看成Downstream 从 Upstream主动拉取消息，但并不是拉取所有消息，必须是在 Downstream 上已经明确定义Bindings关系的Exchange，也就是有实际的物理Queue来接收消息，才会从 Upstream拉取消息到Downstream。使用AMQP协议实施代理间通信，Downstream 会将绑定关系组合在一起，绑定/解除绑定命令将发送到Upstream交换机。因此，FederationExchange 只接收具有订阅的消息，本处贴出官方图来说明;

Kafka

• 介绍

• Kafka是LinkedIn开源的分布式消息系统，目前归属于Apache顶级项目
• Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输
• 0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求,适合产生大量数据的互联网服务的数据收集业务

• 特点

1. 分布式
2. 跨平台
3. 实时性
4. 伸缩性

• Kafaka高性能的原因

1. 顺序写，Page Cache空中接力，高效读写

2. 高性能、高吞吐

3. 后台异步、主动Flush

4. 预度策略、IO调度

   PageCache

   通俗讲，就是把应该从磁盘中读取的数据转换成从内存中读取，把对磁盘的访问转换成对内存的访问。

   传统文件读（多次copy）：
   
   ZeroCopy：
   

Kafka集群模式