dubbo是长连接还是短连接_长连接服务开发的一些实战经验分享

linux下我们开发的程序通常扮演者两种角色，要么是服务端程序即提供listen 节点给业务发调用，另外一种是访问别的服务获取一些数据进行进一步处理。

如果你的程序是一个有网络交互的程序，并且是频繁的网络交互，为了提高性能，你会尽可能的重复利用已经存在的socket连接，所以就有了我们所谓的连接池，比如mysql连接池，redis连接池。如果每次业务网络请求都需要进行一次socket连接，一次tcp连接需要三次握手，简单的思考一下TTL就知道这里的服务性能是多少了，如果是服务端和客户端在不同的机房比如一个在北京、一个在深圳单单是物理距离就要30+ms的延迟。所以我们在开发过程中都会尽可能的重复利用已经建立好的连接。如果一个号称是高性能的TCP服务端程序(网络IO密集型)，如果不是使用长连接那纯粹那所谓的高性能估计也噱头。

Fig Redis 连接池

这里要简单介绍下连接复用、IO复用、并发使用链路的区别：

1)连接复用就是利用已经存在的socket链路，来发起新的网络请求

2) IO复用，他是一种网络IO、磁盘IO的模型，利用这些模型来更方便、更高效地管理多个socket链路而已

3) 并发使用链路，他是在1)的基础之上，一个链路可以并发发起多个网络请求(这里的并发实际上也是串行的，只不过是他不需要等待前一个请求1的应答回来就可以发起另外一个新的请求2)，比如HTTP/2就是属于并发使用链路,HTTP/1.x 、redis协议都是属于连接复用的层面。

如果想要重复利用已经建立好的连接那么就必须要确保链路是长期active的。所谓的长连接无非就是保证服务端跟客户端的socket在linux内核中维护的时间戳在合理的范围内。如何保持这个时间戳？大家可能都很容易想到可以采用心跳来保持tcp长连接。心跳机制就是通过一些极小的网络数据消耗(但是网络协议栈的头开销是免不了的)，来告诉对端我还活着，别把我清理掉。

心跳分为业务心跳、tcp探活心跳。

1)业务心跳由业务通过开发代码定时给对端发送一个类似ping的这种请求。

2)TCP探活心跳(tcp_keepalive_time)

它的作用主要有两点，一维持连接，二是能把一些异常断开的链路及时回收(半打开的连接)

它是系统层面的心跳机制，具体时间长短需要充分了解对端的超时机制，才能合理设置，尤其是涉及到移动客户端的这里就需要非常谨慎了，过于频繁的心跳会导致用户流量消耗过快、功耗过高(耗电快)，说不定你的app很快就上黑名单了。

另外如果你的服务是部署在云上，则需要了解云上的虚拟化session超时时长才能合理的设置

比如阿~云上宿主机和客户机(虚拟机)的链路如果超过15分钟没有任何业务数据，链路就会被回收，回收了还不告诉客户端和服务端，等到你发数据包的时候你才发现链路已经断掉了(会收到RESET包)，所以大家需要根据自己的使用场景合理的配置心跳：

/proc/sys/net/ipv4/tcp_keepalive_time

/proc/sys/net/ipv4/tcp_keepalive_probes

/proc/sys/net/ipv4/tcp_keepalive_intvl

关于tcp keepalive_time,仅仅是配置上面几个是不够的，需要在程序中调用setsockopt,打开tcpkeepalive,你的服务建立的连接才会享受到linux内核的探活机制。(一般只需要服务端设置，当然客户端也可以设置但是没有这个必要)

int keepAlive = 1;setsockopt(client_fd, SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive, sizeof(keepAlive));

另外阿~云上的单个物理机连接数峰值是200万，所以分配到单个虚拟机的据我连接大概在100万左右，如果你的服务是50万，别人的服务是170万长连接而且都在同一个物理机上，那么此时肯定会出现丢包情况，要么是你的服务丢包，要么是别人的服务丢包，所以如果你的服务是部署在阿~云上需要注意下自己服务长连接的限制(不同的套餐最大连接数限制可能不同)，提前做好沟通。