RocketMQ 消费者核心配置
- consumeFromWhere 配置（某些情况失效：参考https://blog.csdn.net/a417930422/article/details/83585397）这个配置基本不用改，采用默认配置即可。
- CONSUME_FROM_FIRST_OFFSET： 初次从消息队列头部开始消费，即历史消息（还储存在 broker 的）全部消费一遍，后续再启动接着上次消费的进度开始消费。
- CONSUME_FROM_LAST_OFFSET： 默认策略，初次从该队列最尾开始消费，即跳过历史消息，后续再启动接着上次消费的进度开始消费。
- CONSUME_FROM_TIMESTAMP：从某个时间点开始消费，默认是半个小时以前，后续再启动接着上次消费的进度开始消费。
- allocateMessageQueueStrategy：负载均衡策略算法，即消费者分配到 queue 的算法
默认值是 AllocateMessageQueueAveragely 即取模平均分配 - offsetStore：消息消费进度存储器 offsetStore 有两个策略：LocalFileOffsetStore 和 RemoteBrokerOffsetStore
广播模式默认使用 LocalFileOffsetStore， 集群模式默认使用 RemoteBrokerOffsetStore - consumeThreadMax：最大消费线程池数量
- consumeThreadMin：最小消费线程池数量
- pullBatchSize：消费者去 broker 拉取消息时，一次拉取多少条。可选配置
- consumeMessageBatchMaxSize：单次消费时一次性消费多少条消息，批量消费接口才有用，可选配置
- messageModel：消费者消费模式
- CLUSTERING：集群模式（默认配置）
- BROADCASTING：广播模式
集群和广播模式下 RocketMQ 消费端处理
Topic 下队列的奇偶数会影响 Customer 个数里面的消费数量
如果是4个队列，8个消息，4个节点则会各消费2条，如果不对等，则负载均衡会分配不均。
如果 consumer 实例的数量比 message queue 的总数量还多的话，多出来的 consumer 实例将无法分到 queue，也就无法消费到消息，也就无法起到分摊负载的作用，所以需要控制让 queue 的总数量大于等于 consumer 的数量。
集群模式(默认)：
Consumer 实例平均分摊消费生产者发送的消息
例子：订单消息，一般是只被消费一次（被标记为同一个 ConsumerGroup 组的消费者不会对消息重复消费）
广播模式：
广播模式下消费消息：投递到 Broker 的消息会被每个 Consumer 进行消费，一条消息被多个 Consumer 消费，广播消费中 ConsumerGroup 暂时无用。
例子：群公告，每个人都需要消费这个消息
怎么切换模式：通过 setMessageModel()
RocketMQ 里面的 Tag 作用和消息过滤原理
一个 Message 只有一个 Tag，Tag 是二级分类。过滤分为 Broker 端和 Consumer 端过滤。
- Broker 端过滤，减少了无用的消息的进行网络传输，增加了 broker 的负担
- Consumer 端过滤，完全可以根据业务需求进行过滤，但是增加了很多无用的消息传输
一般是监听 * ，或者指定 tag，|| 运算，SLQ92，FilterServer 等；
Tag 性能高，逻辑简单
SQL92 性能差点，支持复杂逻辑（只支持 PushConsumer 中使用） MessageSelector.bySql
语法：> ，<，=，IS NULL，AND，OR，NOT 等，sql where 后续的语法即可(大部分)