一種業務消息處理方法及裝置與流程
2023-10-18 09:08:20 2
本申請涉及網際網路數據處理技術領域，尤其涉及一種業務消息處理方法及裝置。
背景技術：
對於一個複雜的業務系統，其包括很多支撐系統。例如，針對電子商務系統這一複雜的業務系統，其可以包括商品系統、交易系統、物流系統、售後系統、運營系統、商家系統等支撐系統。
為了保障各自支撐系統的穩定性，每一支撐系統對業務的處理大都是通過消息交互的方式來進行的。對於某一個支撐系統來說，經常要訂閱很多其他支撐系統的業務消息，這些其他支撐系統既有核心支撐系統，又有非核心支撐系統。
根據一些業務消息(被依賴的業務消息)，執行關聯業務處理時，需要使用到其他業務消息(依賴業務消息)。然而，依賴業務消息往往不能先於被依賴的業務消息到達，導致無法執行關聯業務處理。例如，對於關注整條業務鏈路的支撐系統來說，通常是按照實際的業務發生順序來處理整條鏈路上的業務消息，也可以說是對整條業務鏈上的一些業務消息執行關聯業務處理，但實際上由於業務消息是異步的，再加上消息中間件伺服器有很多，並不能保證訂閱的其他支撐系統的業務消息一定會按照期望的業務消息到達順序到達。下面通過圖1所示的電子商務系統的供應鏈單據中心系統進行說明。
圖1中的供應鏈單據中心系統含有4個支撐系統，分別是交易系統、物流訂單系統、倉儲作業系統和單據中心系統；其中，單據中心系統為關注整條業務鏈路的支撐系統，其需要訂閱交易系統產生的交易付款消息、物流訂單系統產生的物流訂單創建消息和倉儲作業系統產生的倉儲作業訂單創建消息。交易 系統對應3個消息中間件伺服器，物流訂單系統對應2個消息中間件伺服器，倉儲作業系統對應1個消息中間件伺服器；每一支撐系統對應的消息中間件伺服器，通常是以集群的形式存在，主要負責將其對應的支撐系統產生的業務消息轉發至各個目的系統。根據轉發的目的系統對消息的可靠性和及時性的要求不同，可以對對應的各消息中間件伺服器設置不同的資源配置，目的系統對消息的可靠性和及時性要求高的，負責轉發至該目的系統的消息中間件伺服器的資源配置高也就越高，優先級也相應地越高；
圖1中，實際的業務發生順序是：交易付款→物流訂單創建→倉儲作業訂單創建；由於單據中心系統對交易付款→物流訂單創建→倉儲作業訂單創建這一業務鏈上的倉儲作業訂單創建消息，執行關聯業務處理需要使用交易付款消息和物流訂單創建消息，因此，單據中心系統期望的業務消息到達順序是：交易付款消息→物流訂單創建消息→倉儲作業訂單創建消息；
但實際上，由於發送業務消息的各消息中間件伺服器的優先級差異，以及業務消息本身的特定決定了，交易系統、物流系統和倉儲作業系統針對同一交易產生的交易付款消息、物流訂單創建消息和倉儲作業訂單創建消息到達單據中心系統時的順序可能為：物流訂單創建消息→倉儲作業訂單創建消息→交易付款消息、倉儲作業訂單創建消息→物流訂單創建消息→交易付款消息或者交易付款消息→倉儲作業訂單創建消息→物流訂單創建消息等等。
為了確保業務消息能按照期望的業務消息到達順序到達，進而對被依賴的業務消息執行關聯業務處理，現有技術中對業務消息的處理方法如圖2所示，包括以下步驟：
步驟201：接收當前業務消息；
針對圖1中所示的供應鏈單據中心系統而言，這裡假設接收到的當期業務消息是倉儲作業訂單創建消息，該倉儲作業訂單創建消息的依賴業務消息為交易付款消息和物流訂單創建消息，並且之前還沒有接收到交易付款消息和物流訂單創建消息；
步驟202：對該當前業務消息進行獨立業務處理；
這裡的步驟202進行獨立業務處理的目的是，將當前業務消息處理為適合本地處理的業務消息。
步驟203：將當前業務消息保存到可以永久保存的存儲設備中；
這裡，沿用步驟201中的例子，將接收到的倉儲作業訂單創建消息保存到存儲設備中；
步驟204：判斷該當前業務消息是否需要依賴業務消息；若判斷結果為是，則執行步驟205；若判斷結果為否，則結束。
沿用步驟203的例子，這裡判斷出倉儲作業訂單創建消息需要依賴業務消息；
步驟205：判斷該當前業務消息的依賴業務消息是否存在；若判斷結果為是，則執行步驟206；若判斷結果為否，則執行步驟207；
沿用步驟204的例子，這裡由於還沒有接收到交易付款消息和物流訂單創建消息，因此，上述存儲設備中並沒有存儲交易付款消息和物流訂單創建消息，也即判斷出倉儲作業訂單創建消息的依賴業務消息不存在，執行步驟207；
步驟206：利用該當前業務消息的依賴業務消息，對該當前業務消息執行關聯業務處理。
步驟207：向發送該當前業務消息的消息中間件伺服器發送處理失敗稍後重試消息，並回滾對該當前業務消息執行的操作。
沿用步驟205的例子，這裡，單據中心系統向倉儲作業系統發送處理失敗稍後重試消息，將在步驟203中存儲到存儲設備的倉儲作業訂單創建消息刪除。
概括而言，上述方法即為若接收到的當前業務消息的依賴業務消息沒有到達，則該當前業務消息就會被回滾。
上述業務消息處理方法可以保證業務消息一定會按照期望的業務消息到達順序到達，使得可以對被依賴的業務消息進行關聯業務處理。然而，該方法存在的缺陷也顯而易見，那就是當業務消息量大，且不能保證按照設定順序到 達時，大量的業務消息會被重試。這將會導致業務消息在消息中間件伺服器中的大量堆積，並且直接影響消息中間件伺服器的穩定性。如果該消息中間件伺服器負責的是核心支撐系統的業務消息的轉發，這將會對業務的處理造成更為嚴重的影響。
技術實現要素：
本申請實施例提供一種業務消息處理方法及裝置，用以解決現有技術存在的當業務消息量大且不能保證按照設定順序到達時，大量的業務消息會被重試，影響消息中間件伺服器的穩定性的問題。
一種業務消息處理方法，包括：
接收並保存當前業務消息；
若確定保存的業務消息中不存在該當前業務消息的依賴業務消息，則針對該當前業務消息創建等待任務，其中，該當前業務消息的依賴業務消息包括對該當前業務消息執行關聯業務處理時，需要使用的業務消息，創建的所述等待任務用於等待該當前業務消息的依賴業務消息；
將創建的所述等待任務寫入到等待任務隊列中，並指示至少一個第二節點從等待任務隊列中獲取等待任務，以及針對獲取的每一等待任務，若確定第一節點保存的業務消息中存在該等待任務等待的依賴業務消息，則利用該依賴業務消息，對創建該等待任務時所針對的當前業務消息執行關聯業務處理。
一種業務消息處理方法，包括：
從等待任務隊列中獲取等待任務，其中，每個等待任務是第一節點接收到當前業務消息，並確定保存的業務消息中，不存在該當前業務消息的依賴業務消息時，針對該當前業務消息創建的等待任務，該當前業務消息的依賴業務消息包括對該當前業務消息執行關聯業務處理時，需要使用的業務消息，創建的所述等待任務用於等待該當前業務消息的依賴業務消息，所述第一節點將接收到的每一個當前業務消息添加到所述保存的業務消息中；
針對獲取的每一等待任務，執行以下操作：
若確定第一節點保存的業務消息中，存在該等待任務等待的依賴業務消息，則利用該依賴業務消息，對創建該等待任務時所針對的當前業務消息執行關聯業務處理，並刪除該等待任務。
一種業務消息處理裝置，包括：
接收模塊，用於接收當前業務消息；
保存模塊，用於保存接收的當前業務消息；
創建模塊，用於若確定保存的業務消息中不存在該當前業務消息的依賴業務消息，則針對該當前業務消息創建等待任務，其中，該當前業務消息的依賴業務消息包括對該當前業務消息執行關聯業務處理時，需要使用的業務消息，創建的所述等待任務用於等待該當前業務消息的依賴業務消息；
寫入模塊，用於將創建的所述等待任務寫入到等待任務隊列中，並指示至少一個第二節點從等待任務隊列中獲取等待任務，以及針對獲取的每一等待任務，若確定保存的業務消息中存在該等待任務等待的依賴業務消息，則利用該依賴業務消息，對創建該等待任務時所針對的當前業務消息執行關聯業務處理。
一種業務消息處理裝置，包括：
獲取模塊，用於從等待任務隊列中獲取等待任務，其中，每個等待任務是第一節點接收到當前業務消息，並確定保存的業務消息中，不存在該當前業務消息的依賴業務消息時，針對該當前業務消息創建的等待任務，該當前業務消息的依賴業務消息包括對該當前業務消息執行關聯業務處理時，需要使用的業務消息，創建的所述等待任務用於等待該當前業務消息的依賴業務消息，所述第一節點將接收到的每一個當前業務消息添加到所述保存的業務消息中；
執行模塊，用於針對獲取的每一等待任務，執行以下操作：若確定第一節點保存的業務消息中，存在該等待任務等待的依賴業務消息，則利用該依賴業務消息，對創建該等待任務時所針對的當前業務消息執行關聯業務處理，並刪 除該等待任務。
在本申請實施例的方案中，接收並保存當前業務消息，在確定保存的業務消息中不存在該當前業務消息的依賴業務消息時，針對該當前業務消息創建等待任務，將創建的等待任務寫入到等待任務隊列中，並指示至少一個第二節點針對等待任務隊列中的等待任務，在保存的業務消息中存在等待任務等待的依賴業務消息時，利用該依賴業務消息，對創建該等待任務時所針對的當前業務消息執行關聯業務處理。由於在不存在當前業務消息的依賴業務消息時，不是對該當前業務消息進行回滾及重試操作，而是創建等待任務，等待依賴業務消息的到達之後，再進行關聯業務處理，因此，當業務消息量大且不能保證按照設定順序到達時，大量的業務消息不會被重試，業務消息不會因重試而在消息中間件伺服器中的大量堆積，提高了消息中間件伺服器的穩定性。
附圖說明
圖1為本申請背景技術提供的供應鏈單據中心系統的示意圖；
圖2為本申請背景技術提供的業務消息處理方法流程圖；
圖3為本申請實施例一提供的業務消息處理方法流程圖；
圖4為本申請實施例二提供的業務消息處理方法流程圖；
圖5為本申請實施例三提供的業務消息處理裝置的結構示意圖；
圖6為本申請實施例四提供的業務消息處理裝置的結構示意圖。
具體實施方式
在本申請實施例的方案中，第一節點接收並保存當前業務消息，在確定保存的業務消息中不存在該當前業務消息的依賴業務消息時，針對該當前業務消息創建等待任務，將創建的等待任務寫入到等待任務隊列中，並指示至少一個第二節點針對等待任務隊列中的等待任務，在保存的業務消息中存在等待任務等待的依賴業務消息時，利用該依賴業務消息，對創建該等待任務時所針對的 當前業務消息執行關聯業務處理。由於在不存在當前業務消息的依賴業務消息時，不是對該當前業務消息進行回滾及重試操作，而是創建等待任務，等待依賴業務消息的到達之後，再進行關聯業務處理，因此，當業務消息量大且不能保證按照設定順序到達時，大量的業務消息不會被重試，業務消息不會因重試而在消息中間件伺服器中的大量堆積，相對現有技術而言，提高了消息中間件伺服器的穩定性；同時，本申請實施例的方案中，由於第一節點指示至少一個第二節點等待依賴業務消息的到達之後，對等待任務進行處理，也即對等待任務進行異步處理，而不是第一節點來處理，這就使得本申請實施例的方案中第一節點對接收的當前業務消息的處理速度並不遜色於現有技術的處理速度。
此外，本申請實施例中的節點(第二節點、第一節點、分布式定時任務節點)可以是指一個按照分布式協議完成一組邏輯的程序。在具體的工程項目中，這裡的節點通常是指一個作業系統的進程。這裡的第一節點、分布式定時任務節點和至少一個第二節點可以位於同一伺服器上，也可以位於不同的伺服器上。
以下結合說明書附圖對本發明的優選實施例進行說明，應當理解，此處所描述的優選實施例僅用於說明和解釋本發明，並不用於限定本發明。並且在不衝突的情況下，本申請中的實施例及實施例中的特徵可以相互組合。
實施例一
如圖3所示，其為本申請實施例一提供的業務消息處理方法的流程圖，包括以下步驟：
步驟301：第一節點接收當前業務消息；
這裡第一節點接收的可以是來自各業務系統的業務消息，這些業務系統之間通常是具有一定的業務依賴關係；
例如，針對圖1中所示的供應鏈單據中心系統，這裡的第一節點即可為單據中心系統中的第一節點，接收來自交易系統、物流訂單創建系統和倉儲作業 系統產生的交易付款消息、物流訂單創建消息和倉儲訂單創建消息。物流訂單創建系統是在交易系統創建交易訂單之後，在該交易訂單的基礎上創建的物流訂單，而倉儲作業系統在物流訂單創建系統創建的物流訂單的基礎上創建的倉儲作業訂單。
這裡將第一節點當前時刻接收到的業務消息稱為當前業務消息；
步驟302：第一節點將當前業務消息進行保存；
第一節點將接收到的每一當前業務消息進行保存，可得到保存的業務消息；
這裡，還可以對業務消息進行提取處理，提取出業務消息中的業務數據，保存業務數據；
第一節點保存當前業務消息後，不會因該當前業務消息的依賴業務消息不存在而進行刪除；
這裡的當前業務消息，可以為沒有依賴業務消息的當前業務消息，也可以為有依賴業務消息的當前業務消息。
沿用步驟301中所示的例子，若步驟301中接收到的是交易付款消息，該交易付款消息即為沒有依賴業務消息的業務消息；若步驟301中接收到的是倉儲作業訂單創建消息，則該倉儲業務訂單創建消息即為有依賴業務消息的業務消息，因為對倉儲作業訂單創建消息執行關聯業務處理需要使用交易付款消息和物流訂單創建消息。
通常，對於一個業務鏈，因業務鏈中的第一個業務的業務對象不同，可以產生很多串消息；為了區分不同的業務消息，可以對每一業務消息設置一個業務標識，用來唯一標識該業務消息，在該業務消息具有依賴業務消息時，將其依賴的各個業務消息的業務標識也攜帶在這個業務消息中，以便於後續查找；也可以對一串消息設置一個標識，該串消息中的每一業務消息攜帶該標識，以及自身的業務類型(這裡假設該串消息中每一消息的消息類型不同)，在該業務消息具有依賴業務消息時，將其依賴的各個業務消息的業務類型也攜帶在這 個業務消息中，以便於後續查找；
例如：對於一個交易，對應交易付款消息、物流訂單創建消息和倉儲作業訂單創建消息這一串消息；在多個交易下，會產生多個交易付款消息、多個物流訂單創建消息以及多個倉儲作業訂單創建消息，可以對交易付款消息設置一個交易標識，對倉儲作業訂單創建消息設置一個倉儲作業訂單標識，將該倉儲作業訂單標識攜帶在倉儲作業訂單創建消息，並將交易標識和物流訂單標識也攜帶上。或者設置一個交易號，一個交易下產生的交易付款消息、物流訂單創建消息和倉儲作業訂單創建消息均攜帶該交易號，並在交易付款消息中攜帶交易業務類型、在物流訂單創建消息中攜帶物流訂單類型，在倉儲作業訂單創建消息中攜帶倉儲作業訂單類型；
較佳的，當前業務消息中攜帶有第一業務標識，或者攜帶有第一業務標識和至少一個第二業務標識，其中，第一業務標識為該當前業務消息的業務標識，第二業務標識為該當前業務消息的依賴業務消息中包含的業務消息的業務標識；
這裡當前業務消息攜帶的第二業務標識的個數即為該當前業務消息的依賴業務消息中包含的業務消息的個數，後續可以利用該第二業務標識，來查找到該當前業務消息的依賴業務消息。
此外，在上述較佳的方案的基礎上，為了提高後續第二節點查找業務消息的查找速度，可以將業務類型相同的業務消息保存在同一張數據表中，也即較佳的，當前業務消息中還攜帶有第一業務類型，或者第一業務類型和至少一個第二業務類型，其中，所述第一業務類型為該當前業務消息的業務類型，所述第二業務類型為該當前業務消息的依賴業務消息中包含的業務消息的業務類型；
第一節點通過以下方式保存當前業務消息：
第一節點按照接收的當前業務消息包含的第一業務類型，將接收到的每一個當前業務消息添加到所述保存的業務消息中，其中，業務類型相同的業務消 息保存在同一張數據表中；
步驟303：第一節點判斷所述當前業務消息是否具有依賴業務消息；若判斷結果為否，則結束；若判斷結果為是，則執行步驟304；
由於在所述當前業務消息不具有依賴業務消息時，不需要對該當前業務消息進行處理，因此，這裡結束對該當前業務消息處理過程結束，可以針對下一時刻的當前業務消息執行上述步驟301。
沿用步驟301中的例子，假設所述當前業務消息接收到的是交易付款消息，則本步驟303中就結束處理。
具體可以根據當前業務消息是否攜帶第二業務標識來判斷該當前業務消息是否具有依賴業務消息；若攜帶了第二業務標識，則確定具有依賴業務消息，反之，則確定不具有依賴業務消息；在各業務消息的業務類型不相同且該當前業務消息攜帶了第一業務類型時，也可以根據第一業務類型來判斷該當前業務消息是否具有依賴業務消息；若第一業務類型與具有依賴業務消息的業務類型相同，則確定具有依賴業務消息，反之，則確定不具有依賴業務消息；
例如：在當前業務消息為交易付款消息時，其攜帶的業務標識除了交易標識外，沒有攜帶其他業務標識，因此，可以判斷其不具體有依賴業務消息；在當前業務消息為倉儲作業訂單創建消息時，其攜帶的業務標識除了倉儲作業訂單標識外，還有交易標識和物流訂單標識，因此，其具有依賴業務消息。
步驟304：第一節點判斷保存的業務消息中，是否存在該當前業務消息的依賴業務消息；若判斷結果為否，則執行步驟305；若判斷結果為是，則執行步驟306；
具體的，在當前業務消息攜帶有至少一個第二業務標識時，可以針對每一第二業務標識，查找保存的業務消息中是否存在第一業務標識與該第二業務標識相同的業務消息；若均查找到，則確定保存的業務消息中，存在該當前業務消息的依賴業務消息，反之，則確定保存的業務消息中，不存在該當前業務消息的依賴業務消息。
在接收的當前業務消息中攜帶有至少一個第二業務類型，且第一節點將當前業務消息按照攜帶的第一業務類型添加到所述保存的業務消息中時，此時的查找，還可以為針對當前業務消息攜帶的每一個第二業務標識，先查找對應的業務類型與該第二業務標識對應的第二業務類型相同的數據表；然後再在查找到的數據表中，查找包含的第一業務標識與該第二業務標識相同的業務消息。
步驟305：針對該當前業務消息創建等待任務；之後執行步驟307；
其中，該當前業務消息的依賴業務消息包括對該當前業務消息執行關聯業務處理時，需要使用的業務消息；
這裡對該當前業務消息執行關聯業務處理時需要使用的業務消息的個數是根據實際需要來決定的，可以為一個，也可以為多個；
這裡創建的所述等待任務用於等待該當前業務消息的依賴業務消息。
在本步驟305中，還可以為等待任務設置創建時間參數，以方便後續按創建時間的先後順序對等待任務進行處理。
較佳的，在當前業務消息中攜帶有第一業務標識，或者攜帶有第一業務標識和至少一個第二業務標識時，第一節點可以通過以下兩個步驟針對該當前業務消息創建等待任務：
第一步：第一節點將該當前業務消息的第二業務標識以及第一業務標識作為該等待任務的等待條件參數；
在當前業務消息中還攜帶有第一業務類型，或者第一業務類型和至少一個第二業務類型時，所述第一步可具體包括：第一節點將該當前業務消息攜帶的第一業務標識、第一業務類型、第二業務標識和相對應的第二業務類型作為該等待任務的等待條件參數；
第二步：利用該等待條件參數，針對該當前業務消息創建等待任務。
這裡將第一業務標識、第一業務類型、第二業務標識和第二業務類型作為等待條件參數，目的是為了便於後續查找等待任務等待的依賴業務消息。
此外，在創建等待任務時還可以將當前業務消息的擴展數據作為等待任務 的擴展數據參數，方便後續在接收到等待的依賴業務數據後，將當前業務消息中的業務數據、依賴業務消息中的業務數據以及所述擴展業務數據進行關聯業務處理，以滿足不同的業務需求。
步驟306：對該當前業務消息與其依賴的業務消息進行關聯業務處理。
這裡將當前業務消息與其依賴的業務消息進行關聯業務處理本質是根據業務需要，將當前業務消息中的業務數據與其依賴的業務消息中的業務數據進行關聯業務處理。
這裡進行關聯業務處理時，也可以加入該當前業務消息的擴展業務數據，將當前業務消息中的業務數據、依賴業務消息中的業務數據以及所述擴展業務數據進行關聯業務處理，以滿足不同的業務需求。
例如，針對圖1中所示，假設是將倉儲訂單消息，與交易付款消息和物流訂單消息進行關聯業務處理，則此時可以是根據交易付款消息中的交易金額、交易商品的類型、交易商品的重量來計算物流訂單是否需要收取快遞費，以及收取快遞費的金額，並由此來決定倉儲作業訂單的作業優先級。
當然，這裡僅是一個舉例，具體進行何種以及如何進行關聯業務處理是根據業務本身和實際需求進行的，不同的業務和不同的需求進行關聯業務處理的種類和方法並不一定相同，由於這並不是本申請所要解決的技術問題，因此，這裡對此不再進行詳述。
步驟307：第一節點將創建的所述等待任務寫入到等待任務隊列中，並指示至少一個第二節點從等待任務隊列中獲取等待任務，以及針對獲取的每一等待任務，若確定第一節點保存的業務消息中存在該等待任務等待的依賴業務消息，則利用該依賴業務消息，對創建該等待任務時所針對的當前業務消息執行關聯業務處理。
這裡的等待任務隊列可以是第一節點創建的，也可以是其他節點(例如分布式定時任務節點)創建的。
這裡第一節點指示第二節點來對等待任務進行處理，此時的處理是對等待 任務進行異步處理，第一節點繼續進行當前業務消息的接收及保存，隨著時間的推移，等待任務等待的依賴業務消息就可能會被第一節點接收到並添加到保存的業務消息中，此時，在第二節點針對該等待任務進行處理時，就能從當前或最新保存的業務消息中，查詢到依賴業務消息，進而對創建該等待任務時所針對業務消息和查詢到的依賴業務消息進行關聯業務處理。
實施例二
如圖4所示，其為本申請實施例二提供的業務消息處理方法的流程圖，包括以下步驟：
步驟401：第二節點從等待任務隊列中獲取等待任務；之後執行步驟402；
其中，每個等待任務是第一節點接收到當前業務消息，並確定保存的業務消息中，不存在該當前業務消息的依賴業務消息時，針對該當前業務消息創建的等待任務；
該當前業務消息的依賴業務消息包括對該當前業務消息執行關聯業務處理時，需要使用的業務消息；
創建的所述等待任務用於等待該當前業務消息的依賴業務消息；
所述第一節點將接收到的每一個當前業務消息添加到所述保存的業務消息中；
關於等待任務的創建在實施例一中已經進行了詳細的描述，這裡不再贅述。
所述第二節點獲取的等待任務，可以是第二節點從第一節點中主動獲取等待任務，也可以是第二節點通過分布式定時任務節點定時從第一節點中獲取的等待任務；
上述分布式定時任務節點可以對第一節點創建的等待任務隊列定期進行掃描，每次從所述等待任務隊列中取出一批等待任務，將取出的等待任務分發給多個第二節點。掃描的時間間隔可以根據業務系統的業務消息最大延遲時長 來確定，例如，將時間間隔設置為業務消息最大延時時長的設定倍數；針對電子商務系統而言，通常業務消息的延遲都在1秒之內，掃描的時間間隔可以設置為15秒。
這裡的第二節點獲取等待任務以及後續對等待任務進行處理的過程和第一節點接收當前業務消息以及後續執行的保存業務消息，創建等待任務等一系列處理過程，可以是相互獨立的；第二節點和第一節點各自進行自身的處理過程，兩者可以是同時進行的，也可以不是同時進行的；
步驟402：第二節點判斷獲取的等待任務中是否還有等待任務，若是，則執行步驟403；若否，則結束。
步驟403：第二節點從獲取的等待任務中取出一個等待任務，之後執行步驟404；
在消息量大時，創建的等待任務較多，這裡第二節點獲取的等待任務的個數通常為多個，因此，需要從獲取的等待任務中逐一取出每個等待任務，針對該取出的等待任務，執行步驟404至步驟406；
這裡本次取出的等待任務通常是與上一次取出的等待任務不相同的等待任務，除非只剩下一個等待任務。
考慮到一條業務鏈上的各業務通常是順次發生的，業務消息是按照其對應的業務的實際發生時間產生的，該業務消息的依賴業務消息也是按照其對應的業務的實際發生時間產生的，並且第一節點是為先到達的業務消息先創建等待任務，這就使得先創建的等待任務等待的依賴業務消息到達第一節點的時間往往，早於後創建的等待任務等待的依賴業務消息的到達第一節點的時間；為了儘快對等待任務進行處理，將等待任務等待的依賴業務消息與創建該等待任務時所針對的當前業務消息進行關聯業務處理，需要對先創建的等待任務先進行處理，較佳的，所述等待任務具有創建時間參數；此時，本步驟303具體包括：
所述第二節點按照創建時間參數指示的創建時間由先到後的順序，從獲取的等待任務中取出一個等待任務。
步驟404：判斷第一節點保存的業務消息中，是否存在取出的等待任務等待的依賴業務消息；若是，則執行步驟405；若否，則執行步驟406；
這裡可以根據創建等待任務時設置的等待條件參數來判斷第一節點保存的業務消息中，是否存在取出的等待任務等待的依賴業務消息。等待條件參數可被設置為依賴業務消息的業務標識及業務類型等信息。
在當前業務消息中攜帶有攜帶有第一業務標識和至少一個第二業務標識，創建的所述等待任務的等待條件參數包含該當前業務消息攜帶的第二業務標識時，在本步驟404中，第二節點具體可以通過以下兩個步驟確定第一節點保存的業務消息中，是否存在該等待任務等待的依賴業務消息：
步驟1)：在第一節點保存的業務消息中，針對該等待任務的等待條件參數中包含的每一第二業務標識，查找包含的第一業務標識與該第二業務標識相同的業務消息；
步驟2)：若針對該等待任務的等待條件參數中包含的每一第二業務標識，均查找到包含的第一業務標識與該第二業務標識相同的業務消息，則確定保存的業務消息中存在該等待任務等待的依賴業務消息；反之，則確定保存的業務消息中不存在該等待任務等待的依賴業務消息。
較佳的，若當前業務消息中還攜帶有第一業務類型和第二業務類型，所述等待條件參數還包含該當前業務消息攜帶的第一業務類型和第二業務類型；所述保存的業務消息中，攜帶的第一業務類型相同的業務消息保存在同一張數據表中時，上述步驟1)，具體包括：
查找對應的業務類型與該等待任務的等待條件參數中包含的第二業務類型相同的數據表；
在查找到的數據表中，查找包含的第一業務標識與該等待任務的等待條件參數中包含的第二業務標識相同的業務消息。
步驟405：第二節點利用該依賴業務消息，對創建該等待任務時所針對的當前業務消息執行關聯業務處理，並刪除該等待任務；之後跳轉至步驟402；
步驟406：第二節點將該等待任務存入獲取的等待任務中；之後跳轉至步驟403。
由於這裡第一節點保存的業務消息不存在取出的等待任務的依賴業務消息，因此，需要將該等待任務重新放回獲得的等待任務中，獲取的等待任務中必定還有等待任務，因此，不用跳轉至步驟402，而是跳轉至步驟403。
在上述實施例一及實施例二的方案中，所述當前業務消息可以但不限定為物流消息。這裡的物流消息是廣義的，包括與物流相關的各種信息，這些信息將物流過程中的訂貨、收貨、庫存管理、發貨、配送及回收等職能有機地聯繫在一起，使整個物流活動能夠順利進行。例如，圖1中所示的供應鏈單據中心系統中產生的交易付款消息、物流訂單創建消息和倉儲作業訂單創建消息均與物流相關，均可稱為物流信息。
在當前業務消息為物流消息時，本實施例一的方案即為應用在物流業務場景下的物流消息處理方法，在接收到一個物流消息時，由於在該物流消息的依賴業務消息沒有到達時，不是對該物流消息進行回滾及重試操作，而是創建等待任務，等待該物流消息的依賴業務消息的到達之後，再對該物流消息執行關聯業務處理，因此，當物流消息量大且不能保證按照設定順序到達時，大量的物流消息不會被重試，物流消息不會因重試而在消息中間件伺服器中的大量堆積，提高了消息中間件伺服器的穩定性。
例如，針對圖1中所示的供應鏈單據中心系統，根據本申請實施例一的方案，假設在t1時刻，第一節點接收到了業務標識為A_3的倉儲作業訂單創建消息，該倉儲作業訂單創建消息中攜帶有其依賴的交易付款消息和物流訂單創建消息的物流業務標識為A_2和A_1，此時，確定保存的物流消息中沒有存儲業務標識為A_2和A_1的物流消息，保存接收的該業務標識為A_3的倉儲作業訂單創建消息，並創建用於等待業務標識為A_2和A_1的物流消息的等待任務T1，寫入等待任務隊列；
在t2時刻，第一節點接收到業務標識為B_2的物流訂單創建消息並保存 到物流消息中；
在t3時刻，第一節點接收到業務標識為B_1的交易付款消息並保存到物流消息中；
在t4時刻，第一節點接收到業務標識為A_2的物流訂單創建消息並保存到物流消息中；
在t5時刻，第一節點接收到業務標識為A_1的物流訂單創建消息並保存到物流消息中；
在t6時刻，第一節點接收到業務標識為B_3的倉儲作業訂單創建消息，該倉儲作業訂單創建消息還攜帶了業務標識B_1和B_2，此時，第一節點確定保存的物流消息中存在業務標識B_1和B_2的交易付款消息和物流訂單創建消息；利用該業務標識B_1和B_2的交易付款消息和物流訂單創建消息，對業務標識為B_3的倉儲作業訂單創建消息執行業務關聯處理；
與此同時，在t6時刻，第二節點從等待任務隊列中獲取T1任務並進行處理，查找物流消息中存在業務標識為A_2和A_1的交易付款消息和物流訂單創建消息；利用查找到的消息，對業務標識為A_3的倉儲作業訂單創建消息執行業務關聯處理；
由上述過程可見，相對於背景技術中的按照實際業務發生順序執行關聯處理的業務消息處理方案，t1、t2、t4、t6時刻接收到的業務消息均沒有向相應的消息中間件伺服器發送處理失敗稍後重試消息，相應的消息中間件伺服器既不需要接收該失敗重試消息，也不需要將該消息繼續保存(以便稍後的重新發送)，這就使得大量的消息不會被堆積在相應的消息中間件伺服器中，消息中間件伺服器只需要執行轉發任務即可，進而提高了消息中間件伺服器的穩定性。
實施例三
與實施例一相對應的，本申請實施例三提供一種業務消息處理裝置，該業 務消息處理裝置具有上述實施例一中的第一節點的功能，如圖5所示，其為本申請實施例三提供的業務消息處理裝置的結構示意圖，包括：接收模塊51、保存模塊52、創建模塊53和寫入模塊54；其中：
接收模塊51，用於接收當前業務消息；
保存模塊52，用於保存接收的當前業務消息；
創建模塊53，用於若確定保存的業務消息中不存在該當前業務消息的依賴業務消息，則針對該當前業務消息創建等待任務，其中，該當前業務消息的依賴業務消息包括對該當前業務消息執行關聯業務處理時，需要使用的業務消息，創建的所述等待任務用於等待該當前業務消息的依賴業務消息；
寫入模塊54，用於將創建的所述等待任務寫入到等待任務隊列中，並指示至少一個第二節點從等待任務隊列中獲取等待任務，以及針對獲取的每一等待任務，若確定第一節點保存的業務消息中存在該等待任務等待的依賴業務消息，則利用該依賴業務消息，對創建該等待任務時所針對的當前業務消息執行關聯業務處理。
較佳的，所述當前業務消息為物流消息。
較佳的，當前業務消息中攜帶有第一業務標識，或者攜帶有第一業務標識和至少一個第二業務標識，其中，第一業務標識為該當前業務消息的業務標識，第二業務標識為該當前業務消息的依賴業務消息中包含的業務消息的業務標識；
所述創建模塊53，具體用於將該當前業務消息攜帶的第二業務標識作為該等待任務的等待條件參數；利用該等待條件參數，針對該當前業務消息創建等待任務。
較佳的，當前業務消息中還攜帶有第一業務類型，或者第一業務類型和至少一個第二業務類型，其中，第一業務類型為該當前業務消息的業務類型，第二業務類型為該當前業務消息的依賴業務消息中包含的業務消息的業務類型；
所述保存模塊52，具體用於按照攜帶的第一業務類型，將接收到的每一個 當前業務消息添加到所述保存的業務消息中，其中，業務類型相同的業務消息保存在同一張數據表中；
所述創建模塊53，具體用於將該當前業務消息攜帶的第二業務標識和攜帶的第二業務類型作為該等待任務的等待條件參數。
由於該業務消息處理裝置所解決問題的原理與前述實施例一及實施例二的業務消息處理方法相似，因此該業務消息處理裝置的實施可以參見前述實施例一及實施例二的業務消息處理方法的實施，重複之處不再贅述。
實施例四
與實施例二相對應的，本申請實施例四提供一種業務消息處理裝置，該業務消息處理裝置具有上述實施例二中的第二節點的功能，如圖6所示，其為本申請實施例四提供的業務消息處理裝置的結構示意圖，包括：，包括：獲取模塊61和執行模塊62；其中：
獲取模塊61，用於從等待任務隊列中獲取等待任務，其中，每個等待任務是第一節點接收到當前業務消息，並確定保存的業務消息中，不存在該當前業務消息的依賴業務消息時，針對該當前業務消息創建的等待任務，該當前業務消息的依賴業務消息包括對該當前業務消息執行關聯業務處理時，需要使用的業務消息，創建的所述等待任務用於等待該當前業務消息的依賴業務消息，所述第一節點將接收到的每一個當前業務消息添加到所述保存的業務消息中；
執行模塊62，用於針對獲取的每一等待任務，執行以下操作：若確定第一節點保存的業務消息中，存在該等待任務等待的依賴業務消息，則利用該依賴業務消息，對創建該等待任務時所針對的當前業務消息執行關聯業務處理，並刪除該等待任務。
較佳的，所述當前業務消息為物流消息。
較佳的，所述等待任務具有創建時間參數；
所述執行模塊62，具體用於按照創建時間參數指示的創建時間由先到後的 順序，針對獲取的每一等待任務，執行所述操作。
較佳的，當前業務消息中攜帶有第一業務標識和至少一個第二業務標識，其中，第一業務標識為該當前業務消息的業務標識，第二業務標識為該當前業務消息的依賴業務消息中包含的業務消息的業務標識；創建的所述等待任務具有等待條件參數，該等待條件參數包含該當前業務消息攜帶的第二業務標識；
所述執行模塊62，具體用於在第一節點保存的業務消息中，針對該等待任務的等待條件參數中包含的每一第二業務標識，查找攜帶的第一業務標識與該第二業務標識相同的業務消息；若針對每一第二業務標識，均查找到包含的第一業務標識與該第二業務標識相同的業務消息，則確定保存的業務消息中存在該等待任務等待的依賴業務消息。
較佳的，當前業務消息中還攜帶有第一業務類型和至少一個第二業務類型，其中，第一業務類型為該當前業務消息的業務類型，第二業務類型為該當前業務消息的依賴業務消息中包含的業務消息的業務類型；所述至少一個第二業務標識與所述至少一個第二業務類型相對應，所述等待條件參數還包含該當前業務消息攜帶的第二業務類型；所述保存的業務消息中，攜帶的第一業務類型相同的業務消息保存在同一張數據表中；
所述執行模塊62，具體用於在第一節點保存的業務消息中，針對該等待任務的等待條件參數中包含的每一第二業務標識，執行以下操作：查找對應的業務類型與該第二業務標識對應的第二業務類型相同的數據表；在查找到的數據表中，查找包含的第一業務標識與該第二業務標識相同的業務消息。
由於該業務消息處理裝置所解決問題的原理與前述實施例一及實施例二的業務消息處理方法相似，因此該業務消息處理裝置的實施可以參見前述實施例一及實施例二的業務消息處理方法的實施，重複之處不再贅述。
通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到本發明實施例可以通過硬體實現，也可以藉助軟體加必要的通用硬體平臺的方式實現。基於這樣的理解，本發明實施例的技術方案可以以軟體產品的形式體現出 來，該軟體產品可以存儲在一個非易失性存儲介質(可以是CD-ROM，U盤，移動硬碟等)中，包括若干指令用以使得一臺計算機設備(可以是個人計算機，伺服器，或者網絡設備等)執行本發明各個實施例所述的方法。
本領域技術人員可以理解附圖只是一個優選實施例的示意圖，附圖中的模塊或流程並不一定是實施本發明所必須的。
本領域技術人員可以理解實施例中終端中的模塊可以按照實施例描述進行分布於實施例的終端中，也可以進行相應變化位於不同於本實施例的一個或多個終端中。上述實施例的模塊可以合併為一個模塊，也可以進一步拆分成多個子模塊。
上述本發明實施例序號僅僅為了描述，不代表實施例的優劣。
顯然，本領域的技術人員可以對本發明進行各種改動和變型而不脫離本發明的精神和範圍。這樣，倘若本發明的這些修改和變型屬於本發明權利要求及其等同技術的範圍之內，則本發明也意圖包含這些改動和變型在內。