直播聊天室大并发消息处理

       最近在做直播间的聊天室，踩了很多坑，我们采用的是融云的IM,实现聊天室的功能，所有的直播间功能都通过消息进行传递，如，礼物、红包、连麦、踢人、弹幕、禁言、管理...等等。对于这些消息的处理就出现了一些问题，下面我将介绍我踩坑的过程和解决的过程。

一、采用融云的消息处理

        融云其实对大并发消息做了一些处理，在接收消息的地方融云返回了一个nleft表示剩余消息条数，他们建议当nleft 等于0的时候我们在去刷新UI，这样可以避免过多消息处理导致主线程阻塞，内存升高，最终有可能导致APP闪退。我采用的他们的处理方式，但是我的消息不只是普通的文字聊天消息可以在等消息接收完去刷新tableView,我还有礼物播放的消息，连麦消息，它们的优先级都很高需要实时进行刷新，按照刚才的处理方法就有问题，并且还会出现消息丢失的问题，如礼物连续发送的时候消息并发量大，就会导致发送方和接受方礼物的个数不一致，内存过大。

二、定时取消息并刷新视图

        由于上面的情况，后面查阅了很多资料想出了一种方法就是定时取消息并处理刷新，这种方法就是创建一个消息的缓存池，将接收来的所有消息先存放到缓存池中，然后定时0.5秒或者1秒去缓存中拿一条消息去处理并刷新UI,后来测试发现高并发下内存增长不是太高，整体比较流畅，而且也解决了高并发消息丢失的问题，但是这种处理又引发了另一个问题就是我们的缓存池相当于一个队列，遵守先进先出的原则，所有接收的消息都需要排队去处理，这就造成有些即时性比较高的消息需要等待前面的消息处理完才能处理当前的消息，造成消息延迟过大。

三、按优先级缓存消息，定时去取

         基于上述情况 ，我对所有的消息的优先级进行分类，先按即时性分，再按消息量分，对所有的消息我分了五个等级。

1.连麦、关注、踢人、禁言消息量少即时性高放到优先级一级；

2.红包、进场、退场消息量比较大即时性也高放到第二等级；

3.小礼物消息量大消息即时性要求不是很大放到第三等级；

4.普通文本消息量特别大即时性不是很高放到第四等级；

5.弹幕，公告，系统消息消息量不是很大即时性也不是很高第五等级；

        对于这五个等级消息去取，我采用一秒钟取消息的次数划分等级，而且每个时刻只取某一个缓存池的一条消息，优先级一一秒钟取9~11次，优先级二取6~8次，优先级三取4~5次，优先级四取2~3次，优先级五取1次，通过这种处理解决了上述消息的即时性的问题，实际测试中也看到了效果，高并发也不会造成内存增高，消息丢失的问题。

四、总结     

        通过这次的消息处理，降低了CPU的处理，优化了系统性能，提高了用户体验问题，但是这只是初步的处理，其实还有很多优化的地方，比如定时取每个等级消息的时间，我们后期可以做成动态的，根据当前房间人数可以动态调整时间，人数越多，时间可以适当变短或者其他方式，消息的处理还可以采用多线程处理，并行执行，提高执行效率，等等这些优化。