多问几个为什么！
- 什么是自增id？
- 为什么游戏后端需要自增id？使用唯一id不行吗？
- 自增id有哪些方案？
- 我选择什么方案？为什么这么选择？
给出自己的见解
- 自增id是指 一个接口返回的值是一个正整数，且该接口多次调用后不断增加(可能每次不是加1)且不重复。
- 游戏业务中包含角色等
初始配置相同，可重复获得，不可堆叠的的元素，需要使用唯一id加以区分。自增id有唯一id的特性，并且对数据库插入操作更加友好。 - 自增id有多种方案
| 方案 | 性能 | 优点 | 缺点 |
|---|---|---|---|
| 使用关系数据库主键自增 | 低 | 实现方便 无需额外依赖 | 性能低 无法高并发 |
| snowflake雪花算法及其衍生算法(uidgenerator, leaf, tinyid等) | 超高 | 性能超高 单机可实现 | 使用时间有限制 需额外配置机器id或者workId |
| redis的incr原子自增命令 | 高 | 实现方便 无需额外依赖 | 可能会有重复id |
- 综合来看，使用snowflake算法或者redis自增id都是可行的，最终我选择的是
redis的incr原子自增命令。有以下几点原因：
- redis的自增id性能满足需求
- 后端框架本身依赖redis，实现非常方便
- 在redis设置AOF落地策略时，不会有重复id，性能上有所下降，玩家在线不高的情况下也能满足需求。
- 对redis自增id有更高性能需求，也可以选择使用RDB方式落地，选用此种方式可能会由于redis宕机导致重复id的出现。重复id出现后，后端框架在数据同步过程中也能自动补偿。
标签：自增,重复,redis,算法,选型,使用,id 来源： https://blog.csdn.net/s476685226/article/details/122790954
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。