場景

在做一個APP的聊天功能，聊天訊息走socket推過來的，每個訊息有唯一的id，id隨時間是增大的，聊天訊息要按時間有序，不重複，不遺漏。

本部落格主要想說訊息有序，但提到了不重複，不遺漏，也簡單說一下。
不遺漏：一種方式就是本地儲存最新的訊息id，請求最新資料時帶上這個id，等到請求回來，才能更新最新id，注意一下邊界開區間閉區間的問題就可以了，伺服器應該返回 ( 本地最新id, 伺服器最新id ]，這種左開右閉的區間給客戶端就行。還有一種保證訊息100%到達的應用層應答機制，可以在我之前的部落格看到點選檢視。

不重複：有時候行動網路很差，一個請求發出去很久才響應，中間可能隔了幾秒鐘，這個時候，有些使用者很急可能會狂點介面，比如我，導致請求重複發（實際中已做限頻，狂點也不會發請求），然後回來的訊息自然就有很多重複了。去重很簡單了，OC 中用 NSMutableDictionary，底層是雜湊表，把訊息id 作為 key，加入到字典中再拿出來，重複的就沒有了。但實際中資料量較小，你寫兩個 for 迴圈去重也不會有什麼效能問題，理論上會更耗cpu和電量。

訊息有序

第一的想法是每次收到新的訊息就加入到優先佇列中，然後一出隊就全部都是有序的了。但是 oc 中沒有優先佇列這種結構，甚至連佇列都沒有，一個變通的做法就是用 NSMutableArray 來實現佇列和棧，但是用法很彆扭，如果 NSMutableArray 用陣列實現的話，會有大量的位移操作，效率會很低。

一開始我把訊息儲存到 NSArray 中，每次來了新訊息都執行排序+去重的操作來保證有序，資料量小就沒什麼問題，其實也不小，群裡面聊天幾十個人同時發訊息，一下就重複好多次這樣的操作。後來比較有空，就自己用 oc 實現了一個優先佇列，方便使用，效率高，大量資料下效能也很好。

優先佇列

普通佇列是先進先出的結構，優先佇列是一種按照優先順序大小，比如小的先出隊，的一種結構。所以先進的不一定先出，它會把優先順序高的先出，下面我認為id小的優先順序高。要先出隊。

舉個例子

那麼如何實現優先佇列？有以下三種方法

1.入隊有序

就是每加入一個元素的時候，把它移到一個“合適”的位置，舉個例子

入隊已經保證有序了，那麼出隊就直接把第一個元素拿出來，就是最小的了。
顯然 n 個元素的時間複雜度，入隊操作 O(n)，出隊操作 O(1)
缺點：該方法，如果有大量的入隊操作比較耗時。

2.遍歷最小的出隊

因為方法1的入隊操作耗時，那麼方法2做了個改進，入隊的時候什麼也不做，直接追加到尾部，出隊時候去遍歷陣列中最小的元素出隊，舉個例子。

出隊的時候，遍歷陣列，找到最小的元素1，出隊就行了
顯然，入隊操作 O(1)，出隊操作 O(n)
缺點：如果有大量出隊操作比較耗時

3.二叉堆

由於上面兩種方法都有缺點，最後用堆這種資料結構來實現優先佇列

什麼是堆？

如下圖

入隊操作，向堆中加入一個元素

出隊操作，從堆中刪掉一個元素

用堆來實現優先佇列，入隊，出隊操作複雜度 O(log n)，比較平衡。

最後還是上個 oc 寫的程式碼吧（下載地址），順便吐槽一下 c++, java 都 priority_queue 這樣的資料結構，oc 居然沒有，得自己用 NSMutableArray 模擬，或者自己寫一個。