无锁：高性能录音系统根本性改进

当并发呼叫增加到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下，经过实际的大并发考验，其性能和稳定性都堪称强悍。