PHP generates unique identification code under high concurrency

As the title goes, first of all, thank you to all the experts who responded.
Describe the problem:

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

The question now is:

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

Reply content:

As the title goes, first of all, thank you to all the experts who responded.
Describe the problem:

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

The question now is:

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

I will mention a method: preprocessing identifiers

1. Generate absolutely unique identifiers through the algorithm in advance. You can test it yourself during this process, and because it is pre-processed, there is no need to consider time and algorithm complexity.

2. Write the generated unique identifier into the database

3. Only use read operations in high concurrency scenarios

The above mainly solves the problem of fast response under high concurrency, so how to ensure uniqueness?
There are two ideas:

1. Use queues for reading to ensure that all reads are completed through a unique queue, such as using redis’ pop operation

2. Use the sql update command. At this time, another field userid is needed. Pseudo code: update TABLE set userid = $userid where userid = 0 limit 1;, and then use userid to query the corresponding identifier.

Finally, the point I insist on is: design the code to be as safe as possible from the very beginning. Note that security issues must be considered with high priority. As for what are the “high concurrency” scenarios in real scenarios? I just want to say that if something goes wrong, the programmer will still have to take the blame.

If it is required that there is absolutely no repetition, then I think there are two ideas

1. Randomly generate new id data for persistence each time, and then check whether the historical data is repeated each time the randomly generated data is generated (but this is definitely a comparison for data persistence every time) Consumption of performance)

2. Accumulate according to rules (such as date and time stamp balabala), so that the generated ones will not be repeated, but you should consider how to avoid repetition in high concurrency.

I would like to ask a question: Are you more worried about generating the same identification code in a concurrent state or are you more worried about generating historical duplicate identification codes?

If you are worried about concurrency, you should consider adding a certain amount of random numbers to the microsecond-level characters you mentioned (each random number can be converted into characters according to ASCII between 48-122), just add a few more Yes, although theoretically there is no absolute non-repetition, the probability should still be very small

If you think about history repeating, then the two things I thought of are the two mentioned at the beginning

Try using the lock mechanism. .

1 +1 every time you write a file

2 Since you are a promotion system, this unique code will be unique as long as you bring your user ID

3 When I see this kind of high concurrency problem, I feel that I am so idle that the entire Internet is going to There are really not many companies that deal with high concurrency, and they use so much high concurrency. It feels like now, frameworks, systems, high concurrency, and caching have become the mantra of programmers.

You can generate an item, insert it into the database, create a unique index, and let the database remove duplicates for you

Generate a corresponding 62-digit string based on the unique ID in the database.

Many articles analyze the rules of short URLs to generate hexadecimal numbers. In theory, the ID will not be repeated and the string will not be generated repeatedly, but the length will change. See if it's acceptable.

There aren’t that many really high-concurrency things, so requiring high-use user IDs is another way.