一种支付对账方法及服务器
阅读说明：本技术 一种支付对账方法及服务器 (payment reconciliation method and server ) 是由 余意 鲜丹 郭亲华 谭国军 于 2019-07-03 设计创作，主要内容包括：本发明涉及数据处理技术领域,公开一种支付对账方法及服务器,该方法通过获取参考订单信息,然后根据参考订单信息,获取文件索引号及索引地址,该文件索引号用于标识订单文件,该订单文件用于记录与参考订单信息对应的基准订单信息,该索引地址用于指向所述基准订单信息在所述订单文件中的位置,再根据文件索引号及索引地址,获取基准订单信息,最后根据参考订单信息及基准订单信息,生成对账结果,从而达到快速对账的目的。该实施例根据基准订单信息,生成订单文件和索引文件,提高基准订单信息与参考订单信息的对账效率。(The invention relates to the technical field of data processing, and discloses a payment reconciliation method and a server. According to the embodiment, the order file and the index file are generated according to the benchmark order information, and the reconciliation efficiency of the benchmark order information and the reference order information is improved.)
技术领域
本发明涉及数据处理技术领域，特别是涉及一种支付对账方法及服务器。
背景技术
随着互联网技术的发展，人们使用移动支付的频率越来越高，常用的移动支付方式包括支付宝、微信以及银联支付等等。在移动支付产生以后，对账系统会对移动支付产生的订单以及后台产生的交易订单进行对账。随着人们使用移动支付的次数越来越多，产生的交易订单也越来越多，对账系统处理对账的效率因此而变低。
发明内容
本发明实施例一个目的旨在提供一种支付对账方法及服务器，能够提高订单对账效率。
为解决上述技术问题，本发明实施例采用的一个技术方案是：提供一种支付对账方法，包括：
获取参考订单信息；
根据所述参考订单信息，获取文件索引号及索引地址，所述文件索引号用于标识订单文件，所述订单文件用于记录与所述参考订单信息对应的基准订单信息，所述索引地址用于指向所述基准订单信息在所述订单文件中的位置；
根据所述文件索引号及所述索引地址，获取所述基准订单信息；
根据所述参考订单信息及所述基准订单信息，生成对账结果。
在一些实施例中，所述根据所述参考订单信息，获取文件索引号，包括：
从所述参考订单信息提取参考订单号；
对所述参考订单号作哈希取模运算，得到文件索引号。
在一些实施例中，所述根据所述参考订单信息，获取索引地址，包括：
获取索引文件，所述索引文件用于记录与所述参考订单号对应的索引地址，其中，所述参考订单号与所述基准订单信息中的基准订单号一致；
根据所述参考订单信息中的参考订单号，获取索引地址。
在一些实施例中，所述根据所述文件索引号及所述索引地址，获取所述基准订单信息，包括：
确定与所述文件索引号对应的订单文件；
从所述订单文件中遍历出与所述索引地址对应的基准订单信息。
在一些实施例中，所述方法还包括：
预先构建订单文件及索引文件。
在一些实施例中，所述预先构建订单文件，包括：
获取各条基准订单信息；
将所述各条基准订单信息分别归类至对应的订单文件中。
在一些实施例中，所述将所述各条基准订单信息分别归类至对应的订单文件中，包括：
根据哈希算法，启动多线程处理各条基准订单信息，得到与每条所述基准订单信息对应的文件索引号；
将每条所述基准订单信息归类至在所述文件索引号下的订单文件。
在一些实施例中，每个所述线程索引号与每个所述线程一一对应，并且，每个所述线程索引号还分别与文件索引号及索引码对应，每个所述文件索引号与每个所述订单文件一一对应，每个所述索引码与每个所述索引文件一一对应。
在一些实施例中，所述预先构建索引文件，包括：
根据与每条所述基准订单信息对应的索引码，将每条所述基准订单信息的索引地址归类至在所述索引码下的索引文件。
本发明实施例的另一个方面，提供一种服务器，包括：
至少一个处理器；以及，
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述支付对账方法。本发明实施例的有益效果是：区别于现有技术的情况，本发明实施例通过提供的对账方法包括：获取参考订单信息，根据参考订单信息，获取文件索引号及索引地址，文件索引号用于标识订单文件，订单文件用于记录与参考订单信息对应的基准订单信息，索引地址用于指向基准订单信息在订单文件中的位置；根据文件索引号及索引地址，获取基准订单信息；根据参考订单信息及基准订单信息，生成对账结果。该对账方法可以提高支付对账的效率。
附图说明
图1是本发明实施例提供的一种对账系统的结构示意图；
图2是本发明实施例提供的一种对账方法的流程示意图；
图3是图2中步骤202的流程示意图；
图4是图2中步骤203的流程示意图；
图5是本发明另一实施例提供的一种对账方法的流程示意图；
图6是图5中步骤301的流程示意图；
图7是本发明实施例提供的一种对账装置的结构示意图；
图8是本发明实施例提供的一种电子设备的结构示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
需要说明的是，如果不冲突，本发明实施例中的各个特征可以相互结合，均在本发明的保护范围之内。另外，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置示意图中的模块划分，或流程图中的顺序执行所示出或描述的步骤。
参阅图1，图1是应用于本发明的支付对账方法或者对账装置的实施例的示例性系统结构示意图。如图1所示，该系统结构100包括终端设备101、服务器102以及网络103。网络103用于在终端设备101和服务器102之间提供通信链路的介质。网络103可以包括各种连接类型，比如有线、无线通信链路或者光纤电缆等。
用户可以使用终端设备101通过网络103与服务器102交互，以接收或者发送消息。终端设备101可以是有显示屏的各种电子设备，其包括但不限于智能手机、平板电脑、智能手表、电子阅读器等。终端设备101还可以安装各种移动支付应用，比如微信支付应用、支付宝应用以及银联卡应用等，终端设备101还支持各种支付方式，比如刷脸支付、扫码支付等支付方式。
服务器102可以是本地存储数据来应答终端设备请求的服务器。例如，对终端设备101传递过来的订单信息进行数据处理的后台服务器，该服务器在终端设备101传递过来订单信息时，根据订单查找本地系统后台订单数据，再对终端设备传递过来的订单信息与后台订单数据进行对账分析处理，并记录处理结果(例如对账的金额、对账的结果等)。
服务器102也可以是远程地从第三方服务器获得数据来应答终端设备101请求的服务器。例如，在用户使用终端设备101传递过来订单信息时，服务器102根据该订单信息从第三方服务器远程获取系统后台订单数据，进而再对终端设备传递过来的订单信息与后台订单数据进行对账分析处理，并记录处理结果。
需要说明的是，本发明实施例所提供的支付对账方法一般由上述服务器102执行，相应地，支付对账装置一般设置于服务器102中。
应该理解，图1中的终端设备101、服务器102以及网络103的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备101、服务器102以及网络103。
请参阅图2，其示出了根据上述系统结构100所应用的一种支付对账方法的流程示意图，如图2所示，该方法200包括：
步骤201：获取参考订单信息。
在本实施例中，该参考订单信息是指终端设备传递到服务器的订单信息，在用户完成支付以后，会产生订单信息，该订单信息包括订单号、支付金额、支付时间甚至是支付地点等与该支付相关的一些信息，当需要进行对账操作时，获取该订单信息。
步骤202：根据所述参考订单信息，获取文件索引号及索引地址。
在本实施例中，所述文件索引号用于标识订单文件，订单文件可以有多个，该文件索引号就是指订单文件id或者订单文件序号。
所述订单文件用于记录与所述参考订单信息对应的基准订单信息，该基准订单信息是指存于后台服务器，与所述参考订单信息对应的相关订单信息，其包括订单号、支付金额、支付时间以及支付地点等与该支付相关的一些信息，该基准订单信息存于某个订单文件中。
所述索引地址用于指向所述基准订单信息在所述订单文件中的位置，订单文件中会存有多条基准订单信息，每条基准订单信息在订单文件中的位置都不同，这些基准订单信息可以以列表的形式存于订单文件中，在列表中排列的顺序可以按照支付的时间排序，也可以按照支付的金额排序等，根据所述索引地址，可以找到所述基准订单信息在所述订单文件中的位置。
步骤203：根据所述文件索引号及所述索引地址，获取所述基准订单信息。
在本实施例中，根据文件索引号，找到所述基准订单信息所在的订单文件的文件序号，进而找到该订单文件，再根据所述索引地址，找到所述基准订单信息在上述订单文件中的位置，继而获取所述基准订单信息。
步骤204：根据所述参考订单信息及所述基准订单信息，生成对账结果。
在本实施例中，将所述参考订单信息的数据与所述基准订单信息的数据进行比对，比对的数据包括支付金额、支付状态、支付时间以及订单本身的缺失(参考订单多基准订单少，或者基准订单少参考订单多)等，若数据一致，标记该对账结果与已对账订单，若数据不一致，则将所述参考订单与所述基准订单放入异常差错表，以供后续处理。
综上所述，通过上述方法，其可以提高对账效率以及数据处理速度。
在一些实施例中，请参阅图3，步骤202包括：
步骤2021：从所述参考订单信息提取参考订单号。
每一笔参考订单完成后，都会生成与之相对应的、唯一的参考订单号，该参考订单号可以是一连串数字编码，也可以是一连串字母编码，或者是数字与字母混合的编码等形式。
步骤2022：对所述参考订单号作哈希取模运算，得到文件索引号。
哈希算法是指把任意长度的输入(又叫做预映射pre-image)通过散列算法变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，所以不可能从散列值来确定唯一的输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。根据哈希算法，将每一条上述参考订单号都生成相同长度的数据，根据该数据，生成文件索引号，也即订单文件id或订单文件序号。
请继续参阅图3，步骤202还包括：
步骤2023：获取索引文件，所述索引文件用于记录与所述参考订单号对应的索引地址，其中，所述参考订单号与所述基准订单信息中的基准订单号一致。
在一些实施例中，索引文件是预先生成的，基准订单号及与所述基准订单号对应的索引地址就是该基准订单的索引信息，每一条基准订单的索引信息按照某种顺序排列在索引文件列表中，比如按照将索引信息写入索引文件的时间等原则排列。
在一些实施例中，步骤202还包括：
步骤2024：根据所述参考订单信息中的参考订单号，获取索引地址。
所述索引地址包括所述基准订单号以及所述基准订单号对应的起始地址及偏移长度，因此，根据订单号，可以获取与之唯一对应的索引地址。
请参阅图4，步骤203包括：
步骤2031：确定与所述文件索引号对应的订单文件。
在一些实施例中，所述文件索引号即是所述基准订单信息所在的订单文件的文件序号，根据该序号，确定相应的订单文件。
步骤2032：从所述订单文件中遍历出与所述索引地址对应的基准订单信息。
在一些实施例中，确定对应的订单文件以后，根据基准订单号以及基准订单号对应的起始地址及偏移长度，遍历出对应的基准订单信息。
请参阅图5，图5是本发明另一实施例提供的一种支付对账方法的流程示意图。如图5所示，该方法300包括：
步骤301：预先构建订单文件及索引文件。
所述索引文件用于记录与所述基准订单信息有关的基准订单号和索引地址。
请参阅图6，在本实施例中，步骤301，包括：
步骤3011：获取各条基准订单信息。
各条基准订单信息是预先存储在数据库中，在获取各条基准订单信息时，可以采用线程池的方式，设置多条拉取线程进行拉取各条基准订单信息，其中，线程(英语：thread)是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。
线程池是一种多线程处理形式，处理过程中将任务添加到队列，然后在创建线程后自动启动这些任务。线程池线程都是后台线程。每个线程都使用默认的堆栈大小，以默认的优先级运行，并处于多线程单元中。
拉取线程的数量可以按照时间区间的个数进行设置，在相同时间区间的基准订单信息均由相同的拉取线程进行拉取，同时，拉取方法可以采取JDBC方法并发拉取，可以提高拉取效率，并且可以处理大数量的数据，处理速度更快。例如：
对账日期是5.11号，现首先获取5.11号的各条基准订单信息，这些订单信息均存储于数据库中，各条基准订单信息形式为：
那么首先把各条基准订单信息按照时间区间分为4个区间：0点-6点(前开后闭)、6点-12点(前开后闭)、12点-18点(前开后闭)以及18点-次日0点(前开后闭)，时间区间的设置不做具体设定，人们可以根据需要设置不同的时间区间。
然后根据时间区间的个数，设置相同个数的拉取线程，在这里，设置4条拉取线程，采取JDBC方法并发拉取，具体过程为：
第一个线程负责拉取5.11号0点-6点(前开后闭)的基准订单，拉取订单记录为空；
第二个线程负责拉取5.11号6点-12点(前开后闭)的基准订单，拉取订单记录有1条，基准订单号为201901167902；
第三个线程负责拉取5.11号12点-18点(前开后闭)的基准订单，拉取订单记录2条，基准订单号分别为201901167904，201901167905；
第四个线程负责拉取5.11号18点-5.12号0点(前开后闭)的基准订单，拉取订单记录1条，基准订单号为201901167903；
那么总共拉取到4条基准订单。
步骤3012：将所述各条基准订单信息分别归类至对应的订单文件中。
拉取之后的各条基准订单信息按照某种原则，将其进行分类，并将分类之后的同种基准订单信息放在同一订单文件中，其中，订单文件的数量可以与拉取线程的个数相同。具体归类过程包括：
首先，根据哈希算法，启动多线程处理各条基准订单信息，得到与每条所述基准订单信息对应的文件索引号。
为了避免并发写文件的性能问题，在使用多线程拉取基准订单的同时，设置同等数量的接收线程来接收对应的基准订单信息，在获取每条基准订单信息时，根据哈希算法，得到与每条所述基准订单信息对应的接收线程号，将每条所述基准订单信息存储到对应接收线程号下的接收线程中，再根据接收线程号得到对应的文件索引号，即文件序号或者文件id号，再将每条所述基准订单信息归类至在所述文件索引号下的订单文件。例如：在上述例子中，设置4条拉取线程进行拉取基准订单信息，那么同时设置4条接收线程进行接收所述基准订单信息，分别称为接收线程1、接收线程2、接收线程3以及接收线程4，并设置4个订单文件用于存储所述基准订单信息，分别称为file[0]、file[1]、file[2]以及file[3]，那么文件id，即0、1、2以及3是不同的文件索引号。对于订单号为201901167904的基准订单信息，做哈希算法，得到接收线程号为0，则由接收线程号为0的接收线程接收该基准订单信息，然后将该基准订单信息归类至文件索引号为0的订单文件中，即订单文件file[0]中，再次读取下一条基准订单信息，再进行归类，循环该操作，直至所有的基准订单信息均被归类至对应的订单文件中，具体结果为：
步骤3013：根据与每条所述基准订单信息对应的索引码，将每条所述基准订单信息的索引地址归类至在所述索引码下的索引文件。
在本实施例中，每个所述线程索引号与每个所述线程一一对应，并且，每个所述线程索引号还分别与文件索引号及索引码对应，每个所述文件索引号与每个所述订单文件一一对应，每个所述索引码与每个所述索引文件一一对应。
在生成订单文件的同时，可以生成同等数量的索引文件，将每条所述基准订单信息归类至对应的所述订单文件以后，再次根据索引码，将该基准订单信息在对应的所述订单文件的位置以及订单号同时归类至在所述索引码下的索引文件。其中，所述基准订单信息在对应的所述订单文件的位置可以用其位置偏移量以及该条订单信息的字节长度共同表示。例如：在上述例子中，在生成4个订单文件的同时，会生成4个索引文件，分别为索引文件index[0]、索引文件index[1]、索引文件index[2]以及索引文件index[3]，其中，索引文件id号，即0、1、2以及3为四个不同的索引码。由于订单号为201901167904的基准订单信息由第0个线程抓取并处理，于是，处理的结果为：线程索引号为0，文件索引号为0，那么索引码为0，若该基准订单信息在订单文件file[0]中的位置偏移量是0，字节长度为52，那么该基准订单信息的索引地址就是201901167904,0,52，将该索引地址归类至索引文件index[0]中，若该订单文件中存在多条基准订单信息，那么继续读取该订单文件中的第二条基准订单信息，且第二条基准订单信息在订单文件file[0]中的偏移量要从52开始，若其字节长度为50，那么第二条基准订单信息的索引地址就是订单号,52,50，将该索引地址归类至索引文件index[0]中，每条基准订单信息的索引地址在索引文件中的顺序可以按照基准订单信息的读取时间进行排序，也可以按照其他原则进行排序。根据索引文件中的索引地址，就可以找到该基准订单信息在对应的订单文件中的位置，继而获取该基准订单信息。
上述操作可以在参考订单信息传送到服务器之前完成，比如可以在凌晨进行该操作，这样就会有充足的时间进行分时间区间拉取基准订单信息，然后生成订单文件和索引文件，并且可以把时间区间分得更小更细，减小数据库的存储压力，并且提高JDBC的拉取效率，当参考订单信息传送到服务器以后，采用事先生成好的订单文件和索引文件进行对账，节约对账时间，提高对账效率。
请参阅图5，步骤302：获取参考订单信息；
参考订单信息是存在与文件中，其存放的数据包括订单号、交易时间、交易金额以及交易状态等。例如：在上述例子中，参考订单信息可以在5.11号传输到服务器中的相应文件中，存储状态为：
每次进行对账时，从参考订单信息文件中获取一条参考订单，将该参考订单加载到内存，然后进行后续对账处理，当参考订单文件较大时，可以将参考订单文件进行文件切片，并生成其对应的索引文件，文件切片同样可以按照时间区间进行切片，然后按照同样上述方法生成索引文件，然后在对账时候，可以先读取索引文件，再根据索引文件获取对应的参考订单信息，这种操作可以为后续对账增加并发能力，也能提高对账速度。
步骤303：根据所述参考订单信息，获取文件索引号及索引地址，所述文件索引号用于标识订单文件，所述订单文件用于记录与所述参考订单信息对应的基准订单信息，所述索引地址用于指向所述基准订单信息在所述订单文件中的位置；
在进行对账时，对所述参考订单信息的订单号做哈希算法，可以得到文件索引号，例如对于订单号为201901167904的参考订单信息，对该订单号做哈希算法，得到文件索引号为0，然后通过hashmap.get(orderNo)命令可以从索引文件indx[0]中得到与该订单号对应的基准订单信息在订单文件的偏移量和字节长度，对于该订单号来说，其偏移量和字节长度为0和52。其中，上述操作均在内存中完成。
步骤304：根据所述文件索引号及所述索引地址，获取所述基准订单信息。
根据所述文件索引号，先找到对应文件索引号下的订单文件，再根据索引地址，获取所述基准订单信息。例如：对于订单号为201901167904的参考订单信息，文件索引号为0，那么可以得到文件索引号为0，在索引文件index[0]中找到订单号为201901167904的基准订单信息的索引地址，即201901167904,0,52，根据该索引地址在file[0]中找到订单号为201901167904的基准订单信息的位置，继而获得其信息。
步骤305：根据所述参考订单信息及所述基准订单信息，生成对账结果。
对于已对账订单会做出相应标记，并将一些出现差错的订单放进异常差错表。例如：将上述参考订单信息及基准订单信息进行对账，最终对账结果如下：
1)201901167901订单时间不一致(跨天，会引发结算时间问题)；
2)201901167902订单金额不一致(对不平)；
3)201901167903订单状态不一致(订单状态不同步，需同步一下状态)；
4)201901167904订单信息一致(对平)；
5)201901167905基准订单多参考订单少(产生挂销账)；
6)201901167906基准订单少参考订单多(产生挂销账)。
除了第4条订单之外，将其他参考订单信息和基准订单信息放进异常差错表，并进行下一轮的对账。
本发明实施例提供了一种支付对账方法，该方法通过获取参考订单信息，然后根据参考订单信息，获取文件索引号及索引地址，该文件索引号用于标识订单文件，该订单文件用于记录与参考订单信息对应的基准订单信息，该索引地址用于指向所述基准订单信息在所述订单文件中的位置，再根据文件索引号及索引地址，获取基准订单信息，最后根据参考订单信息及基准订单信息，生成对账结果，从而达到快速对账的目的。该实施例根据基准订单信息，生成订单文件和索引文件，提高基准订单信息与参考订单信息的对账效率。
请参阅图7，图7是本发明实施例提供的一种支付对账装置的结构示意图，如图所示，该支付对账装置400包括：第一获取模块401，第二获取模块402，第三获取模块403，第一生成模块404。
其中，第一获取模块401用于获取参考订单信息；第二获取模块402用于根据所述参考订单信息，获取文件索引号及索引地址，所述文件索引号用于标识订单文件，所述订单文件用于记录与所述参考订单信息对应的基准订单信息，所述索引地址用于指向所述基准订单信息在所述订单文件中的位置；第三获取模块403，用于根据所述文件索引号及所述索引地址，获取所述基准订单信息；第一生成模块404，用于根据所述参考订单信息及所述基准订单信息，生成对账结果。
其中，请继续参阅图7，第二获取模块402包括：第一提取单元4021，第一生成单元4022，第一获取单元4023，第二获取单元4024。
第一提取单元4021用于从所述参考订单信息提取参考订单号。
第一生成单元4022用于对所述参考订单号作哈希取模运算，得到文件索引号。
第一获取单元4023用于获取索引文件，所述索引文件用于记录与所述参考订单号对应的索引地址，其中，所述参考订单号与所述基准订单信息中的基准订单号一致。
第二获取单元4024用于根据所述参考订单信息中的参考订单号，获取索引地址。
其中，请继续参阅图7，第三获取模块403包括：第一确定单元4031、第一遍历单元4032。
第一确定单元4031用于确定与所述文件索引号对应的订单文件。
第一遍历单元4032用于从所述订单文件中遍历出与所述索引地址对应的基准订单信息。
在本实施例的一些可选地实现方式中，同样参阅图7，所述装置400还包括第二生成模块405，其具体用于预先构建订单文件及索引文件。
其中第二生成模块405包括第三获取单元4051、第一归类单元4052，第二归类单元4053。
第三获取单元4051用于获取各条基准订单信息。
第一归类单元4052用于将所述各条基准订单信息分别归类至对应的订单文件中，具体用于根据哈希算法，启动多线程处理各条基准订单信息，得到与每条所述基准订单信息对应的文件索引号；再将每条所述基准订单信息归类至在所述文件索引号下的订单文件。
第二归类单元4053用于根据与每条所述基准订单信息对应的索引码，将每条所述基准订单信息的所述索引地址归类至在所述文件索引号下的索引文件。
值得说明的是，上述装置内的模块之间的信息交互、执行过程等内容，由于与本发明的方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。
本发明实施例提供了一种支付对账方法装置，该装置通过通过获取参考订单信息，然后根据参考订单信息，获取文件索引号及索引地址，该文件索引号用于标识订单文件，该订单文件用于记录与参考订单信息对应的基准订单信息，该索引地址用于指向所述基准订单信息在所述订单文件中的位置，再根据文件索引号及索引地址，获取基准订单信息，最后根据参考订单信息及基准订单信息，生成对账结果，从而达到快速对账的目的。该实施例根据基准订单信息，生成订单文件和索引文件，提高基准订单信息与参考订单信息的对账效率。
请参阅图8，图8是本发明实施例提供执行上述支付对账方法的电子设备500的硬件结构示意图，如图8所示，该电子设备500包括：
一个或多个处理器501以及存储器502，图8中以一个处理器501为例。
处理器501和存储器502可以通过总线或者其他方式连接，图8中以通过总线连接为例。
存储器502作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本发明实施例中的广告推荐方法对应的程序指令/模块(例如，附图7所示的各个模块)。处理器501通过运行存储在存储器502中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例支付对账方法。
存储器502可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据支付对账装置的使用所创建的数据等。此外，存储器502可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器502可选包括相对于处理器501远程设置的存储器，这些远程存储器可以通过网络连接至支付对账装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
所述一个或者多个模块存储在所述存储器502中，当被所述一个或者多个处理器501执行时，执行上述任意方法实施例中的支付对账方法，例如，执行以上描述的图2至图6的方法步骤，实现图7中的各模块和各单元的功能。
上述产品可执行本发明实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明实施例所提供的方法。
本发明实施例的电子设备以多种形式存在，包括但不限于:
(1)服务器:提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
(2)其他具有数据交互功能的电子装置。
本发明实施例提供了一种非易失性计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个处理器执行，例如，执行以上描述的图2至图6的方法步骤，实现图7中的各模块和各单元的功能。
本发明实施例提供了一种计算机程序产品，包括存储在非易失性计算机可读存储介质上的计算程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时时，使所述计算机执行上述任意方法实施例中的广告推荐方法，例如，执行以上描述的图2至图6的方法步骤，实现图7中的各模块和各单元的功能。
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
通过以上的实施例的描述，本领域普通技术人员可以清楚地了解到各实施例可借助软件加通用硬件平台的方式来实现，当然也可以通过硬件。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory,ROM)或随机存储记忆体(Random Access Memory,RAM)等。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明，它们没有在细节中提供；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。