分布式ID生成

分布式ID生成详解
本文深入探讨了分布式ID生成的重要性及三种主流解决方案:UUID、Redis自增ID与雪花算法。UUID确保ID唯一但长度过长;Redis自增ID依赖数据库但能保证线程安全;雪花算法由Twitter提出,性能高效且无需第三方服务。

分布式ID生成
1.1 为什么使用分布式ID

在这里插入图片描述
1.2 分布式ID解决方案
1). UUID
UUID 可以保证每一次生成的ID不重复 ;
缺点 :

  • 长度比较长 , 占用磁盘空间
  • 无法排序
    2). Redis
    通过redis的指令 incr指令, 来实现一个自增的主键 , 可以保证ID不会重复 , 并且线程安全 ;

    实现:
    incr orderid
    缺点 :
  • 借助于redis数据库 ;
    在这里插入图片描述

3). 雪花算法
自己编写的一种算法实现 , 是推特网站提供的一种分布式ID生成机制 ; 不需要借助于第三方服务, 性能高;

在这里插入图片描述
64 = 1 + 41 + 10(5 + 5) + 12 ;
5: 代表数据中心ID
5: 代表机器ID

在这里插入图片描述
1.3 雪花算法实现
IdWorker idWorker = new IdWorker(0,0);
for(int i=0;i<1000;i++){
long id = idWorker.nextId();
System.out.println(id);
}

将IdWorker交给Spring管理 :
@Value("${workerId}")
private Integer workerId;

@Value("{datacenterId}")
private Integer datacenterId;
@Bean
public IdWorker idWorker(){
return new IdWorker(workerId,datacenterId);
}

### 分布式ID生成方案及其实现 #### 常见的分布式ID生成方法 在分布式系统中,为了唯一标识对象或事务,通常会采用特定的ID生成策略。以下是几种常用的分布式ID生成方案: 1. **雪花算法(Snowflake)** 雪花算法是由Twitter提出的用于生成全局唯一ID的一种解决方案[^1]。该算法的核心思想是通过组合多个字段来构建一个64位整数作为ID。具体结构如下: - 1位:符号位,始终为0。 - 41位:时间戳,记录毫秒级的时间差。 - 10位:机器ID,可以区分不同的服务器实例。 - 12位:序列号,在同一毫秒内生成的不同ID可以通过此字段区分。 下面是一个基于Python实现的简单版本的雪花算法: ```python import time class SnowflakeGenerator: def __init__(self, machine_id): self.machine_id = machine_id & 0b1111111111 # 确保machine_id不超过10位 self.sequence = 0 self.last_timestamp = -1 def generate(self): timestamp = int(time.time() * 1000) if timestamp < self.last_timestamp: raise Exception("Clock moved backwards") if timestamp == self.last_timestamp: self.sequence = (self.sequence + 1) & 0xFFF if self.sequence == 0: timestamp = self.wait_next_millis(timestamp) else: self.sequence = 0 self.last_timestamp = timestamp return ((timestamp << 22) | (self.machine_id << 12) | self.sequence) def wait_next_millis(self, last_timestamp): timestamp = int(time.time() * 1000) while timestamp <= last_timestamp: timestamp = int(time.time() * 1000) return timestamp ``` 2. **UUID(通用唯一识别码)** UUID是一种标准的128位长度的编号格式,广泛应用于各种场景下生成唯一标识符。它分为多种版本,最常见的是基于随机数的UUID v4和基于MAC地址与时间戳的UUID v1。尽管UUID能保证全球范围内的唯一性,但由于其无序特性以及较大的存储开销,在某些性能敏感的应用中可能不适用。 3. **数据库自增主键** 使用关系型数据库中的自增列也可以作为一种简单的分布式ID生成方式。然而这种方式存在明显的局限性——当面对大规模高并发请求时,单台数据库可能会成为瓶颈,难以满足高性能需求[^3]。 4. **ZooKeeper/etcd等协调服务** 利用像Apache ZooKeeper或者CoreOS etcd这样的分布式一致性协议工具可以帮助我们设计更复杂的ID分配机制。例如可以在集群环境中维护一个计数器资源,并通过原子操作对其进行更新从而获取新的ID值[^2]。 #### 实现注意事项 无论选择哪种具体的实现技术路线,都需要考虑以下几个方面因素以确保整个系统的稳定高效运行: - **高可用性**:即使部分节点发生故障停机,整体服务仍然能够正常提供功能支持; - **低延迟响应速度**:尤其是在互联网业务场景下,用户体验至关重要,因此要尽量减少每次调用所需耗费的时间成本; - **扩展能力规划**:随着数据规模不断扩大,原有的设计方案是否容易调整适应新增加的工作负载量也是一个重要考量维度; ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值