一種消息發送方法及裝置與流程
2023-05-31 17:46:21 2

本發明實施例涉及軟體技術領域,尤其涉及一種消息發送方法及裝置。
背景技術:
現有的消息通知系統一般採用一個隊列緩衝區來存放從通知庫中撈取的數據,然後將隊列緩衝區的數據發送到對應的客戶端。該方法實現簡單,但緩衝區通過使用隊列來實現,數據到達時要在隊列尾部分配內存,數據發送完成時需要在隊列頭部釋放內存。如果系統承載著較大的數據流,將面臨著較大的內存操作導致的開銷壓力。同時,在多線程環境下,對隊列中的數據進行處理將面臨著頻繁的加解鎖操作,極大地影響系統的TPS。
技術實現要素:
本發明實施例提供一種消息發送方法及裝置,用以提高消息發送的效率,降低系統開銷。
本發明實施例提供的一種消息發送方法,包括:
確定第二消息循環隊列存儲的消息的數量;
若所述第二消息循環隊列存儲的消息的數量未超過第一閾值,則獲取第一消息循環隊列存儲的待發送的消息,並存儲至所述第二消息循環隊列中;
對所述第二消息循環隊列中的待發送的消息進行處理,並將處理之後的待發送的消息發送至客戶端。
優選地,在將處理之後的待發送的消息發送至客戶端之後,還包括:
若所述客戶端反饋所述待發送的消息未發送成功,則將所述未發送成功的消息存儲至第三消息循環隊列中;
將所述第三消息循環隊列中的未發送成功的消息發送至所述客戶端。
優選地,將所述第三消息循環隊列中的未發送成功的消息發送至所述客戶端之後,還包括:
若所述未發送成功的消息的發送次數大於第二閾值,則通知伺服器所述未發送成功的消息發送失敗。
優選地,在將所述未發送成功的消息存儲至第三消息循環隊列中之前,還包括:
若所述第三消息循環隊列中的未發送成功的消息的數量超過第三閾值,則通知伺服器所述待發送的消息未發送成功,並在設定時間之後從所述伺服器中重新撈取所述未發送成功的消息至所述第一消息循環隊列。
優選地,還包括:
確定所述第一消息循環隊列、第二消息循環隊列和第三消息循環隊列中存儲的消息的總量是否小於第四閾值;
若是,則從所述伺服器中撈取待發送的消息;
將從伺服器中撈取的待發送的消息按序存儲至所述第一消息循環隊列的尾部。
優選地,還包括:
若所述客戶端反饋消息發送成功,則將消息發送成功的狀態通知給伺服器,以使所述發送成功的消息不被撈取。
優選地,還包括:
若所述第一消息循環隊列存儲的待發送的消息超過第五閾值,將從所述伺服器撈取的消息丟棄。
相應地,本發明實施例還提供了一種消息發送裝置,包括:
確定單元,用於確定第二消息循環隊列存儲的消息的數量;
獲取單元,用於若所述第二消息循環隊列存儲的消息的數量未超過第一閾值,則獲取第一消息循環隊列存儲的待發送的消息,並存儲至所述第二消息循環隊列中;
處理單元,用於對所述第二消息循環隊列中的待發送的消息進行處理,並將處理之後的待發送的消息發送至客戶端。
優選地,所述處理單元還用於:
在將處理之後的待發送的消息發送至客戶端之後,若所述客戶端反饋所述待發送的消息未發送成功,則將所述未發送成功的消息存儲至第三消息循環隊列中;
將所述第三消息循環隊列中的未發送成功的消息發送至所述客戶端。
優選地,所述處理單元還用於:
將所述第三消息循環隊列中的未發送成功的消息發送至所述客戶端之後,若所述未發送成功的消息的發送次數大於第二閾值,則通知伺服器所述未發送成功的消息發送失敗。
優選地,所述處理單元還用於:
在將所述未發送成功的消息存儲至第三消息循環隊列中之前,若所述第三消息循環隊列中的未發送成功的消息的數量超過第三閾值,則通知伺服器所述待發送的消息未發送成功,並在設定時間之後從所述伺服器中重新撈取所述未發送成功的消息至所述第一消息循環隊列。
優選地,所述確定單元,還用於確定所述第一消息循環隊列、第二消息循環隊列和第三消息循環隊列中存儲的消息的總量是否小於第四閾值;
所述獲取單元,還用於若所述第一消息循環隊列、第二消息循環隊列和第三消息循環隊列中存儲的消息的總量小於第四閾值,則從所述伺服器中撈取待發送的消息;並將從伺服器中撈取的待發送的消息按序存儲至所述第一消息循環隊列的尾部。
優選地,所述處理單元還用於:
若所述客戶端反饋消息發送成功,則將消息發送成功的狀態通知給伺服器,以使所述發送成功的消息不被撈取。
優選地,所述處理單元還用於:
若所述第一消息循環隊列存儲的待發送的消息超過第五閾值,將從所述伺服器撈取的消息丟棄。
本發明實施例表明,通過確定第二消息循環隊列存儲的消息的數量,若所述第二消息循環隊列存儲的消息的數量未超過第一閾值,則獲取第一消息循環隊列存儲的待發送的消息,並存儲至所述第二消息循環隊列中,對所述第二消息循環隊列中的待發送的消息進行處理,並將處理之後的待發送的消息發送至客戶端。通過多個消息循環隊列分別存儲不同的消息,避免了採用一個隊列緩衝區頻繁的進行內存分配與釋放的問題,從而提高消息發送效率,降低系統開銷。
附圖說明
為了更清楚地說明本發明實施例中的技術方案,下面將對實施例描述中所需要使用的附圖作簡要介紹,顯而易見地,下面描述中的附圖僅僅是本發明的一些實施例,對於本領域的普通技術人員來講,在不付出創造性勞動的前提下,還可以根據這些附圖獲得其他的附圖。
圖1為本發明實施例提供的一種系統架構的結構示意圖;
圖2為本發明實施例提供的一種消息發送方法的流程示意圖;
圖3為本發明實施例提供的一種系統部署的示意圖;
圖4為本發明實施例提供的一種消息發送方法的流程示意圖;
圖5為本發明實施例提供的一種消息發送方法的流程示意圖;
圖6為本發明實施例提供的一種消息發送方法的流程示意圖;
圖7為本發明實施例提供的一種消息發送裝置的結構示意圖。
具體實施方式
為了使本發明的目的、技術方案和優點更加清楚,下面將結合附圖對本發明作進一步地詳細描述,顯然,所描述的實施例僅僅是本發明一部分實施例,而不是全部的實施例。基於本發明中的實施例,本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其它實施例,都屬於本發明保護的範圍。
圖1示例性的示出了本發明實施例提供的一種系統架構,該系統架構適用於運行本發明實施例中提供的一種消息發送方法。該系統架構包括伺服器101、客戶端102、消息撈取裝置103、消息處理髮送裝置104和消息存儲轉發裝置105。該伺服器101用於提供待發送的消息,消息撈取裝置103用於從伺服器中撈取消息並存儲在循環隊列1中,消息處理髮送裝置104用於從循環隊列1中獲取待發送消息存儲在循環隊列2中,並對循環隊列2中的消息進行處理和發送至客戶端102中,消息存儲轉發裝置105用於發送消息處理髮送裝置104未發送成功的消息。
基於上述描述,圖2示出了本發明實施例提供的一種消息發送的流程,該流程可以由消息發送裝置執行。
如圖2所示,該方法流程具體步驟包括:
步驟201,確定第二消息循環隊列存儲的消息的數量。
步驟202,若所述第二消息循環隊列存儲的消息的數量未超過第一閾值,則獲取第一消息循環隊列存儲的待發送的消息,並存儲至所述第二消息循環隊列中。
步驟203,對所述第二消息循環隊列中的待發送的消息進行處理,並將處理之後的待發送的消息發送至客戶端。
在本發明實施例中,在對第二消息循環隊列中的待發送的消息進行處理之前,需要確定第二消息循環隊列存儲的消息的數量,若該第二消息循環隊列存儲的消息的數量未超過第一閾值,就可以獲取第一消息循環隊列存儲的待發送的消息,並將該獲取的待發送的消息存儲至第二消息循環隊列中,然後對該第二消息循環隊列中的待發送的消息進行處理,並將處理之後的待發送的消息發送至客戶端。其中,該第一消息循環隊列可以為上述圖1中的循環隊列1,該第二消息循環隊列可以為上述圖1中的循環隊列2,第一閾值可以依據經驗進行設定。
舉例來說,上述消息處理髮送裝置從循環隊列1中獲取消息並保存至循環隊列2中,同時對該消息進行處理和發送。具體的,當循環隊列1不為空時,如果循環隊列2未滿,則將循環隊列1的頭部獲取的消息保存至循環隊列2中,如果循環隊列2已滿,則繼續查詢循環隊列2是否已滿。在對循環隊列2中的消息進行處理時,可以是內部欄位數據更新、形變等處理方式。特別地,此時對循環隊列2中的消息進行處理與循環隊列1的消息接收隔離開來,無需進行加解鎖操作。
在上述步驟203中將處理之後的待發送的消息發送至客戶端之後,若客戶端反饋該待發送的消息未發送成功,則將該未發送成功的消息存儲至第三消息循環隊列中,並將該第三消息循環隊列中未發送成功的消息發送至客戶端。該待發送的消息未發送成功可以表示為發送失敗或發送超時。若該客戶端反饋消息發送成功,則將消息發送成功的狀態通知給伺服器,以使該發送成的消息不被撈取。通過第三消息循環隊列來存儲未發送成功的消息,可以預防因發送失敗或超時的消息的積壓導致緩衝區內數據處理的低效的問題。
進一步地,在將第三消息循環隊列中的未發送成功的消息發送至客戶端之後,若該未發送成功的消息的發送次數大於第二閾值,則通知伺服器該未發送成功的消息發送失敗。該第二閾值可以依據經驗進行設置,該第三消息循環隊列可以是圖1中的循環隊列3。
具體的,在循環隊列3不為空時,從循環隊列3中獲取消息進行發送,當消息發送次數超過配置參數規定的次數時,更新消息發送失敗至伺服器,否則就是重新發送消息,直至消息發送次數超過配置參數規定的次數。
優選地,在上述將未發送成功的消息存儲至第三消息循環隊列中之前,若第三消息循環隊列中的未發送成功的消息的數量超過第三閾值,則通知伺服器待發送的消息未發送成功,並在設定時間之後從伺服器中重新撈取該未發送成功的消息至該第一消息循環隊列,避免由於第三消息循環隊列滿而引起的消息丟失。
為了能更精確的從伺服器中撈取待發送的消息,還需要確定上述第一消息循環隊列、第二消息循環隊列和第三消息循環隊列中存儲的消息的總量是否小於第四閾值,若是,則從伺服器中撈取待發送的消息,否則,說明消息總量過多,無法撈取新的待發送的消息。在撈取之後,將從伺服器中撈取的待發送的消息按序存儲至第一消息循環隊列的尾部。
進一步地,在從伺服器中撈取待發送的消息時,若干第一消息循環隊列中存儲的待發送的消息數量過滿,也就是說若上述第一消息循環隊列存儲的待發送的消息超過第五閾值,則將從伺服器撈取的消息丟棄。該第五閾值依據經驗設置。
為了更好的解釋本發明實施例,下面將結合圖1、圖3、圖4、圖5和圖6來,描述本發明實施例中消息發送的具體流程。
圖3示例性的示出了本發明實施例適用的系統部署的結構,消息撈取裝置中的消息撈取線程從伺服器撈取消息存儲到循環隊列1中,消息處理髮送裝置中的消息處理髮送線程從循環隊列1中獲取消息,並保存至循環隊列2中,對該循環隊列2中的消息進行處理,然後通過Internet發送至客戶端。如果消息未發送成功,則保存至循環隊列3中,消息存儲轉發裝置中的消息存儲轉發線程對循環隊列3中的消息進行發送。
具體的,消息撈取裝置所執行的流程如圖4所示,該流程具體包括:
步驟401,從配置參數中獲取撈取消息觸發值n。
步驟402,判斷服務是否運行,若是,則轉入步驟403,若否,則轉入步驟408。
步驟403,判斷三個循環隊列消息總量是否小於n,若是則轉入步驟404,若否,則重新執行步驟403。
步驟404,從伺服器中撈取m條消息。
步驟405,判斷m是否大於0,若是,則轉入步驟406,若否,則轉入步驟409。
步驟406,判斷循環隊列1是否未滿,若是,則轉入步驟407,若否,則轉入步驟410。
步驟407,將消息保存至循環隊列1中。
步驟408,結束服務。
步驟409,線程休眠。
步驟410,將消息丟棄。
上述消息撈取裝置主要功能為從伺服器獲取消息數據並保存至循環隊列1中,具體的,消息撈取線程啟動,讀取配置參數,獲得線程睡眠時間片大小,撈取消息觸發值大小等,然後在主服務保持運行的情況下,分別獲取3個循環隊列的剩餘消息數,其總量小於撈取消息觸發值時,觸發消息撈取動作。從伺服器撈取消息,如果撈取不到消息,則線程睡眠一段時間後重新進入步驟b;如果撈取到消息,則將消息按序插入到循環隊列1中。在將消息保存到循環隊列1中時,如果配置的循環隊列1長度較短或撈取到的通知消息較多導致循環隊列1被塞滿,則將消息丟棄。由於伺服器中消息狀態未被設置為成功或失敗,後續這些消息依然會被重新撈取,因此該操作並不會導致消息真正丟失。
消息處理髮送裝置所執行的流程如圖5所示,該流程具體包括:
步驟501,啟動消息處理髮送線程。
步驟502,判斷服務是否運行,若是,則轉入步驟503,否則,轉入步驟511。
步驟503,判斷循環隊列1是否不為空,若是,則轉入步驟504,若否,則轉入步驟512。
步驟504,判斷循環隊列2是否未滿,若是,則轉入步驟505,若否,則重新執行步驟504。
步驟505,從循環隊列1中的頭部獲取消息並保存至循環隊列2的尾部。
步驟506,對最新獲取的消息進行處理。
步驟507,將處理後的消息發送至客戶端。
步驟508,判斷消息發送是否未成功,若是,則轉入步驟509,若否,則轉入步驟513。
步驟509,判斷循環隊列3中未用長度是否大於15%,若是,則轉入步驟510,若否,則轉入步驟514。
步驟510,將該條消息存儲至循環隊列3。
步驟511,結束。
步驟512,等待被喚醒或等待超時。
步驟513,更新消息投遞狀態至伺服器。
步驟514,通知伺服器更新該消息時間戳以便後續撈取。
該消息處理髮送裝置主要功能為從循環隊列1中獲取消息數據並保存至循環隊列2中,同時對該消息進行處理和發送,具體的,消息處理髮送線程啟動,讀取配置參數,獲得線程超時等待時間片大小等參數信息。在主服務保持運行的情況下,如果循環隊列1為空,則線程阻塞等待被喚醒或等待超時後繼續查詢循環隊列1是否為空,當循環隊列1不為空時,如果循環隊列2未滿,則將循環隊列1頭部獲取的消息保存到循環隊列2中。如果循環隊列2已滿,則繼續查詢循環隊列2是否已滿,對最新獲取的消息進行處理,如內部欄位數據更新、形變等等。將處理後的消息發送至客戶端,如果發送成功,則更新消息投遞狀態至伺服器,後續該條消息將不再被撈取。如果發送失敗或超時,此時若循環隊列3的未用長度不足總長度的10%,則直接通知伺服器,設定此消息在未來幾分鐘之後被再次撈取,從而避免由於循環隊列3滿而引起的消息丟失。否則,將該條消息存儲至循環隊列3。
消息存儲轉發裝置所執行的流程如圖6所示,該流程具體包括:
步驟601,從配置參數中獲取消息發送嘗試次數T。
步驟602,判斷服務是否運行,若是,則轉入步驟603,若否,則轉入步驟609。
步驟603,判斷循環隊列3是否不為空,若是,則轉入步驟604,若否,則轉入步驟610。
步驟604,從循環隊列3中獲取消息進行處理,並令t=T。
步驟605,判斷t是否大於0,若是,則轉入步驟606,若否,則轉入步驟611。
步驟606,將處理後的消息發送至客戶端。
步驟607,判斷消息發送是否未成功,若是,則轉入步驟608,若否,則轉入步驟612。
步驟608,令t=t-1。
步驟609,結束。
步驟610,等待被喚醒或等待超時。
步驟611,更新消息投遞狀態至伺服器。
步驟612,更新消息投遞狀態至伺服器。
該消息存儲轉發裝置主要功能為將消息處理髮送裝置投遞失敗或超時的消息進行存儲轉發,具體的,消息存儲轉發線程啟動,讀取配置參數,獲得消息重複發送次數等參數信息。在主服務保持運行的情況下,如果循環隊列3為空,則線程阻塞等待被喚醒或等待超時後繼續查詢循環隊列3是否為空,當循環隊列3不為空時,從循環隊列3獲取消息等待發送。當消息發送次數超過配置參數規定的次數時,更新消息發送失敗至伺服器,否則,將獲取的消息進行發送。重複這個過程,直至發送次數滿更新消息發送失敗至伺服器,或發送成功後更新消息發送成功至伺服器。
本發明實施例表明,通過確定第二消息循環隊列存儲的消息的數量,若所述第二消息循環隊列存儲的消息的數量未超過第一閾值,則獲取第一消息循環隊列存儲的待發送的消息,並存儲至所述第二消息循環隊列中,對所述第二消息循環隊列中的待發送的消息進行處理,並將處理之後的待發送的消息發送至客戶端。通過多個消息循環隊列分別存儲不同的消息,避免了採用一個隊列緩衝區頻繁的進行內存分配與釋放的問題,從而提高消息發送效率,降低系統開銷。
基於相同的技術構思,圖7示出了本發明實施例提供的一種消息發送裝置的結構,該裝置可以執行消息發送方法的流程。
如圖7所示,該裝置具體包括:
確定單元701,用於確定第二消息循環隊列存儲的消息的數量;
獲取單元702,用於若所述第二消息循環隊列存儲的消息的數量未超過第一閾值,則獲取第一消息循環隊列存儲的待發送的消息,並存儲至所述第二消息循環隊列中;
處理單元703,用於對所述第二消息循環隊列中的待發送的消息進行處理,並將處理之後的待發送的消息發送至客戶端。
優選地,所述處理單元703還用於:
在將處理之後的待發送的消息發送至客戶端之後,若所述客戶端反饋所述待發送的消息未發送成功,則將所述未發送成功的消息存儲至第三消息循環隊列中;
將所述第三消息循環隊列中的未發送成功的消息發送至所述客戶端。
優選地,所述處理單元703還用於:
將所述第三消息循環隊列中的未發送成功的消息發送至所述客戶端之後,若所述未發送成功的消息的發送次數大於第二閾值,則通知伺服器所述未發送成功的消息發送失敗。
優選地,所述處理單元703還用於:
在將所述未發送成功的消息存儲至第三消息循環隊列中之前,若所述第三消息循環隊列中的未發送成功的消息的數量超過第三閾值,則通知伺服器所述待發送的消息未發送成功,並在設定時間之後從所述伺服器中重新撈取所述未發送成功的消息至所述第一消息循環隊列。
優選地,所述確定單元701,還用於確定所述第一消息循環隊列、第二消息循環隊列和第三消息循環隊列中存儲的消息的總量是否小於第四閾值;
所述獲取單元702,還用於若所述第一消息循環隊列、第二消息循環隊列和第三消息循環隊列中存儲的消息的總量小於第四閾值,則從所述伺服器中撈取待發送的消息;並將從伺服器中撈取的待發送的消息按序存儲至所述第一消息循環隊列的尾部。
優選地,所述處理單元703還用於:
若所述客戶端反饋消息發送成功,則將消息發送成功的狀態通知給伺服器,以使所述發送成功的消息不被撈取。
優選地,所述處理單元703還用於:
若所述第一消息循環隊列存儲的待發送的消息超過第五閾值,將從所述伺服器撈取的消息丟棄。
本發明是參照根據本發明實施例的方法、設備(系統)、和電腦程式產品的流程圖和/或方框圖來描述的。應理解可由電腦程式指令實現流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合。可提供這些電腦程式指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數據處理設備的處理器以產生一個機器,使得通過計算機或其他可編程數據處理設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。
這些電腦程式指令也可存儲在能引導計算機或其他可編程數據處理設備以特定方式工作的計算機可讀存儲器中,使得存儲在該計算機可讀存儲器中的指令產生包括指令裝置的製造品,該指令裝置實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。
這些電腦程式指令也可裝載到計算機或其他可編程數據處理設備上,使得在計算機或其他可編程設備上執行一系列操作步驟以產生計算機實現的處理,從而在計算機或其他可編程設備上執行的指令提供用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。
儘管已描述了本發明的優選實施例,但本領域內的技術人員一旦得知了基本創造性概念,則可對這些實施例作出另外的變更和修改。所以,所附權利要求意欲解釋為包括優選實施例以及落入本發明範圍的所有變更和修改。
顯然,本領域的技術人員可以對本發明進行各種改動和變型而不脫離本發明的精神和範圍。這樣,倘若本發明的這些修改和變型屬於本發明權利要求及其等同技術的範圍之內,則本發明也意圖包含這些改動和變型在內。