业务ID 生成策略,从技术上说,基本要借助一个集中式的引擎来帮忙实现。
为了扩大业务ID生成策略的并发问题,还有更为技巧性的提升。
先来介绍普遍的分布式ID生成策略:
1. 利用DB的自增主键
这里又有两种做法,一种是 单独创建一个只有自增主键的表,来负责主键自增,业务表从这里取得自增的主键返回给业务主键生成组件使用。
另外一种: 业务中不使用DB的自增主键, 自增主键仅存在DB层面,并增加业务主键字段,并加以约束。这种比较常见。
通常的步骤为:
A. Create table `tbl_biz_order`( `id` bigint auto_increment primary key NOT NULL, `biz_order` bigint NULL, key `biz_order_idx`(`biz_order`) ); B. insert into `tbl_biz_order` (); select last_insert_key(); C. 应用层拿到 id 字段的值,进行一系列拼接。根据规则,生成biz_order。 D. update `tbl_biz_order` set `biz_order`=${biz_order} where id=${id}; 时序图说明这件事情可能更好
2. 利用redis 等生成局部业务ID
在防止冲突这里,基本上可以使用一些方法进行优化,一般来说,基本上使用redis 的list 数据结构。
比如redis 的list 对象预存 100000 序列号,然后进程去lpop。
问题在于redis 要考虑网络不稳定,以及故障恢复后的应用层面要考虑兼容。
3. 机器本地生成
内存中维持计数器,如全局的automaticInteger 这种生成方式。
在分布式情况可能有问题
原文地址:https://www.cnblogs.com/lykm02/p/9020104.html
时间: 2024-11-02 13:12:35