分布式Id解决方案
分布式ID解决方案
分布式ID是什么? ? 在分布式集群环境下,生成的唯一id,成为分布式ID。
分布式ID解决了什么问题? ? 在分布式集群环境下,后台数据库服务有多台,每台数据库服务都有同一张表,那么应用程序在对多台数据库服务中的同一张表进行存储数据时,就需要保证id唯一。单机环境下,可以使用mysql的表自增,但是在分布式集群环境下了,就不能使用mysql的表自增了, 因为这样会造成多个数据库中的同类型表id重复,所以此时就需要分布式id来保证数据的唯一性。
分布式ID生产的常用解决方案
-
UUID
使用Java中jdk自带的UUID机制,具体代码为:UUID.randomUUID().toString()
。此时生成的是一个36位无规律的字符串
,理论上是唯一的
, 重复的概率可以忽略不记
。
- 【分布式Id解决方案】
独立数据库自增id
单独部署一台数据库,然后创建一张表,给这张表创建几个字段,比如创建时间,然后每次需要新增时,就在这张表里面新增一条记录, 用主键自增id返回当作分布式id
使用。
-
雪花算法
这是一个有名的算法,这里说一下它的原理。它会生成一个long型
的数据,long型为8个字节
,也就是64位
。
64位分为4部分
- 最高位为符号位,固定为0表示正数 (
占1位
) - 第2位到42位表示毫秒级时间戳 (
占41位
) - 第43位到52位表示机器id(即物理机id,自己定义,比如mac地址等等) (
占10位
) - 第53位到64表示0-4095递增的数字 (
占12位
)
- 最高位为符号位,固定为0表示正数 (
使用redis incr自增
可以利用redis的原子性,可以使用incr命令来生成唯一的id, 使用这个命令如果key不在返回1,存在则加加。
第一种方案在实际工作中`可以用`,缺点就是因为它生成的是无规则的字符串,会对mysql的索引性能有所下降。
第二种方案,`不建议使用`。因为如果独立数据库宕机了或者产生了瓶颈,就容易造成业务不可用。
第三种方案,可以使用,`推荐使用`。
第四种方案,可以使用,`推荐使用`。
推荐阅读
- 数据库|分布式ID解决方案比较(雪花算法-Snowflake)
- 实时流处理与分布式存储过程中对文件的操作
- 分布式链路追踪
- 微服务架构学习与思考(09)(分布式链路追踪系统-dapper论文学习)
- Redis分布式实现原理
- MFC软件国际化的几个问题及其解决方案
- Redis(二)分布式锁与Redis集群搭建
- ES|ES 架构及基础 - 1
- 京东一面(高并发下,如何保证分布式唯一全局 ID 生成())
- 没有人想错过NFT,NFT交易平台解决方案