hepyu commented on issue #12800: URL: https://github.com/apache/pulsar/issues/12800#issuecomment-973801437
> @hepyu I think there are 2 questions > > 1. The consumer stop consuming data from the topic, looks you already point out the root cause > 2. For the second one, I think you can try to reduce the receiver queue size of the consumer, by default you will receive 1000 batches(might more than 1000 messages) when starting the consumer 2这个调整也没用。类似的调整消费rate等也是没有用的。都是只能让服务慢点死。 造成本issue的根本原因： key_shard模式下，pulsar-client会用一个receiverQueue不断接收pulsar-broker推送过来的消息，receiverQueueSize只能限制这个queue的大小，但这个限制没用，只能让服务慢点死。因为每个shard都在client分配了一个singleThreadPool来处理，而这个singleThreadPool是一个无界队列，receiverQueue不断接收到消息后转发到shard的threadPool中的无界队列后，receiverQueue继续从pulsar-broker接收推送来的消息，直到把所有的shard的threadpool的无界队列打到最大极限，把服务吃死。 这个问题只有两种解决方式： 1.增加consumer的消费节点，和每个消费节点的消费能力。但是我们的业务场景是不可能的，因为处理速度是恒定的，我不可能无限加节点去解决这个问题。如果还要用这个方式，当出现这个问题后，只能临时加节点结合不断重启来解决，这样做也很奇葩。 2.改用同步pull的方式去消费，肯定没有问题。对于我们的业务来说，这个是正确选择。 pulsar的这个设计本身来说没有任何问题，push类型本来就是给高tps消费能力的场景使用的。但是我有个建议：是否能在push的这个方案上进行优化，来解决我们遇到的这个问题，比如shard的threadpool的无界队列是否可以可配，结合对broker的通知来控制推送强度。不过，这个貌似很麻烦。 这个issue我关了。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
