主要观点总结
本文介绍了在服务器中生成唯一ID的雪花算法的应用和改进过程，以及在账号ID生成中遇到的一系列问题和解决方案的探索过程。最终选择了预申请一批ID的方式，并设计了短ID方案细节，包括发号表的设计和各种情况的分析。
关键观点总结
关键观点1: 账号ID生成的问题和挑战
文章讨论了如何根据实际需求在服务器中生成账号ID，面临的主要问题是生成的ID过长和数据库自增ID的并发问题。
关键观点2: 雪花算法的应用和改进
初次考虑使用雪花算法生成ID，但由于生成的ID过长，需要进行改进。
关键观点3: 数据库自增ID的并发问题
尝试使用数据库自增ID生成账号ID时，遇到了并发死锁问题。
关键观点4: 其他解决方案的探索
讨论了其他可能的解决方案，包括使用多个数据库服务器、调整自增步长和间隔、读写分离等，但都存在一些问题或限制。
关键观点5: 最终解决方案的确定和实施
最终选择了预申请一批ID的方案，并设计了短ID方案细节，包括发号表的设计和启动、停用服务器时的情况处理。
文章预览
今天聊聊服务器中唯一ID生成。唯一ID生成中雪花算法大家都比较熟，那如果加一个要求呢： 尽量短的数字ID 背景 之前的项目有个需求：为用户账号生成账号ID。最开始用的是UUID（长字符串ID），但是字符串账号相对于数字账号，存储和传输性能都稍逊，也不利于记忆和传播。 因此，生成一套业务内的数字账号，并且尽量简短就是当务之急。 初步版本 我们最开始考虑的是雪花算法方案，使用的是经典的 twitter开源的算法 snowflake。这个算法非常强大，生成的是 64bit 的数字id，天然支持分布式。 有关这个算法的详细分析，可以移步： https://juejin.cn/post/7386243179278041128 雪花算法看起来无懈可击，但是唯一的问题就是生成的64位 ID 太长了。账号ID希望能控制的尽量短，个人理解有以下原因： 账号id一般显示在个人设置里，会暴露给用户，需要便于输入 + 记
………………………………
