一种券码的生成方法及服务器与流程

本发明涉及互联网领域，特别是涉及一种券码的生成方法及服务器。

背景技术：

随着计算机网络的高速发展，以电子商务为代表的新型商业模式已经融入了社会生活的各个方面，比如日常购物、娱乐、餐饮等消费，各商家也以各种优惠券的形式进行促销或提高知名度。近年来，随着电商日的活动产生，比如618、818、1111、1212电商日，各领域的商家也根据活动日发放大量的不同形式的优惠券码。

一般的，传统技术采用高并发的分布式集群服务器来生成大量的券码并存储于数据库中，当用户需要输出券码时，服务器直接读取数据库中存储的券码进行输出。

发明人在实现本发明的过程中，发现相关技术存在以下问题：采用高并发的分布式集群服务器生成券码容易产生重复，特别是在各种电商日时，大量的券码在存储过程中给数据库造成了巨大的存储压力。

技术实现要素：

本发明实施例提供一种券码的生成方法及服务器，其解决了现有技术中大量的券码在存储过程中给数据库造成了巨大的存储压力的技术问题。

为了解决上述技术问题，本发明提供以下技术方案：

在一方面，本发明实施例提供一种券码的生成方法及服务器，所述方法包括：

获取券码数据；

将所述券码数据生成固定格式的实时券码；

在写入所述服务器的数据库之前，遍历所述数据库是否存在与所述实时券码重复的参考券码；

若是，舍去所述实时券码；

若否，将所述实时券码写入所述数据库。

可选地，所述获取券码数据，包括：

启动自检程序触发券码生成请求；

生成与每个所述券码生成请求对应的券码数据。

可选地，所述券码生成请求由当所述数据库缓存的券码低于或等于预设券码阈值时而生成的。

可选地，所述服务器按照预设频率轮询所述数据库缓存的券码是否低于或等于预设券数阈值。

可选地，所述生成与每个所述券码生成请求对应的券码数据，包括：

获取券码请求时间；

根据所述券码请求时间，得到与每个所述券码生成请求对应的券码数据。

可选地，所述根据所述券码请求时间，得到与每个所述券码生成请求对应的券码数据，包括：

判断所述券码请求时间是否匹配券码高峰时间段；

若是，选择与所述券码请求时间对应的券码高峰生成量，根据所述券码高峰生成量，得到与每个所述券码生成请求对应的券码数据；

若否，选择与所述券码请求时间对应的券码低峰生成量，根据所述券码低峰生成量，得到与每个所述券码生成请求对应的券码数据；

其中，所述券码高峰生成量大于所述券码低峰生成量。

可选地，所述券码生成请求还包括由外部终端触发所述服务器而生成的。

可选地，所述生成与每个所述券码生成请求对应的券码数据，包括：

从由外部终端触发所述服务器而生成的券码生成请求提取出券码购买量；

根据所述券码购买量，得到与每个所述券码生成请求对应的券码数据。

可选地，所述根据所述券码购买量，得到与每个所述券码生成请求对应的券码数据，包括：

判断所述券码购买量是否大于预设券码购买阈值；

若是，在与所述券码购买量对应的券码生成量的基础上，增加预设购买量的券码，以得到与每个所述券码生成请求对应的券码数据；

若否，得到与每个所述券码生成请求对应的券码数据。

在第二方面，本发明实施例提供、一种服务器，其中，所述服务器包括：

至少一个处理器；以及

与所述至少一个处理通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令程序，所述指令程序被所述至少一个处理器执行，以使所述至少一个处理器执行如上所述的券码生成方法。

在本发明各个实施例中，通过服务器生成大量的券码数据，将生成的券码数据处理成固定格式的实时券码并存入数据库中，采用数据库的唯一性来检验实时券码的重复性，若没有重复，则将实时券码存入数据库中；若有重复，则将实时券码舍去。因此，采用服务器生成大量的券码后，将生成的券码处理成固定格式的实时券码存储于数据库中，由数据库的唯一性来舍去重复数据，缓解了数据库的压力，提高了券码生成的效率。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是本发明实施例提供一种券码生成方法的系统结构框图；

图2是本发明实施例提供一种券码生成方法的方法流程示意图；

图2a是本发明实施例提供一种券码生成方法的方法流程示意图；

图2b是本发明实施例提供一种券码生成方法的方法流程示意图；

图3是本发明实施例提供三种固定格式的券码组成的结构框图；

图4是本发明实施例体供一种券码生成方法的方法流程示意图；

图4a是本发明实施例体供一种券码生成方法的方法流程示意图；

图5是本发明实施例体供一种券码生成方法的装置结构示意图；

图6是本发明实施例提供的一种服务器的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

图1为本申请实施例提供的券码生成方法的系统结构框图，该图所示的券码生成方法的系统可以用于实现本申请实施例提供的券码生成方法，请参照图1，该系统包括服务器10以及与其连接的至少一个客户端20，客户端20可以是个人计算机和/或ipad电脑，客户端20通过互联网与服务器10连接。服务器10可能是多台服务器组成的服务器集群，也可能是单台服务器，在本实施例中，主要用于生成大量的券码，并进行存储或输出。关于券码的生成、存储或输出的过程可以参见以下实施例的描述。

在一些实施例中，客户端20可以是安装如上述所述设备上的应用程序，用户可以通过app向服务器20申请券码。

本申请提供的券码生成方法也可以适用于该系统，本申请对该系统的具体组成结构不做限定。

请参看图2所示的一种券码生成方法的流程示意图，该方法可以包括以下步骤：

步骤101、获取券码数据。

在本实施例中，券码数据是通过服务器计算机根据其组成结构生成的，比如，券码数据可以由服务器编码+业务编码+时间编码+随机数构成，其中服务器编码是对生成券码的服务器进行编号，每台服务器对应有一个编号，其需要根据服务器的mac地址去数据库集群进行注册，以获取服务器的唯一编号。业务编码是指每个业务模块编码，时间编码是指当前的时间戳，通过这种组合方式来产生大量的券码数据，该券码数据可以生成有效的二维码，以供核销使用。

在一些实施例中，根据券码组成可把券码分为不同的类型，比如团购券、品牌打折券或餐饮券等等，商户可以根据不同的业务需求向服务器发送券码生成请求，以获得对应的券码数据。

在一些实施例中，请参阅图2a，步骤101包括以下步骤：

步骤1011、启动自检程序触发券码生成请求。

在一些实施例中，根据商户第一次的生成请求，已经在服务器中生成有一定数量的券码数据并保存在服务器数据库中。用户通过安装在客户端的应用程序，向服务器申请指定业务类型的券码数据，服务器根据接收到的业务类型，从数据库缓存中输出对应业务类型的券码数据。数据库中的券码数据被不停的输出后，导致数据库中的券码数量不断的减少，可能会导致券码数量不足，影响券码的输出，导致客户体验差。

在本实施例中，服务器启动自检程序，检查数据库中各种业务类型的券码数量，以触发服务器生成券码。

在另一些实施例中，所述券码生成请求由当所述数据库缓存的券码数量低于或等于预设券码阈值时而生成的。

在本实施例中，服务器对每一种业务类型的券码设置有与业务类型对应的券码数量阈值，上述券码数量阈值是由业务类型根据时间、用户反馈或热度等大数据分析所得。服务器启动自检程序来检测各种业务类型的券码数量是否低于或等于预设券码阈值，如若券码数量是否低于或等于预设券码阈值，则服务器触发券码生成请求生成一定数量券码，使的当前的券码数量大于预设券码阈值，以保证券码的充足性。如若券码数量不低于预设券码阈值，则服务器不触发券码生成请求。

步骤1012、生成与每个所述券码生成请求对应的券码数据。

服务器对存储于数据库中的每一种业务类型的券码数量进行检查，每一种业务类型对应有自己的券码数量阈值，当检查到数据库中某一业务类型的数量低于或等于其预设券码阈值时，服务器启动针对该类型的券码生成请求，生成一定数量的该业务类型的券码数据，以供用户使用。

在另一些实施例中，请参阅图2b，步骤1012包括以下步骤：

步骤1012a、获取券码请求时间。

步骤1012b、根据所述券码请求时间，得到与每个所述券码生成请求对应的券码数据。

在本实施例中，券码数据由服务器编码+业务编码+时间编码+随机数构成，因此，在服务器触发券码生成请求后，获取当前的券码请求时间，即获取当前的时间戳(unixtimestamp)，以区别不同时段生成的券码。

在实际应用中，时间戳不是指当前时间，而是一种相对时间的表示方式，是以格林威治时间起至当前时间的总秒数，可以采用不同的编程语言将当前的时间转换为时间戳。

在一些实施例中，所述根据所述券码请求时间，得到与每个所述券码生成请求对应的券码数据，还包括：

判断所述券码请求时间是否匹配券码高峰时间段；

若是，选择与所述券码请求时间对应的券码高峰生成量，根据所述券码高峰生成量，得到与每个所述券码生成请求对应的券码数据；

若否，选择与所述券码请求时间对应的券码低峰生成量，根据所述券码低峰生成量，得到与每个所述券码生成请求对应的券码数据；

其中，所述券码高峰生成量大于所述券码低峰生成量。

在上述论述中提到，券码数量阈值是由业务类型根据时间、用户反馈或热度等大数据分析所得。也就是说，券码的数量会根据时间、用户反馈或热度的变化而调整，特别是时间，由于电商日的兴起，比如618、1111、1212等，各商家需要在电商日设置大量的打折券码，以吸引用户进行购买。所以，时间的提取对券码生成数量尤为重要，服务器需要根据不同的时间生成足够数量的券码数据存储在数据库，以备用户取用。

在本实施例中，将获取的券码请求时间与券码高峰时间进行匹配，判断是否处于券码高峰时间段。以电商日618为例，商户根据电商日为6月18号，将6月17号00：00-6月19号23：59这个时间段作为券码高峰时间段，当获取到的券码请求时间落在上述券码高峰时间段内时，服务器根据该时段券码请求生成对应的券码高峰生成量。当获取到的券码请求时间没有落在上述券码高峰时间段内时，服务器根据该时段券码请求生成对应的券码低峰生成量。其中，券码高峰生成量大于券码低峰生成量。

步骤103、将所述券码数据生成固定格式的实时券码。

在本实施例中，根据不同的业务、不同的商家，需要产生多种类型的券码数据，因此，采用高并发分布式集群服务器来生成大量的券码。其中，券码数据有几种编码拼接构成，常用的，券码数据可以由服务器编码+业务编码+时间编码+随机数构成。但如果商户需要对券码的类型再做进一步的细分，假设此券码为打折券，打折券又分八八折券、六八折券和五折券等，那么在以上构成部分的基础上，还需要在做进一步的细分，比如在随机数后面再加一位数据进行标识，这就使的券码数据的格式和长度会根据类型而产生变化。

生成的券码数据需要放入数据库中进行保存，大量的不同格式和长度的券码数据写入数据库，这无疑就大幅度的增加了写数据库的压力。所以为了缓解写数据库的压力，在写入数据库之前，将数据处理成固定格式的实时券码数据，以简化数据库写数据时的运算，从而缓解了数据库的写数据压力，同时也提高了写数据的速度。

在本实施例中，主要采用三种组成方式将券码数据生成固定格式的实时券码。第一种固定格式券码组成为：机器编码(1位)+业务编码(后3位)+时间戳(后3位)+随机数(3位)；第二种固定格式券码组成为：机器编码+业务编码+随机字母(2位)+时间戳+随机数；第三种固定格式券码组成为：机器编码+业务编码+前缀随机数(3位)+时间戳+随机数。

请参看图3所示的三种固定格式的券码组成的结构框图，第一种固定格式：机器编码(1位)+业务编码(后3位)+时间戳(后3位)+随机数(3位)，由上可知，该券码固定格式是由10位有效数据构成，这种券码数据格式较短，因此生成的对应券码数量也较少，因此，该数据格式适合在券码低峰时段生成。第二种固定格式：机器编码+业务编码+随机字母(2位)+时间戳+随机数，第二种固定格式在第一种数据组成的基础上扩展了一个组成结构，增加了一项随机字母(2位)，并且对每一项组成结构的位数也没有做限制，明显的，第二种固定格式的数据在存储的数量上得到了较大的扩展，因此，适合在券码高峰时段即电商日生成，以保证在数据库中有足够的券码进行备用。第三种固定格式：机器编码+业务编码+前缀随机数(3位)+时间戳+随机数，第三种固定格式与第二种固定格式的区别在于扩展的组成结构不同，第三种固定格式的扩展项为前缀随机数(3位)，在存储数量上相对小于第二种固定格式，但第三种固定格式扩展项为数字，第三种固定格式生成对应的二维码后，能被大多数的应用进行扫描识别，而第二种固定格式生成对应的二维码后，扫描二维码的应用必须支持字母的识别，因此，在本申请中，优先把券码数据处理成第二种固定格式的实时券码数据。

在本申请中采用了多种固定格式的方式来简化券码数据，以适应不同的应用场景需要，同时，采用固定格式的券码数据进行数据库的写操作，从而简化了数据库的数据运算，从而提高了存储的速度和效率。

步骤105、在写入服务器的数据库之前，遍历数据库是否存在与实时券码重复的参考券码。

在本实施例中，券码数据是由机器编码+业务编号+前缀随机数(3位)+时间戳+随机数构成，若在同一时间内需要生成大量的券码时，特别是在电商日的券码高峰时间段，券码数据容易出现重复的情况，因此我们需要将重复的数据检测出来并舍去重复的数据。由于券码数据都是存储在数据库中，因此我们可以采用数据库的唯一性对券码数据进行重复性判断。在实际应用中，可以根据需要选择数据库的类型，可以是elasticsearch数据库、redis数据库、mongodb数据库或mysql分布式集群数据库中的一种，在本实施例中，采用的数据库为redis数据库。数据库接收到实时券码数据后，采用redis数据库中cap(consisitency,availability,partitiontolerance)二次判断原理，将实时券码与存储在数据库中的参考券码进行比较，以检测实时券码数据是否有重复。

步骤107、若是，舍去所述实时券码。

若采用cap检测的结果为实时券码数据与存储在数据库中的参考券码数据出现重复，则及时的舍去实时券码数据，并通知服务器重新生成券码数据存入。

步骤109、若否，将所述实时券码写入所述数据库。

若采用cap检测的结果为实时券码数据与存储在数据库中的参考券码数据未出现重复，则将该实时券码数据写入数据库中，并通知服务器进行下一组券码数据的生成。

在一些实施例中，所述券码生成请求由外部终端触发所述服务器而生成的。

在一些应用场景中，由于缓存的券码数据与实时券码有时间差，因此，也可以通过客户端的应用程序直接向服务器触发券码生成请求，服务器端根据券码生成请求生成对应业务编码的固定格式的券码数据，并输出到客户端，而不在数据库中进行缓存。以团购的优惠券为例，团购的券码是在一定时段内有效的，过了有效时段，券码数据将被识别为无效数据，因此，这种券码数据具有时效性。

在一些实施例中，请参阅图4，所述生成与每个所述券码生成请求对应的券码数据，包括以下步骤：

步骤201、从由外部终端触发所述服务器而生成的券码生成请求提取出券码购买量。

步骤202、根据所述券码购买量，得到与每个所述券码生成请求对应的券码数据。

在一些应用场景中，券码数据具有数量限制和时效性，因此，可以直接通过客户端的应用程序触发券码生成请求，服务器根据券码生成请求生成对应业务编码的一组实时券码，该组实时券码具有规定的数量，具体数量可以从大数据中分析获得，而且具有时效性。若该组实时券码没有在规定时段内被用户输出，则将该组实时券码视为无效券码。

在另一些实施例中，请参阅图4a，步骤202还包括以下步骤：

步骤2021、判断所述券码购买量是否大于预设券码购买阈值；

步骤2022、若是，在与所述券码购买量对应的券码生成量的基础上，增加预设购买量的券码，以得到与每个所述券码生成请求对应的券码数据；

步骤2023、若否，得到与每个所述券码生成请求对应的券码数据。

在实际应用中，具有数量限制和时效性的券码数据可以根据实际的实施情况及时的调整其数量限制，以使券码使用情况达到最大化。

综上所述，在本实施例中，通过服务器生成大量的不同类型的券码数据，并将券码数据在存入数据库之前处理成固定格式的实时券码，从而简化了数据库写数据的运算，以缓解数据库的写数据压力，采用数据库的cap二次判断来检测该实时券码数据，以舍去重复的券码数据，提高了数据库中券码数据的有效性，使用户能顺利的在客户端输出券码数据，提高用户体验。

图5是本发明实施例提供一种券码生成方式的装置结构示意图，如图5所示，该装置30包括数据获取模块301、格式化数据模块302、重复性判断模块303和数据处理模块304。

获取模块301用于获取券码数据。在本实施例中，券码数据是通过服务器计算机根据其组成结构生成的，比如，券码数据可以由服务器编码+业务编码+时间编码+随机数构成，其中服务器编码是对生成券码的服务器进行编号，每台服务器对应有一个编号，其需要根据服务器的mac地址去数据库集群进行注册，以获取服务器的唯一编号。业务编码是指每个业务模块编码，时间编码是指当前的时间戳，通过这种组合方式来产生大量的券码数据，该券码数据可以生成有效的二维码，以供核销使用。

格式化数据模块302用于将所述券码数据生成固定格式的实时券码。在本实施例中，主要采用三种组成方式将券码数据生成固定格式的实时券码。第一种固定格式：机器编码(1位)+业务编码(后3位)+时间戳(后3位)+随机数(3位)，由上可知，该券码固定格式是由10位有效数据构成，这种券码数据格式较短，因此生成的对应券码数量也较少，因此，该数据格式适合在券码低峰时段生成。第二种固定格式：机器编码+业务编码+随机字母(2位)+时间戳+随机数，第二种固定格式在第一种数据组成的基础上扩展了一个组成结构，增加了一项随机字母(2位)，并且对每一项组成结构的位数也没有做限制，明显的，第二种固定格式的数据在存储的数量上得到了较大的扩展，因此，适合在券码高峰时段即电商日生成，以保证在数据库中有足够的券码进行备用。第三种固定格式：机器编码+业务编码+前缀随机数(3位)+时间戳+随机数，第三种固定格式与第二种固定格式的区别在于扩展的组成结构不同，第三种固定格式的扩展项为前缀随机数(3位)，在存储数量上相对小于第二种固定格式，但第三种固定格式扩展项为数字，第三种固定格式生成对应的二维码后，能被大多数的应用进行扫描识别，而第二种固定格式生成对应的二维码后，扫描二维码的应用必须支持字母的识别，因此，在本申请中，优先把券码数据处理成第二种固定格式的实时券码数据。

重复性判断模块303用于在写入所述服务器的数据库之前，遍历所述数据库是否存在与所述实时券码重复的参考券码。在本实施例中，券码数据是由机器编码+业务编号+前缀随机数(3位)+时间戳+随机数构成，若在同一时间内需要生成大量的券码时，特别是在电商日的券码高峰时间段，券码数据容易出现重复的情况，因此我们需要将重复的数据检测出来并舍去重复的数据。由于券码数据都是存储在数据库中，因此我们可以采用数据库的唯一性对券码数据进行重复性判断。

数据处理模块304用于根据重复性判断模块303的判断结果进行对应的数据处理，若是，舍去所述实时券码；若否，将所述实时券码写入所述数据库。在本实施例中，若采用cap检测的结果为实时券码数据与存储在数据库中的参考券码数据出现重复，则及时的舍去实时券码数据，并通知服务器重新生成券码数据存入。若采用cap检测的结果为实时券码数据与存储在数据库中的参考券码数据未出现重复，则将该实时券码数据写入数据库中，并通知服务器进行下一组券码数据的生成。

综上所述，在本实施例中，装置30通过数据获取模块301生成大量的不同类型的券码数据；将券码数据输入格式化数据模块302以将券码处理成固定格式的实时券码，从而简化了数据库写数据的运算，以缓解数据库的写数据压力；采用重复性判断模块303来检测该实时券码数据，以舍去重复的券码数据；最后由数据处理模块304根据重复性判断模块303的判断结果来处理实时券码数据，通过该装置30提高了数据库中券码数据的有效性，使用户能顺利的在客户端输出券码数据，提高用户体验。

图6是本发明实施例提供一种服务器的硬件结构示意图。如图6所示，该电子设备40包括一个或多个处理器401以及存储器402。其中，图6中以一个处理器401为例。

处理器401和存储器402可以通过总线或者其他方式连接，图6中以通过总线连接为例。

存储器402作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本发明实施例中的券码生成的方法对应的程序指令/模块(例如，附图5所示的各个模块)。处理器401通过运行存储在存储器402中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例券码生成的方法以及上述装置实施例的各个模块的功能。

存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器402可选包括相对于处理器401远程设置的存储器，这些远程存储器可以通过网络连接至处理器401。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述程序指令/模块存储在所述存储器402中，当被所述一个或者多个处理器401执行时，执行上述任意方法实施例中的券码生成的方法，例如，执行以上描述的图2、图2a、图2b、图4以及图4a所示的各个步骤；也可实现图5所述的各个模块。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明，它们没有在细节中提供；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。