互联网业务的处理方法及装置与流程

本申请涉及互联网技术领域，尤其涉及一种互联网业务的处理方法及装置。

背景技术：

随着互联网的发展，互联网业务越来越普遍，为了均衡互联网业务的处理压力，也为细节行业内不同的分工，一般会有不同的终端专门进行不同的操作，比如有专门的终端接收互联网业务(简称“业务”)请求，并根据业务请求生成业务文件，发送给专门用于处理业务的终端。

现有技术，当接收业务请求的终端将业务文件发送给用于处理业务的终端(简称“业务处理终端”)后，业务处理终端会读取其中的业务请求，并进行相应地处理，在处理完毕后，会将处理结果直接写入到该业务文件中，并返回给相应的终端，而且业务文件的收发均通过一个接口完成。然而，随着业务数量的增大，业务种类的增多，业务文件中包含的信息也在不断增多，业务处理终端在基于接收到的业务文件继续写入处理结果时，如果在继续写入时由于应用程序出错或硬件设备出现问题(写入失败、写入错误信息、磁盘出现坏道等)都可能使这个业务文件损坏或错乱，导致无法继续写入、或者即使写入完毕返回给相应的终端也可能导致无法正常读取等，进而使得业务处理的效率较低，而且业务文件的收发均通过一个接口完成，如果业务很多就会压力过大，从而出现拥堵、出错等问题，进一步使得业务处理的效率较低。所以如何在基于业务文件进行业务处理的场景下降低业务文件出错的概率，来提高业务处理效率成为了需要解决的问题。更何况随着计算机处理能力的提高以及应用程序的优化，互联网业务效率要求越来越高的情况下，降低业务文件出错的概率，来提高业务处理效率更是亟需解决的问题。

技术实现要素：

本申请实施例提供一种互联网业务的处理方法，用于降低业务处理过程中业务文件出现错误的概率，提高互联网业务的处理效率。

本申请实施例提供一种互联网业务的处理装置，用于降低业务处理过程中业务文件出现错误的概率，提高互联网业务的处理效率。

本申请实施例采用下述技术方案：

一种互联网业务的处理方法，包括：

接收请求方发送的业务请求；

根据所述业务请求生成第一业务文件，并发送给业务处理终端，在生成第一业务文件后，所述第一业务文件只能被读取；

接收所述业务处理终端发送的第二业务文件，所述第二业务文件为所述业务处理终端读取所述第一业务文件并处理所述业务请求后根据业务处理结果生成的，所述第二业务文件在生成后只能被读取；

读取所述第二业务文件，并将业务处理结果返回给请求方。

优选地，根据所述业务请求生成第一业务文件，包括：

创建业务文件；

将所述业务请求写入到所述业务文件中；

根据写入完毕的业务文件，生成第一业务文件。

优选地，将所述业务请求写入到所述业务文件中，包括：

写入进程发送针对所述业务文件的锁定请求，以便所述写入进程在将业务请求写入到业务文件的过程中其他写入进程无法执行写入操作；

写入进程将所述业务请求中的部分业务请求写入到业务文件中；

当所述写入进程写入完毕时，发送针对写入后的业务文件的解锁请求，以便其他写入进程对业务文件继续执行写入操作；

下一个写入进程以所述写入进程的方式将所述业务请求中的剩余业务请求写入到业务文件中，直到所述业务请求全部被写入到业务文件中。

优选地，所述业务请求中包含业务类型，则根据所述业务请求生成第一业务文件，并发送给业务处理终端，包括：

选取所述业务请求中的相同业务类型的业务请求；

根据所述相同业务类型的业务请求生成第一业务文件，并发送给业务处理终端。

优选地，根据所述相同业务类型的业务请求生成第一业务文件，并发送给业务处理终端，包括：

根据所述相同业务类型的业务请求生成第一业务文件，通过为所述业务类型预先设置的接口发送给业务处理终端；则

接收业务处理终端发送的第二业务文件，包括：

通过所述接口接收业务处理终端发送的第二业务文件。

一种互联网业务的处理装置，包括：业务请求接收单元、业务文件生成单元、业务文件接收单元以及业务文件读取单元，其中，

所述业务请求接收单元，用于接收请求方发送的业务请求；

所述业务文件生成单元，根据所述业务请求生成第一业务文件，并发送给业务处理终端，在生成第一业务文件后，所述第一业务文件只能被读取；

所述业务文件接收单元，用于接收所述业务处理终端发送的第二业务文件，所述第二业务文件为所述业务处理终端读取所述第一业务文件并处理所述业务请求后根据业务处理结果生成的，所述第二业务文件在生成后只能被读取；

所述业务文件读取单元，用于读取所述第二业务文件，并将业务处理结果返回给请求方。

优选地，所述业务文件生成单元，具体用于：

创建业务文件；

将所述业务请求写入到所述业务文件中；

根据写入完毕的业务文件，生成第一业务文件。

优选地，所述业务文件生成单元，具体用于：

写入进程发送针对所述业务文件的锁定请求，以便所述写入进程在将业务请求写入到业务文件的过程中其他写入进程无法执行写入操作；

写入进程将所述业务请求中的部分业务请求写入到业务文件中；

当所述写入进程写入完毕时，发送针对写入后的业务文件的解锁请求，以便其他写入进程对业务文件继续执行写入操作；

下一个写入进程以所述写入进程的方式将所述业务请求中的剩余业务请求写入到业务文件中，直到所述业务请求全部被写入到业务文件中。

优选地，所述业务文件生成单元，具体用于：

选取所述业务请求中的相同业务类型的业务请求；

根据所述相同业务类型的业务请求生成第一业务文件，并发送给业务处理终端。

优选地，所述业务文件生成单元，具体用于：

根据所述相同业务类型的业务请求生成第一业务文件，通过为所述业务类型预先设置的接口发送给业务处理终端；

通过所述接口接收业务处理终端发送的第二业务文件。

一种互联网业务的处理方法，包括：

接收请求方发送的业务请求，并根据所述业务请求生成业务请求文件；

通过第一接口将所述业务请求文件发送给业务处理终端；

通过第二接口接收业务确认文件，所述业务确认文件为所述业务处理终端读取所述业务确认文件并处理所述业务请求后根据业务处理结果生成的；

读取所述业务确认文件，并将业务处理结果返回给请求方。

优选地，业务请求中包含业务类型，则

通过第一接口将所述业务请求文件发送给业务处理终端，包括：

通过为所述业务类型预先设置的第一接口将所述业务请求文件发送给业务处理终端；

通过第二接口接收业务确认文件，包括：

通过为所述业务类型预先设置的第二接口接收业务确认文件。

一种互联网业务的处理装置，包括：请求文件生成单元、请求文件发送单元、确认文件接收单元以及，其中，

所述请求文件生成单元，用于接收请求方发送的业务请求，并根据所述业务请求生成业务请求文件；

所述请求文件发送单元，用于通过第一接口将所述业务请求文件发送给业务处理终端；

所述确认文件接收单元，用于通过第二接口接收业务确认文件，所述业务确认文件为所述业务处理终端读取所述业务确认文件并处理所述业务请求后根据业务处理结果生成的；

所述确认文件读取单元，用于读取所述业务确认文件，并将业务处理结果返回给请求方。

优选地，所述业务请求中包含业务类型，则

所述请求文件发送单元，具体用于：

通过为所述业务类型预先设置的第一接口将所述业务请求文件发送给业务处理终端；

所述确认文件接收单元，具体用于：

通过为所述业务类型预先设置的第二接口接收业务确认文件。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：业务平台在接收到业务请求后，根据业务请求生成第一业务文件，该第一业务文件被设置为只能被读取，并将该业务文件发送给业务处理终端，业务处理终端同样根据业务处理结果生成只能被读取的第二业务文件，再交给业务平台读取，由此，就实现了对于需要进行文件交换的互联网业务中业务文件的读写分离操作，避免了两方都在一个业务文件中读写的情况，从而降低了业务文件出错的概率。同时，在接收到业务请求并生成业务请求文件后，通过第一接口专门发 送业务请求文件，并通过第二接口专门接收业务处理终端发送来的业务确认文件，将发送和接收独立分开，进一步降低了由于压力过大而收发又均通过一个接口时，带来拥堵、出错的问题的概率。也就提高了业务处理的效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例1提供的互联网业务的处理方法的流程示意图；

图2为本申请实施例2提供的互联网业务的处理装置的结构框图；

图3为本申请实施例3提供的互联网业务的处理方法的流程示意图；

图4为本申请实施例3提供的互联网业务的处理方法的示意图；

图5为本申请实施例4提供的互联网业务的处理装置的结构框图；

图6为本申请实施例5提供的一种众筹业务的处理方法的流程示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

如前所述，现有技术，业务处理终端会读取业务文件中的业务请求，并进行相应地处理，在处理完毕后，会将处理结果直接写入到该业务文件中，并返 回给相应的终端。比如，有某个业务平台，可以接收用户发送的各种业务请求，当接收到业务请求后，会根据业务请求生成与业务处理终端约定好的指定格式的业务文件1，并将业务文件1发送给业务处理终端，该业务文件中包含多个数量以及多种类型的业务请求。当业务处理终端接收到该业务文件时，读取其中的业务请求并逐个处理，当处理完毕后，将处理结果写回到业务文件1中，并将写完的业务文件1返回给该业务平台。但是，随着业务数量和种类的增多，业务处理终端基于原有的业务文件再次写入时，由于数量过多，种类多样会增加应用程序出错或硬件设备出现问题(写入失败、写入错误信息、磁盘出现坏道等)的概率，而这都可能使这个业务文件损坏或错乱，导致无法继续写入、或者将损坏或错乱的业务文件返回给相应的终端，也导致无法正常读取等情况。比如，在将每个业务请求的业务处理结果写回到业务文件1时，由于不停地在不同业务间切换导致应用程序出错，使得业务文件1损坏，造成业务平台和业务处理终端双方都无法再读取或写入，从而降低了互联网业务的处理效率。所以现有技术的业务处理过程会导致业务文件出错概率较高、互联网业务的处理效率较低。基于此缺陷，本发明人提出了一种互联网业务的处理方法，用于降低业务处理过程中业务文件出现错误的概率，提高互联网业务的处理效率。假设执行主体是业务平台的服务器，该方法的流程示意图如图1所示，包括下述步骤：

步骤11：接收请求方发送的业务请求。

业务平台在一天中会持续不断的接收请求方发送的各种业务请求，比如，注册业务、登记业务、支付业务等。请求方就可以是各个用户，可以通过无线终端、也可以通过有线终端等。在实际应用中，一个业务平台可能存在多个服务器或多个子系统同时接收各个终端发送来的业务请求，所以接收业务请求也可以是业务平台下的多个服务器同时接收业务请求。

步骤12：根据业务请求生成第一业务文件，并发送给业务处理终端。

一般地，业务处理终端与业务平台都会预先约定好一种业务文件的格式， 即业务平台按照这种格式生成业务文件，以便业务处理终端可以方便的读取。在本实施例开头已经介绍，现有技术导致互联网业务处理效率较低的原因就是对于业务处理终端在接收到包含数量和种类都很多的业务文件后，在该业务文件中继续写入，如果写入过程中出现问题，就会导致业务文件损坏或错乱，从而使该业务文件不再能被写入和读取。基于这个缺陷，本步骤在根据业务请求生成业务文件后，可以使该业务文件仅能被读取，而不能被写入。具体实现方式可以通过设置权限来实现。

需要说明的是，该业务文件仅能被读取的意思，是指除了生成该业务文件的业务平台以外的所有终端、平台只可以读取业务文件而不能写入任何信息，而生成该业务文件的业务平台是可以继续写入和读取的。比如，业务平台a根据接收到的业务请求生成了第一业务文件，当除业务平台a的其他业务平台、终端、系统等，接收到第一业务文件后，只可以读取其中的信息，而不能再写入新的信息；而业务平台a还可以继续对该第一业务文件进行写入和读取。

在生成业务文件后，就可以发送给业务处理终端，业务处理终端只能读取而不能写入，但业务处理终端在处理完成后，也需要将处理结果告之该业务平台，所以就可以单独写在另外一个业务文件中。

具体地，根据业务请求生成第一业务文件的方法可以像“填表”一样，即有一个空的业务文件，其中包含若干业务属性，业务平台可以将业务请求中的信息对应地写入到空的业务文件中，写入完毕后就可以生成第一业务文件。

除了“填表”的方法，还可以是“从无到有”的生成方法：创建业务文件；将业务请求写入到业务文件中；根据写入完毕的业务文件，生成第一业务文件。

当接收到业务请求后，业务平台先创建一个业务文件，该业务文件就可以是空白的，将业务请求按照指定的格式写入到业务文件中，当写入完毕后，就可以生成第一业务文件。

在步骤11中已经介绍，由于业务平台也不止一个服务器，负责接收来自 各终端的业务请求，而业务文件在发送给业务处理终端时，也会按照一定的时间间隔，比如5分钟一次、10分钟一次等，当各个服务器接收到业务请求后，都会调用写入进程将接收到的业务请求写入到业务文件中。现有技术在写入时，多个进程可以同时将业务请求写入到业务文件中，就像“一张纸可以由多人同时写业务请求”，这就有可能会出现写入错乱的情况，比如，覆盖，误删等情况。即使有多个写入进程排队写入，第一个写入进程出现假死且没有被结束任务，第二个写入进程启动后，第一个写入进程又恢复了，这时又出现了同时写入的问题，也就有可能出现写入错乱等问题。

为了在将业务请求写入到业务文件的过程中，保证业务文件的质量，在一种实施方式中，将业务请求写入到所述业务文件中，可以包括：一个写入进程发送针对业务文件的锁定请求，以便这个写入进程在将业务请求写入到业务文件的过程中其他写入进程无法执行写入操作；这个写入进程将业务请求中的部分业务请求写入到业务文件中；当这个写入进程写入完毕时，发送针对写入后的业务文件的解锁请求，以便其他写入进程对业务文件继续执行写入操作；如果有下一个写入进程，再以上一个写入进程的方式将业务请求中的剩余业务请求写入到业务文件中，直到业务请求全部被写入到业务文件中。需要说明的是这个所说的“以上一个写入进程的方式将业务请求中的剩余业务请求写入到业务文件中”，不是指写入这件事本身，而是指先锁定、再写入、最后解锁的方式。

具体地，步骤11中已经介绍，业务请求是由多个服务器(多个子系统)同时接收到，在该步骤中已经介绍，会间隔一定时间生成一次业务文件，所以，当各个服务器接收到业务请求后，都会调用写入进程将业务请求写到业务文件中，比如，业务文件在一个总服务器上，每个子服务器接收业务请求，并调用写入进程访问总服务器上的业务文件并写入业务请求。为了防止写入错乱的情况，第一个写入进程先向总服务器发送针对业务文件的锁定请求，以便第一个写入进程在将业务请求写入到业务文件过程中，没有其他写入进程干扰，写入 完毕后，再向总服务器发送针对业务文件的解锁请求，以便第二个写入进程可以再次向总服务器发送针对该业务文件的锁定请求，直到业务请求全部被写入到业务文件中。如果再第一个写入进程没有解锁的情况下，就认为第一个写入进程没有写完，当有别的写入进程需要访问正在进行写入操作的业务文件时，就会被拒绝。也就是，当写入进行发送了针对业务文件的锁定请求后，“锁定服务”会标识“宿主”身份，如果第二个写入进行需要访问该业务文件时由于“宿主”身份不同，就会被拒绝，特殊情况下，如果正在执行写入操作的第一写入进程出现异常(假死、无响应等)，此时，可以发出告警，以便通知管理员检查问题，或者可以虚拟一个第一写入进程，访问该业务文件，完成写入操作。

由于业务请求是每个服务器接收到，所以每个服务器的写入进程写业务文件时，就可以认为是将业务请求中的部分内容写入，直到全部写入完毕。需要说明的是，由于每个业务文件也都是有时间间隔的，所以预先设定一个业务文件可以让固定个数的进程写入。

可以理解为，业务文件放在一个屋子中，一个时间间隔内可以有10个人在门外排队，将接收到业务请求写到业务文件中，第一个人进去后，将门上锁，写完后将门开锁再出来，再下一个人进去，直到写完为止，或者到时间为止，换下一个业务文件，逐个进去写。

如开头所述，业务处理终端基于原有的业务文件再次写入时，由于数量过多，种类多样会增加应用程序出错或硬件设备出现问题的概率，而这都可能使这个业务文件损坏或错乱，所以，为了在一定程度上避免，可以将不同的业务进行分离。在一种实施方式中，当业务请求中包含业务类型时，根据业务请求生成第一业务文件，并发送给业务处理终端，可以包括：选取业务请求中的相同业务类型的业务请求；根据相同业务类型的业务请求生成第一业务文件，并发送给业务处理终端。

具体地，就是为了防止在处理业务时，总是在切换处理不同业务导致的出现问题，本申请将业务文件进行分类，即一种业务文件中只包含一种类型的业 务请求，在写入业务文件时，选取业务请求中相同业务类型的业务请求，比如，选择全都是注册业务的业务请求，将这些相同类型的业务请求写入到业务文件中，生成第一业务文件，并发送给业务处理终端。

通过上述业务平台的先锁定后解锁的写入方法，不同业务类型之间相互独立生成业务文件的方法，以及业务平台与业务处理终端之间读写分离的方法，也就降低了业务文件出问题的概率。

在现有技术一般情况下，业务平台与业务处理终端之间在通过通信接口进行交换文件时往往不区分业务类型，比如，注册业务文件与交易业务文件都通过一个接口进行交换，一旦这个接口出现问题，那么所有利用该接口进行文件交换的业务都无法使用。所以，为了达到通信接口专属化的目的，在一种实施方式中，根据相同业务类型的业务请求生成第一业务文件，并发送给业务处理终端，可以包括：根据相同业务类型的业务请求生成第一业务文件，通过为该业务类型预先设置的接口发送给业务处理终端。具体地，一个业务文件中仅包含一种业务类型，也就可以根据业务类型，将业务文件通过预先设置的专属接口发送。比如，注册类型业务请求的业务文件与交易类型业务请求的业务文件，通过不同的通信接口进行发送。利用专属接口的好处还可以自由配置各种类型业务的文件交换要求，比如，每隔一段时间开放接口，每次发送/接收多少个业务文件等，而所有业务类型的业务文件混在一起用则不好根据业务类型配置接口。

步骤13：接收业务处理终端发送的第二业务文件。

在步骤12中已经介绍，根据业务请求生成业务文件后，可以使该业务文件仅能被读取，而不能被写入，所以相应地，业务处理终端在接收到第一业务文件并读取后，可以将业务处理结果写在另外一个业务文件中，也即第二业务文件，该第二业务文件即为业务处理终端读取第一业务文件并处理业务请求后根据业务处理结果生成的，该第二业务文件在生成后只能被读取。也就是业务平台根据业务请求生成的第一业务文件，在业务处理终端中只能读取不能写入， 业务处理终端根据业务处理结果生成的第二业务文件在业务平台中也只能读取不能写入。这样就做到了两方读取分离，互相不干扰。

需要说明的是，在前文已经解释了业务文件仅能被读取的意思，所以在这里，第二业务文件在生成后只能被读取的意思也是只能被除业务处理终端之外的其他平台、终端、系统读取，而本业务处理终端还可以继续写入和读取。

步骤14：读取第二业务文件，并将业务处理结果返回给请求方。

在第二业务文件中，含有业务处理终端写入的业务处理结果，并且第二业务文件只能被读取，所以可以读取，并将业务处理结果返回给请求方。

采用实施例1提供的该方法，业务平台在接收到业务请求后，根据业务请求生成第一业务文件，该第一业务文件被设置为只能被读取，并将该业务文件发送给业务处理终端，业务处理终端同样根据业务处理结果生成只能被读取的第二业务文件，再交给业务平台读取，由此，就实现了对于需要进行文件交换的互联网业务中业务文件的读写分离操作，避免了两方都在一个业务文件中读写的情况，从而降低了业务文件出错的概率，也就提高了业务处理的效率。此外，在根据业务请求生成第一业务文件时，采用每个进程先锁定，再写入，最后解锁的方法，避免出现同时写入造成业务文件出错的情况，也就降低了业务文件出错的概率。另外，还按照业务类型区分不同的业务文件，并利用专属的通信接口进行文件传输，相比于现有的业务文件中有不同类型且共用接口的情况进一步降低了业务文件出错的概率。

实施例2

基于相同的发明构思，实施例2提供了一种互联网业务的处理装置，用于降低业务处理过程中业务文件出现错误的概率，提高互联网业务的处理效率。图2为该装置的结构框图，该装置包括：业务请求接收单元21、业务文件生成单元22、业务文件接收单元23以及业务文件读取单元24，其中，

业务请求接收单元21，可以用于接收请求方发送的业务请求；

业务文件生成单元22，可以根据业务请求生成第一业务文件，并发送给业务处理终端，在生成第一业务文件后，第一业务文件只能被读取；

业务文件接收单元23，可以用于接收业务处理终端发送的第二业务文件，第二业务文件为业务处理终端读取第一业务文件并处理业务请求后根据业务处理结果生成的，第二业务文件在生成后只能被读取；

业务文件读取单元24，可以用于读取第二业务文件，并将业务处理结果返回给请求方。

在一种实施方式中，业务文件生成单元22，可以用于：

创建业务文件；

将业务请求写入到业务文件中；

根据写入完毕的业务文件，生成第一业务文件。

在一种实施方式中，业务文件生成单元22，可以用于：

写入进程发送针对业务文件的锁定请求，以便写入进程在将业务请求写入到业务文件的过程中其他写入进程无法执行写入操作；

写入进程将业务请求中的部分业务请求写入到业务文件中；

当写入进程写入完毕时，发送针对写入后的业务文件的解锁请求，以便其他写入进程对业务文件继续执行写入操作；

下一个写入进程以写入进程的方式将业务请求中的剩余业务请求写入到业务文件中，直到业务请求全部被写入到业务文件中。

在一种实施方式中，业务文件生成单元22，可以用于：

选取业务请求中的相同业务类型的业务请求；

根据相同业务类型的业务请求生成第一业务文件，并发送给业务处理终端。

在一种实施方式中，业务文件生成单元22，可以用于：

根据相同业务类型的业务请求生成第一业务文件，通过为业务类型预先设置的接口发送给业务处理终端；

通过接口接收业务处理终端发送的第二业务文件。

采用实施例2提供的该装置，业务平台在接收到业务请求后，根据业务请求生成第一业务文件，该第一业务文件被设置为只能被读取，并将该业务文件发送给业务处理终端，业务处理终端同样根据业务处理结果生成只能被读取的第二业务文件，再交给业务平台读取，由此，就实现了对于需要进行文件交换的互联网业务中业务文件的读写分离操作，避免了两方都在一个业务文件中读写的情况，从而降低了业务文件出错的概率，也就提高了业务处理的效率。此外，在根据业务请求生成第一业务文件时，采用每个进程先锁定，再写入，最后解锁的方法，避免出现同时写入造成业务文件出错的情况，也就降低了业务文件出错的概率。另外，还按照业务类型区分不同的业务文件，并利用专属的通信接口进行文件传输，相比于现有的业务文件中有不同类型且共用接口的情况进一步降低了业务文件出错的概率。

实施例3

在现有技术中，业务文件的收发均通过一个接口完成，如果业务很多就会压力过大，从而出现拥堵、出错等问题，进一步使得业务处理的效率较低。比如，就如实施例1中介绍的第一业务文件和第二业务文件，分别是根据业务请求以及业务处理结果生成的，这两类文件在传输过程中，均通过一个接口完成，如果文件过多，就会导致接口的单向或双向压力过大，从而出现拥堵、出错的问题。基于此缺陷，本发明人又提出了一种互联网业务的处理方法，用于降低业务处理过程中业务文件出现错误的概率，提高互联网业务的处理效率。假设执行主体依旧是业务平台的服务器，该方法的流程示意图如图3所示，包括下述步骤：

步骤31：接收请求方发送的业务请求，并根据该业务请求生成业务请求文件。

当业务平台接收到请求方发送的业务请求后，就可以根据这个业务请求生成业务请求文件，与实施例1中的步骤11类似，不再赘述。

步骤32：通过第一接口将该业务请求文件发送给业务处理终端。

该步骤中，可以为专为业务请求文件单独设置一个接口，专门用于发送业务请求文件，不是业务请求文件，也就不会从这个接口中传输。

由于在实际应用中，会有很多业务类型，这一点在实施例1的步骤12中已经介绍现有技术一般情况下，业务平台与业务处理终端之间在通过通信接口进行交换文件时往往不区分业务类型的，并且实施例1已经为不同业务类型专门设置了不同接口，在本步骤中，还可以进一步细化，即通过为业务类型预先设置的第一接口将业务请求文件发送给业务处理终端。也就是针对不同业务类型的业务请求文件，再设置一个独立的接口，专门用于传输业务请求文件。

步骤33：通过第二接口接收业务确认文件。

在步骤32中已经介绍了为业务请求文件单独设置一个接口，类似地，也可以为业务确认文件单独设置一个接口，专门用于传输业务确认文件。在上一步骤已经介绍了为不同业务类型进一步细化，所以在本步骤中，也可以通过为业务类型预先设置的第二接口接收业务确认文件。这里所说的业务确认文件，与实施例1中类似，就可以是业务处理终端读取业务确认文件并处理业务请求后根据业务处理结果生成的。

由此看出，在发送业务请求文件和接收业务确认文件的过程中，是分别走两个接口的，对于不同业务类型，还可以进行细化，保证每种业务类型都有发送和接收两个接口，可以参照图4所示的互联网业务的处理方法的示意图，即为每个业务都设置两个接口，分别用户发送接收。由于服务器往往不止一个，所以可以有一个服务器，通过调度分服务器，来完成业务处理；也可以由多个服务器协作完成，比如不同服务器对应不同接口，分别处理不同业务等。

步骤34：读取业务确认文件，并将业务处理结果返回给请求方。

本步骤也可以参照实施例1中的步骤14，此处不再赘述。

采用实施例3提供的该方法，业务平台在接收到业务请求并生成业务请求文件后，通过第一接口专门发送业务请求文件，并通过第二接口专门接收业务 处理终端发送来的业务确认文件，将发送和接收独立分开，有效降低了由于压力过大而收发又均通过一个接口时，带来的拥堵、出错的问题的概率。

实施例4

基于相同的发明构思，实施例4提供了一种互联网业务的处理装置，用于降低业务处理过程中业务文件出现错误的概率，提高互联网业务的处理效率。图5为该装置的结构框图，该装置包括：请求文件生成单元41、请求文件发送单元42、确认文件接收单元43以及确认文件读取单元44，其中，

请求文件生成单元41，可以用于接收请求方发送的业务请求，并根据所述业务请求生成业务请求文件；

请求文件发送单元42，可以用于通过第一接口将所述业务请求文件发送给业务处理终端；

确认文件接收单元43，可以用于通过第二接口接收业务确认文件，所述业务确认文件为所述业务处理终端读取所述业务确认文件并处理所述业务请求后根据业务处理结果生成的；

确认文件读取单元44，可以用于读取所述业务确认文件，并将业务处理结果返回给请求方。

在一种实施方式中，可以业务请求中可以包含业务类型，则

请求文件发送单元42，可以用于：

通过为所述业务类型预先设置的第一接口将所述业务请求文件发送给业务处理终端；

确认文件接收单元43，可以用于：

通过为所述业务类型预先设置的第二接口接收业务确认文件。

采用实施例4提供的该装置，业务平台在接收到业务请求并生成业务请求文件后，通过第一接口专门发送业务请求文件，并通过第二接口专门接收业务处理终端发送来的业务确认文件，将发送和接收独立分开，有效降低了由于压 力过大而收发又均通过一个接口时，带来的拥堵、出错的问题的概率。

实施例5

随着互联网金融业的发展，众筹，是指一种向群众募资，以支持发起的个人或组织的行为。众筹业务比私募业务涉众更广，证监会也将其定性为强监管业务，并要求所有投资人/融资人的开户，交易登记必须通过中国证券登记结算(简称“中登”)的服务器来完成，现有技术中，众筹平台(服务器)与中登(服务器)之间在交换业务文件，是基于一个业务文件双方都可以读写，也就是众筹平台根据接收到的用户发送的业务请求生成业务文件，并将该业务文件发送给中登，中登读取该业务文件中的业务请求，并将业务处理结果写入到该业务文件中，再返回给众筹平台，并且，所有业务文件的收发过程也均是通过一个接口的。但是，随着众筹的发展，各种各样的产品以众筹的形式进行融资，投资人也越来越多，由于众筹业务本身就包含开户业务、证券信息登记、证券初始登记、证券增发登记、证券质押登记、证券解质押登记、证券持有人名册查询等，中登基于原有的业务文件再次写入时，由于数量过多，种类多样会增加应用程序出错或硬件设备出现问题(写入失败、写入错误信息、磁盘出现坏道等)的概率，而这都可能使这个业务文件损坏或错乱，导致无法继续写入、或者将损坏或错乱的业务文件返回给相应的终端，也导致无法正常读取等情况，并且所有业务文件的收发均通过一个接口完成，如果业务很多就会压力过大，从而出现拥堵、出错等问题，进一步使得业务处理的效率较低。基于此缺陷，本发明人提出了一种众筹业务的处理方法，用于降低处理众筹业务过程中业务文件出现错误的概率，提高众筹业务的处理效率。假设执行主体是众筹平台的服务器，该方法的流程示意图如图6所示，包括下述步骤：

步骤51：众筹平台接收用户发送的业务请求。

业务平台在一天中会持续不断的接收用户发送的开户业务、证券信息登记等各种业务请求。

步骤52：众筹平台根据业务请求生成第一业务文件，并通过第一接口发送给业务处理终端。

此时，业务处理终端可以就是中登(服务器)，众筹平台根据业务请求生成的第一业务文件，只能被除众筹平台以外的、如中登读取而不能写入。

在实施例1中已经介绍了两种生成业务文件的方法，在该步骤中，也可以按照这两种方法生成业务文件，其中，对于第二种方法，也可以采用多个写入进程先锁定，再写入，最后解锁的写入方式，业务文件可以在众筹平台中一个公共的服务器中，每个子服务器接收到业务请求后，调用写入进程，排队将业务请求写入到第一业务文件中，在一定程序上，保证了众筹平台生成的第一业务文件的质量。

在前文已经介绍，众筹平台内有多种类型的业务，开户业务、证券信息登记、证券初始登记、证券增发登记、证券质押登记、证券解质押登记、证券持有人名册查询等，该步骤中，也可以按照实施例1中的方式，按照不同的业务类型，将业务文件进行分类，每个业务文件中只包含一种类型的业务请求。

在将业务文件分类后，还可以按照实施例1以及实施例3中介绍的，为每种业务类型的业务文件设定专属接口，并且为每个业务类型对于收发业务文件分别设定专属的收和发的接口，用于与中登进行文件交换。比如开户登记第一接口，用于众筹平台向中登发送开户登记的业务请求文件，开户登记第二接口，用于众筹平台接收中登发送的开户登记的业务确认文件。

步骤53：众筹平台通过第二接口接收业务处理终端发送的第二业务文件。

在步骤52中，众筹平台根据业务请求生成的第一业务文件只能被中登读取，那么也可以与中登约定好，中登在处理完业务请求后，根据处理结果生成新的业务文件，即第二业务文件，该业务文件也只允许除中登以外的、如众筹平台读取，如果再针对第二业务文件的问题(比如，失败、缺少必要信息等)，再重新编辑第一业务文件，或者重新生成第三业务文件，发送给中登。这样就做到了众筹平台与中登在业务文件交换的过程中，读写是分开的，一个文件只 能一方写入/读取。

在步骤52中，已经介绍了，为每个业务类型对于收发业务文件分别设定专属的收和发的接口，所以本步骤，也可以设定第二接口，专门用于接收中登发送的第二业务文件(即业务确认文件)。

步骤54：众筹平台读取第二业务文件，并将业务处理结果返回给相应的用户。

在第二业务文件中，含有中登端写入的业务处理结果，并且第二业务文件只能被读取，所以众筹平台可以读取，并将业务处理结果返回给相应的用户。

在传统的金融业务处理过程中，较为常见的一天一次文件交换，或定时一次(1小时一次等)，在此基础上，可以和中登进行约定，缩短定时的间隔，延长业务处理的时段，尽量做到24小时不间断收发处理，也就可以做到不间断实时处理众筹业务。

采用实施例5提供的该方法，众筹平台在接收到业务请求后，根据业务请求生成第一业务文件，并将该业务文件发送给中国证券登记结算(服务器)，该第一业务文件被设置为只能被中登读取，中登同样根据业务处理结果生成只能被读取的第二业务文件，再交给众筹平台读取，由此，就实现了对于需要进行文件交换的众筹业务中业务文件的读写分离操作，避免了两方都在一个业务文件中读写的情况，从而降低了业务文件出错的概率，也就提高了业务处理的效率。此外，在根据业务请求生成第一业务文件时，采用每个进程先锁定，再写入，最后解锁的方法，避免出现同时写入造成业务文件出错的情况，也就降低了业务文件出错的概率。另外，还可以按照业务类型区分不同的业务文件，并利用专属的分别用于收发的接口进行文件传输，相比于现有的业务文件中有不同类型且共用接口的情况进一步降低了业务文件出错的概率。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结 合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。