當併發呼叫增加到1千以上（交換機埠映象過來的流量達150m），含多種語音編碼時（如g711a、u和g729等），錄音系統效能出現下降，如丟錄音，丟包，卡頓甚至崩潰等情況。
經過徹底改進和優化，錄音系統執行非常順暢，可以長時間穩定執行而不會丟失任何資料。
下面記錄一下改進的關鍵部分。
1、抓包改進
抓包庫使用的pcap_開頭的函式，有很多可優化的地方，如設定緩衝區大小，讀包延時（最好就不要延時）等。有些程式設計師懷疑迴圈讀取的方式是否能夠處理每秒幾百m的流量，是不是需要用pcap庫核心方式來處理？答案是不需要，完全可以不丟乙個包。
2、rtp匹配，原先是讀寫鎖，改為無鎖。
rtp的資料報數量十分巨大，改為無鎖後，匹配過程不需要做任何等候，大大提高效率。
1個執行緒專門處理sip信令訊息，4個執行緒專門處理rtp包，如何做到無鎖？
1個執行緒專門處理sip信令訊息，根據call-id生成乙個個會話，存放在佇列裡。
我實現的讀寫鎖雖然效率高，但還是要用到條件變數、臨界區等作業系統的全域性訊號呼叫，必然還是有等待，最根本的解決之道是什麼鎖都不要。解決之道是：兵乓兩個索引，讀和寫分開。
3、對會話增加斷流判斷
會話如果丟失bye訊息，將吊死在記憶體中，錄音檔案也關閉不了。
此外，如果一直收不到rtp語音流，保留會話只會無謂地占用記憶體。
在信令處理執行緒中對每個會話進行跟蹤，如果超過6秒沒有再收到rtp包，將主動關閉會話，錄音結束，**資源。
4、解決ipp解碼器被崩潰問題
對於g729編碼，我們採用intel的高效能庫ipp，g729的處理部分分為浮點庫和整型庫，一般採用浮點庫，系統不定期出現問題，導致崩潰，將ipp公升級到最新版本，問題依舊。改為使用整型庫後，問題也並沒有解決。
後來通過寫日誌仔細跟蹤，發現映象了多個節點的相同rtp資料，因為本系統是多執行緒處理rtp包（更高的效率），兩個執行緒同時呼叫ipp的729的codec解碼，會導致問題。修改程式，防範不同執行緒資料，解決了此類問題。
經過上述改進，系統可以進行運營級別的大容量錄音。
系統執行在64位的windows或linux下，經過實際的大併發考驗，其效能和穩定性都堪稱強悍。
高效能無鎖佇列 Disruptor 初體驗
最近一直在研究佇列的一些問題，今天樓主要分享乙個高效能的佇列 disruptor 它是英國外匯交易公司 lmax 開發的乙個高效能佇列，研發的初衷是解決記憶體佇列的延遲問題。基於 disruptor 開發的系統單執行緒能支撐每秒600萬訂單。目前，包括 apache storm log4j2 在內的...
系統高效能
總的來說，系統的設計是否合理，比區域性 問題，對效能的影響更大。例如，程式設計成頻繁讀寫磁碟中的資料，肯定比先把資料一次性載入到記憶體中再讀寫，在合適的時候再寫入更新到磁碟的設計，效能要差很多。使用伺服器集群 多執行緒多程序的架構，肯定比使用單伺服器 單執行緒單程序的架構，效能要差。服務端使用非同步...
乙個高效能無鎖非阻塞鍊錶佇列
這個是乙個用c 11標準實現的無鎖非阻塞鍊錶佇列，通過增加乙個dummy節點，解偶合煉表頭指標和尾指標。使得當只有乙個生產者和乙個消費者時，進隊和出隊都無需加鎖，進隊操作的是尾指標，出隊操作的是頭指標，互不干涉。對於多個生產者且單個消費者時，只需要對尾指標加鎖保護，而頭指標不需要加鎖。反之，對於單生...