Mysql ID生成策略的三种方法选择及优缺点 |
|
mysql ID生成策略一般常用的有三种：自增、UUID 以及雪花算法，下面就拿着三种展开分析一下 。 自增主键（Auto Increment）优点：简单、易于使用和理解，保证唯一性，无需额外的查询操作 。 缺点：不适用于分布式系统，因为每个节点都需要维护一个独立的计数器，可能会导致冲突和性能问题 。 使用场景：适用于单机或小规模应用，不需要分布式支持的场景 。例如，传统的单机应用、小型网站或内部管理系统 。 UUID（Universally Unique Identifier）优点：全局唯一性，分布式支持，独立性 。 缺点：占用较多的存储空间，无序性，可读性较低 。 使用场景：适用于需要分布式支持、全局唯一性和独立生成ID的场景，特别是在没有数据库连接的情况下 。例如，分布式系统、大规模系统或需要独立生成ID的场景 。 雪花算法（Snowflake）优点：支持分布式环境，生成的ID有序且唯一，包含时间戳信息 。 缺点：依赖于机器的唯一标识，不同机器之间的时间同步问题可能导致ID重复 。 使用场景：适用于需要分布式支持、有序和唯一的ID的场景 。例如，大规模的分布式系统、微服务架构、分布式数据库等 。 雪花算法生成 ID 冲突问题：1. 前提条件： (1). 预分配（静态） 应用上线前，统计当前服务的节点数，人工去申请标识位 。 这种方案，没有代码开发量，在服务节点固定或者项目少可以使用，但是解决不了服务节点动态扩容性问题 。 (2). 动态分配 将标识位存放在 Redis、Zookeeper、MySQL 等中间件，在服务启动的时候去请求标识位，请求后标识位并将其更新为下一个可用的 。 通过存放标识位，延伸出一个问题：雪花算法的 ID 是 服务内唯一还是全局唯一 。 以 Redis 举例，如果要做服务内唯一，存放标识位的 Redis 节点使用自己项目内的就可以；如果是全局唯一，所有使用雪花算法的应用，要用同一个 Redis 节点 。 两者的区别仅是 不同的服务间是否公用 Redis 。如果没有全局唯一的需求，最好使 ID 服务内唯一，因为这样可以避免单点问题 。 服务的节点数超过 1024，则需要做额外的扩展；可以扩展 10 bit 标识位，或者选择开源分布式 ID 框架 。 动态分配实现方案：Redis 存储一个 Hash 结构 Key，包含两个键值对：dataCenterId 和 workerId 。 雪花算法不是万能的，并不能适用于所有场景 。如果 ID 要求全局唯一并且服务节点超出 1024 节点，可以选择修改算法本身的组成，即扩展标识位，或者选择开源方案：美团LEAF、百度UID 。 总结根据实际使用场景进行选择： 单机或小规模应用：对于规模较小、不需要分布式支持的应用，ID自增是简单而可行的选择 。它易于使用和理解，并能保证唯一性 。 大规模分布式系统：在需要分布式支持、有序和唯一ID的大规模系统中，雪花算法是更合适的选择 。它能够生成分布式环境下的有序且唯一ID，适应大规模的分布式架构 。 分布式环境下的全局唯一ID：如果全局唯一性是主要要求，并且不需要严格的有序性，UUID是一个可选的策略 。它可以在分布式环境中生成全局唯一的ID，适用于分布式系统、大规模系统或需要独立生成ID的场景 。 需要注意的是，对于雪花算法和UUID，在分布式环境中需要注意时间同步问题 。确保机器时间的同步性，以避免ID重复 。 综上所述，选择适当的ID生成策略需要综合考虑系统规模、分布式支持、唯一性和有序性要求以及时间同步问题 。自增主键适用于规模较小、不需要分布式支持的简单应用，而雪花算法则适用于需要分布式支持、有序和唯一ID的大规模应用 。UUID 我们一般不做考虑，因为针对于分布式系统来说雪花算法比UUID方式性能更好，UUID占用存储更大 。 到此这篇关于Mysql ID生成策略的选择及优缺点的文章就介绍到这了,更多相关Mysql ID生成策略内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！ |
