RocketMQ学习总结

RocketMQ

1.部署模式：

	单Marster（即一个broker）
	多Marster（即多个broker）
	一主一从或多从（即一个broker，多个slave）
	多主多从（异步复制或同步双写）(即多对broker-slave)

2.相关术语：

	nameServer:类似服务注册发现的集群进程，每个nameServer可独立提供服务，互相之间没有强依赖。
	broker:提供RocketMQ核心服务的集群进程。具体功能的执行由下列子模块完成。
		client:客户端模块。供producer和consumer依赖使用，用于消息的生产与消费。
		store:具体执行存储的子模块。
		remoting:使用netty进行远程数据传输的子模块。
		tools:命令行工具。
	filtersrv:为consumer提供复杂消息过滤的单独进程，与broker部署在同一机器上。
	producer:一个生产消息的应用集群。用同一个producerGroupName来标识。
	consumer:一个消费消息的应用集群。用同一个consumerGroupName来标识。
	producerGroup:每一个生产消息的集群式的应用归为一个producerGroup,用同一个producerGroupName来标识。每一个producerGroup可以发送多个topic。
	consumerGroup:每一个消费消息的集群式的应用归为一个consumerGroup,用同一个consumerGroupName来标识。每一个consumerGroup可以订阅多个topic。
		消息的消费是以consumerGroup为单位进行负载均衡的。
	topic:用于将消息进行分类，且还有一个子分类tag，以此来唯一标识一个消息。

	异步复制:broker在存储producer发来的消息后在没有通知slave之前就通知producer接收成功，后续异步将消息给到slave。有丢失消息的可能。
	同步双写:broker在自身和slave都保存完消息后才通知producer接收成功。效率较异步复制低10%。不会丢失消息。

	物理部署示图（下面每一个节点都是可以是单个或集群）：
			nameServer
		       /    |     \
	       producer - broker - consumer

3.整个功能服务的过程

	启动顺序nameServer>broker>filtersrv>consumer>producer
	每一个broker会实时将自身状态和存储的topic信息同步给每一个nameServer。
	consumer从nameServer上获知broker和topic信息，并从broker订阅和消费topic，消费方式有push和pull两种模式。
	producer从nameServer上获知broker和topic信息，创建并发送消息到broker上，生产模式有：普通模式、顺序模式、事物模式。
	filersrv作为消息复杂过滤请求和响应的中间人，处于broker和consumer之间，帮助consumer在服务端完成消息过滤。
	默认属于同一个topic的所有消息会均摊发送到broker集群，同时每个broker会为每一个topic创建4个队列，消息会均摊放入每个队列里。

4.消息类型

	a.普通模式：producer以负载均衡式的方式生产和消费消息，不保证顺序。(这里的负载均衡是说broker集群以均摊的方式接收消息)
	b.顺序模式：遵循全局顺序的时候使用一个队列，局部顺序的时候可以使用多个队列并行消费。
		例如：producer要保证同一订单下的不同消息发送到同一队列里就可以了，消费端从队列有序的消费消息。
			而且多个订单可以在不同的队列中并发处理，减少了相互阻塞。
	c.事物模式：producer先将消息发送到borker中，但对消费端不可见，等生产者端的事物提交成功后再通知broker变消息为可见。

5.producerAPI(生产者端API)

	可以在代码里创建producer时设置相关参数，比如：压缩消息、重试、超时时间、消息体最大值限制等。
	可以发送三种模式的消息。

6.consumerAPI(消费者端API)

	可以设置消息的消费模式：集群消费、广播消费。
		集群消费（默认）：消息的消费是以consumerGroup为单位进行负载均衡的，即consumer集群会均摊消费一个topic下的所有消息。
		广播消费：topic下的每一个消息都会被consumer集群的每一个consumer消费一次。
	push和pull本质上都是拉去，实际上push模式是在client端封装了循环拉去，拉到消息后触发监听器，对用户感觉是在推。
	推荐使用push模式，不用指定拉取的队列和队列中的下标且不用自己实现补偿消费。但如果消息量很大，严重影响到消费端性能时就用pull模式。
	当consumer不返回或返回错误ACK时broker端有消息重试机制，consumer如果消费失败时可以获取此条消息已经重试的次数判断是否继续重试或记录日志等。
	默认重试间隔：1s、5s、10s、1m、2m、3m等。

7.重复消费和幂等性

	由于各种原因，消息会被consumer重复消费，此时需要consumer端保证幂等性。
	幂等性：同一消息的多次消费结果相同。
	如何保证幂等性：根据数据库的唯一索引或用redise的key不可重复性。

8.多主多从

	从节点不提供写服务，且只有在主节点挂了的情况下提供读服务。
	同一消息在从节点被消费后，在主节点修复重启时不会被重复消费。