一种基于MySQL的业务流水号生成方法与流程

一种基于mysql的业务流水号生成方法
技术领域
1.本发明涉及分布式系统领域，具体为一种基于mysql的业务流水号生成方法。


背景技术：

2.在很多交易场景下，每一笔交易或每一笔业务需要生成唯一的业务流水号，以记录该笔业务或交易。当前有多种方式用于业务流水号的生成，生成的业务流水号也有多种不同的形式。目前，优选的方式就是利用分布式系统进行业务流水号生成，但是现有技术中，在利用分布式系统生成业务流水号时，如果处于业务并发分段等场景下，由于分布式系统中的服务器各自独立，无法完全保证被同步的节点的时间完全一致，因此在生成业务流水号时难以同时保证唯一性和连续性。


技术实现要素：

3.本发明的目的在于：提出一种基于mysql的业务流水号生成方法，该技术方案能够简单快速地生成具有业务连续性及唯一性的业务流水号。
4.为解决上述问题，本发明提供的基础方案：一种基于mysql的业务流水号生成方法，包括以下步骤：s1：建立自增索引；s2：获取业务流水号各部分结构对应的数据，获取的数据包括自增id；s3：将s2获得的数据组合生成业务流水号；s4：重置自增主键。
5.基础方案的有益效果：本技术方案在业务流水号时，在传统的生成规则基础上加入mysql自增id，无须依赖复杂算法，对业务性能影响较小，支持多业务多场景使用，可保证各分段任务并发处理时，任务不会被交叉重复处理，自增id与传统生成规则结合保证了业务流水号具有唯一性，自增id递增的特性也保证了业务具有连续性。
6.作为优选方案，所述s1包括：
7.s11：创建自增索引表；
8.s12：设置自增主键字段。
9.本技术方案，s11创建自增索引表，有利于快速、灵活地进行大数据量的复杂查询处理；s22设置自增主键字段，便于后续s2生成自增id。
10.作为优选方案，所述s2包括：
11.s21：获取接收到业务流水号生成请求时的系统时间；
12.s22：获取自增id。
13.本技术方案，业务流水号包括系统时间、自增id，通过获取系统时间能够标识业务发生的时间，自增id能保证业务流水号具有唯一性与连续性。同时相比现有技术中主键一百多位字符的长度，本技术方案有效缩减了字符长度，节约了存储空间。
14.作为优选方案，所述s22包括：
15.s22-1：创建标签，在标签中添加usegeneratekey＝true；
16.s22-2：执行标签插入mysql数据库操作；
17.s22-3：返回自增id值。
18.本技术方案，通过s22-1告知数据库使用了自动生成主键的方式，而后执行s22-2、s22-3获取新插入数据的自增id值。
19.作为优选方案，还包括s4：重置自增主键。
20.本技术方案，能够保证自增主键可循环重复使用，使业务流水号能连续顺利地生成。
21.作为优选方案，所述s4包括：
22.s41：设置重置阈值，若自增id等于该设置的阈值则执行s42；
23.s42：对自增索引表的自增id进行重置。
24.本技术方案，能够对自增id进行检查，并在自增id超过一定数值之后进行重置。
25.作为优选方案，所述s42采用trancate的方式对自增id进行重置。
26.本技术方案，使用trancate语句能够使索引表所占用的空间恢复到初始大小，重置表的自增id值，并且保证表结构及其约束、索引等保持不变。
27.作为优选方案，所述s2获取的数据还包括业务场景前缀。
28.本技术方案，通过加入业务场景前缀，便于判断该业务发生场景，
29.作为优选方案，所述s21通过获取分布式系统中多个服务器的时间，计算平均时间作为请求时的系统时间。
30.本技术方案，通过对多服务器平均时间的计算，尽可能降低生成业务流水号时，系统时间的误差。
附图说明
31.图1是本发明的逻辑图；
32.图2是本发明实施例一生成的业务流水号的结构示意图。
具体实施方式
33.下面通过具体实施方式对本技术技术方案进行进一步详细说明：
34.实施例一
35.如图1所示，一种基于mysql的业务流水号生成方法，包括以下步骤：
36.s1：建立自增索引，具体包括：
37.s11：创建自增索引表，创建获取到的数据源对应数据表的元信息的结构。
38.s12：设置自增主键字段，自增主键id字段采用int类型，并定义整形变量与常量，自增主键字段的数量可以根据实际情况进行设置，本实施例中索引表只需一个自增主键字段即可，同时给表创建主键时，系统也会创建一个约束给该字段。
39.s2：获取业务流水号各部分结构对应的数据，具体包括：
40.s21：获取接收到业务流水号生成请求时的系统时间，服务器获取接收到业务流水号生成请求时的系统时间，并根据该系统时间生成时间戳，时间戳精确到秒，包括年、月、时、分、秒，格式为yyyymmddhhmmss，用14位字符表示时间戳；当业务量较大时，也可精确到毫秒，此时格式为yyyymmddhhmmsssss，以17位字符表示时间戳。
41.s22：获取自增id，本技术方案使用mybatis框架与数据库交互，以对数据进行新增、修改、删除和查询，具有使用方便、性能高、灵活性强等优点，具体包括以下步骤：
42.s22-1：接收到服务节点发来的自增id获取请求后开始创建标签，在标签中添加usegeneratekey＝true，告知数据库使用了自动生成主键的方式，添加keyproperty＝id，使s1所创建的自增主键字段赋予java对象的属性名，保证标签插入后正确获取id值。
43.s22-2：执行标签插入mysql数据库操作。
44.s22-3：返回对象中对应的id值即为新插入数据的自增id值。
45.s23：将本次请求的系统时间、场景前缀、自增id发送至所述多个服务节点中的其中一个服务节点，使用前将会先检索当前资源占用率最小服务节点，由该当前资源使用率最小的服务节点负责生成对应的业务流水号。
46.s3：服务节点接收到将s2获得的数据后，会按照如图2的业务流水号结构进行组合，生成业务流水号。
47.s4：对自增id进行重置，具体包括：
48.s41：设置重置阈值，int类型的写入值超出最大值后，将会出现写入数据库报错。如果不及时处理，则业务流水号将无法正常生成，因此该阈值应当小于int类型自增主键能够增长到的峰值，若自增id等于该设置的阈值则执行s42。
49.s42：使用trancate的方式对自增索引表的自增id进行重置，重置后，自增主键id会由0重新开始自增，保证自增主键可循环重复使用。
50.实施例二
51.本实施例与实施例一的区别在于，所述s2还根据业务场景添加对应的场景前缀，场景前缀一般为3位字符，可以根据业务数量灵活调整配置，获取场景前缀时会通过申请该业务流水号的账户进行查询，查询该账户关联的最近一笔业务场景，将其业务号作为场景前缀，便于通过业务流水号判断该业务发生场景，也便于进一步巩固生成业务流水号的唯一性。
52.实施例三
53.本实施例与实施例二的区别在于，所述s21通过获取分布式系统中多个服务器的时间，计算平均时间作为请求时的系统时间。为了避免单个服务器未能有效同步时间，导致获取的系统时间与实际的时间误差较大的问题，在生成系统时间时，获取分布式系统中多个服务器的时间，计算平均时间作为请求时的系统时间。此处平均可以是平均值、众数或中值。
54.计算前还将对于偏离误差较多的系统时间进行滤除，进一步避免误差。此时，还将针对该系统时间偏离较多的服务器进行示警，以提醒维护人员排查其问题原因。
55.实施例四
56.本实施例与实施例三的区别在于，所述s1创建的自增索引对应多个数据库，本实施例中对应三个数据库，分别为个位数据库、十位数据库、百位数据库，各自的权重分别为1、10、100。
57.当需要生成的流水号时，s22根据需要获取的自增id值数量，判定需要使用的数据库，并从该数据库中获取新插入数据自增id值，同时读取其余数据库此时的自增id值，并对所有获取到底自增id值进行求和得到最终的自增id值。例如，当需要生成10个流水号时，s22可以增加十位数据库现有的自增id值，直接从十位数据库中值获取新插入数据自增id值，并同时读取个位数据库与百位数据库此时的自增id值，并对三个数据库的自增id值按
照权重进行求和获得最终的自增id值，由于十位数据库的权重为10，因此自增id的值也将直接增加10，从获得的最终自增id值开始往回读取10个，即为新生成的自增id值，再交由s3与其他结构对应的数据进行拼接即可生成10个流水号。相较于现有技术只能逐个获取自增id值的技术方案，本技术方案可以快速批量获取多个自增id值，提高了流水号生成效率。
58.实施例五
59.本实施例与实施例四的区别在于，所述s22在获取自增id值之前还将选择最优获取方法。s22将首先分析流水号的生成需求，并设定一定的规则选择最优获取方法，最优获取方法包括分别获取整数个的自增id值与零散个自增id值，或者直接获取整数个自增id值，从最终获取的自增id值开始往回读取需要的自增id值数量。
60.本技术方案首先对需要获取的流水号数量四舍五入，四舍五入后的数值小于需要生成的流水号数量则采取分别获取的方法，四舍五入后的数值大于需要生成的流水号数量则采取往回读取的方式。例如当需要获取13个流水号时，其四舍五入后为10，小于需要生成的流水号数量13，采取从十位数据库获取10个自增id值以及从个位数据库获取3个自增id值的方法，此方法能够避免自增id值浪费。例如当需要获取19个流水号时，其四舍五入后为20，大于需要生成的流水号数量19，采取从十位数据库获取20个自增id值，并从获取的最终自增id值往回读取19个的方法，此方法能够加快自增id值的获取效率。本技术方案，通过一定的规则选取最优获取方法在避免资源过度浪费的前提下提高获取效率。
61.以上的仅是本发明的实施例，方案中公知的具体结构及特性等常识在此未做过多描述，所属领域普通技术人员知晓申请日或者优先权日之前发明所属技术领域所有的普通技术知识，能够获知该领域中所有的现有技术，并且具有应用该日期之前常规实验手段的能力，所属领域普通技术人员可以在本技术给出的启示下，结合自身能力完善并实施本方案，一些典型的公知结构或者公知方法不应当成为所属领域普通技术人员实施本技术的障碍。应当指出，对于本领域的技术人员来说，在不脱离本发明结构的前提下，还可以做出若干变形和改进，这些也应该视为本发明的保护范围，这些都不会影响本发明实施的效果和专利的实用性。本技术要求的保护范围应当以其权利要求的内容为准，说明书中的具体实施方式等记载可以用于解释权利要求的内容。