開發一款即時通訊的聊天軟體，或者說近實時的聊天軟體，最基本的要求，就是要保證訊息的順序，這個順序指的是在傳送者的角度來講，傳送者傳送訊息的時候，順序是乙個樣子，在退出聊天頁，或者重新登入之後，再次進入到聊天介面，看到的順序任然是退出之前的樣子，不能讓訊息的順序出現跳動，
如果這個基本要求不能保證，就會導致重新整理聊天介面之後，或者說退出再次進入聊天介面之後，訊息的順序和傳送訊息時的順序不一樣，就像下面這樣：
從訊息的接收者的角度來看，允許接收者視角和傳送者視角看到的訊息順序不一致。比如下面的截圖：
訊息接收者和傳送者的手機螢幕上，訊息的順序就是不一致，接收者並不知道訊息傳送者真實的傳送順序是怎麼樣的，這並不影響雙方的對話。導致這種情況可能是網路延遲的問題，比如傳送者第一條訊息傳送的是，第二條訊息傳送的是純文字，由於網路延遲的原因，接收者收到訊息的時候，先收到文字，後收到，這樣就導致接收者和傳送者看到的順序不一致，這種情況是允許存在的。
但是上面說的第一種情況，就不能允許了，即同乙個視角下，重新整理介面前後，順序改變，跳訊息，怎麼來設計，才能避免跳訊息這種情況呢？最主要還是在訊息id的設計上。
聊天介面訊息的排序，涉及到兩種訊息id，一種是全域性訊息id，一種是是本地訊息id，本地指的就是聊天介面，不管是訊息的傳送者還是接收者。
服務端需要提供乙個id生成介面，專門用於生成全域性的訊息id，全域性的訊息id需要保證嚴格的單調遞增，才不會影響訊息的排序，id生成規則可以是：時間戳(秒)+自增id，也可以是其他的生成策略，原則就是單調遞增，切不能重複。
本地訊息id（localid）生成策略：
如果本地沒有上一條訊息，第一條本地訊息id localid=從伺服器獲取乙個全域性msgid*100。
接收到的訊息localid=msgid*100
上條訊息是非本地的，當前訊息的localid =上個訊息的msgid*100+1
上條訊息是本地的，當前訊息的localid =上個localid+1
訊息傳送到伺服器之後，localid會隨著訊息一起儲存在資料庫中，本地使用localid排序。
為什麼訊息id要乘以100（也可以加100）？
為了防止這種情況的發生，如果客戶端傳送了100條訊息，但是只有10條訊息傳送出去，如果此時接收到一條來自服務端的訊息，該訊息的localid=msgid*100就可以將該條訊息排序在客戶端的100條訊息之後。這樣，當清空本地訊息，從服務端重新拉取訊息時，展現時，不至於出現，這條服務端的訊息插在100條客戶端訊息的中間。
即時通訊IM
mqtt message queuing telemetry transport，訊息佇列遙測傳輸 是ibm開發的乙個即時通訊協議，有可能成為物聯網的重要組成部分。該協議支援所有平台，幾乎可以把所有聯網物品和外部連線起來，被用來當做感測器和致動器 比如通過twitter讓房屋聯網 的通訊協議。xmp...
即時通訊 IM
1 協議選型 2 im伺服器選型 3 對協議和伺服器做相應修改，通常來說直接拿個標準協議和開源伺服器是一定不能用到生產環境的 4 保證訊息到達率，絕不丟訊息 一 協議選型 常用做im的協議 mqtt協議 ibm開發的乙個即時協議 優點 多平台 缺點 簡單的訊息協議，要自己實現好友群組 用例 推送 s...
即時通訊 im
no.1 即時通訊 作用 即時通訊 instant message，im 是指能夠即時傳送和接收 網際網路 訊息等的業務。1998年即時通訊的功能日益豐富，逐漸整合了 電子郵件 部落格 電視 遊戲和 搜尋 等多種功能。即時通訊已經發展成集交流 資訊 娛樂 搜尋 電子商務 辦公協作和企業客戶服務等為一...