互聯網業務的處理方法及裝置與流程

本申請涉及互聯網技術領域，尤其涉及一種互聯網業務的處理方法及裝置。

背景技術：

隨著互聯網的發展，互聯網業務越來越普遍，為了均衡互聯網業務的處理壓力，也為細節行業內不同的分工，一般會有不同的終端專門進行不同的操作，比如有專門的終端接收互聯網業務(簡稱“業務”)請求，并根據業務請求生成業務文件，發送給專門用于處理業務的終端。

現有技術，當接收業務請求的終端將業務文件發送給用于處理業務的終端(簡稱“業務處理終端”)后，業務處理終端會讀取其中的業務請求，并進行相應地處理，在處理完畢后，會將處理結果直接寫入到該業務文件中，并返回給相應的終端，而且業務文件的收發均通過一個接口完成。然而，隨著業務數量的增大，業務種類的增多，業務文件中包含的信息也在不斷增多，業務處理終端在基于接收到的業務文件繼續寫入處理結果時，如果在繼續寫入時由于應用程序出錯或硬件設備出現問題(寫入失敗、寫入錯誤信息、磁盤出現壞道等)都可能使這個業務文件損壞或錯亂，導致無法繼續寫入、或者即使寫入完畢返回給相應的終端也可能導致無法正常讀取等，進而使得業務處理的效率較低，而且業務文件的收發均通過一個接口完成，如果業務很多就會壓力過大，從而出現擁堵、出錯等問題，進一步使得業務處理的效率較低。所以如何在基于業務文件進行業務處理的場景下降低業務文件出錯的概率，來提高業務處理效率成為了需要解決的問題。更何況隨著計算機處理能力的提高以及應用程序的優化，互聯網業務效率要求越來越高的情況下，降低業務文件出錯的概率，來提高業務處理效率更是亟需解決的問題。

技術實現要素：

本申請實施例提供一種互聯網業務的處理方法，用于降低業務處理過程中業務文件出現錯誤的概率，提高互聯網業務的處理效率。

本申請實施例提供一種互聯網業務的處理裝置，用于降低業務處理過程中業務文件出現錯誤的概率，提高互聯網業務的處理效率。

本申請實施例采用下述技術方案：

一種互聯網業務的處理方法，包括：

接收請求方發送的業務請求；

根據所述業務請求生成第一業務文件，并發送給業務處理終端，在生成第一業務文件后，所述第一業務文件只能被讀取；

接收所述業務處理終端發送的第二業務文件，所述第二業務文件為所述業務處理終端讀取所述第一業務文件并處理所述業務請求后根據業務處理結果生成的，所述第二業務文件在生成后只能被讀取；

讀取所述第二業務文件，并將業務處理結果返回給請求方。

優選地，根據所述業務請求生成第一業務文件，包括：

創建業務文件；

將所述業務請求寫入到所述業務文件中；

根據寫入完畢的業務文件，生成第一業務文件。

優選地，將所述業務請求寫入到所述業務文件中，包括：

寫入進程發送針對所述業務文件的鎖定請求，以便所述寫入進程在將業務請求寫入到業務文件的過程中其他寫入進程無法執行寫入操作；

寫入進程將所述業務請求中的部分業務請求寫入到業務文件中；

當所述寫入進程寫入完畢時，發送針對寫入后的業務文件的解鎖請求，以便其他寫入進程對業務文件繼續執行寫入操作；

下一個寫入進程以所述寫入進程的方式將所述業務請求中的剩余業務請求寫入到業務文件中，直到所述業務請求全部被寫入到業務文件中。

優選地，所述業務請求中包含業務類型，則根據所述業務請求生成第一業務文件，并發送給業務處理終端，包括：

選取所述業務請求中的相同業務類型的業務請求；

根據所述相同業務類型的業務請求生成第一業務文件，并發送給業務處理終端。

優選地，根據所述相同業務類型的業務請求生成第一業務文件，并發送給業務處理終端，包括：

根據所述相同業務類型的業務請求生成第一業務文件，通過為所述業務類型預先設置的接口發送給業務處理終端；則

接收業務處理終端發送的第二業務文件，包括：

通過所述接口接收業務處理終端發送的第二業務文件。

一種互聯網業務的處理裝置，包括：業務請求接收單元、業務文件生成單元、業務文件接收單元以及業務文件讀取單元，其中，

所述業務請求接收單元，用于接收請求方發送的業務請求；

所述業務文件生成單元，根據所述業務請求生成第一業務文件，并發送給業務處理終端，在生成第一業務文件后，所述第一業務文件只能被讀取；

所述業務文件接收單元，用于接收所述業務處理終端發送的第二業務文件，所述第二業務文件為所述業務處理終端讀取所述第一業務文件并處理所述業務請求后根據業務處理結果生成的，所述第二業務文件在生成后只能被讀取；

所述業務文件讀取單元，用于讀取所述第二業務文件，并將業務處理結果返回給請求方。

優選地，所述業務文件生成單元，具體用于：

創建業務文件；

將所述業務請求寫入到所述業務文件中；

根據寫入完畢的業務文件，生成第一業務文件。

優選地，所述業務文件生成單元，具體用于：

寫入進程發送針對所述業務文件的鎖定請求，以便所述寫入進程在將業務請求寫入到業務文件的過程中其他寫入進程無法執行寫入操作；

寫入進程將所述業務請求中的部分業務請求寫入到業務文件中；

當所述寫入進程寫入完畢時，發送針對寫入后的業務文件的解鎖請求，以便其他寫入進程對業務文件繼續執行寫入操作；

下一個寫入進程以所述寫入進程的方式將所述業務請求中的剩余業務請求寫入到業務文件中，直到所述業務請求全部被寫入到業務文件中。

優選地，所述業務文件生成單元，具體用于：

選取所述業務請求中的相同業務類型的業務請求；

根據所述相同業務類型的業務請求生成第一業務文件，并發送給業務處理終端。

優選地，所述業務文件生成單元，具體用于：

根據所述相同業務類型的業務請求生成第一業務文件，通過為所述業務類型預先設置的接口發送給業務處理終端；

通過所述接口接收業務處理終端發送的第二業務文件。

一種互聯網業務的處理方法，包括：

接收請求方發送的業務請求，并根據所述業務請求生成業務請求文件；

通過第一接口將所述業務請求文件發送給業務處理終端；

通過第二接口接收業務確認文件，所述業務確認文件為所述業務處理終端讀取所述業務確認文件并處理所述業務請求后根據業務處理結果生成的；

讀取所述業務確認文件，并將業務處理結果返回給請求方。

優選地，業務請求中包含業務類型，則

通過第一接口將所述業務請求文件發送給業務處理終端，包括：

通過為所述業務類型預先設置的第一接口將所述業務請求文件發送給業務處理終端；

通過第二接口接收業務確認文件，包括：

通過為所述業務類型預先設置的第二接口接收業務確認文件。

一種互聯網業務的處理裝置，包括：請求文件生成單元、請求文件發送單元、確認文件接收單元以及，其中，

所述請求文件生成單元，用于接收請求方發送的業務請求，并根據所述業務請求生成業務請求文件；

所述請求文件發送單元，用于通過第一接口將所述業務請求文件發送給業務處理終端；

所述確認文件接收單元，用于通過第二接口接收業務確認文件，所述業務確認文件為所述業務處理終端讀取所述業務確認文件并處理所述業務請求后根據業務處理結果生成的；

所述確認文件讀取單元，用于讀取所述業務確認文件，并將業務處理結果返回給請求方。

優選地，所述業務請求中包含業務類型，則

所述請求文件發送單元，具體用于：

通過為所述業務類型預先設置的第一接口將所述業務請求文件發送給業務處理終端；

所述確認文件接收單元，具體用于：

通過為所述業務類型預先設置的第二接口接收業務確認文件。

本申請實施例采用的上述至少一個技術方案能夠達到以下有益效果：業務平臺在接收到業務請求后，根據業務請求生成第一業務文件，該第一業務文件被設置為只能被讀取，并將該業務文件發送給業務處理終端，業務處理終端同樣根據業務處理結果生成只能被讀取的第二業務文件，再交給業務平臺讀取，由此，就實現了對于需要進行文件交換的互聯網業務中業務文件的讀寫分離操作，避免了兩方都在一個業務文件中讀寫的情況，從而降低了業務文件出錯的概率。同時，在接收到業務請求并生成業務請求文件后，通過第一接口專門發 送業務請求文件，并通過第二接口專門接收業務處理終端發送來的業務確認文件，將發送和接收獨立分開，進一步降低了由于壓力過大而收發又均通過一個接口時，帶來擁堵、出錯的問題的概率。也就提高了業務處理的效率。

附圖說明

此處所說明的附圖用來提供對本申請的進一步理解，構成本申請的一部分，本申請的示意性實施例及其說明用于解釋本申請，并不構成對本申請的不當限定。在附圖中：

圖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、光學存儲器等)上實施的計算機程序產品的形式。

以上僅為本申請的實施例而已，并不用于限制本申請。對于本領域技術人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本申請的權利要求范圍之內。