zoukankan      html  css  js  c++  java
  • consumer详解

    https://blog.csdn.net/weixin_42195284/article/details/93461429#7.1 push和pull模式

    push和pull模式

    在RocketMQ中,消费者有两种模式,一种是push模式,另一种是pull模式。

    • push模式:客户端与服务端建立连接后,当服务端有消息时,将消息推送到客户端。
    • pull模式:客户端不断的轮询请求服务端,来获取新的消息。

    但在具体实现时,Push和Pull模式都是采用消费端主动拉取的方式,即consumer轮询从broker拉取消息。

    区别: Push方式里,consumer把轮询过程封装了,并注册MessageListener监听器,取到消息后,唤醒 MessageListener的consumeMessage()来消费,对用户而言,感觉消息是被推送过来的。 Pull方式里,取消息的过程需要用户自己写,首先通过打算消费的Topic拿到MessageQueue的集合,遍历 MessageQueue集合,然后针对每个MessageQueue批量取消息,一次取完后,记录该队列下一次要取的开 始offset,直到取完了,再换另一个MessageQueue。

    疑问:既然是采用pull方式实现,RocketMQ如何保证消息的实时性呢?

    长轮询

    长轮询即是在请求的过程中,若是服务器端数据并没有更新,那么则将这个连接挂起,直到服务器推送新的 数据,再返回,然后进入循环周期。 客户端像传统轮询一样从服务端请求数据,服务端会阻塞请求不会立刻返回,直到有数据或超时才返回给客 户端,然后关闭连接,客户端处理完响应信息后再向服务器发送新的请求

    消息模式

    • 集群模式 
      同一个 ConsumerGroup(GroupName相同) 里的每 个 Consumer 只消费所订阅消息的一部分内容, 同 一个 ConsumerGroup 里所有的 Consumer消费的内容合起来才是所订阅 Topic 内容的整体, 从而达到 负载均衡的目的 。
    • 广播模式 
      同一个 ConsumerGroup里的每个 Consumer都 能消费到所订阅 Topic 的全部消息,也就是一个消息会 被多次分发,被多个 Consumer消费。

    重复消息的解决方案

    造成消息重复的根本原因是:网络不可达。只要通过网络交换数据,就无法避免这个问题。所以解决这个问题的办 法就是绕过这个问题。那么问题就变成了:如果消费端收到两条一样的消息,应该怎样处理?

    1. 消费端处理消息的业务逻辑保持幂等性
    2. 保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现

    第1条很好理解,只要保持幂等性,不管来多少条重复消息,最后处理的结果都一样。 
    第2条原理就是利用一张日志 表来记录已经处理成功的消息的ID,如果新到的消息ID已经在日志表中,那么就不再处理这条消息。 第1条解决方案,很明显应该在消费端实现,不属于消息系统要实现的功能。第2条可以消息系统实现,也可以业务 端实现。正常情况下出现重复消息的概率其实很小,如果由消息系统来实现的话,肯定会对消息系统的吞吐量和高 可用有影响,所以最好还是由业务端自己处理消息重复的问题,这也是RocketMQ不解决消息重复的问题的原因。

    RocketMQ不保证消息不重复,如果你的业务需要保证严格的不重复消息,需要你自己在业务端去重

  • 相关阅读:
    java实现验证码功能
    C# 自动注册OCX方法
    wamp出现You don’t have permission to access/on this server提示
    C# 图像旋转代码
    C# 实现图像快速 水平 垂直 翻转
    C#创建Graphics对象的方法
    winform控件大小改变是防止背景重绘导致的闪烁(转载)
    C#中DataTable中Rows.Add 和 ImportRow 对比
    MongoDb C# 驱动操作示例
    解决c#所有单线程单元(STA)线程都应使用泵式等待基元(如 CoWaitForMultipleHandles),并在运行时间很长的操作过程中定期发送消息。 转载
  • 原文地址:https://www.cnblogs.com/xhyouyou/p/12465573.html
Copyright © 2011-2022 走看看