业务ID 生成策略,从技术上说,基本要借助一个集中式的引擎来帮忙实现。redis
为了扩大业务ID生成策略的并发问题,还有更为技巧性的提高。网络
先来介绍广泛的分布式ID生成策略:数据结构
1. 利用DB的自增主键并发
这里又有两种作法,一种是 单首创建一个只有自增主键的表,来负责主键自增,业务表从这里取得自增的主键返回给业务主键生成组件使用。分布式
另一种: 业务中不使用DB的自增主键, 自增主键仅存在DB层面,并增长业务主键字段,并加以约束。这种比较常见。优化
一般的步骤为: spa
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 等生成局部业务IDcode
在防止冲突这里,基本上能够使用一些方法进行优化,通常来讲,基本上使用redis 的list 数据结构。对象
好比redis 的list 对象预存 100000 序列号,而后进程去lpop。blog
问题在于redis 要考虑网络不稳定,以及故障恢复后的应用层面要考虑兼容。
3. 机器本地生成
内存中维持计数器,如全局的automaticInteger 这种生成方式。
在分布式状况可能有问题