背景
公司有一个topic，消费者160多个，全都使用了tag来区分消息，在压测的时候，发现一个问题，消费者触发了积压告警，压测的consumerA还没开始压测，平台显示 consumerA的积压值在不停的变化。而且实际上生产者并没有发送consumerA所使用的tag，理论上不应该有积压才对。
在平台上看consumerA的积压情况，到集群通过命令行查看也是一样都显示积压。
原因分析
假如消费者在消费offset=100的这条tag1消息后，后面连续出现1000W条非tag1的消息，客户端向服务端拉取消息，连续1000W条消息都不符合条件，一次过滤查找这么多消息，肯定非常耗时，客户端也不能等待这么久，那服务端必须采取措施，必须触发一个停止查找的条件并向客户端返回NO_MESSAGE。
客户端在消息查找时最大的超时时间为30s。如果服务端连续1000W条非tag1的消息，拉取请求不会一次性筛选，而是会返回，不至于让客户端超时。
所以我们所看到积压，并不是真正的积压，而是消费者为了能正常消费到属于自己tag时不会超时导致。实际上这个显示的积压值不会对业务产生影响。
如果大家有兴趣研究源码，可以查阅丁威老师出版的《RocketMQ技术内幕》书籍。
