票据归集方法和设备与流程

1.本发明涉及数据处理领域，更具体地，涉及一种票据归集方法、票据归集设备、计算机存储介质、计算机程序产品以及支付清算服务器。


背景技术：

2.随着信息社会的不断发展和生活节奏的日益加快，快速便捷的支付正步入人们日常的生活、工作和学习之中，包括但不局限于餐饮、购物、停车等等。
3.以移动2g、3g、4g网络、wifi、蓝牙等为代表的无线技术，日益成熟，悄然改变了人们的生活习惯和生活方式，其高安全性、低成本、高速率、低功耗、高集成度、小体积等优点，也极大程度的满足了人们的日常需要。而现代支付方式，凭借着便利、高效、易用、亲民等特色，正全面取代传统的支付方式，各种电子支付app也层出不穷。
4.现有的电子支付app在为用户提供支付时，一般不能提供即时开票的功能。原因在于大部分的电子支付app采用接收推送的方式，即由票据提供方（或称为“票据开具方”）将票据相关信息推送至票据归集方（也称为“票据接收方”）。而部分票据提供方仅有订单信息，没有用户信息，因而票据归集方无法完成用户与票据的匹配，使得电子支付app无法在用户支付后即时向其显示电子票据。


技术实现要素：

5.根据本发明的一方面，提供了一种票据归集方法，所述方法包括：从票据开具方接收订单信息和与所述订单信息对应的票据信息；从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息；以及利用布隆过滤器，基于所述订单信息来将所述票据信息和所述用户信息进行匹配关联。
6.作为上述方案的补充或替换，在上述方法中，在从票据开具方接收订单信息和与所述订单信息对应的票据信息之后，所述方法还包括：在商户协作平台推送记录表中查询与所述订单信息对应的订单；以及基于所查询到的订单，确定所述订单中的用户信息，以便与所述票据信息进行关联。
7.作为上述方案的补充或替换，在上述方法中，在从票据开具方接收订单信息和与所述订单信息对应的票据信息之后，所述方法还包括：在未查询到与所述订单信息对应的订单时，将待查询的订单号存入所述布隆过滤器。
8.作为上述方案的补充或替换，在上述方法中，在从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息之后，所述方法还包括：将所述订单信息中的订单号写入商户协作平台推送记录表中；将所述订单号与所述布隆过滤器进行匹配；在成功匹配时，从票据订单表中查询与所述订单号对应的订单；以及基于所查询到的订单，确定所述订单对应的票据信息，以便与所述用户信息进行关联。
9.作为上述方案的补充或替换，上述方法还包括：通过zookeeper进行分布式的表套号切换。
10.作为上述方案的补充或替换，在上述方法中，通过zookeeper进行分布式的表套号切换包括：在清算时间开始后，清空待切换过去的商户协作平台推送记录表和票据订单表中的数据，并创建新的布隆滤波器。
11.作为上述方案的补充或替换，在从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息之后，所述方法还包括：基于所述订单信息判断是否为今日收取到的订单。
12.作为上述方案的补充或替换，在上述方法中，所述表套号包括第一表套号以及第二表套号。
13.作为上述方案的补充或替换，在上述方法中，通过zookeeper进行分布式的表套号切换包括：在准备从所述第一表套号切换到所述第二表套号时，清空与所述第二表套号对应的商户协作平台推送记录表、票据订单表以及布隆滤波器中的数据；以及至少根据票据订单数量来创建新的布隆滤波器。
14.作为上述方案的补充或替换，上述方法还包括：将匹配关联后的票据信息和用户信息写入用户票包表中。
15.根据本发明的另一个方面，提供了一种票据归集设备，所述设备包括：第一接收装置，用于从票据开具方接收订单信息和与所述订单信息对应的票据信息；第二接收装置，用于从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息；以及匹配关联装置，用于利用布隆过滤器，基于所述订单信息来将所述票据信息和所述用户信息进行匹配关联。
16.作为上述方案的补充或替换，上述设备还包括：第一查询装置，用于在所述第一接收装置从票据开具方接收订单信息和与所述订单信息对应的票据信息之后，在商户协作平台推送记录表中查询与所述订单信息对应的订单；以及第一确定装置，用于基于所查询到的订单，确定所述订单中的用户信息，以便与所述票据信息进行关联。
17.作为上述方案的补充或替换，上述设备还包括：存入装置，用于在未查询到与所述订单信息对应的订单时，将待查询的订单号存入所述布隆过滤器。
18.作为上述方案的补充或替换，上述设备还包括：第一写入装置，用于在所述第二接收装置从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息之后，将所述订单信息中的订单号写入商户协作平台推送记录表中；匹配装置，用于将所述订单号与所述布隆过滤器进行匹配；第二查询装置，用于在成功匹配时，从票据订单表中查询与所述订单号对应的订单；以及第二确定装置，用于基于所查询到的订单，确定所述订单对应的票据信息，以便与所述用户信息进行关联。
19.作为上述方案的补充或替换，上述设备还包括：切换装置，用于通过zookeeper进行分布式的表套号切换。
20.作为上述方案的补充或替换，在上述设备中，所述切换装置配置成：在清算时间开始后，清空待切换过去的商户协作平台推送记录表和票据订单表中的数据，并创建新的布隆滤波器。
21.作为上述方案的补充或替换，上述设备还包括：判断装置，用于在所述第二接收装置从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息之后，基于所述订单信息判断是否为今日收取到的订单。
22.作为上述方案的补充或替换，在上述设备中，所述表套号包括第一表套号以及第二表套号。
23.作为上述方案的补充或替换，在上述设备中，所述切换装置配置成：在准备从所述第一表套号切换到所述第二表套号时，清空与所述第二表套号对应的商户协作平台推送记录表、票据订单表以及布隆滤波器中的数据；以及至少根据票据订单数量来创建新的布隆滤波器。
24.作为上述方案的补充或替换，上述设备还包括：第二写入装置，用于将匹配关联后的票据信息和用户信息写入用户票包表中。
25.根据本发明的又一个方面，提供了一种计算机存储介质，所述介质包括指令，所述指令在运行时执行如前所述的方法。
26.根据本发明的又一个方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现如前所述的方法。
27.根据本发明的又一个方面，提供了一种支付清算服务器，所述服务器包括如前所述的票据归集设备。
28.本发明的实施例的票据归集方案不仅从票据开具方接收订单信息和与所述订单信息对应的票据信息，还从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息，从而将接收到的已成功开票的订单号-票据信息组合与商户侧全量订单号-用户信息组合进行快速匹配，使用户在支付后可以在可接受的时间内，能够查看到自己的电子票据，达到增强用户粘性的目的。另外，本发明的实施例的票据归集方案利用布隆过滤器来进行海量数据的过滤从而匹配关联，实现在o(1)时间复杂度内判断待查数据是否在给定集合中，且占用内存量较小。
29.此外，本发明的一个或多个实施例的票据归集方案通过zookeeper进行分布式的表套号切换，弥补了布隆过滤器的扩展性不足的缺点。
附图说明
30.从结合附图的以下详细说明中，将会使本发明的上述和其他目的及优点更加完整清楚，其中，相同或相似的要素采用相同的标号表示。
31.图1示出了根据本发明的一个实施例的票据归集方法的流程示意图；以及图2示出了根据本发明的一个实施例的票据归集设备的结构示意图。
具体实施方式
32.下面结合附图和实施例对本发明的实施方式作进一步详细描述。以下实施例用于说明本发明，但不能用来限制本发明的范围。
33.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在不相互矛盾的情况下，本
领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
34.图1示出了根据本发明的一个实施例的票据归集方法1000的流程示意图。如图1所示，票据归集方法1000包括如下步骤：在步骤s110中，从票据开具方接收订单信息和与所述订单信息对应的票据信息；在步骤s120中，从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息；以及在步骤s130中，利用布隆过滤器，基于所述订单信息来将所述票据信息和所述用户信息进行匹配关联。
35.在本发明的上下文中，术语“票据开具方”也被称为票据提供方或票据推送方。在一个实施例中，用户在支付并开票后，票据开具方识别出支付渠道为云闪付后，将订单信息与票据信息推送至票据归集方。
36.术语“商户协作平台”（mcs），是指向下游系统推送转发某行业下所有商户的全量支付订单信息及用户信息的系统。在一个或多个实施例中，该商户协作平台仅支持推送功能，不支持查询功能。
37.在本发明的上下文中，术语“布隆过滤器”（英语：bloom filter）实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
38.在一个或多个实施例中，通过布隆过滤器来进行巨量数据的过滤。这样，票据归集方可将接收到的已成功开票的订单号-票据信息组合（即从票据开具方所接收的订单信息以及票据信息）与商户侧全量订单号-用户信息组合（即从商户协作平台所接收的订单信息以及用户信息）进行快速匹配。这有利于用户在支付后能够立即查看到自己的电子票据，达到增强用户粘性的目的。
39.在一个实施例中，在步骤s110之后，上述票据归集方法1000还包括：在商户协作平台推送记录表中查询与所述订单信息对应的订单；以及基于所查询到的订单，确定所述订单中的用户信息，以便与所述票据信息进行关联。在未查询到与所述订单信息对应的订单时，将待查询的订单号存入所述布隆过滤器。
40.例如， 在接收政务服务侧推送后，根据本发明的一个实施例的票据归集方法1000可包括：（1）在当日mcs推送记录表中，查到该笔订单时，取出订单中的用户信息，与票据信息关联后，结束流程。若未查到订单，则进入第2步；（2）将待查询订单号存入当日redis的布隆过滤器中，流程结束。
41.所谓redis（remote dictionary server )，即远程字典服务，是一个开源的使用ansi c语言编写、支持网络、可基于内存亦可持久化的日志型、key-value数据库，并提供多种语言的api。和memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set
ꢀ‑‑
有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性地把更新的数据写入磁盘或者把修改操作
写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
42.redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了java，c/c++，c#，php，javascript，perl，object-c，python，ruby，erlang等客户端，使用很方便。
43.redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。
44.在一个实施例中，在步骤s120之后，上述票据归集方法1000还可包括：将所述订单信息中的订单号写入商户协作平台推送记录表中；将所述订单号与所述布隆过滤器进行匹配；在成功匹配时，从票据订单表中查询与所述订单号对应的订单；以及基于所查询到的订单，确定所述订单对应的票据信息，以便与所述用户信息进行关联。
45.例如，在接收mcs侧推送订单后，本发明的实施例的票据归集方法1000可进一步包括如下步骤：（1）将mcs侧接收到的订单号写入当日mcs订单记录表；（2）将接收到的订单号与redis中bloomfilter进行匹配，若成功匹配，进入第3步；否则，流程结束；（3）从当日待查询票据订单表中查询该笔订单，若查到，则取出票据信息与用户信息关联入用户票包；若未查到，则流程结束。
46.需要说明的是，由于网络路径问题及延时问题，政务服务侧的推送数据与mcs侧的订单推送信息的先后顺序并无法保证，因此在本发明的一个或多个实施例中，步骤s110和步骤s120的顺序并不固定。例如，在一个实施例中，步骤s110可在步骤s120之前执行。在另一个实施例中，步骤s110可在步骤s120之后执行。
47.另外，由于业务需求的特性，来自mcs侧的订单推送量将远大于需要匹配的票据订单量。因此需要用到大数据量的过滤功能。同时，由于订单数据的实效性，我们仅关心当天数据即可，因此在一个实施例中，可以将分布式定时日切功能与布隆滤波器功能进行结合。
[0048] 使用布隆滤波器的好处在于，可以在o(1)时间复杂度内判断待查数据是否在给定集合中，且占用内存量较小。具体来说，占用内存量为 ,其中，fpp为误判率，n为待判断集合。相较之下，若数据库匹配采用b+树结构，时间复杂度在o（lgn）以上，且占用空间将远大于布隆滤波器。
[0049]
本技术的发明人也发现，使用布隆滤波器存在扩展性不足的缺点，即当待判数据的体量增大时，需要启用新的布隆滤波器进行并重新将所有的现存数据写入新的布隆滤波器。
[0050]
为了解决该问题，考虑到在当前业务需求中需要借助布隆滤波器进行判断的数据仅为一天内的数据，因此可以通过ab表日切的方式来克服扩展性的问题。
[0051]
在一个实施例中，尽管图1中未示出，上述票据归集方法1000还包括：通过zookeeper进行分布式的表套号切换。
[0052]
具体来说，上述票据归集方法1000包括如下流程：
（1）所有应用主机订阅zookeeper上的znode节点bloomfiltercode与ordercode；（2）在每日清算时间开始后，所有应用节点通过zookeeper获取日切任务的分布式一致性锁，成功获取锁的应用节点执行第3步；（3）清空待切过去的mcs记录表、票据订单记录表及布隆过滤器中的数据；举例来说，如当前的表套号为a，打算切到b，则清空号码为b的表中所有数据，并根据票据订单数量及营销计划等因素创建新的布隆过滤器；（4）更改znode节点bloomfiltercode与ordercode的值，如从a切换到b；（5）所有接收到zookeeper推送的订阅者节点更新自己本地内存中的表套号值，流程结束。
[0053]
在本发明的上下文中，zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，是google的chubby一个开源的实现，是hadoop和hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。zookeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
[0054]
在zookeeper中，znode是一个跟unix文件系统路径相似的节点，可以往这个节点存储或获取数据。如果在创建znode时flag设置为ephemeral，那么当创建这个znode的节点和zookeeper失去连接后，这个znode将不再存在在zookeeper里，zookeeper使用watcher察觉事件信息。当客户端接收到事件信息，比如连接超时、节点数据改变、子节点改变，可以调用相应的行为来处理数据。zookeeper的wiki页面展示了如何使用zookeeper来处理事件通知，队列，优先队列，锁，共享锁等。
[0055]
在一个实施例中，利用zookeeper实现分布式锁可包括如下步骤：（1）客户端调用create()方法创建名为“locknode/guid-lock
‑”
的节点，需要注意的是，这里节点的创建类型需要设置为ephemeral_sequential；（2）客户端调用getchildren(“locknode”)方法来获取所有已经创建的子节点；（3）客户端获取到所有子节点path之后，如果发现自己在步骤1中创建的节点是所有节点中序号最小的，那么就认为这个客户端获得了锁；（4）如果创建的节点不是所有节点中序号最小的，那么则监视比自己创建节点的序列号小的最大的节点，进入等待；直到下次监视的子节点变更的时候，再进行子节点的获取，判断是否获取锁；（5）释放锁的过程相对比较简单，就是删除自己创建的那个子节点即可。
[0056]
上述利用zookeeper实现分布式锁的方式基于临时顺序节点。可以理解的是，利用zookeeper实现分布式锁的方式不限于上述举例。本领域技术人员可根据实际需要来进行变更。
[0057]
另外，在一个实施例中，上述方法1000还包括：将匹配关联后的票据信息和用户信息写入用户票包表中。这样，用户可在完成支付后的一定合理时间范围内，在电子支付app（例如云闪付）中看到自己的电子票据。
[0058]
通过以上各种实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体
现出来，该计算机软件产品可以存储在计算机可读存储介质中，所述计算机可读记录介质包括用于以计算机(例如计算机)可读的形式存储或传送信息的任何机制。例如，机器可读介质包括只读存储器(rom)、随机存取存储器(ram)、磁盘存储介质、光存储介质、闪速存储介质、电、光、声或其他形式的传播信号(例如，载波、红外信号、数字信号等)等，该计算机软件产品包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
[0059]
图2示出了根据本发明的一个实施例的票据归集设备2000的结构示意图。如图2所示，票据归集设备2000包括第一接收装置210、第二接收装置220以及匹配关联装置230。
[0060]
其中，第一接收装置210用于从票据开具方接收订单信息和与所述订单信息对应的票据信息；第二接收装置220用于从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息；以及匹配关联装置230用于利用布隆过滤器，基于所述订单信息来将所述票据信息和所述用户信息进行匹配关联。
[0061]
在本发明的上下文中，术语“票据开具方”也被称为票据提供方或票据推送方。在一个实施例中，用户在支付并开票后，票据开具方识别出支付渠道为云闪付后，将订单信息与票据信息推送至票据归集方。
[0062]
术语“商户协作平台”（mcs），是指向下游系统推送转发某行业下所有商户的全量支付订单信息及用户信息的系统。在一个或多个实施例中，该商户协作平台仅支持推送功能，不支持查询功能。
[0063]
在本发明的上下文中，术语“布隆过滤器”（英语：bloom filter）实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
[0064]
在一个或多个实施例中，通过布隆过滤器来进行巨量数据的过滤。这样，票据归集方可将接收到的已成功开票的订单号-票据信息组合（即从票据开具方所接收的订单信息以及票据信息）与商户侧全量订单号-用户信息组合（即从商户协作平台所接收的订单信息以及用户信息）进行快速匹配。这有利于用户在支付后能够立即查看到自己的电子票据，达到增强用户粘性的目的。
[0065]
在一个实施例中，尽管图2中未示出，上述设备2000还包括：第一查询装置，用于在所述第一接收装置从票据开具方接收订单信息和与所述订单信息对应的票据信息之后，在商户协作平台推送记录表中查询与所述订单信息对应的订单；以及第一确定装置，用于基于所查询到的订单，确定所述订单中的用户信息，以便与所述票据信息进行关联。在一个实施例中，上述设备2000还可包括：存入装置，用于在未查询到与所述订单信息对应的订单时，将待查询的订单号存入所述布隆过滤器。
[0066]
例如， 在第一接收装置接收政务服务侧推送后，第一查询装置用于在当日mcs推送记录表中查询与订单信息对应的订单。若第一查询装置查到该笔订单时，则第一确定装置取出订单中的用户信息，以便与票据信息关联。若第一查询装置未查到订单，则存入装置将待查询订单号存入当日redis的布隆过滤器中。
[0067]
所谓redis（remote dictionary server )，即远程字典服务，是一个开源的使用ansi c语言编写、支持网络、可基于内存亦可持久化的日志型、key-value数据库，并提供多种语言的api。和memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set
ꢀ‑‑
有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性地把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
[0068]
redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了java，c/c++，c#，php，javascript，perl，object-c，python，ruby，erlang等客户端，使用很方便。
[0069]
redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。
[0070]
在一个实施例中，上述设备2000还可包括：第一写入装置，用于在所述第二接收装置从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息之后，将所述订单信息中的订单号写入商户协作平台推送记录表中；匹配装置，用于将所述订单号与所述布隆过滤器进行匹配；第二查询装置，用于在成功匹配时，从票据订单表中查询与所述订单号对应的订单；以及第二确定装置，用于基于所查询到的订单，确定所述订单对应的票据信息，以便与所述用户信息进行关联。
[0071]
例如，在第二接收装置接收mcs侧推送订单后，第一写入装置将mcs侧接收到的订单号写入当日mcs订单记录表。接着，匹配装置将接收到的订单号与redis中布隆过滤器进行匹配。若成功匹配，则第二查询装置从当日待查询票据订单表中查询该笔订单。若第二查询装置查到该笔订单，则第二确定装置取出票据信息，以便与用户信息关联入用户票包。
[0072]
在一个实施例中，上述设备2000还可包括：判断装置，用于在所述第二接收装置从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息之后，基于所述订单信息判断是否为今日收取到的订单。
[0073]
另外，由于业务需求的特性，来自mcs侧的订单推送量将远大于需要匹配的票据订单量。因此需要用到大数据量的过滤功能。同时，由于订单数据的实效性，我们仅关心当天数据即可，因此在一个实施例中，可以将分布式定时日切功能与布隆滤波器功能进行结合。
[0074]
使用布隆滤波器的好处在于，可以在o(1)时间复杂度内判断待查数据是否在给定集合中，且占用内存量较小。具体来说，占用内存量为 ,其中，fpp为误判率，n为待判断集合。相较之下，若数据库匹配采用b+树结构，时间复杂度在o（lgn）以上，且占用空间将远大于布隆滤波器。
[0075]
本技术的发明人也发现，使用布隆滤波器存在扩展性不足的缺点，即当待判数据
的体量增大时，需要启用新的布隆滤波器进行并重新将所有的现存数据写入新的布隆滤波器。
[0076]
为了解决该问题，考虑到在当前业务需求中需要借助布隆滤波器进行判断的数据仅为一天内的数据，因此可以通过ab表日切的方式来克服扩展性的问题。
[0077]
在一个或多个实施例中，上述设备2000还包括：切换装置，用于通过zookeeper进行分布式的表套号切换。例如，切换装置可配置成：在清算时间开始后，清空待切换过去的商户协作平台推送记录表和票据订单表中的数据，并创建新的布隆滤波器。
[0078]
在本发明的上下文中，zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，是google的chubby一个开源的实现，是hadoop和hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。zookeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
[0079]
在zookeeper中，znode是一个跟unix文件系统路径相似的节点，可以往这个节点存储或获取数据。如果在创建znode时flag设置为ephemeral，那么当创建这个znode的节点和zookeeper失去连接后，这个znode将不再存在在zookeeper里，zookeeper使用watcher察觉事件信息。当客户端接收到事件信息，比如连接超时、节点数据改变、子节点改变，可以调用相应的行为来处理数据。zookeeper的wiki页面展示了如何使用zookeeper来处理事件通知，队列，优先队列，锁，共享锁等。
[0080]
在一个实施例中，表套号包括第一表套号以及第二表套号。在该实施例中，切换装置配置成：在准备从所述第一表套号切换到所述第二表套号时，清空与所述第二表套号对应的商户协作平台推送记录表、票据订单表以及布隆滤波器中的数据；以及至少根据票据订单数量来创建新的布隆滤波器。
[0081]
在一个实施例中，上述设备2000还可包括：第二写入装置，用于将匹配关联后的票据信息和用户信息写入用户票包表中。
[0082]
上述票据归集设备2000可集成在各种类型的支付清算服务器中。这样，支付清算服务器从票据开具方以及商户协作平台分别接收信息，并对所接收的信息进行归集，从而为用户提供“支付即开票”功能。
[0083]
在一个实现场景下，包含票据开具方、票据归集方以及商户协作平台的系统交互流程包括如下步骤：（1）用户通过云闪付app缴纳财政款项，如路侧停车费等；（2）交易信息经过银联全渠道系统通知到商户协作平台（mcs）；（3）商户协作平台判断收款商户属于政务类商户后，将订单信息与用户信息推送至票据归集方；（4）票据归集方接收到mcs侧推送的订单信息后，判断是否为今日收取到的票据订单，若是进入第5步；否则流程结束；（5）通过订单信息组合mcs侧推送来的用户信息与财政服务侧（即票据开具方）推送来的票据信息，组装成票据信息，写入用户票包表，流程结束；（6）财政服务侧确认用户付款成功后，开具票据，并将票据信息与银联侧订单信息推送至票据归集方；
（7）票据归集方接收到财政服务的推送信息后，判断今日是否已从mcs侧接收到对应的订单信息，若是进入第5步；否则记为待补全信息，并结束流程。
[0084]
综上，本发明的实施例的票据归集方案不仅从票据开具方接收订单信息和与所述订单信息对应的票据信息，还从商户协作平台接收所述订单信息和与所述订单信息对应的用户信息，从而将接收到的已成功开票的订单号-票据信息组合与商户侧全量订单号-用户信息组合进行快速匹配，使用户在支付后可以在可接受的时间内，能够查看到自己的电子票据，达到增强用户粘性的目的。另外，本发明的实施例的票据归集方案利用布隆过滤器来进行海量数据的过滤从而匹配关联，实现在o(1)时间复杂度内判断待查数据是否在给定集合中，且占用内存量较小。
[0085]
此外，本发明的一个或多个实施例的票据归集方案通过zookeeper进行分布式的表套号切换，弥补了布隆过滤器的扩展性不足的缺点。
[0086]
本技术是参照根据本技术实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0087]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0088]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0089]
尽管已描述了本技术的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本技术范围的所有变更和修改。显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。