优化特定格式的ID生成
我希望以特定的格式生成in。格式如下：
{N，S，E，W} {A-Z}连{YY} \ {0-9} {0-9} {0-9} {0-9} {0-9} {0-9}
"X“部分是一个固定的字符，第二部分可以是基于注册表格数据的4个值N、S、E、W(北、南、东、西)中的任意一个，第三部分是集合{ are }的字母表，与输入数据不相关(可以随机分配)，YY是当前年份的最后2位数字，最后一部分是从00000到99999之间的5位数字。
我计划通过生成所有5个部分并将结果连接到一个最终字符串来构造这个ID。生成每个部分的步骤：
这种格式每年为特定区域提供26x10^5=2600000个唯一ID，这对于我的用例来说就足够了。
为了处理冲突，我计划查询数据库，如果该ID已经存在于DB中，则生成一个新ID。这将继续下去，直到我生成一个不存在于DB中的ID。
这个策略是好的还是我应该使用其他的？当DB在特定年份中有很多特定区域的条目时，碰撞的近似概率或预期的DB调用数是多少？
我是否应该使用这样的顺序ID：
- 从第3部分中的"A“开始，在第5部分”
- Increment part 3“中从"00000”开始到"B"，而在第5部分
中使用了"99999“
如果我确实使用了这个策略，是否有一种方法可以实现这一点，而无需查看DB，以便首先找到最后插入的ID？
或者以这种格式生成ID的其他方式。我主要关心的是这个过程应该是快速的(不要太多的DB调用)。
如果没有办法绕过DB调用，我是否应该使用Redis这样的缓存来使其更快一些？这到底是怎么回事？
回答 1
Stack Overflow用户
发布于 2021-03-26 17:18:45
为了处理冲突，我计划查询数据库，如果ID已经存在于DB中，则生成一个新的ID。这将继续下去，直到我生成一个不存在于DB中的ID。
如果您为此进行了10个这样的DB调用，该怎么办。随机性的问题是，即使概率很低，也会发生碰撞。在高负荷的生产系统中，使用随机数据进行检查是危险的。
这种格式每年为特定区域提供26x10^5=2600000个唯一ID，这对于我的用例来说就足够了。
毫无疑问，你的射程很小。但是你需要看到塔哈特碰撞的概率是1/ 26 * 10^5，这不是很大！
因此，如果哈希大小没有问题，请阅读有关UUID、Twitter雪花等的内容。
--如果没有办法绕过DB调用，我应该使用像Redis这样的缓存来加快速度吗？这到底是怎么回事？
使用缓存是个好主意。同样，这里的问题是持之以恒。如果你在寻找一致性，那么Redis使用LRU，键会在时间上丢失。
下面是我解决这个问题的方法：
因此，我首先要为字符编写一个映射器范围。例:n从A到F，S从G到M等。
这确保了无核武器区之间的某种一致性。
在此之后，我们可以做随机方法本身，但与索引。
那么，假设有一个碰撞的机会。我们可以大幅降低这一价值。
将表中的唯一哈希设置为可索引。
这意味着你的搜索要快得多。
当您想插入时，生成2个随机散列并执行一个IN查询--类似于“从表中选择散列(hash1，hash2)”。如果这不起作用，下一次，您需要生成4个随机散列并执行相同的查询。如果它有效，请使用哈希。不断增加指数值以避免碰撞。
再一次，这是推测的，更好的approcahes可能在那里。
https://stackoverflow.com/questions/66820200
复制相似问题
腾讯云开发者
