消息队列 资料汇总

汇总收集到的关于 MQ 方面的资料，包括 RabbitMQ、Kafka、Pulsar等

基础概念

模式	说明
简单原型	生产者往消息队列中扔消息，消费者从消息队列取消息，一次取一个。缺点是局域网内最大消费速度是2000QPS
批量处理消息	每次可以取多条消息处理
多个 Consumer 处理消息 - Push 模式	push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。中心节点需要监听Consumer 的 ACK 消息用于判断消息是否处理成功，并处理当前的消息。
多个 Consumer 处理消息 - Pull 模式	而pull模式则可以根据consumer的消费能力以适当的速率消费消息。 这种模式好处，消费者不需要返回 ACK 信息，因为当消费者申请消费下一条消息可以认为上一条领取的消息已经处理完，也不需要处理超时的问题，Consumer 愿意处理到啥时候就到啥时候。 如何保证多个 consumer 处理的消息不会重复了？
多个消息队列 - Pull 模式	kafka模式 点击查看图片

详细查看： 流式计算 - kafka(1)

案例分析

知乎千万级高性能长连接网关揭秘

• 我们怎么设计通信协议
  • 业务解耦
    • 基于经典的发布订阅模式
    • 传输的消息是纯二进制数据，网关也无需关心业务方的具体协议规范和序列化方式。
  • 权限设计
    • 基于回调的鉴权
    • Topic 模板变量
  • 消息可靠性保证
    1. 回执和重传
    2. 基于消息队列的接收和发送方式
• 我们怎么设计系统架构
• 我们如何构建长连接网关
  • 接入层
    • 负载均衡
      • 为什么不用IP Hash： 分布不均匀和不能准确的标识客户端。
      • 基于七层负载均衡，使用 Nginx 的 Preread机制。实现基于客户端的唯一标识来进行一致性 Hash
  • 订阅
  • 发布
  • 会话
  • 持久化
  • 滑动窗口

基于 Flink 的资讯场景实时数仓

如何将 Kafka 和 Flink 进行整合，通过消息队列 Kafka 版和实时计算 Flink 实现实时 ETL 和数据流。

参考资料

[1] Alicloud: 基于Flink的资讯场景实时数仓