天天看點

今天項目組裡面發生了一次讨論。是關于終端與伺服器如何同步資料,保持資料的一緻性的問題。伺服器采用mqtt做資料下發,不保

今天項目組裡面發生了一次讨論。是關于終端與伺服器如何同步資料,保持資料的一緻性的問題。

伺服器采用mqtt做資料下發,不保證資料必達,導緻終端和伺服器可能因為掉線或者網絡丢包問題導緻資料出現不一緻。測試測出這個問題後提了一個bug。研發的讨論就此展開。

服務端認為,伺服器有提供全量查詢接口,終端定時全量查詢自己判斷就可以解決問題。

終端認為,伺服器應該提供增量資料查詢接口,這樣終端可以減少計算量。

兩人在群裡面争論不休,都想讓對方改。最後還是研發經理出面,才定下方案:mqtt分發資料保持現狀,伺服器增加一個查詢接口(查詢指定ID以後的資料),終端做一個定時請求資料的操作,來同步資料。終端請求資料時帶上上次查詢時獲得的最後一條資料的ID,這樣就能保證資料一緻了。

這個方案雖然能夠解決資料不一緻問題,但有兩個明顯缺點:

1、假如剛定時同步完成,終端資料就丢失,要等到下一次定時同步資料才能一緻(這個定時時間有可能是一小時)。

2、終端定時拿到資料後需要做大量比對計算,且定時擷取的資料絕大多數是備援資料。由于終端是電池供電,是以會導緻裝置耗電量增加。

至于為什麼不使用Qos2模式(必達去重模式)。研發的答複說,伺服器端性能不足無法實作,如果這麼做需要消耗更多伺服器資源,是以不做。

你們說是伺服器端增加消耗更劃算,還是終端修改更合理呢?

#頭條創作挑戰賽#

今天項目組裡面發生了一次讨論。是關于終端與伺服器如何同步資料,保持資料的一緻性的問題。伺服器采用mqtt做資料下發,不保
今天項目組裡面發生了一次讨論。是關于終端與伺服器如何同步資料,保持資料的一緻性的問題。伺服器采用mqtt做資料下發,不保
今天項目組裡面發生了一次讨論。是關于終端與伺服器如何同步資料,保持資料的一緻性的問題。伺服器采用mqtt做資料下發,不保

繼續閱讀