syhleo commented on PR #8469: URL: https://github.com/apache/rocketmq/pull/8469#issuecomment-2270692927
> > > > > If the grayscale message and normal message data formats are inconsistent, and grayscale is enabled for production but not for consumption, will the grayscale data consumed normally fail to parse or cannot be processed normally? > > > > > > > > > > > > Yes. If only the production is gray, the consumption is not gray, that is, the gray consumption does not exist at all, that is, all the messages are consumed by the normal consumer end. However, first of all, the change of MQ message data format, the production side and the consumer side are to be logically adjusted together, if your business scene inside the production side of the grayscale message and the data format of the ordinary message is inconsistent, the consumer side needs to follow together with the grayscale, so that the grayscale consumer side consumes the grayscale message (data format A). The normal consumer consumes normal messages (data format B). This is also the full-link gray scale release that we have been advocating. > > > > > > > > > What I want is that the grayscale queue can only be consumed by grayscale consumers. When there is no grayscale consumer, I don’t want the data of both the grayscale queue and the ordinary queue to be consumed by normal consumers, so that the data is strung together. > > > > > > When implemented this way, there will be problems. Imagine this: If your producer service is in a grayscale environment, at this time a steady stream of grayscale messages are sent, and your consumer service is not in grayscale (because the consumer service has no distribution requirements at all, it has been a non-grayscale state), if the grayscale queue can only be used by grayscale consumers, in this case, the grayscale queue will cause a large number of messages to accumulate. During grayscale, grayscale queues can only be used by grayscale consumers, provided that there are grayscale consumers. If there are grayscale consumers, it is absolutely guaranteed that the grayscale queue can only be used by grayscale consumers. What we need to do is, during the full link gray scale release, the messages sent by gray scale producers can be accurately consumed by gray scale consumers, and the messages sent by non-gray scale producers can be accurately consumed by non-gray scale con sumers, so that the gray scale verification involving MQ message changes can be preserved in the business. In order to ensure the normal switching between gray level and gray level, the same group of consumers perceive each other whether there are consumers with gray level identification to determine whether non-gray level consumers need to take over the gray level queue message. > > Our usage scenarios are different. In our production implementation, grayscale can only be consumed by grayscale, and grayscale and ordinary messages are separated. Otherwise, they will be mixed and the meaning of grayscale will be lost. > > > > > If the grayscale message and normal message data formats are inconsistent, and grayscale is enabled for production but not for consumption, will the grayscale data consumed normally fail to parse or cannot be processed normally? > > > > > > > > > > > > Yes. If only the production is gray, the consumption is not gray, that is, the gray consumption does not exist at all, that is, all the messages are consumed by the normal consumer end. However, first of all, the change of MQ message data format, the production side and the consumer side are to be logically adjusted together, if your business scene inside the production side of the grayscale message and the data format of the ordinary message is inconsistent, the consumer side needs to follow together with the grayscale, so that the grayscale consumer side consumes the grayscale message (data format A). The normal consumer consumes normal messages (data format B). This is also the full-link gray scale release that we have been advocating. > > > > > > > > > What I want is that the grayscale queue can only be consumed by grayscale consumers. When there is no grayscale consumer, I don’t want the data of both the grayscale queue and the ordinary queue to be consumed by normal consumers, so that the data is strung together. > > > > > > When implemented this way, there will be problems. Imagine this: If your producer service is in a grayscale environment, at this time a steady stream of grayscale messages are sent, and your consumer service is not in grayscale (because the consumer service has no distribution requirements at all, it has been a non-grayscale state), if the grayscale queue can only be used by grayscale consumers, in this case, the grayscale queue will cause a large number of messages to accumulate. During grayscale, grayscale queues can only be used by grayscale consumers, provided that there are grayscale consumers. If there are grayscale consumers, it is absolutely guaranteed that the grayscale queue can only be used by grayscale consumers. What we need to do is, during the full link gray scale release, the messages sent by gray scale producers can be accurately consumed by gray scale consumers, and the messages sent by non-gray scale producers can be accurately consumed by non-gray scale con sumers, so that the gray scale verification involving MQ message changes can be preserved in the business. In order to ensure the normal switching between gray level and gray level, the same group of consumers perceive each other whether there are consumers with gray level identification to determine whether non-gray level consumers need to take over the gray level queue message. > > Our usage scenarios are different. In our production implementation, grayscale can only be consumed by grayscale, and grayscale and ordinary messages are separated. Otherwise, they will be mixed and the meaning of grayscale will be lost. Well, each scheme has advantages and disadvantages. For schemes such as Shadow topic and group, on the one hand, there is a critical problem, that is, when gray verification is switched to prod, there may be messages missed consumption, which is unacceptable. On the other hand, there is the cost problem. If you think about the relatively large scale of the business, the cost brought by doubling each topic and group can not be ignored. This solution is to let rocketmq native support grayscale capabilities through gray partitioning, so that users low cost, easy access. -- 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]
