PHP generates a unique identification code with high concurrency

Title, first of all, thank you for all the answers to Daniel.
Describe the problem:

学习PHP过程中想通过实践编写一套推广系统。推广地址:**http://xxxx.com/N4aF35aS7**"N4aF35aS7"作为一个识别码。

Now the question is:

PHP有函数以微秒级别获取字符,但是如果考虑到高并发(具体有多高不讨论,但需要考虑进来)可能会有重复?另外,识别码在生成上有规范:1.长度固定(8位左右,太长地址不友好)2.组合形式为大写、小写字母，数字(参考百度网盘分享地址)3.绝对不重复,这点很重要4.没什么要求了，再谢谢来回答的人。

Reply content:

Title, first of all, thank you for all the answers to Daniel.
Describe the problem:

学习PHP过程中想通过实践编写一套推广系统。推广地址:**http://xxxx.com/N4aF35aS7**"N4aF35aS7"作为一个识别码。

Now the question is:

PHP有函数以微秒级别获取字符,但是如果考虑到高并发(具体有多高不讨论,但需要考虑进来)可能会有重复?另外,识别码在生成上有规范:1.长度固定(8位左右,太长地址不友好)2.组合形式为大写、小写字母，数字(参考百度网盘分享地址)3.绝对不重复,这点很重要4.没什么要求了，再谢谢来回答的人。

I mention one way: preprocessing identifiers

1. An absolute non-repeating identifier is generated in advance by the algorithm, which can be tested on its own, and because it is preprocessed, it does not need to take into account time and algorithmic complexity.

2. Writes the generated non-duplicate identifiers to the database

3. Use only read operations in high concurrency scenarios

The above is mainly to solve the high concurrency under the rapid response problem, then the uniqueness of how to guarantee it?
There are two ways of thinking:

1. Use the queue to read to ensure that all reads are done through a unique queue, such as a pop operation using Redis

2. Using the SQL UPDATE command, this time requires another field userid, pseudo code: update TABLE set userid = $userid where userid = 0 limit 1; , and then use UserID to query the corresponding identifier.

Finally, I insisted on the idea that the code should be designed to be as safe as possible at the very beginning, and that security issues must be given high priority.
So what are the "high concurrency" scenarios in the real scene? I just want to say that there is a problem or a programmer to back the pot.

If the requirements are absolutely not repeated then I feel like there are two
1. Each time a randomly generated new ID data is persisted, and then the data is randomly generated every time the historical data is duplicated (but this will certainly be more cost-per-use for data persistence)
2. Accumulate by law (for example, by date-time stamp Balabala), so that the resulting will not be repeated, but how high concurrency is not repeated should be considered.

To ask the question what is the main worry is that the concurrency of the same identification code or is more worried about the generation of historical duplicate identification code?

If you are worried about concurrency, you should consider the microsecond-level characters wrongly written character plus a random number (each random number can be converted from ASCII to a character between 48-122), plus a few more bits, although theoretically not absolutely not repeating but the probability is still very small

If you think about historical repetition, then I'm thinking about the first two.

Try it with the lock mechanism.

1 Write files every +1
2 You're the extension system. The only thing you need is a user ID.
3 See this high concurrency problem feel is their own idle egg pain, the whole internet to deal with high concurrency of the company really not much, bring so much high concurrency. The feeling is now that the framework, the system, the high concurrency, the cache has become the programmer's mantra.

can generate a plug-in database to build a unique index let the database to you to the heavy

Generates a corresponding 62 binary string based on the unique ID in the database.
More articles Analysis of the short URL rules are generated 62, the theoretical ID is not duplicated and will not repeat the generation of strings, but the length will change. To see if it is acceptable.
Without that much real high concurrency, it's also a way to ask for a high user ID.

