分布式 | dble 中分布式时间戳方式的全局序列

作者：吴金玲
爱可生 dble 项目团队成员，主要负责 dble 相关的日常测试工作，擅长对 dble 中出现的问题进行排查。热爱测试工作，余生欲将测试工作进行到底。
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

---

dble 中目前有 4 种方式的全局序列，分别是 MySQL offset-step 方式、时间戳方式、分布式时间戳方式、分布式 offset-step 方式全局序列。本文将会从测试的角度简单讲述一下分布式时间戳方式的全局序列的环境搭建及使用。

一、分布式时间戳方式的全局序列简介

此种方式提供一个基于 Zookeeper（以下简称 ZK）的分布式 ID 生成器，可以生成全局唯一的 63 位（首位恒为 0，保证全局序列为正数）二进制 ID。

正数的 63 位模式如下：

其中：

• a - e 为从高位到低位；

• a 为线程 id 的低 9 位值；

• b 为 5 位实例 id 值；
  此值为配置文件 sequence_distributed_conf.properties 中的 INSTANCEID 值或者从 zookeeper 服务器获取的值；

• c 为 4 位数据中心 id 值;
  即配置文件 sequence_distributed_conf.properties 中的 CLUSTERID 的值；

• d 为 6 位自增长值；

• e 为系统当前时间戳的低 39 位值（可以使用 17 年）。

二、搭建使用分布式时间戳方式的全局序列的环境

1. 配置 ZK 环境

搭建 dble & ZK 环境请参见社区的另外一篇文章《利用 ZooKeeper 手工部署 dble 集群环境》。本文中一个 ZK 管理 3 台 dble（dble-1,dble-2,dble-3）构成集群，3 台 dble 的版本均为 2.20.04.0。

2.dble 的配置要求

1）集群中各 dble 的 sequence_distributed_conf.properties 配置

dble-1 中的 sequence_distributed_conf.properties 配置为：

INSTANCEID=zk
CLUSTERID=01
START_TIME=2010-11-04 09:42:54

dble-2 中的 sequence_distributed_conf.properties 配置为：

INSTANCEID=zk
CLUSTERID=02
START_TIME=2010-11-04 09:42:54

dble-3 中的 sequence_distributed_conf.properties 配置为：

INSTANCEID=zk
CLUSTERID=03
START_TIME=2010-11-04 09:42:54

sequence_distributed_conf.properties 中：

INSTANCEID：指定实例 ID 值，可以为‘zk’或者 n（n 为区间 [0，31] 中的一个整数）。如果配成 zk，则序列的维护（主要是 INSTANCEID 值的维护）用 zookeeper 的临时自增节点来维持。每次生成全局序列时，向 zk 申请一个临时自增节点，通过计算自增节点数 %32 获取 INSTANCEID。如果 INSTANCEID 值不为’zk’, 序列的维护仅依赖于单实例（主要是 INSTANCEID 值的维护），此时序列类似于时间戳方式。

CLUSTERID：指定组 ID 值，可以为 m（m 为区间 [0, 15] 中的一个整数）。

START_TIME：指定开始时间，时间格式固定，必须为 2010-11-04 09:42:54 这种格式。

2）将 dble-1 中的 schema.xml 及 server.xml 配置修改如下：

schema.xml 关键配置为：

<schema name="schema1" dataNode="dn1">
<table name="tb_autoIncre" dataNode="dn1,dn2,dn3,dn4" rule="hash-four" cacheKey="id" incrementColumn="id"/>
</schema>

server.xml 关键配置为：

<system>
    <pro
perty name="sequenceHandlerType">3</property>
</system>

3）登录 dble-1 的管理端口并执行管理命令 reload @@config_all，然后依次重启 3 台 dble，使配置在集群中生效。

三、操作及结果验证

1.建表及插入数据

创建一张含有 bigint 类型的自增列的表，登录 dble-1 的业务端口，执行：

mysql -p111111 -utest -P8066 -Dschema1 -e "create table tb_autoIncre(id bigint,time char(120));"

插入数据，执行：

datestr=`date +%Y%m%d`
mysql -p111111 -utest -P8066 -Dschema1 -e "insert tb_autoIncre values('${datestr}');"

查询插入的数据，执行：

mysql -p111111 -utest -P8066 -Dschema1 -e "select * from tb_autoIncre ;"

2.验证插入的 id 自增列值是否正确:

上图中的 id 是个正数，将此正数转化成二进制，然后按照上文简介中的 63 位二进制数组成规则反推各组成部分的是否和设计一致。具体步骤如下：

1）将步骤二中得到的 id 转换成二进制记录为 (a)，若结果不足 64 位，前面加 0 补足 64 位

select conv(id, 10, 2) from  tb_autoIncre;

所以补足 64 位后的二进制为：0000000000000000001000000100011000100001001011100011111101011000

2）记录二进制 (a) 的前 [16~19] 位闭区间为 0001,转化为十进制为 1，值与配置中 CLUSTERID 值相等；取前 [11~15] 位闭区间为 00000，转化为十进制为 0，而 zk 中临时自增节点 instance 值为，

0%32 也为 0，所以符合预期；截取二进制的后 39 位为一个新的二进制 100011000100001001011100011111101011000，记为 (b)‬。

3）将二进制 (b) 转化成十进制

select conv(100011000100001001011100011111101011000, 2, 10);

所以 (b) 转化为十进制为：301204389720，记为 ©。

4）将 © 转化成日期 (t1)

set @unixtime=301204389720/1000;
select from_unixtime(@unixtime);

5）将得到的日期 (t1)-1970/01/01，得到时间差记为 (t2)

select datediff('1979-01-08 08:53:58.752000','1970-01-01');

6）用 start time(2010/11/04 09:42:54) + (t2) 得到最终的时间 (t3)：

select date_add('2010-11-04 09:42:54', interval 3486 day);

(t3) 与 select 出的 time 列的值近似相等。

结论：从以上分析可以看出，插入到自增列的值是正确的。