上一期我们介绍了全局序列的原理，接下来我们通过视频来演示一下全局序列功能。我们来看一下这两种全局序列是怎么工作的。
时间戳算法
首先是 snowflake ，也就是所谓时间戳算法。
默认的是直接使用时间戳算法，在实际的使用中先设置一下。在 server.xml 里面有一个叫 sequnceHandlerType 的属性。值为 2 表示时间戳类型，其它数值在文档中有详细介绍。我们去配置一个有全局序列的表。tb_hash_sharding_er2 表里面的 autoIncrement 属性为 true。target 是用来配置的全局序列的。然后 snowflake 算法还有一个工作节点，它标识了机器的 ID 。在配置文件当中分别有两行配置。这两行是一个联合主键，只要在不同机器上，联合值就不一样，那么就实现了标识。
登录一个 dble 的流量端口。查看刚刚建的表是空的。再看一下这张表的结构，一共是三行。第一行数据类型是 bigint ，因为 snowflake 是一个 64 位的整数。64 位的整数超过了一般 int 的长度，所以我们选用 bigint 存储，这里我们需要注意。
然后我们插入一条数据，看到已经生成了一个意向的序列号。然后我们再插入另外一个值。可以看到生成了一个完全不一样的序列号。假如我同时插入多个值，因为这张表其实是按照1024求模，然后按照 0 到 512 范围的查询算法。我们写了一个 512 这样一个值插入，可以看到其中的一个全局序列完全不一样。所以这是一个按时间戳拆分的一个全局序列的算法。值得注意的是，如果一个系统已经确定了全局序列的算法，是不能更改的。因为方式 A 和方式 B 的全局序列同时设置，很有可能会有数据冲突。所以我们展示完这个类型就要删掉。
offset-setup 类型
接下来是第二种 offset-setup 类型全局序列的配置和生成的演示。
首先要看一下全局序列的方式。刚才我们属性值是 2，选择 offset-setup 这里要改成 1，当然需要重启才能生效。改好配置后，使用 testdb 库中的 tb_hash_sharding_er2 表，在 sequence_db 配置文件中添加一行。现在我们知道这个全局序列的粒度是到表的，所以不同表之间是可以不一样的。需要配置出这样一个库表，来标识我们的表要使用全局序列。后面的值表示我的载体放在哪里，发号器要放在哪一个地方。我们把它放到 dn1（数据库的一个实例节点）上。db1 指向 datahost1，可在 33061 端口登录。
我已经准备好了 dbseq.sql，里面是建表语句和存储过程。建的表就是发号器存放的地方，存储过程就是这个发号器。表非常简单，就三行。存储过程细节可以到文档中查看。发号器就是个为了控制不同请求不冲突的东西。发号器通过锁来变更一张表的记录，然后把记录返回回去。当有其它请求发过来的时候不会冲突，然后去 33061 端口的 dn1 里面把建表语句和存储过程执行一下。我们通过 source 命令去把这个表建立起来，存储过程也建立起来。
这时我去看就有这张表了。表的数据现在是空的，需要我们显式的加一条数据。发号器的一个起始值和一批次的长度。其实这个起始值为 0 更合适，1 到 1000 也没有问题。这样的话，发号器里面就有一条记录了，之后的发号都会从这里面去申请。修改全局序列类型后，需要重启 dble。我们去 log 里面验证一下是成功的！
通过 8066 端口来演示这种全局序列生成的过程。将表清空，重新插入多条数据。观察在表中最终出现的形式。另外第一行可以不用 bigint 了。可以看到我们插入数据的时候是指定后面两列，第一位是自动生成的，从 2 开始。在插入两个数据以后，就自动 2,3…… 递增。递增效果由 DBLE 内部控制。举个例子，比如说我 DBLE 突然挂了，重启以后会发生什么？其实发号器已经发过 1 到 1000 的号了，但是我还没用，DBLE 就重启了。实际上会再去申请，所以序列有可能是会有间断的。在 1 到 1000 的使用过程中挂了，那我就废弃再去取，保证唯一性。
图文稿为了方便阅读，在不影响学习的情况下优化了一些口语化词汇，文稿与视频会尽量保持一致。
DBLE 及相关项目代码地址：
https://github.com/actiontech/dble
https://github.com/actiontech/dble-docs-cn
https://github.com/actiontech/dble-test-suite
课程咨询：
-
「爱可生开源社区」微信公众号：ActiontechOSS
「爱可生开源社区」官方技术交流群（669663113）
