业务ID 生成策略

标签：list   引擎   全局   时序图   常见   步骤   primary   业务   last   

业务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 这种生成方式。

在分布式情况可能有问题

业务ID 生成策略

标签：list   引擎   全局   时序图   常见   步骤   primary   业务   last   

原文地址：https://www.cnblogs.com/lykm02/p/9020104.html