讨论下高并发、连续自增的 id 的生成方案

提前生成好，分发只需要查询修改。

如果是绝区零这样的成熟游戏与应用，基本可以确认用的是传统 RDMS （如 MySQL ）来保存账号。

不能只想着分配 id ，别忘了还用户资料、昵称、人物数据等等。这些都得有地方存啊。说来说去，还是数据库赛高。

我不那么相信 “几分钟就生成了上百万 id”，可能是之前预约用户已经分配、初始化好账号了。如果我是该产品的开发，一定会想出削峰填谷的策略。

退一万步“几分钟的百万次请求”其实也并不算大，3K QPS 情况下，5 分钟就可以生成 100w 个数据了，3K QPS 插入，在 SSD + 较多核服务器 + user 表 sharding 情况下，还是可以扛住的。但这样搞，技术风险大，压力测试也难做。想必还是用预约玩家的数据已经生成好了

为什么非要自增不可呢

不要小看了跑在高性能 SSD 上的数据库的性能啊

一、分布式 ID （ MybatisPlus 、Twitter 、美团）
二、数据库插入行为由 MQ 或线程池异步执行，避免高并发可能造成的 ID 生成问题
三、有没有好心人捞个 Java 开发

@dwu8555 确实没必要，不过楼主的例子，绝区零是自增的而已

我猜是中心发号段+预分配。
不是来一个帐号发一次，而是一个登录服务器会预取一段号码（ 1000-几万个），中心发号器只需要一段段分配就行了。

这也能解释为啥有人就是登录卡了一下，uid 直接上 100 多万了都。。

高并发系统嘛，无非就是来来回回几个方案，去中心化，批处理，异步队列。核心就是打散 IO 压力。

@Ashe007 没有看到连续递增的需求，可能需要根据 Twitter 的雪花算法稍微定制下

@0608516518 #2 楼主，qps 和 tps 是怎么理解的？生成 id 包括请求-生成-返回才算做完，我认为应该用 tps 吧。
单算 qps 请求性能不完整吧。

都是提前分发的，不存在一个单点且可靠的高性能自增方案，A 机器领 2000 ，B 机器领 2000 号段就行了，反正最终是肯定会用完的

有没有一种可能，这点数据量，什么都不用考虑，机器就能扛下来？

假设 1 分钟生成一百万个自增 ID ，平均每秒 16666 个自增 ID 。

Redis benchmark ，https://openbenchmarking.org/test/pts/redis ，i3-8100T ，每秒 123 万个 request 。

另外自从 SATA-SSD 普及以来，有没有发现，关于数据库性能的讨论，越来越少了？ nvme-SSD 普及后，这类讨论几乎绝迹了。原因是，1 块正规的 SATA-SSD ，性能是 HDD 的 100 多倍，甚至 pcie5-nvme 能达到 2 千多倍。

建议学软件开发的，一定要经常关注硬件性能测试。

游戏开服是一件完可以预估到并发情况的事情，这种情况就直接按照预估去预分配就可以了

@dwu8555 #4 有没有一种可能楼主是在问《绝区零是如何实现连续自增 ID 的》

我理解你以为的是：按照请求顺序，严格顺序递增。实际上不一定是这样，可能前一秒注册的比后一秒 ID 大。

很多框架啊。都是 8 楼说的那样一个服务生成一大堆，客户端每次拿一批。

@cheneydog 哦严格来说确实是 TPS 。只不过站在后端视角，一个 API call 一般也就是一个 transaction 。所以 QPS 与 TPS 基本一致。

当然你可以说强调数据库写入性能时用 TPS ，强调应用服务器处理请求时，使用 QPS

不是严格递增的话，数据库主键自增性能也是够的，可以多部署几个数据库实例进行分片，然后写一个提前生成 id 的功能应对开服流量。

通常不会用 redis ，正常的时候没问题，万一出了问题，就是大问题，这个风险不敢赌
最好就是关系型数据库，通常就是 ID 分段，用个表管理 ID 段（这个表里可以根据预期预设好），每个实例已有段用完了就拿新的，段内自己做自增，万一故障恢复所需要校验的也不多
这样无法严格保证一定是小先大后（只要一个段不是特别宽，也很难察觉到），但基本能保证连续，没有跳号
这样缩容扩容也简单，无脑加减机器就行（严格连续的话，减机器是要做处理的）

不太可能是实时自增，要我做我肯定是号段分配的，根据地区百分比做服务器权重分发

甚至我缺德一点给预约玩家提前分一个靠前号段的 id （

提前生产 1000w 个，如果余额不够 1000w 就补足到 1000w 。新用户来就直接分配，用不着实时生成

5 分钟 1000w ， 每秒钟 tps 是 33333 ， 假设 16 张表，每秒 2000 ，如果还多 2 个 mysql 实例，每秒 1000 ， 还觉得多再拆表*2 ， 每秒钟 500

广告新思路？好几个《绝区零》的帖子了

用 MySQL 的话，有内置的顺序 ID 生成器，非常好用：

SELECT uuid_short() AS id;

这个内置 ID 生成器性能非常，也不用担心 ID 生成器会挂导致所有服务受影响，因为当你数据库都挂了，那么你什么都挂了。

这个生成器我目前发现唯一的缺点：有部分云厂商的定制化 MySQL 会返回 19 位的数字，刚刚好超出 Java 里 long 的范围（因为 Java 没有 unsigned ，最数字是 9,223,372,036,854,775,807 ）。

1. REDIS 单实例写 ops 扛 1w 毫无压力, 正常 key 分散的情况下 5-6w 应该可以, 但这种热 key 不确定
2.预计就是实现了一个 id 生成器, jvm 中预先分配号段, 我之前实现过, 这种简单的接口单机扛百万 qps 毫无压力

我问下啊，是怎么确定的这个 ID 是连续的呢？

kv 支持下（比如 redis 效率已经很高了），需要中间件配合，设计思路如下：

1. 不是每次 incr 1 ，而是每次 incr step ，比如 +1000 ，那么就有 (X, X + 1000] 这个区间都可使用

2. step 的计算方式如下，比如设计成最多 T 时间，incr step ，运行中一直调整 step

3. 初始状态：step 初始化为 1 ，T 举个例子：1s ，变化倍数 rate: 2

4. 那么，1s 内如果多次 incr step ，那么 step = step * 2 ，让 step 尽量变长，尽量超过 1s

5. 当 incr step 间隔时间超过 2s ，那么 step = step / 2 ，让 step 尽量变小，尽量靠近 1s

6. 在 4/5 结合之下，step 将把 qps 接近 1s ，上下徘徊，算法可以微调

缺点：

重启的时候，会丢弃一些 id ，这个也可以细节改进，比如把未使用的 id 返回给 redis

最简单的就是提前生成好塞队列。
另一种类似多台 id 发放器，生成不同片的 id （单数，双数，末尾是 1 ，2,3 的），虽然他们严格上不连续，但在短时间内并发过程中是连续的。
就算最差的实现方式都可以用逻辑优化。

就算只用 mysql ，自增 id 5 分钟跑 100 万 完全轻轻松松啊，你自己搭个 mysql 试一下 5 分钟能插入多少就知道了。mysql 的经验在好的硬件面前已经跟不上了，一块 4k 性能好的 ssd 顶 10 个 dba 不是开玩笑。

如果不是非按严格的顺序自增的话，雪花 id 就行了吧，本地直接生成

你们是不是低估了 MySQL 的性能，几分钟几百万个请求，算什么垃圾

每个公司都有自己的发号器服务吧