RocketMQ读书笔记2——生产者

【RocketMQ读书笔记2——生产者】的更多相关文章

RocketMQ读书笔记2——生产者

[生产者的不同写入策略] 生产者向消息队列里写入数据,不同的业务需要生产者采用不同的写入策略: 同步发送.异步发送.延迟发送.发送事务消息等. [DefaultMQProduce示例] public class ProducerQuickStart { public static void main(String[] args) throws MQClientException,InterruptedException { /**1.设置Producer的GroupName**/ Default…

RocketMQ读书笔记7——吞吐量优先的场景

[Broker端进行消息过滤] 在Broker端进行消息过滤,可以减少无效消息发送到Consumer,少占用网络宽带从而提高吞吐量. [过滤方式1——通过Tag过滤] [ 关于Tag和Key ] 对一个应用来说,尽可能只用一个Topic,不同消息子类型用Tag来标识,每条消息只能有一个Tag,服务端基于Tag进行过滤,并不需要读取消息体的内容,效率较高.Producer发送消息设置了Tag以后,Consumer在订阅消息时,才会利用Tag在Broker端做消息过滤. 消息的Key,发送的消息设置…

RocketMQ读书笔记6——可靠性优先的使用场景

[顺序消息] 顺序消费是指消息的产生顺序和消费顺序相同. 比如订单的生成.付款.发货,这三个消息必须按顺序处理才可以. [顺序消息的分类] 全局顺序消息和部分顺序消息. 上面订单的例子,其实是部分顺序消息,只要保证同一个订单ID的三个消息能顺序消费即可. [全局顺序消息] [部分顺序消费] 在实际的场景中,更多的是像订单类消息那样,只需要部分有序即可. [ MessageQueueSelector ] Producer发送端使用MessageQueueSelector类来控制把消息发往哪个Mes…

RocketMQ读书笔记5——消息队列的核心机制

[Broker简述] Broker是RocketMQ的核心,大部分“重量级”的工作都是由Broker完成的,包括: 1.接受Producer发过来的消息: 2.处理Consumer的消费信息请求: 3.消息的持久化存储: 4.消息的HA机制: 5.服务端的过滤功能. [消息存储] 分布式消息队列因为有高可靠性的要求,所以数据要通过磁盘进行持久化存储. RocketMQ的消息是存储到磁盘上的,这样既可以保证断电后恢复,也可以不受内存大小的限制. [ 磁盘存储的“快”——顺序写 ] 磁盘存储,使用得…

RocketMQ读书笔记4——NameServer(MQ的协调者)

[NameServer简述] 对于一个消息队列集群来说,系统由很多机器组成,每个机器的角色.IP地址都不相同,而且这些信息是变动的(如在某些情况下,会有新的Producer或Consumer加入). NameServer的存在主要是为了解决这类问题,由NameServer维护这些配置信息.状态信息,其他角色都通过NameServer来协同执行. [NameServer的功能] NameServer是整个消息队列中的状态服务器,集群的各个组件通过它来了解全局的信息.各个角色的机器要定时向NameS…

RocketMQ读书笔记3——消费者

[不同类型的消费者] DefaultMQPushConsumer 由系统控制读取操作,收到消息后自动调用传入的处理方法来处理. DefaultMQPullConsumer 读取操作中的大部分功能由使用者自动控制. [DefaultMQPushConsumer的使用] [特点] 1.系统收到消息后自动调用处理方法来处理消息,自动保存Offset. 2.加入的新的DefaultMQPushConsumer会自动做负载均衡. public class QuickStart { /** * Defaul…

RocketMQ读书笔记1——简述

[消息队列的功能介绍] 分布式消息队列可以提供应用解耦.流量削峰.消息分发.保证最终一致性.方便动态扩容等功能. [MQ使用场景1——应用解耦] 复杂的系统如电商系统,会存在多个子系统,如订单系统.库存系统.物流系统.支付系统.如果各个子系统之间耦合性太强,会导致整体系统的可用性大幅降低,多个低错误率的子系统强耦合,会得到一个高错误率的整体系统. 用户创建订单后,如果耦合地调用库存系统.物流系统.支付系统,任何一个子系统出现故障不可用,都会造成下单操作异常,影响用户体验. [ 举例——通过MQ解…