开发者学堂课程【消息队列 RocketMQ 5.0 云原生架构升级课程：RocketMQ 5.0 多样消费功能详解消息过滤】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1234/detail/18399
RocketMQ5.0 多样消费功能详解-消息过滤
（3）两种模式差异
那介绍完这两种固定模式之后，来总结一下这两种模式的一个差异以及对比。那在过滤目标方面的话，它的标签过滤的话，主要是针对消息的标签进行过滤，然后说一些属性过滤的话，主要是针对消息的一些属性过滤，然后在过滤成本方面的话，它的标签过滤的话是基于哈希这种方式来进行过滤的，所以它的过滤的效率会比较高。然后计算也比较简单，然后circle属性过滤的话，它是需要用到SQL语法来进行匹配，然后整个计算过程的话会比较复杂一点，服务端对应的开销也会比较大。那么在使用限制方面的话，它的标签过滤它只支持单一维度的一个标签过滤，然后他支持的标签必须是可以获取的，然后多个标签之间那只能支持获得一个关系。然后生态属性过滤的话，它支持多维度的一个属性过滤，然后它可支持可枚举的，也可以支持不可枚举的。然后他还持这种疑惑，非这种复杂的一个逻辑关系的一个过滤，在使用成本方面的话，它和标记过滤它是比较容易上手的。Tag过滤然后的话，它需要掌握一定的语法，然后有一定的学习成本。那在使用场景方面的话，它的标签过滤它只支持那个简单的一个过滤场景，然后计算逻辑相对相对来说会比较简单和清亮一点。然后SQL属性过滤的话，它可以支持复杂的一些过滤场景，然后相应的它的计算逻辑也会变得更加的一个复杂。
四、最佳实践介绍
（1）主题划分及消息定义
接下来的话主要是来介绍一下消息过滤的两个最大的实践。那第一个最佳时间的话是关于如何进行主题的划分和消息的定义的主题和消息背后的本质，其实就是业务实体的一个属性，还有行为或者状态发生了一些变化。
那只有发生了变化的话，生产者才会往主题里面去发送消息，然后消费者才需要监听这个消息去完成自己的一个业务逻辑。
那么如何做好消息的一个主题划分以及消息的一个定义，以订单时期为例，
首先就是主题划分的一个原则，第一个原则的话是关于业务领域是否一致的问题，然后不同的业务领域它背后的一个 实体它是不同的，那他定的属性行为还有状态也是天差地别的。比如说商品和订单，他们都属于两个完全独立的一个业务领域，那就不能定成一个主题。第二个的话就是关于他们的业务场景是不是一致，同一个业务领域的话，它存在不同的业务和技术场景，比如说订单流程和那个订单缓存刷新这个流程的话，他们虽然跟订单有关系，但是订单缓存刷新，它可能需要被不同的流程触发。那复用订单这个流程的一个主题的话，就会导致部分场景缓存不上线的这样一个情况，所以他们是不能定义成一个主题的。
第三个原则的话是关于消息类型是否一致，那同一个业务领域和业务场景对消息类型需求是有可能不一样的。比如说订单处理过程中，需要发送一个事故消息，但是同时也要发生一个定时消息，那么这个这两个消息就不能共用一个主题。
那消息定义的原则是怎么样的，首先就是无标签无属性的这种情况，那对业务实体极其简单的，比如说blogo的同步，那就是不需要定义标签和属性的。那还有一种情况的话，就是让所有的消费者，它是没有这个消息过滤的一个诉求的，所以也也是不需要定义标签和属性的。
那么如何定义这个消息这个标签，那标签这个过滤它是Rocket MQ中使用最简单，然后而且性能最好的一种消息过滤方式，为了能够发挥其巨大的优势，可以考虑优先使用。在使用的时候需要确认这个字段，在业务时期和业务流程中它是否是唯一定义的，然后并且他是否被绝大多数的一个消费者作为过滤条件的，如果是的话，那可以将它作为一个标签来定义。比如来说就是订单中有下单这个渠道，还有订单操作这个两个字段了这两个字段都是唯一的，但是订单操作它会被大多数的一个消费者作为过滤条件，那么它这个字段的话就会比较合适作为一个标签来使用。
那么如何定义消息的属性， SQL的一个过滤，它的开销是相对比较大的。所以只有在那个标签过你无法得到满足的时候，才推荐使用。那比如说这个标签它已经被其他的数量给占用了，或者说它过滤这个这个字段，它是不可的，并且要支持多属性这种复杂逻辑的这种固定的，那就只能定义成属性，来使用那个收购过滤这种方式了。
（2）保持订阅关系一致
那么第二个属性的话是关于保持订阅关系一致性的一个问题，然后订阅关系一致性的话，主要是指同一个消费者组下面所有的消费者所订阅的那个 Topic和过滤表达式都是必须是完全一致的。
然后正如这个图所描述的消费者组下面的话，包括两个消费者，他们同时订阅了topic a这个主题，但是消费者一的话，他订阅的是Top a这个标签的一个消息，然后消费者二的话是订阅是tagb这样的一个标签的一个消息，那么他们之间的话就是产生了一个对应关系的一个不一致，那么地缘关系不一致的话，它会导致什么样的一个问题，然后第一个问题的话主要是会导致频繁的负载均衡，那就在使用过程中客户端会向 block定时的发送，那这个过程中会上传那个订阅关系。
那block发现这个订阅关系发生了变化了，就会去触发的客户端进行负载均衡。那么订阅关系两个不一致的一个客户端，他们就会去交叉去上传自己的一个订阅关系，从而导致那个客户端频繁的进行负载均衡。那第二个问题的话就是关于消费速率下降的一个问题，客户端触发了一个负载均衡之后，它会导致消费者所持有的一个消费队列发生了一个变化，那这个时候的话就会出现阶段性的一个暂停，消息拉取的一个过程，那导致整个消费的速率就会下降下来，甚至这个时候还会出现消息积压的一个情况，还有重复消费这个问题，客户端触发了一个负债均衡之后，会导致已经消费成功的消息。因为消费队列发生变化了，所以他就会放弃向block提交消费位点。那block会认为这条消息没有消费成功，从而向消费者去发起投递，那这样的话就会导致消息重复消费的一个情况。
那第四个点的话主要是消息未被消费的一个情况，地缘关系不一致的话会出现两种情况，导致那个消息未被消费。第一种的话就是的消费者，他的订阅关系跟block的订阅关系它是不一致的，所以就是消息就会在block这一端就会被过滤了。然后第二种的话就是的消费者和block订阅关系它是一致的，但是block又把这个消息投递都给了另外一个消费者，这个这个另外一个消费者把这个消费本地过滤掉了。
所以第一个建议就是不要共用消费者组，不同的业务系统的话，它是由不同的团队来维护的。他们如果使用同一个消费者组去定义同一个主题的消息的时候，就很容易发生一个团队改了之后，没有通知另外一个团队的这种情况，从而很容易导致订阅关系的一个不一致。然后第二个的话，就是 不要频繁的去变更那个订阅关系，这种情况的话会比较少，但是也存在部分用户实现的时候，是通过在线规则或者说动态参数来去设置一些订阅关系。那这样这有可能就是导游是订阅关系，很容易发生变化，第三个点的话主要是在做地缘关系变更的时候，需要做好风险的评估，由于那个业务的发展还需求的变更，订阅关系不可能是一直不变的，但是变更的时候，需要考虑整个变更发布过程中所需要的一个时间。还有一个整个发布过程中，对业务是不是会带来风险这种问题。第四个的话是也是比较重要的一点，就是在做消费的时候需要做好幂等处理，不管是订阅关系不一致，还是客户端的一个上下线，都可能导致消息的一个重复投递。
在业务逻辑中，消费者需要保证对已经处理过的消息直接返回成功。那一方面的话主要是为了避免二次消费对业务造成的一个损害。另一方面的话，如果返回失败的话，就会导致消费一直在从事，然后直到这个消息进入死线为止。
五、EDMO 演示
接下来然后针对这个消息过滤这个功能的话，做一个demo的一个演示。
Uh通过模拟订单的这个处理的流程来进行像小企业过滤这个演示，首先准备了两个订单，这两个订单的话是由不同的买家进行下单的，同时他们在不同的渠道，然后价格也是不一样的。
然后准备了两个订单的一个操作，第一个是下单，第二个是支付。然后会发送三三条消息，第一条消息的话主要是发送第一个订单的一个下单消息，第二个的话主要是放松一个订单的一个支付消息。第三个的话主要是放松第二个订单的一个下单消息，然后订阅者组方面的话，启动了两个消费者，然后第一个消费者的话主要是基于tag标签进行过滤的，然后它主要是订阅的是支付的消息。然后第二个 是基于SQL属性过滤的，订阅的是渠道一，并且价格大于5000的一个消息。
然后先来运行一下消费者。
消费者已经启动了，然后运行一下生产者来进行消息的一个发送，可以看到的三条消息都已经发送出去了，看一下消费者的一个情况，消费者这边的话基于tag，标签过滤的话，它收到了一个支付的一个消息，和订阅关系上面的一个设置是完全是一样的，第二个的话就是关于授课属性过滤一个结果，然后它主要消费的是渠道的一天猫，并且价格大于5000的一个消息。
