上一期我们进行了 hint 的简单介绍和演示。我们的基本功能就介绍到这里，下面介绍一些进阶功能。
全局序列
我们先来介绍一下全局序列，我们DBLE目前支持四种全局序列。说是四种，如果按照他的内核区分是两种，只不过这两种方式放在不同的载体里面成为了四种。
我们先看这两种大概是一个什么概念。
中间还有一个名叫工作机器 ID。这个是为集群设计的，当我的 DBLE 不是单节点部署的，而是集群部署的，或者是负载均衡方式部署的。我需要保证我插入数据库的最终的拆分序列是唯一的，其实我是通过给不同机器或者不同实例标识 ID 来做的，这样的话只要我们单个机器的时间不回退，我的时间戳，我的机器 ID 就能保证我的全局序列是唯一的。但如果你的并发某个峰值真的超过了每毫秒 4096 了，会有重复吗？其实他也不会重复，他会等待。他会直接把峰值满足不了的并发，它会等到这个毫秒过去以后再去下一个毫秒重新去生成新的序列，这种情况下延迟会受到一些影响。
offset-step
好，这是 snowflake 的原理，下面是 offset-step 的原理。它是一个什么概念呢？他是有一个发号器，可以按照步长发号。比如说我这里按照 1000 一个步长发号。当我的 DBLE 需要用到全局序列的话，去这个发号器申请一个步长单位的发号。申请 1000 个号，这 1000 个都归我使用。比如说 DBLE 是个集群，另外一个 DBLE 也来申请这个号的话，通过发号器的并发控制，申请发号的结果一定保证不在同一个区间，这样保证我的序列是唯一的。这个方式其实相对于上一个方式来说，优缺点都很明显。优点是它可以把粒度细到某一张表。比如说我表和表之间的全局序列之间没有关系，我们可以重用数字。snowflake 因为跟时间相关的，所以不能重用。所有的自增序列表用的同一套值。发号器方式可以重用。确定是需要额外一个载体，谁来做这个发号器，用于控制并发和发放号以及持久化。所以我们才会有 MySQL 和 zk 两种模式,其实就是发号器的载体。
图文稿为了方便阅读，在不影响学习的情况下优化了一些口语化词汇，文稿与视频会尽量保持一致。
DBLE 及相关项目代码地址：
https://github.com/actiontech/dble
https://github.com/actiontech/dble-docs-cn
https://github.com/actiontech/dble-test-suite
课程咨询：
-
「爱可生开源社区」微信公众号：ActiontechOSS
「爱可生开源社区」官方技术交流群（669663113）
