?

同步狀態和消息推送，幾乎是每個app或者設備都需要的，設計一個省流量，能簡化兩端邏輯，能應對業務增長的框架尤為重要。

我認為，以下方法不夠好：

1.每一個狀態都設計一個消息，導致每增加一個狀態，服務端都需要改動。

2.每次上線后都請求一次所有類型的最新的消息。

3.最新的消息只推送一次就完事。

?

第一個缺點已經說了，解決的方法是設計一個通用的消息結構和存儲模型，集存儲、轉發、推送于一身。

第二個方法，一個是消息太多，不可能每個都有更新，所以沒必要每次都請求。而發送的請求帶來沒必要帶寬的浪費和處理的壓力，尤其在移動互聯網情況下，掉線太多，浪費的帶寬和cpu也是成倍增加。

解決方法，類似日志式的方法，設備的每次變化都對應一個日志，讓設備依次重放每個日志，如果狀態具有唯一性，那么可以刪除這個狀態舊的日志，保留新的日志。

第三個問題，在完成日志式的改造后，讓每個日志對應一個數字，日志越新，數字越大，設備或者app只需要請求更新的日志即可。推送不再丟失消息，也不會重復消息。

?

另外，考慮到日志太多，可能會導致同步緩慢，所以應該將日志分類，將一些緊急的狀態變化分為一類，將一些不是很重要的消息，又分為一類，這時候存在兩份不同的日志序列，按需請求即可。

?

轉載于:https://www.cnblogs.com/dearplain/p/7896885.html

總結

以上是生活随笔為你收集整理的消息推送与同步协议的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。