前言

LinkedIn 的即时通信系统目前单台机器可以处理数十万的持久连接，这是不断调优的结果。

最近，他们在官网博客中发布了优化过程，介绍了即时通信系统的技术选型、调优的重点。
基础技术构成

即时通信技术的基本要求就是server能够向client推送数据，需要通过持久连接实现，而不是传统的“请求-响应”模式。

对于这个需求，LinkedIn 选择了 Server-sent events (SSE)来实现。

SSE 特点是简单、兼容性好，client只需要和server建立一个普通的HTTP连接，当server中有事件发送时，就会向client推送数据流。

配合 SSE 的 EventSource 接口被所有现代浏览器支持，iOS 与 Android 中也有现成的库，所以 SSE 的兼容性不成问题，这也是 LinkedIn 没有选择 Websockets 原因。

开发语言使用 JAVA，编程模型选用 Actor模型，Akka是一个优秀的Actor库。

开发框架使用了 Play，他可以很好的集成 EventSource 与 Akka。
优化过程

    socket最大连接数限制

LinkedIn 刚开始做性能测试时，发现并发连接始终无法超过128个，这肯定是不正常的，应用服务器处理上千并发连接是很轻松的，后来发现是一个系统内核参数的限制：

net.core.somaxconn

这个参数控制的是允许积压的TCP连接数量， 当一个连接请求过来时，如果数量达到上限了，就会被拒绝掉，128是很多系统的默认值。

可以在 /etc/sysctl.conf中进行调整。

    临时端口的限制

负载均衡器每次连接到一个server节点时，都会使用一个 临时端口，当连接终止时，这个端口会再次可用。

而持久连接不会像普通HTTP连接那样终止，所以，负载均衡器的临时端口就可能被耗尽。

这一点需要在选择负载均衡器时特别注意。

    文件描述符的限制

在加大测试压力后，出现了一个异常：

java.net.SocketException: Too many files open

这说明文件描述符不够用了，在 Linux 中，一切皆文件，例如访问标准的文件、连接网络socket 等等，都需要文件描述符。

对于运行中进程的文件描述符限制，可以这样查看：

$ cat /proc/<pid>/limits

...
Max open files            30000

假设想调整到 200000，修改 /etc/security/limits.conf：

<process username>  soft nofile 200000

<process username>  hard nofile 200000

系统级的文件描述符限制的调整是在 /etc/sysctl.conf 中：

fs.file-max

小结

这里整理的是几个通用的优化点，原文中有更详细的描述，还有两点对JVM的调优，有兴趣的朋友可以看下原文，地址：

https://www.1.qixoo.com/blog/2016/10/instant-messaging-at-linkedin--scaling-to-hundreds-of-thousands-

LinkedIn 即时通信系统的优化