為使本說明書的目的、技術方案和優點更加清楚，下面將結合本說明書具體實施例及相應的附圖對本申請案技術方案進行清楚、完整地描述。顯然，所描述的實施例僅是本申請案一部分實施例，而不是全部的實施例。基於說明書中的實施例，本領域普通技術人員在沒有做出進步性勞動前提下所獲得的所有其他實施例，都屬於本申請案保護的範圍。 以下結合附圖，詳細說明本申請案各實施例提供的技術方案。 圖2為說明書實施例提供的一種任務執行的過程，具體可包括以下步驟： S100：接收任務請求。 在本說明書一個或多個實施例中，可由服務提供方的設備接收任務請求，並根據該任務請求執行對應的任務。其中，該服務提供的設備可以是終端或者伺服器，例如，手機、個人電腦、伺服器等等，本說明書對此不做限定。為了方便描述，後續以伺服器為該任務執行過程的執行主體為例進行說明。 另外，該任務請求中可攜帶有執行任務所需的資料，以便該伺服器後續執行任務。該伺服器可以是單獨的一台設備或者是由多台設備組成的系統，如分散式伺服器。 進一步地，在本說明書實施例中，該任務請求可為確定若干資料中的極值資料的請求。具體的，其中若干資料可為執行任務請求對應的任務所需的資料，則該極值資料可為上述所需的資料中的最大值或者最小值。 需要說明的是，在本說明書中，該極值資料可以直接是執行任務所需的資料本身（如，從若干資料中選擇對應的數值最大或者最小的資料），或者也可以通過執行任務所需的資料確定出的結果。 例如，任務請求為確定用戶A至D中借貸風險最大的用戶，則執行任務所需的資料可以包括使用者A~D的身份資訊、交易記錄等等資料，當進一步根據執行任務所需的資料，確定出的使用者A~D分別對應的借貸風險結果時，再從各借貸風險結果中確定最大值。則此時極值資料不是輸入的資料本身，而是根據輸入的資料計算得到的結果。 S102：根據所述任務請求生成有向非循環圖DAG的葉子節點，以及確定所述DAG圖節點總數。 在本說明書中，該伺服器可根據該任務請求，先生成任務對應的DAG圖中的各葉子節點，以通過DAG圖的各葉子節點將該任務請求對應任務拆分為若干簡單的子任務，來執行該任務請求對應的任務。另外，由於該伺服器已經確定出該DAG圖的葉子節點，所以該伺服器還可根據該任務請求進一步確定該DAG圖的節點總數，以便後續通過執行任務生成下游節點時，可以確定何時該任務執行完畢（如，當生成了該DAG圖的全部節點）。 具體的，伺服器可先根據該任務請求，確定執行任務請求對應的任務需要輸入的資料，再根據確定出的資料生成所述DAG圖中的各葉子節點。或者，當該任務請求中已經攜帶了執行任務所需的資料時，伺服器也可直接根據任務請求攜帶的資料，生成DAG圖中的各葉子節點。當然，上述兩種生成葉子節點的方法可以單獨或者組合使用，本說明書不做限定。 例如，伺服器接收到任務請求為，確定用戶A在銀行a~d中哪家銀行的存款最多。而銀行a~d都有可能是使用者A存款最多的銀行，因此，伺服器可以確定執行任務需要輸入的資料為使用者A在銀行a~d中的存款。 首先，伺服器可以通過分別向銀行a~d發送查詢請求的方式，確定使用者A分別在銀行a~d中的存款，作為執行任務請求對應的任務需要輸入的資料。或者，假設該任務請求是由銀行a發送的，該任務請求中攜帶有用戶A在銀行a中的存款數值，於是伺服器可通過向銀行b~d發送查詢請求，以確定執行任務請求對應的任務需要輸入的資料。 然後，伺服器可根據使用者A在各銀行a~d的存款分別生成DAG圖的葉子節點，生成DAG圖的葉子節點。 假設，使用者A在銀行a~d中的存款如表1所示。
表1 則該伺服器可建立如圖3所示的DAG圖葉子節點。在圖3中可見，各葉子節點標識有節點標識1~4，其中，各葉子節點分別對應一個銀行的標識。並且，針對每個葉子節點，伺服器可將該用戶A在與該葉子節點對應的銀行中的存款數值作為該葉子節點對應的數值。於是，可見圖3中各葉子節點分別對應有銀行的標識以及使用者A在該銀行中的存款數值。 當然，上述例子僅為本說明書實施例提供的一種示例，本說明書並不限定該伺服器如何生成各葉子節點，以及如何確定各葉子節點對應的數值。例如，當該任務請求為，確定用戶A在各銀行中最多的單筆存款時，則生成的各葉子節點可僅對應與用戶A在各銀行中的各單筆存款的數值。又或者，當該任務請求為確定用戶瀏覽次數最多的網頁時，可以根據該使用者已經瀏覽過的各網頁分別生成葉子節點，而將該用戶瀏覽各網頁的次數作分別作為各葉子節點對應的數值，等等。 進一步地，在本說明書一個或多個實施例中，該伺服器在確定出該DAG圖的葉子節點之後，還可確定該DAG圖的節點總數，即，確定該DAG圖中應該存在多少個節點。以便後續可基於該DAG圖的節點總數，判斷任務請求對應的任務是否執行完畢。 具體的，由於DAG圖可用於將複雜的任務拆分為簡單的多個子任務，而採用何種方式確定子任務，即，如何組裝節點對應的任務可以根據需要進行設置。所以在本說明書中，該伺服器中可預先儲存有任務組裝條件。則伺服器可根據已經生成的各葉子節點的數量，以及預存的任務組裝條件，確定該DAG圖節點的總數量。 在本說明書中，當該任務請求具體為從若干資料中確定極值資料的任務時，該任務組裝條件具體可為：選擇預設數量的未執行過對應任務的節點，該預設數量可根據需要設置，例如，2個、3個等等。 繼續沿用上例，假設對於判斷數值大小的任務請求，該伺服器預先配置有任務組裝條件為：選擇未執行過任務的兩個節點，即預設數量為2。伺服器根據該任務組裝條件，可選擇兩個節點對應的數值，進行兩兩比較，將比較結果作為執行結果。因此該DAG圖的節點總數可以根據公式：確定。其中，m為節點總數，n為葉子節點數量。於是，該伺服器可確定對於4個葉子節點來說，根據該任務組裝條件可確定DAG圖節點總數為7，如圖4a所示。或者，假設該伺服器生成了7個葉子節點，則根據相同的任務組裝條件，可確定該DAG圖的節點總數為13，如圖4b所示。 圖4a以及圖4b為本說明書實施提供的確定DAG圖節點總數的示意圖，其中，葉子節點為已生成的節點，以實線表示，而DAG圖中其餘的節點尚未生成，以虛線表示，圖中的虛線箭頭表示DAG圖的走向，即節點的上下游關係。 當然，需要說明的是，上述圖4a至4b所示的虛線為示意，由於此時尚未組裝任務，所以箭頭均為虛線表示一種可能的任務組裝情況，並不表示該DAG圖後續一定會以該虛線表示的節點形式生成，該虛線僅為最終該任務對應的DAG圖在最終確定時的一種可能的形式。 S104：將所述葉子節點作為待執行節點，以及確定所述待執行節點對應的任務並執行，得到執行結果。 在本說明書中，如在步驟S102中所述的伺服器可以根據預設的任務組裝條件，組裝並執行任務。於是，伺服器可先將各葉子節點作為待執行節點，再確定待執行接待節點對應任務。最後將滿足任務組裝條件的節點對應的任務組裝，並通過執行組裝後的任務得到執行結果。 例如，以確定用戶A在銀行a~d中哪家銀行的存款最多為例，假設DAG圖中的節點1和2對應的任務為對比資料大小，則在將節點1和2對應的任務組裝執行後，則可確定銀行b中的存款更多，則可確定執行結果為銀行b，其對應的數值為200元。而節點3和4對應的任務若被組裝並執行後，可確定執行結果為銀行c，其對應的數值為5000元。 另外，由於在現有技術中為了方便使用電腦語言根據DAG圖執行任務，通常將DAG圖轉換為鏈表形式，並依據該鏈表確定需要執行的子任務。並且，由於鏈表的資料結構中沒有資料索引，所以在每次確定下一步需要執行什麼時（如，確定後續執行哪個節點對應的任務），伺服器通常需要遍歷該鏈表，以確定需要執行哪個節點對應的任務。 但是，由於本說明書中DAG圖並不能預先確定，所以也就沒有對應的鏈表用於以輔助執行。 因此，在本說明書實施例中，伺服器在確定出DAG圖的葉子節點後，還可根據待執行節點是否滿足任務組裝條件，通過兩個輔助任務執行的佇列，將節點添加或者移出這兩個輔助任務執行的佇列，從而輔助動態的生成DAG圖中的節點，進而推動任務的執行。 具體的，伺服器可確定滿足任務組裝條件的待執行節點，添加至執行佇列，確定不滿足任務組裝條件的待執行節點，添加至準備佇列。之後，再根據任務組裝條件，組裝執行佇列中的待執行節點對應的任務並執行。並且，當該準備佇列中的節點滿足任務組裝條件後，可將滿足任務組裝條件的節點移動至該執行佇列中，以組裝任務並執行。一方面輔助了任務的執行，另一方面由於沒有採用鏈表的形式，所以避免了現有技術中伺服器需要反復遍歷鏈表導致效率較低的問題。 例如，以伺服器生成了7個葉子節點為例進行說明。繼續假設任務組裝條件為：選擇未執行過任務的兩個節點。則伺服器可從7個葉子節點中，選擇了6個葉子節點，作為滿足任務組裝條件的節點添加至執行佇列，並將剩餘的一個不滿足任務組裝條件的葉子節點添加至準備佇列，如圖5所示。 進一步地，當執行佇列中的待執行節點對應的任務被組裝並執行完畢後，伺服器還可將該已執行了對應的任務的待執行節點作為已執行節點移出所述執行佇列，以避免重複組裝節點任務。 當然，本說明書並不限定何時將滿足任務組裝條件的待執行節點移動至執行佇列，只要在得到執行結果之前移動即可。例如，該伺服器在確定準備佇列中的存在滿足任務組裝條件的待執行節點時，也可先組裝以及執行滿足任務組裝條件的待執行節點對應的任務，再將該滿足任務組裝條件的待執行節點移動至執行佇列。 S106：根據已執行了對應的任務的節點數量以及所述節點總數，判斷所述任務請求對應的任務是否執行完畢，若是，則執行步驟S108，若否則執行步驟S110。 在本說明書提供的一種或多種實施例中，在每次組裝並執行了任務之後，伺服器可判斷任務請求對應的任務是否執行完畢，並根據判斷結果分別執行不同的後續操作。 具體的，由於步驟S102中該伺服器已經確定出了該DAG圖的節點總數，所以該伺服器可以根據已執行了對應的任務的節點數量（即，已經生成的節點數量），確定該DAG圖中已生成且已經執行了對應任務的節點數量，是否與該節點總數一致，若是，說明對於該任務請求對應的任務，伺服器根據DAG圖的輔助將其拆分出的各子任務均已執行完畢，則執行步驟S108，若否則執行步驟S110。 另外，由於通常在任務的執行過程中，伺服器難以確定已經執行了對應任務的節點數量的，所以在本說明書中，伺服器可以根據已經生成的節點數量與節點總數是否一致，以及上述步驟S104中所述的執行佇列和準備佇列是否均為空，來判斷任務請求對應的任務是否執行完畢。 具體的，由於在步驟S102中，伺服器已經確定出DAG圖的節點總數，所以當生成的節點數量等於該節點總數時，可以確定所有節點均以生成。如以圖4a為例，當生成最下方的節點時，可以確定該DAG圖全部節點均已經生成。 進一步地，為了確定已生成的節點對應的任務是否已經執行完畢，伺服器還可根據在執行佇列中以及在準備佇列中是否還有節點來確定。由於，對於待執行節點來說，當其對應的任務執行完畢時，伺服器可將該待執行節點作為已執行節點移出執行佇列，所以當執行佇列為空時，可以確定滿足任務組裝條件的節點均已執行完任務。而若此時準備佇列中還存在待執行節點，則說明尚有未執行對應任務的節點存在，所以可以確定任務請求對應的任務尚未執行完畢。而當準備佇列與執行佇列中均為空時，可確定生成的節點均已執行過任務。 因此當伺服器判斷已生成的節點數量是否等於節點總數，以及判斷準備佇列以及執行佇列是否均為空時，若判斷結果均為是，則確定任務請求對應的任務執行完畢，並執行步驟S108，若有任一判斷結果為否，則確定任務請求對應的任務未執行完畢，並執行步驟S110。 需要說明的是，繼續以圖4a為例，最後生成的節點只有一個，該節點對應的任務為“將執行結果返回”。該節點對應的任務與DAG圖中其他節點對應的任務不同，該節點對應的任務無需與其他節點組裝。因此在本說明書中，已執行了對應的任務的節點可視為，根據任務組裝條件與其他節點組裝並執行任務的節點，以及執行“將執行結果返回”的任務的節點。 S108：則將所述執行結果作為任務結果。 在本說明書實施例中，當確定任務請求對應的任務執行完畢後，伺服器便可將該執行結果作為任務結果。 並且，需要說明的是，此時該任務結果已經返回。已執行了對應的任務的節點，均為伺服器已經生成的節點，而下游節點為根據執行結果生成的，因此針對每個節點，伺服器可以確定該節點的與其他節點的上下游關係。則當確定出任務結果時，該任務對應的DAG圖也已經生成完畢，即動態的生成了DAG圖的所有節點。 S110：則根據所述執行結果生成下游節點，並將所述下游節點作為待執行節點，繼續執行待執行節點對應的任務，直至確定所述任務請求對應的任務執行完畢為止。 在本說明書提供的一個或多個實施例中，在確定任務請求對應的任務未執行完畢時，該伺服器還可以根據所述執行結果生成下游節點，以便繼續將下游節點作為待執行節點，執行待執行節點對應的任務，直到任務請求對應的任務未執行完畢為止。 具體的，當確定出下游節點後，可將該下游節點作為待執行節點添加至準備佇列中，並重複步驟S104以及步驟S106。 例如，假設伺服器確定出了7個葉子節點，並且任務組裝條件仍為：選擇未執行過任務的兩個節點。進一步假設，節點3和節點4對應的任務已經執行完畢，則此時根據執行結果確定生成下游節點：節點8，並且作為節點3和節點4的下游節點，如圖6a所示。之後，伺服器可將執行佇列中的節點3和節點4移出，並將節點8添加到準備佇列中，如圖6b所示。則此時準備佇列中可存在節點7以及節點8，伺服器可確定節點7以及8滿足任務組裝條件，並將節點7以及節點8移動至執行佇列中，並組裝節點7以及節點8對應的任務，並執行，如圖6c所示。 通過圖2所示的任務執行過程，可見在無法預先確定DAG圖來輔助任務執行時，可以先生成DAG圖的葉子節點，並在任務執行過程中，通過逐步完善DAG圖繼續輔助任務的執行，從而避免了在現有技術中對於某系服務場景，無法預先生成DAG圖時，難以採用DAG圖輔助任務執行的方式執行任務的缺陷。 需要說明的是，本申請案實施例所提供方法的各步驟的執行主體均可以是同一設備，或者，該方法也由不同設備作為執行主體。比如，步驟S100的執行主體可以為設備1，步驟S102的執行主體可以為設備2。上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在附圖中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多工處理和並行處理也是可以的或者可能是有利的。 在本說明書中，該伺服器可以為分散式伺服器，該分散式伺服器中包含有多個管理方以及多個執行方。由各管理方共同執行該任務請求對應的任務，以及維護該任務對應的DAG圖。由執行方接收待執行節點對應的任務並執行，並將確定執行結果並返回任一管理方，如圖7所示。 圖7為本說明書實施例提供的一種執行圖2所示的任務執行方法的任務執行系統的示意圖。其中可見該系統分為管理方以及執行方，並且均存在多個，虛線框中表示各管理方共同維護的任務執行過程。 任一管理方在接收任務請求後，可執行步驟S102對應的操作以及步驟S104中的確定待執行節點對應的任務的部分。之後，便可將該任務發送至任一執行方，由接收任務的執行方執行任務，並向任一管理方返回執行結果。再由接收到執行結果的管理方執行步驟S106的判斷操作，當確定執行行步驟S110時，則重複上述過程，直至確定執行完畢時，執行步驟S106。 可見由於任務請求對應的任務由多個管理方維護，所以無論執行方將執行結果返回哪個管理方，任務流程都可繼續執行下去。並且，管理方在分配任務時，可以是非同步執行的。即，當確定出多個待執行節點對應的任務時，可以分別將確地出的任務發送給不同的執行方。於是，針對每個執行方，當該執行方確定出執行結果後，便可將該執行結果返回任一一個管理方，使該管理方繼續後續步驟的操作。 當然，對於管理方設備如何保持資料同步本說明書不做限定，具體可採用與現有技術中分散式系統中相同的方法。 基於圖1所示的資料存證方法，本說明書實施例還提供一種任務執行裝置，如圖8所示。 圖8為本說明書實施例提供的一種資料存證裝置的結構示意圖，包括： 接收模組200，接收任務請求； 確定模組202，根據所述任務請求生成有向非循環圖DAG的葉子節點，以及確定所述DAG圖的節點總數； 執行模組204，將所述葉子節點作為待執行節點，以及確定所述待執行節點對應的任務並執行，得到執行結果； 判斷生成模組206，根據已執行了對應的任務的節點數量以及所述節點總數，判斷所述任務請求對應的任務是否執行完畢，若是，則將所述執行結果作為任務結果，若否，則根據所述執行結果生成下游節點，並由所述執行模組204將所述下游節點作為待執行節點，繼續執行待執行節點對應的任務，直至確定所述任務請求對應的任務執行完畢為止。 所述確定模組202，根據所述任務請求，確定執行所述任務請求對應的任務需要輸入的資料，根據確定出的資料生成所述DAG圖中的各葉子節點。 所述確定模組202，根據預設的任務組裝條件以及所述葉子節點的數量，確定所述DAG圖的節點總數。 所述執行模組204，確定滿足所述任務組裝條件的待執行節點，添加至執行佇列，確定不滿足所述任務組裝條件的待執行節點，添加至準備佇列，根據所述任務組裝條件，組裝所述執行佇列中的待執行節點對應的任務並執行。 所述執行模組204，得到執行結果之後，將所述待執行節點作為已執行節點移出所述執行佇列。 所述執行模組204，將所述下游節點作為待執行節點添加至所述準備佇列，判斷所述準備佇列中是否存在滿足所述任務組裝條件的待執行節點，若是，則將滿足所述任務組裝條件的待執行節點移動至所述執行佇列，以根據所述任務組裝條件，組裝所述執行佇列中的待執行節點對應的任務並執行，若否，則等待其他待執行節點添加至所述準備佇列。 判斷生成模組206，判斷已生成的節點數量是否等於所述節點總數，判斷所述準備佇列以及所述執行佇列是否均為空，若判斷結果均是，則確定所述任務請求對應的任務執行完畢，若任一判斷結果為否，則確定所述任務請求對應的任務未執行完畢。 所述任務請求為：從若干資料中確定極值資料的請求。 所述執行模組204，確定所述待執行節點對應的任務，並將所述待執行任務發送至執行方，以使所述執行方執行所述任務，並將執行結果返回。 基於圖1所示的任務執行方法，本說明書對應提供一種伺服器，如圖9所示，包括：一個或多個處理器及記憶體，記憶體儲存有程式，並且被配置成由一個或多個處理器執行以下步驟： 接收任務請求； 根據所述任務請求生成有向非循環圖DAG的葉子節點，以及確定所述DAG圖的節點總數； 將所述葉子節點作為待執行節點，以及確定所述待執行節點對應的任務並執行，得到執行結果； 根據已執行了對應的任務的節點數量以及所述節點總數，判斷所述任務請求對應的任務是否執行完畢； 若是，則將所述執行結果作為任務結果； 若否，則根據所述執行結果生成下游節點，並將所述下游節點作為待執行節點，繼續執行待執行節點對應的任務，直至確定所述任務請求對應的任務執行完畢為止。 需要說明的是，本說明書中的各個實施例均採用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於本申請案實施例提供的移動終端以及伺服器而言，由於其基本相似於方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。 在20世紀90年代，對於一個技術的改進可以很明顯地區分是硬體上的改進（例如，對二極體、電晶體、開關等電路結構的改進）還是軟體上的改進（對於方法流程的改進）。然而，隨著技術的發展，當今的很多方法流程的改進已經可以視為硬體電路結構的直接改進。設計人員幾乎都通過將改進的方法流程程式設計到硬體電路中來得到相應的硬體電路結構。因此，不能說一個方法流程的改進就不能用硬體實體模組來實現。例如，可程式設計邏輯裝置（Programmable Logic Device, PLD）（例如現場可程式設計閘陣列（Field Programmable Gate Array，FPGA））就是這樣一種積體電路，其邏輯功能由使用者對裝置程式設計來確定。由設計人員自行程式設計來把一個數位系統“集成”在一片PLD上，而不需要請晶片製造廠商來設計和製作專用的積體電路晶片。而且，如今，取代手工地製作積體電路晶片，這種程式設計也多半改用“邏輯編譯器（logic compiler）”軟體來實現，它與程式開發撰寫時所用的軟體編譯器相類似，而要編譯之前的原始代碼也得用特定的程式設計語言來撰寫，此稱之為硬體描述語言（Hardware Description Language，HDL），而HDL也並非僅有一種，而是有許多種，如ABEL（Advanced Boolean Expression Language）、AHDL（Altera Hardware Description Language）、Confluence、CUPL（Cornell University Programming Language）、HDCal、JHDL（Java Hardware Description Language）、Lava、Lola、MyHDL、PALASM、RHDL（Ruby Hardware Description Language）等，目前最普遍使用的是VHDL（Very-High-Speed Integrated Circuit Hardware Description Language）與Verilog。本領域技術人員也應該清楚，只需要將方法流程用上述幾種硬體描述語言稍作邏輯程式設計並程式設計到積體電路中，就可以很容易得到實現該邏輯方法流程的硬體電路。 控制器可以按任何適當的方式實現，例如，控制器可以採取例如微處理器或處理器以及儲存可由該（微）處理器執行的電腦可讀程式碼（例如軟體或固件）的電腦可讀媒體、邏輯閘、開關、專用積體電路（Application Specific Integrated Circuit，ASIC）、可程式設計邏輯控制器和嵌入微控制器的形式，控制器的例子包括但不限於以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20 以及Silicone Labs C8051F320，記憶體控制器還可以被實現為記憶體的控制邏輯的一部分。本領域技術人員也知道，除了以純電腦可讀程式碼方式實現控制器以外，完全可以通過將方法步驟進行邏輯程式設計來使得控制器以邏輯閘、開關、專用積體電路、可程式設計邏輯控制器和嵌入微控制器等的形式來實現相同功能。因此這種控制器可以被認為是一種硬體部件，而對其內包括的用於實現各種功能的裝置也可以視為硬體部件內的結構。或者甚至，可以將用於實現各種功能的裝置視為既可以是實現方法的軟體模組又可以是硬體部件內的結構。 上述實施例闡明的系統、裝置、模組或單元，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦。具體的，電腦例如可以為個人電腦、膝上型電腦、蜂窩電話、相機電話、智慧型電話、個人數位助理、媒體播放機、導航設備、電子郵件設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任何設備的組合。 為了描述的方便，描述以上裝置時以功能分為各種單元分別描述。當然，在實施本申請案時可以把各單元的功能在同一個或多個軟體和/或硬體中實現。 本領域內的技術人員應明白，本發明的實施例可提供為方法、系統、或電腦程式產品。因此，本發明可採用完全硬體實施例、完全軟體實施例、或結合軟體和硬體方面的實施例的形式。而且，本發明可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存媒體（包括但不限於磁碟記憶體、CD-ROM、光學記憶體等）上實施的電腦程式產品的形式。 本發明是參照根據本發明實施例的方法、設備（系統）、和電腦程式產品的流程圖和／或方塊圖來描述的。應理解可由電腦程式指令實現流程圖和／或方塊圖中的每一流程和／或方塊、以及流程圖和／或方塊圖中的流程和／或方塊的結合。可提供這些電腦程式指令到通用電腦、專用電腦、嵌入式處理機或其他可程式設計資料處理設備的處理器以產生一個機器，使得通過電腦或其他可程式設計資料處理設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程和／或方塊圖一個方塊或多個方塊中指定的功能的裝置。 這些電腦程式指令也可儲存在能引導電腦或其他可程式設計資料處理設備以特定方式工作的電腦可讀記憶體中，使得儲存在該電腦可讀記憶體中的指令產生包括指令裝置的製造品，該指令裝置實現在流程圖一個流程或多個流程和／或方塊圖一個方塊或多個方塊中指定的功能。 這些電腦程式指令也可裝載到電腦或其他可程式設計資料處理設備上，使得在電腦或其他可程式設計設備上執行一系列操作步驟以產生電腦實現的處理，從而在電腦或其他可程式設計設備上執行的指令提供用於實現在流程圖一個流程或多個流程和／或方塊圖一個方塊或多個方塊中指定的功能的步驟。 在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。 記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體(RAM)和/或非易失性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀媒體的示例。 電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可程式設計唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶，磁帶磁片儲存或其他磁性存放裝置或任何其他非傳輸媒體，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀媒體不包括暫存電腦可讀媒體(transitory media)，如調變的資料信號和載波。 還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。 本領域技術人員應明白，本申請案的實施例可提供為方法、系統或電腦程式產品。因此，本申請案可採用完全硬體實施例、完全軟體實施例或結合軟體和硬體方面的實施例的形式。而且，本申請案可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存媒體（包括但不限於磁碟記憶體、CD-ROM、光學記憶體等）上實施的電腦程式產品的形式。 本申請案可以在由電腦執行的電腦可執行指令的一般上下文中描述，例如程式模組。一般地，程式模組包括執行特定任務或實現特定抽象資料類型的常式、程式、物件、組件、資料結構等等。也可以在分散式運算環境中實踐本申請案，在這些分散式運算環境中，由通過通信網路而被連接的遠端處理設備來執行任務。在分散式運算環境中，程式模組可以位於包括存放裝置在內的本地和遠端電腦儲存媒體中。 本說明書中的各個實施例均採用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於系統實施例而言，由於其基本相似於方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。 以上所述僅為本申請案的實施例而已，並不用於限制本申請案。對於本領域技術人員來說，本申請案可以有各種更改和變化。凡在本申請案的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本申請案的申請專利範圍之內。In order to make the purpose, technical solution, and advantages of the present specification clearer, the technical solution of the present application will be clearly and completely described in combination with specific embodiments of the present specification and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the specification, all other embodiments obtained by a person of ordinary skill in the art without making progressive labor fall within the protection scope of the present application. The technical solutions provided by the embodiments of the present application will be described in detail below with reference to the accompanying drawings. FIG. 2 is a task execution process provided by an embodiment of the specification, which may specifically include the following steps: S100: Receive a task request. In one or more embodiments of the present specification, a device of a service provider may receive a task request and execute a corresponding task according to the task request. The device provided by the service may be a terminal or a server, for example, a mobile phone, a personal computer, a server, etc., which is not limited in this specification. For the convenience of description, the following description uses the server as the execution subject of the task execution process as an example. In addition, the task request may carry information required for performing the task, so that the server can perform the task subsequently. The server can be a single device or a system composed of multiple devices, such as a decentralized server. Further, in the embodiment of the present specification, the task request may be a request for determining extreme data among several data. Specifically, some of the data may be data required to perform a task corresponding to a task request, and the extreme value data may be a maximum value or a minimum value of the required data. It should be noted that, in this specification, the extremum data may be the data itself required to perform the task directly (for example, selecting the corresponding data with the largest or smallest value from a number of data), or it may also be required to perform the task. The results determined by the information. For example, if the task request is to determine the user with the highest risk of borrowing among users A to D, the information required to perform the task may include the identity information, transaction records, and other information of users A to D. According to the information required to perform the task, When the determined borrowing risk results of the users A to D are respectively determined, the maximum value is determined from the respective borrowing risk results. In this case, the extreme data is not the input data itself, but a result calculated based on the input data. S102: Generate leaf nodes of the directed acyclic graph DAG according to the task request, and determine the total number of nodes of the DAG graph. In this specification, the server may first generate each leaf node in the DAG graph corresponding to the task according to the task request, so as to split the corresponding task request task into several simple subtasks through each leaf node in the DAG graph. To execute the task corresponding to the task request. In addition, since the server has determined the leaf nodes of the DAG graph, the server can further determine the total number of nodes in the DAG graph according to the task request, so that when subsequent nodes are generated by executing the task, it can determine when the task is Execution is complete (for example, when all nodes of the DAG graph are generated). Specifically, the server may first determine, according to the task request, the data that needs to be input to execute the task corresponding to the task request, and then generate each leaf node in the DAG graph according to the determined data. Alternatively, when the data required for performing the task is already carried in the task request, the server may also directly generate each leaf node in the DAG graph according to the data carried in the task request. Of course, the above two methods for generating leaf nodes can be used alone or in combination, which are not limited in this specification. For example, the server receives the task request to determine which of the banks a to d has the most deposits by the user A. Banks a to d are all likely to be the bank where user A has the most deposits. Therefore, the server can determine that the data required to perform the task is user A's deposits in banks a to d. First, the server can determine the user A's deposits in the banks a to d by sending query requests to the banks a to d, respectively, as the data that needs to be input to perform the task corresponding to the task request. Or, suppose that the task request is sent by bank a, and the task request carries the deposit value of user A in bank a, so the server can send a query request to banks b to d to determine the corresponding task execution request. Information required for the task. Then, the server may generate leaf nodes of the DAG graph according to the deposits of the user A in each bank a to d, and generate leaf nodes of the DAG graph. Assume that the deposit of user A in banks a to d is shown in Table 1. In Table 1, the server can build the DAG graph leaf nodes shown in Figure 3. It can be seen in FIG. 3 that each leaf node identifier has node identifiers 1 to 4, wherein each leaf node corresponds to an identifier of a bank. In addition, for each leaf node, the server may use the deposit value of the user A in the bank corresponding to the leaf node as the value corresponding to the leaf node. Therefore, it can be seen that each leaf node in FIG. 3 corresponds to the identifier of the bank and the deposit value of the user A in the bank. Of course, the above example is only an example provided by the embodiment of this specification, and this specification does not limit how the server generates each leaf node and how to determine the corresponding value of each leaf node. For example, when the task request is to determine the largest single deposit of user A in each bank, each leaf node generated may only correspond to the value of each single deposit of user A in each bank. Or, when the task request is to determine the webpage that the user has browsed the most times, leaf nodes may be generated according to each webpage that the user has browsed, and the number of times that the user browses each webpage is used as the corresponding leaf node. Values, etc. Further, in one or more embodiments of the present specification, after determining the leaf nodes of the DAG graph, the server may also determine the total number of nodes in the DAG graph, that is, determine how many nodes should exist in the DAG graph. . In order to determine whether the task corresponding to the task request has been completed based on the total number of nodes in the DAG graph. Specifically, since the DAG graph can be used to divide a complex task into a plurality of simple subtasks, in which manner the subtasks are determined, that is, how to assemble the tasks corresponding to the nodes can be set as required. Therefore, in this specification, the task assembly conditions may be stored in the server in advance. Then the server can determine the total number of nodes in the DAG graph according to the number of leaf nodes that have been generated and the pre-stored task assembly conditions. In this specification, when the task request is specifically a task for determining extreme data from a number of materials, the task assembly conditions may specifically be: selecting a preset number of nodes that have not performed the corresponding task, and the preset number may be based on Need to be set, for example, 2, 3, etc. Continuing the above example, suppose that for a task request that determines the value of a value, the server is pre-configured with task assembly conditions as follows: two nodes that have not performed a task are selected, that is, the preset number is two. Based on the task assembly conditions, the server can select the values corresponding to the two nodes, perform pairwise comparison, and use the comparison result as the execution result. Therefore, the total number of nodes in the DAG graph can be based on the formula: determine. Among them, m is the total number of nodes, and n is the number of leaf nodes. Therefore, the server can determine that for the four leaf nodes, the total number of nodes in the DAG graph can be determined according to the task assembly conditions, as shown in FIG. 4a. Alternatively, assuming that the server generates 7 leaf nodes, according to the same task assembly conditions, the total number of nodes in the DAG graph can be determined to be 13, as shown in FIG. 4b. Figures 4a and 4b are schematic diagrams for determining the total number of nodes in the DAG graph provided in the implementation of this specification. Among them, the leaf nodes are generated nodes and are represented by solid lines, while the remaining nodes in the DAG graph have not yet been generated and are represented by dashed lines. The dashed arrows indicate the direction of the DAG graph, that is, the upstream and downstream relationship of the nodes. Of course, it should be noted that the dashed lines shown in the above Figures 4a to 4b are schematic. Since the tasks have not been assembled at this time, the arrows are dotted lines to indicate a possible task assembly situation, and it does not mean that the DAG diagram will follow the The node form generated by the dashed line is generated, and this dashed line is only one possible form of the final DAG graph corresponding to the task at the time of final determination. S104: Use the leaf node as a node to be executed, and determine and execute a task corresponding to the node to be executed to obtain an execution result. In this specification, the server as described in step S102 may assemble and execute tasks according to preset task assembly conditions. Therefore, the server may first regard each leaf node as a node to be executed, and then determine the task corresponding to the reception node to be executed. Finally, the tasks corresponding to the nodes that meet the task assembly conditions are assembled, and the execution results are obtained by executing the assembled tasks. For example, to determine which user A has the most deposits in banks a to d as an example. Assuming that the tasks corresponding to nodes 1 and 2 in the DAG graph are comparative data sizes, the tasks corresponding to nodes 1 and 2 are assembled and executed. Later, it can be determined that there are more deposits in bank b, and it can be determined that the execution result is bank b, and the corresponding value is 200 yuan. After the tasks corresponding to nodes 3 and 4 are assembled and executed, it can be determined that the execution result is bank c, and the corresponding value is 5000 yuan. In addition, in the prior art, in order to conveniently use a computer language to perform tasks according to the DAG diagram, the DAG diagram is usually converted into a linked list form, and the subtasks to be executed are determined according to the linked list. Moreover, because there is no data index in the data structure of the linked list, each time when determining what needs to be performed next (for example, determining which node corresponds to a subsequent task to be executed), the server usually needs to traverse the linked list to determine the need to execute Which node corresponds to the task. However, since the DAG diagram in this specification cannot be determined in advance, there is no corresponding linked list to assist execution. Therefore, in the embodiment of the present specification, after determining the leaf nodes of the DAG graph, the server can also add or remove nodes from the two auxiliary task execution queues according to whether the to-be-executed nodes meet the task assembly conditions. Assist the execution of the task queue, thereby assisting the dynamic generation of nodes in the DAG graph, and then promote the task execution. Specifically, the server may determine the pending nodes that meet the task assembly conditions and add them to the execution queue, and determine the pending nodes that do not meet the task assembly conditions and add it to the preparation queue. Then, according to the task assembly conditions, the tasks corresponding to the nodes to be executed in the execution queue are assembled and executed. In addition, after the nodes in the preparation queue meet the task assembly conditions, the nodes that meet the task assembly conditions can be moved to the execution queue to assemble the tasks and execute them. On the one hand, the task execution is assisted, and on the other hand, because the form of a linked list is not adopted, the problem that the server needs to traverse the linked list repeatedly in the prior art is caused, resulting in lower efficiency. For example, the server generates 7 leaf nodes as an example. Continue to assume that the task assembly condition is: select two nodes that have not performed the task. Then the server can select 6 leaf nodes from the 7 leaf nodes and add them to the execution queue as nodes that meet the task assembly conditions, and add the remaining leaf nodes that do not meet the task assembly conditions to the preparation queue. As shown in Figure 5. Further, after the tasks corresponding to the to-be-executed nodes in the execution queue are assembled and executed, the server may also remove the to-be-executed nodes that have executed the corresponding tasks from the execution queue as executed nodes to Avoid repeated assembly node tasks. Of course, this specification does not limit when to move the nodes to be executed that meet the task assembly conditions to the execution queue, as long as it is moved before the execution result is obtained. For example, when the server determines that there are to-be-executed nodes that meet the task assembly conditions in the preparation queue, it may also first assemble and execute the tasks corresponding to the to-be-executed nodes that meet the task assembly conditions, and then The execution node moves to the execution queue. S106: Determine whether the task corresponding to the task request has been completed according to the number of nodes that have executed the corresponding task and the total number of nodes, and if yes, execute step S108; otherwise, execute step S110. In one or more embodiments provided in this specification, after each task is assembled and executed, the server may determine whether the task corresponding to the task request has been completed, and perform different subsequent operations according to the judgment result. Specifically, since the server has determined the total number of nodes of the DAG graph in step S102, the server may determine the DAG graph according to the number of nodes that have performed the corresponding task (that is, the number of nodes that have been generated). The number of nodes that have been generated and have executed the corresponding task is consistent with the total number of nodes. If so, it indicates that for the task corresponding to the task request, the server has divided the sub-tasks according to the assistance of the DAG diagram. If it is completed, step S108 is performed, otherwise, step S110 is performed. In addition, since it is often difficult for the server to determine the number of nodes that have executed the corresponding task during the execution of the task, in this specification, the server can determine whether the number of nodes that have been generated is consistent with the total number of nodes, and the above step S104 Whether the execution queue and the preparation queue described in the description are both empty to determine whether the task corresponding to the task request has been completed. Specifically, since the server has determined the total number of nodes of the DAG graph in step S102, when the number of generated nodes is equal to the total number of nodes, it can be determined that all nodes are generated. Taking FIG. 4a as an example, when generating the lowest node, it can be determined that all nodes of the DAG graph have been generated. Further, in order to determine whether the task corresponding to the generated node has been executed, the server may also determine according to whether there are nodes in the execution queue and in the preparation queue. Because, for a node to be executed, when the execution of the corresponding task is completed, the server can remove the node to be executed as an executed node from the execution queue. Therefore, when the execution queue is empty, it can be determined that the task assembly conditions are met. Have completed their tasks. And if there are nodes to be executed in the preparation queue at this time, it means that there are nodes that have not yet executed the corresponding tasks, so it can be determined that the tasks corresponding to the task requests have not been executed. When both the preparation queue and the execution queue are empty, it can be determined that the generated nodes have already performed the task. Therefore, when the server judges whether the number of generated nodes is equal to the total number of nodes, and whether the preparation queue and the execution queue are both empty, if the judgment results are all yes, it is determined that the task corresponding to the task request has been completed, and the steps are performed. In step S108, if any of the determination results is no, it is determined that the task corresponding to the task request has not been completed, and step S110 is performed. It should be noted that, taking FIG. 4a as an example, there is only one node that is finally generated, and the corresponding task of the node is “return the execution result”. The task corresponding to this node is different from the tasks corresponding to other nodes in the DAG graph, and the tasks corresponding to this node do not need to be assembled with other nodes. Therefore, in this specification, a node that has performed a corresponding task can be regarded as a node that is assembled with other nodes and performs the task according to the task assembly conditions, and a node that executes the task of “returning the execution result”. S108: Use the execution result as the task result. In the embodiment of the present specification, when it is determined that the task corresponding to the task request is completed, the server may use the execution result as the task result. And, it should be noted that the task result has been returned at this time. The nodes that have performed the corresponding tasks are all the nodes that the server has generated, and the downstream nodes are generated according to the execution results. Therefore, for each node, the server can determine the upstream and downstream relationships between the node and other nodes. When the task result is determined, the DAG graph corresponding to the task has also been generated, that is, all nodes of the DAG graph are dynamically generated. S110: Generate a downstream node according to the execution result, and use the downstream node as the node to be executed, and continue to execute the task corresponding to the node to be executed until it is determined that the task corresponding to the task request is completed. In one or more embodiments provided in this specification, when it is determined that the task corresponding to the task request has not been completed, the server may further generate a downstream node according to the execution result, so as to continue to use the downstream node as a node to be executed. The task corresponding to the node to be executed until the task corresponding to the task request is not completed. Specifically, after a downstream node is determined, the downstream node may be added to the preparation queue as a to-be-executed node, and steps S104 and S106 are repeated. For example, assume that the server has identified 7 leaf nodes and the task assembly conditions are still: selecting two nodes that have not performed a task. It is further assumed that the tasks corresponding to nodes 3 and 4 have been performed, and at this time, a downstream node: node 8 is determined to be generated according to the execution result, and as a downstream node of node 3 and node 4, as shown in FIG. 6a. After that, the server can remove node 3 and node 4 from the execution queue, and add node 8 to the preparation queue, as shown in FIG. 6b. Node 7 and node 8 may exist in the preparation queue at this time. The server may determine that nodes 7 and 8 meet the task assembly conditions, move node 7 and node 8 into the execution queue, and assemble node 7 and node 8 correspondingly. And execute the task as shown in Figure 6c. Through the task execution process shown in Figure 2, it can be seen that when the DAG graph cannot be determined in advance to assist the task execution, the leaf nodes of the DAG graph can be generated first, and during the task execution process, the DAG graph is gradually improved to continue to assist the task execution. Therefore, in the prior art, when a DAG diagram cannot be generated in advance for a certain service scenario, it is difficult to perform the task of using the DAG diagram to assist in task execution. It should be noted that the execution subject of each step of the method provided in the embodiment of the present application may be the same device, or the method may also use different devices as the execution subject. For example, the execution subject of step S100 may be device 1, and the execution subject of step S102 may be device 2. The specific embodiments of the present specification have been described above. Other embodiments are within the scope of the appended patent applications. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order than in the embodiments and still achieve the desired result. In addition, the processes depicted in the figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In some embodiments, multiplexing and parallel processing are also possible or may be advantageous. In this specification, the server may be a decentralized server, and the decentralized server includes multiple management parties and multiple execution parties. Each manager jointly executes the task corresponding to the task request and maintains the DAG map corresponding to the task. The execution party receives and executes the task corresponding to the node to be executed, and determines the execution result and returns to any management party, as shown in FIG. 7. FIG. 7 is a schematic diagram of a task execution system for performing the task execution method shown in FIG. 2 according to an embodiment of the present specification. It can be seen that the system is divided into a management party and an executive party, and there are multiple ones. The dashed box indicates the task execution process jointly maintained by each management party. After receiving the task request, any manager may perform the operation corresponding to step S102 and the part of step S104 that determines the task corresponding to the node to be executed. After that, the task can be sent to any executor, the executor receiving the task executes the task, and returns the execution result to any manager. Then, the manager receiving the execution result executes the judgment operation of step S106. When it is determined that step S110 is executed, the above process is repeated until it is determined that the execution is completed, and step S106 is executed. It can be seen that since the task corresponding to the task request is maintained by multiple managers, the task process can continue to be executed no matter which manager the execution party returns the execution result to. In addition, the management side may execute asynchronously when assigning tasks. That is, when tasks corresponding to a plurality of nodes to be executed are determined, the tasks that are actually performed may be sent to different execution parties, respectively. Therefore, for each executor, after the executor determines the execution result, the execution result can be returned to any management party, so that the management party can continue the operation of the subsequent steps. Of course, this description does not limit how the management device maintains data synchronization, and the same method as in the prior art decentralized system can be specifically used. Based on the data storage method shown in FIG. 1, an embodiment of the present specification further provides a task execution device, as shown in FIG. 8. FIG. 8 is a schematic structural diagram of a data storage device provided by an embodiment of this specification, including: a receiving module 200 that receives a task request; a determination module 202 that generates a leaf node of a directed acyclic graph DAG according to the task request, And determine the total number of nodes in the DAG graph; the execution module 204 uses the leaf node as a to-be-executed node, and determines and executes a task corresponding to the to-be-executed node to obtain an execution result; and determines the generation module 206 according to the The number of nodes that executed the corresponding task and the total number of nodes determine whether the task corresponding to the task request has been executed. If so, the execution result is used as the task result. If not, a downstream node is generated according to the execution result. And the execution module 204 uses the downstream node as the node to be executed, and continues to execute the task corresponding to the node to be executed, until it is determined that the task corresponding to the task request is completed. The determination module 202 determines, according to the task request, data required to be input to perform a task corresponding to the task request, and generates each leaf node in the DAG graph according to the determined data. The determining module 202 determines the total number of nodes in the DAG graph according to a preset task assembly condition and the number of the leaf nodes. The execution module 204 determines a to-be-executed node that satisfies the task assembly conditions and adds it to an execution queue, determines a to-be-executed node that does not meet the task assembly conditions and adds it to a preparation queue, and according to the task assembly conditions , Assemble and execute the tasks corresponding to the nodes to be executed in the execution queue. After the execution module 204 obtains the execution result, the execution node is removed from the execution queue as an executed node. The execution module 204 adds the downstream node as a to-be-executed node to the preparation queue, and determines whether there is a to-be-executed node that satisfies the task assembly conditions in the preparation queue. The to-be-executed nodes of the task assembly condition are moved to the execution queue to assemble and execute tasks corresponding to the to-be-executed nodes in the execution queue according to the task assembly conditions, and if not, wait for other to-be-executed nodes Add to the preparation queue. The judgment generation module 206 judges whether the number of generated nodes is equal to the total number of nodes, determines whether the preparation queue and the execution queue are both empty, and if the judgment results are both, determines whether the task request corresponds to The task execution is completed, and if any judgment result is no, it is determined that the task corresponding to the task request has not been executed. The task request is: a request for determining extreme value data from several data. The execution module 204 determines a task corresponding to the node to be executed, and sends the task to be executed to an executing party, so that the executing party executes the task, and returns an execution result. Based on the task execution method shown in FIG. 1, this specification correspondingly provides a server, as shown in FIG. 9, which includes: one or more processors and memory, the memory stores programs, and is configured by one or more processors. Each processor executes the following steps: receiving a task request; generating leaf nodes of a directed acyclic graph DAG according to the task request, and determining the total number of nodes of the DAG graph; using the leaf nodes as nodes to be executed, and determining all nodes The task corresponding to the node to be executed is described and executed to obtain the execution result; according to the number of nodes that have executed the corresponding task and the total number of nodes, it is determined whether the task corresponding to the task request has been completed; if so, the execution result is As a task result; if not, generate a downstream node according to the execution result, and use the downstream node as a node to be executed, and continue to execute a task corresponding to the node to be executed until it is determined that the task corresponding to the task request is completed. It should be noted that each embodiment in this specification is described in a progressive manner, and the same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. Office. In particular, for the mobile terminal and the server provided in the embodiments of the present application, since they are basically similar to the method embodiments, the description is relatively simple. For the related parts, refer to the description of the method embodiments. In the 1990s, for a technical improvement, it can be clearly distinguished whether it is an improvement in hardware (for example, the improvement of circuit structures such as diodes, transistors, switches, etc.) or an improvement in software (for method and process Improve). However, with the development of technology, the improvement of many methods and processes can be regarded as a direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by designing the improved method flow program into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user's programming of the device . Designers can program their own digital system to "integrate" on a PLD without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development. The original source code before compilation must also be written in a specific programming language. This is called the Hardware Description Language (HDL), and there is not only one type of HDL, but many types, such as ABEL (Advanced Boolean Expression Language, AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, Ruby Hardware Description Language (RHDL), etc. Currently the most commonly used are Very-High-Speed Integrated Circuit Hardware Description Language (VHDL) and Verilog. Those skilled in the art should also be clear that as long as the method flow is logically programmed and integrated into the integrated circuit using the above-mentioned several hardware description languages, the hardware circuit implementing the logic method flow can be easily obtained. The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer-readable medium storing computer-readable code (such as software or firmware) executable by the (micro) processor. , Logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that, in addition to implementing the controller in pure computer-readable code, it is entirely possible to make the controller controlled by logic gates, switches, dedicated integrated circuits, and programmable logic by programming logic steps in the method steps Controller and embedded microcontroller to achieve the same function. Therefore, the controller can be considered as a hardware component, and the device included in the controller for implementing various functions can also be considered as a structure in the hardware component. Or even, a device for implementing various functions can be regarded as a structure that can be both a software module implementing the method and a hardware component. The system, device, module, or unit described in the foregoing embodiments may be specifically implemented by a computer chip or entity, or by a product having a certain function. A typical implementation is a computer. Specifically, the computer may be, for example, a personal computer, a laptop, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, or a wearable device. Or a combination of any of these devices. For the convenience of description, when describing the above device, the functions are divided into various units and described separately. Of course, when implementing the present application, the functions of each unit may be implemented in the same or multiple software and / or hardware. Those skilled in the art should understand that the embodiments of the present invention may be provided as a method, a system, or a computer program product. Therefore, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk memory, CD-ROM, optical memory, etc.) containing computer-usable code therein. . The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, and a combination of the flow and / or block in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to generate a machine for instructions executed by the processor of the computer or other programmable data processing device Generate means for implementing the functions specified in one or more flowcharts and / or one or more blocks of the block diagram. These computer program instructions may also be stored in computer readable memory that can guide a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory generate a manufactured article including a command device , The instruction device realizes the functions specified in a flowchart or a plurality of processes and / or a block or a block of the block diagram. These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operating steps can be performed on the computer or other programmable equipment to generate computer-implemented processing, and thus on the computer or other programmable equipment The instructions executed on the steps provide steps for realizing the functions specified in one or more flowcharts and / or one or more blocks of the block diagram. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-permanent memory, random access memory (RAM), and / or non-volatile memory in computer-readable media, such as read-only memory (ROM) or flash memory ( flash RAM). Memory is an example of a computer-readable medium. Computer-readable media includes permanent and non-permanent, removable and non-removable media. Information can be stored by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), and other types of random access memory (RAM) , Read-only memory (ROM), electrically erasable and programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only disc read-only memory (CD-ROM), digital multifunction Optical discs (DVDs) or other optical storage, magnetic tape cartridges, magnetic tape storage or other magnetic storage devices, or any other non-transmission media may be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves. It should also be noted that the terms "including,""including," or any other variation thereof are intended to encompass non-exclusive inclusion, so that a process, method, product, or device that includes a range of elements includes not only those elements, but also Other elements not explicitly listed, or those that are inherent to such a process, method, product, or device. Without more restrictions, the elements defined by the sentence "including a ..." do not exclude the existence of other identical elements in the process, method, product or equipment including the elements. Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, this application may use computer program products implemented on one or more computer-usable storage media (including, but not limited to, magnetic disk memory, CD-ROM, optical memory, etc.) containing computer-usable code. form. This application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application can also be practiced in a decentralized computing environment in which tasks are performed by a remote processing device connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices. Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For the relevant part, refer to the description of the method embodiment. The above descriptions are merely examples of the present application and are not intended to limit the present application. For those skilled in the art, various modifications and changes can be made to this application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included in the scope of patent application of this application.