上一期我们介绍了全局序列的原理,接下来我们通过视频来演示一下全局序列功能。我们来看一下这两种全局序列是怎么工作的。

时间戳算法

首先是 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 全局序列功能,我们今天先介绍到这里。
图文稿为了方便阅读,在不影响学习的情况下优化了一些口语化词汇,文稿与视频会尽量保持一致。

DBLE 及相关项目代码地址:

https://github.com/actiontech/dble

https://github.com/actiontech/dble-docs-cn

https://github.com/actiontech/dble-test-suite

课程咨询:

  • 「爱可生开源社区」微信公众号:ActiontechOSS

  • 「爱可生开源社区」官方技术交流群(669663113)