[Improve][TubeMQ] Improve the precision of tube consumer id

[Reo-LEI]

Description

inlong/inlong-tubemq/tubemq-client/src/main/java/org/apache/inlong/tubemq/client/consumer/BaseMessageConsumer.java

Lines 589 to 594 in 017e400

	StringBuilder strBuffer = new StringBuilder(256)
	.append(this.consumerConfig.getConsumerGroup())
	.append("_").append(AddressUtils.getLocalAddress())
	.append("-").append(pidName)
	.append("-").append(System.currentTimeMillis())
	.append("-").append(consumerCounter.incrementAndGet());

In the k8s environment with hostNetwork enabled, there will be multiple pods running on the same host, and the ip of these pods will be the same.

Assume these pods are taskmanager as a flink cluster and the flink cluster is exclusive to a job. At this time, taskmanagers running on the same host will most likely have the same pid. And because each taskmanager has the same parallelism, so the number of tube consumers is also the same, and the self-incrementing id will also have the same probability at this time.

When the parallelism of the tube source is relatively high, it is easy for multiple consumers to be created in parallel at the same time. At this time, the timestamp is likely to have the same value, which makes the tube consumer id duplicate. In the end, the tube server has been unable to wait for enough consumers so that the flink job cannot consume any data.

Therefore, it is hoped that the accuracy of the consumer id can be improved to avoid the above situation.

InLong Component

InLong TubeMQ

Are you willing to submit PR?

• Yes, I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Hello @Reo-LEI, thank you for opening your first issue in InLong 🧡 We will respond as soon as possible ⏳
If this is a bug report, please provide screenshots or error logs for us to reproduce your issue, so we can do our best to fix it.
If you have any questions in the meantime, you can also ask us on the InLong Discussions 🔍

[Reo-LEI]

@gosonzhang Please take a look of this issue, thx~

[gosonzhang]

@Reo-LEI, thanks for your report

[gosonzhang]

Maybe replacing milliseconds with nanoseconds and adding random numbers would be a better way

[gosonzhang]

I'll push a PR to fix this, thanks @Reo-LEI