分布式ID

最新推荐文章于 2022-12-30 10:38:11 发布

_萤火

最新推荐文章于 2022-12-30 10:38:11 发布

阅读量225

点赞数

分类专栏：分布式

本文链接：https://blog.csdn.net/winter_wu_1998/article/details/105164595

版权

3 篇文章 0 订阅

订阅专栏

分布式下的全局ID需要具备如下特点
- 全局唯一: 区别于单机唯一，需要保证集群中的每台机器生成的ID都是不一样的，不能存在重复
- 趋势递增: 生成的全局ID需要能够近似有序递增
  - 因为分布式ID是用来标识数据唯一性的，所以多数时候会被定义为主键或者唯一索引
  - 对于 B+Tree这个数据结构来讲，数据以自增顺序来写入的话，b+tree的结构不会时常被打乱重塑，存取效率是最高的
- 信息安全：在趋势递增的基础上，不能被恶意用户推测出下一个ID
- 性能要求：需要考虑并发访问较大情况下带来的性能问题
应用场景
- 对数据分库分表后需要有唯一ID来标识一条数据
- 订单、优惠券等也都需要有唯一ID做标识
- URL短连接生成

MySQL自增主键

Flicker方案设计单独的库表，利用数据库的自增 ID 来生成全局 ID
使用“双主模式“解决单点故障问题
- 启用两台数据库服务器来生成 ID，通过区分 auto_increment 的起始值和步长来生成奇偶数的 ID
- 如果想配置主从复制来避免单点，主从切换时的不一致可能会导致重复发号
优点
- 简单，复用了数据库自增 ID 机制
缺点
- 并发量不大
- 强依赖DB，当DB异常时整个系统不可用，可用性低
- ID连续，安全性低
- 水平扩展困难
  - 定义好了起始值、步长和机器台数之后，如果要添加机器就比较麻烦了

因为 Redis 中的所有命令都是单线程的，可以利用 Incrby命令来模拟 ID 的递增
可以通过使用集群来提升吞吐量
- 我们可以为不同的 Redis 节点设置不同的初始值并统一步长，这样就能利用 Redis 生成唯一且趋势递增的 ID 了
- 如有 3 个 Redis 节点，分别设置初始值为 1、2、3 ，这时步长就应该定为 3
优点
- 不依赖数据库，且性能优于依赖数据库的 Flicker 方案
缺点
- Reids 宕机可能会生成重复的ID
- 水平扩展困难，原因同上
- ID连续，安全性低

UUID是通用唯一识别码（Universally Unique Identifier）的缩写
UUID是由128位二进制组成
- 一般转换成十六进制，然后用String表示
- 以连字号分为五段，形式为8-4-4-4-12的36个字符
  - 示例：550e8400-e29b-41d4-a716-446655440000
生成的 ID 中没有带 Timestamp
UUID 有多个版本，各版本算法不同
- 核心思想都是结合机器的网卡、系统时间、一个随机数来生成特定长度的字符串
优点
- 本地生成，没有网络消耗，性能好
缺点
- 字符串占用的空间比较大
  - 作为主键时，索引的效率非常低
- 无序，无法保证趋势递增
  - 不利于做主键，每次插入都会对B+tree结构进行修改，严重影响性能
- 由于UUID包含MAC地址，不太安全

在这里插入图片描述

在这里插入图片描述

基于Snowflake算法的唯一ID生成器
支持自定义workerId位数和初始化策略，从而适用于docker等虚拟化环境下实例自动重启、漂移等场景
采用RingBuffer来缓存已生成的UID, 并行化UID的生产和消费, 同时对CacheLine补齐，避免了由RingBuffer带来的硬件级「伪共享」问题
通过消费未来时间克服了雪花算法的并发限制