Shrimp_millet

postSubscriptionWhenPull为true时，client在拉取时每次都会传递subscription，broker会以client传递的为准但是postSubscriptionWhenPull默认为false，所以tag 或者sql过滤时client没传subscription，broker会从本地取classFilter时client从filter Server拉取消息。

/ 自定义过滤类@Override// 自定义过滤逻辑// 示例：只接受北京地区且包含"important"的消息需要服务端过滤减少网络传输过滤条件相对固定且简单不同消费者需要不同数据视图消息量较大，客户端处理压力大简单过滤用 Tag，复杂过滤用 SQL92，特殊需求用自定义过滤类。

大部分业务场景推荐使用 DefaultMQPushConsumer只有在需要精细控制消费逻辑时才使用 DefaultLitePullConsumer从 Push 切换到 Pull 需要慎重，因为失去了很多内置的可靠性保障。

DefaultLitePullConsumer是业务消费时主动拉取的入口。

测试不同故障场景下，读写的行为。

RocketMQ有同步刷盘与异步刷盘的方法，可以根据场景进行选择刷盘的方式，同步刷盘对性能影响比较大，但是可靠性比较高，因为要等到消息刷盘以后才给生产者返回确认消息；异步输盘方式只要写入到缓存以后就给生产者返回确认消息，同时采用后台异步的方式进行刷盘，提高了性能以及吞吐量。

RocketMQ采用两阶段提交（2PC）的思想来实现事务消息，当事务消息失败或者超时，同时采用补偿的方式处理这个问题。这两个阶段分别为正常事务消息的发送与提交以及事务消息的补偿。我们看看官方文档给的事务消息的流程图：1、事务消息的发送与提交MQProducer将事务消息发送给MQServer（Broker服务器），这时的消息称为半消息，半消息是不能被消费者消费的。

先关掉broker的读写权限，客户端对这个节点的读写操作会报nopermission异常，客户端会重试其他节点。配置文件broker-a.properties。观察该节点无读写流量后，再执行下机器操作。配置文件目录conf。

到此为止，Broker注册的代码就分析完成了，总而言之，Broker注册就是Broker将相关的元数据信息，如Broker名字，Broker地址、topic信息发送给NameServer服务器，NameServer接收到以后将这些元数据缓存起来，以供后续能够快速找到这些元数据，生产者和消费者也可以通过NameServer服务器获取到Broke相关的信息，这样，生产者和消费者就可以和Broker服务器进行通信了，生产者发送消息给Broker服务器，消费者从Broker服务器消费消息。

读写队列的数量可以动态修改，初始读写队列都是16，缩容时，写队列先调整为8，读队列不变，后8个queue中的消息消费完毕后，再将写队列调整为8，整个缩容过程不会丢失任何消息。：相同consumer group中的每个consumer平均分摊同一topic中的消息。：所有的消息都存储在同一个Commitlog文件中，确保消息发送时顺序写文件，尽最大的能力确保消息发送的高性能和高吞吐量。○ 物理偏移量（8字节）：这是消息在CommitLog文件中的物理位置，即消息的起始字节在文件中的偏移量。