为什么选择rocketMQ

参照：https://rocketmq.apache.org/docs/motivation/
搭建rocketMQ动机
在早起是基于ActiveMQ 5.X进行搭建了分布式消息中间件，但是当吞吐量增加的时候，发现消息集群处理非常迫切需要；

随后选择采用kafka，但是发现它本身是一个分布式流平台，对于alibaba的大吞吐，高并发的场景不适用；

所以alibaba发明了rocketMQ，该组件应用广泛，可以用于发布/订阅场景，用以满足高容量，消息不丢失的需求。

那为什么kafka不适用呢？

1.生产者的并行写操作会收到分区个数的制约
2.消费者消费并行性的程度也受到正在消费的分区数量的限制。假设分区的数量为20，则并发消费消费者的最大数量为20
3.每个主题由固定的分区数组成，所以分区去也制约了主题的个数；

kafka为什么不支持更多分区

1.Each partition stores the whole message data. Although each partition is orderly written to the disk, as number of concurrently writing partitions increases, writing become random in the perspective of operating system.

2.Due to the scattered data files, it is difficult to use the Linux IO Group Commit mechanism.

RocketMQ如何支持更多分区

1. 所有消息数据都存储在提交日志文件中。所有写入都是完全连续的，而读取是随机的。

2. ConsumeQueue存储实际的用户消费位置信息，这些信息也会按顺序刷新到磁盘。

每个消费队列都是轻量级的，包含的元数据数量有限。

对磁盘的访问是完全按顺序进行的，这避免了磁盘锁争用，并且在创建大量队列时不会导致高磁盘IO等待。

对比

常见问题

新创建的consumer从哪里开始消费

1. 如果是三天内发送的消息，则会从第一条消息开始消费
2. 如果是3天以前发送的消息（默认只保留3天），则三天前的消息就无法读取到了，将会从message queue的tail部位开始消费
3. 如果消费者重启，则会从上一次的消费offset位置开始消费

消费失败后，如何消费

1. 如果是集群模式，则会重试，最多16次重试机会
2. 如果是广播模式，则没有重试

如何查询消费失败的消息

1. 使用“按时间主题查询”， 可以查询这段时间内的消息。
2. 按照topic和消息ID可以精准查找某条消息
3. 按照topic和message key可以查询同一message key类型的消息集合

配置相关

1. 消息会被存储过久–默认存储3天
2. 消息体的最大大小限制是多少–256KB
3. 如何设置消费端的线程数

consumer.setConsumeThreadMin(20);
consumer.setConsumeThreadMax(20);