How to prevent duplication of the auto-incrementing primary key of a high-concurrency website?

For example, the Weibo id of Sina Weibo, the user uid of registered users, the post number tid of Baidu Tieba, etc. I have observed that they all show an increasing relationship according to the publishing time, but I am very curious about this high concurrency Websites are generally distributed databases. There must be cache, message queue and other middleware before the database. So how to ensure that when multiple databases are finally inserted into multiple databases, there will be no duplication when the primary keys between them are automatically incremented?

And there are many random ID generation algorithms with low collision probability. Why are they not used by these high-concurrency websites? Is it due to efficiency?

Reply content:

For example, the Weibo id of Sina Weibo, the user uid of registered users, the post number tid of Baidu Tieba, etc. I have observed that they all show an increasing relationship according to the publishing time, but I am very curious about this high concurrency Websites are generally distributed databases. There must be cache, message queue and other middleware before the database. So how to ensure that when multiple databases are finally inserted into multiple databases, there will be no duplication when the primary keys between them are automatically incremented?

And there are many random ID generation algorithms with low collision probability. Why are they not used by these high-concurrency websites? Is it due to efficiency?

I would like to recommend you a knowledge article about the popular scienceID generator or global number generator
http://weibo.com/p/1001603800404851831206

Then I recommend an ID generator implemented in PHP named SnowFlake internally by Twitter
https://github.com/sschiau/Particle.php

I'm ready to start talking nonsense. . . .

The system starts from scratch, mostly from small to large.

In the beginning, money was scarce and time was tight. Naturally, whatever was officially supported was used, and whatever was simple and easy to maintain was used. If the later conversion costs are high, the risks are high, and the returns are low, who is going to deal with all this?

Secondly, with high concurrency, most of them will not be written concurrently.

Finally, even if you encounter the situation you mentioned, you can set up a number sender and send a self-increasing ID. Okay, now the question is, how to set up a distributed dispatcher. . .