如何保證消息不丟失？

在客戶端與服務器的交互過程當中，特別是多個客戶端須要與服務器同步時，例如遊戲同屏，要保證客戶端A到客戶端B的消息成功發送。可是因爲網絡的複雜狀況，可能會出現如下狀況：

1）服務器崩潰，msg:N包未發出
2）網絡抖動，msg:N包被網絡設備丟棄

 

通常狀況下，當A向服務器發送一個信息以後，只能說明A發送成功了，可是不能保證服務器必定接收到了數據。在某些狀況下，可能會出現上述丟包的緣由。如何保證消息不丟失呢？

 

能夠採起如下方法：

1，消息確認當A向服務器發送一條消息後，等待服務器返回處理請求成功的確認，即Ack

2,服務器接收A發送的消息後，要發送給B。

3，B，接收到消息到給服務器發送一個確認的Ack.

 

可是使用這種方法也可能會有問題，好比發送端可能由於上述緣由接收不到Ack的確認消息，那該如何保證消息不丟失呢？這就須要藉助於超時和重傳機制了。

在發送端（好比A）若是發送出去消息以後，在一段時間內沒有收到消息的回覆，則爲從新發送一次消息。因此發送端會維護一個發送後等待Ack的隊列，並配合超時機制，以記錄哪些消息沒有收到ack確認，以待從新發送。

上述明顯存在一個問題，若是發送端發送了重複的請求該怎麼辦呢？這個時候就須要使用消息去重機制了。每條發送的消息，都有一個自增的消息id，同一個消息使用同一個id發送。讓接收者處理重複的消息。

 

總結，通常要保證消息的可靠性傳輸，都會能過超時，重發，確認，去重這幾個步驟。Rabbitmq有這個機制，可藉助它實現部分消息的可靠傳輸（通常用於內網rpc）。具體的實用方法你們能夠查看rabbitmq的文檔。

在遊戲開發中，在應該是網絡通訊框架的一部分，須要一個長期完善的過程，若是沒有一個長時間的積累，開發出這樣一套機制仍是須要必定時間的。因此前期大部分團隊都不怎麼考慮這個問題，會留到後期優化時再處理。可是對於有經驗的團隊，這應該是現成的。

轉載自：http://www.youxijishu.com/h-nd-149-2_323.html

更多遊戲技術方面的資料請參照：遊戲技術網：http://www.youxijishu.com/