引子

现在在公司的一项工作是负责IM系统的长连接，我们的长连接系统是用C实现的，事件驱动使用的是libevent，有一次和另一个朋友交流，他们说他们的长连接是基于netty实现的，实现起来比我们的要简单方便很多，当时就想后面有时间就比较一下这两种实现方案。

其实这俩本来是没有可比性的，所以本文对比的是netty+java实现的长连接和libevent+c实现的长连接系统的对比。

长连接系统简介

IM的长连接是指用户端和后台建立的一条较长时间存在的信息通路，起到的最大作用是消息的实时触达。当后台有消息的时候，会通过这个通路实时的发送给用户。

我们的用户端有app端，js端，pc端，为了能兼容所有的设备和浏览器，我们初始的协议选择了http协议，使用的是long polling的方式，后来协议增加了websocket协议，在高级别浏览器和微信小程序能提供更好的体验。

内存对比

基于libevent+C实现

基本数据结构

• session数组
• 每个链接的动态buffer

session数组的索引是fd，存储的是session对象，session对象主要包括一个链接的客户端ip，登录时间，读和写的buffer指针，读和写event以及创建时间等。每个session对象416B，由于使用的是数组，我们根据系统的最大承受量，预留了100w个session对象，所以占用空间416M。

每个链接的读buffer是为了解决tcp的粘包问题，即读到一个完整的业务包才能交到下一个环节处理。
每个链接的写buffer是为了解决tcp的链接不可写的问题，因为使用的是异步操作，有数据的时候，有可能tcp链接并不可写，这时候就缓存在写buffer里面，可写的时候再写。

基于netty+java实现

netty中一个链接是一个channel，每一个channel会有一个DefaultPipeline，然后会有一个HeadContext和TailContext以及Unsafe对象。java对象比较多，所以java占用的内存会多一些。

netty实现的长连接的内存会有一个gc的问题，因为长连接的链接相关对象的存活时间是和链接相同声明周期的，那么会有很多内存存储在老年代，会导致fgc的时间比较长。

线程管理（CPU）对比

基于libevent+C实现

因为我们使用的是纯异步的设计，所以我们首先申请了和cpu核数一样多的线程数，然后通过fd取模得到对应的线程索引，那么这个链接的所有读写都是这个线程负责的。（accept的线程后面会单说）

基于netty+java实现

netty的EventLoopGroup的一个实现是MultithreadEventLoopGroup，这个里面使用多个线程，每一个线程都是一个NioEventLoop，channel选择EventLoop的方式是轮询，所以每一个channel里有一个引用指向这个NioEventLoop，这个channel的所有读写都是这个NioEventLoop完成的（包括accept的线程）。

线程交互

线程交互指的是一个链接的要给另一个链接发送数据，而这两个链接又有可能属于不同的线程，所以存在线程交互的问题。

基于libevent+C实现

libevent是基于事件驱动的，所以我们引入了pipe，线程之间交互是通过pipe的读事件通知的，当一个线程管理的链接需要给另一个线程管理的链接发送数据的时候，就通过pipe通知另一个线程。pipe有一个比较好的特性是write接口原子性，即发送4096的数据是原子的，就是多个线程同时写的时候不会出现一个线程写一半数据，然后另一个线程写一半数据的情况。

基于netty+java的实现

netty的实现没有使用事件的机制，而是加入了一个队列，同一个线程在处理完nio的事件后会检查一下队列是否有数据要发，因为nio在没有数据的时候是会block的，所以需要wakeup一下。

accept线程优化

长连接是一个外网的系统，那么不能避免的会有攻击或者垃圾流量过来，所以有可能链接的请求特别多，在我们的系统里面，accept的线程的cpu占用是其他线程的2倍。

基于libevent+C的优化

给同一个fd（accept socket的fd）分配多个event，然后绑定到多个线程，这样cpu就比较均匀了，缺点是：同一个event会有多个线程同时相应，但只有一个socket能accept到结果。

nginx的优化

nginx的accept的fd不是固定到一个线程管理的，哪个线程空闲就那个线程管理，这样也能使cpu比较均匀。

实现复杂度

上面提到了内存管理（分为动态和静态两部分）、线程分布、线程交互和accept优化四个方面，netty几乎都已经比较好的解决了，所以如果基于netty和java实现的话，实现复杂程度就会简单很多，如果用libevent和c来实现，都需要自己来实现，实现复杂程度陡增。

总结

上面从内存、CPU、线程交互、accpet线程优化以及实现复杂度五个方面比较了基于netty和基于libevent+c的实现，总结起来：

• 内存上c有优势，特别是长连接这样的系统，大部分内存都会进入java的老年代
• accept线程优化方面，netty并没有很好的考虑
• 实现复杂程度，netty+java的方案简单很多，对并发连接数不是很多的系统，可以优先考虑