业务unique ID的生成策略分析

30 篇文章 0 订阅
6 篇文章 0 订阅

 

业务unique ID的生产策略分析

 

需求上下文:

 

业务是和单个user相关的(userId),业务表分到10个DB host中

 

 

 需求:

 高并发下生产唯一的业务ID

 

 

首先根据此用户的userId mapping到不同的DB host(oracle), 

 

每个DB host上有一个业务seq,  这个seq自增步长是10,然后每个host起点不一样, 0 是0, 1是1,这样每个 DB host生成的seq数据就不会冲突(host1上只会生产尾数为1的seq,host2上只会生产尾数为2的seq,类推)

 

具体生产seq的oracle sql为:

 

SELECT  BUSINESS_ID_SEQ_0.NEXTVAL FROM dual   //生成一个

 

SELECT  BUSINESS_ID_SEQ_0.NEXTVAL FROM dual CONNECT BY LEVEL <= 100  //生成100个

 

 

查询的时候每次seq生成100个,缓存到本地内存中的队列(ConcurrentLinkedQueue), 下次就从内存中取了

 

但这个code中的synchronized锁加的很奇怪, ConcurrentLinkedQueue是在锁的代码块内部使用的, 但如果上下文环境是安全的,ConcurrentLinkedQueue这个高并发队列不就没意义了吗,

 

个人觉得加锁应该只加在从数据库拿100个seq的时候加,防止多个线程同时去数据库创建100个seq,导致重复创建。在那之外的获取seq其实不用加锁的,因为ConcurrentLinkedQueue已经是线程安全。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值