在第1部分,我们通过实验验证了当Server Port确定的情况下,Client和Server两者之间最大的TCP连接数。
那么问题来了,有了这样的限制,我们在部署或编程实践中应该如何面对这样的限制。
下面提供几个思路。
我知道的是确实在国内有公司在利用这样的解决方案。
这方面做的最好的是Google, 已经向IETF提交quic raft,就是一个可靠UDP协议。
起官方主页:
https://www.chromium.org/quic
quic好处:
1)没有TCP三次握手,开销小,尤其是针对web这样的业务,大规模消费短连接
2)在用户空间(User Space)实现了基于UDP的可靠传输,有很多很炫的功能,比如引入存储里RAID类似的机制等
3)用户空间程序开发迭代周期短、熟手多,目前如果想在Linux Kernel修改一段TCP代码,对开发者要求太高
https://github.com/lzueclipse/learning/blob/master/c_cpp/libzdb3.1/src/db/ConnectionPool.c#L326
用一个Vector保存所有的Connection,如果当前所有Connection都被使用,那么在不超过连接池最大配置数的情况下,
可以再申请新Connection,并添加到Vector。进一步思考,如果超过连接池最大配置数的情况下,调用者只能根据返回值去等待了。
https://github.com/lzueclipse/learning/blob/master/c_cpp/libzdb3.1/src/db/ConnectionPool.c#L289
启动一个线程,定时去ping 数据库,探测这个Connection是否还Alive。
_doSweep()----->_reapConnections()------>Connection_ping()。
具体看了下代码,mysql用的是 mysql_ping(); postgresql用的是 PQstatus().
那么问题来了,有了这样的限制,我们在部署或编程实践中应该如何面对这样的限制。
下面提供几个思路。
1. 多IP
仅仅从部署上考虑的话,Client或Server配置多个IP,可以在不修改代码的情况下,突破第1部分中说的TCP连接数限制。2. 采用可靠UDP
如果采用UDP,就没有Connection的限制,但是需要保证自己应用层的协议是可靠(reliable)的。我知道的是确实在国内有公司在利用这样的解决方案。
这方面做的最好的是Google, 已经向IETF提交quic raft,就是一个可靠UDP协议。
起官方主页:
https://www.chromium.org/quic
quic好处:
1)没有TCP三次握手,开销小,尤其是针对web这样的业务,大规模消费短连接
2)在用户空间(User Space)实现了基于UDP的可靠传输,有很多很炫的功能,比如引入存储里RAID类似的机制等
3)用户空间程序开发迭代周期短、熟手多,目前如果想在Linux Kernel修改一段TCP代码,对开发者要求太高
3. TCP连接池
我从 http://www.tildeslash.com/libzdb/ 找到了一个用C语言写的数据库连接池,分享下。https://github.com/lzueclipse/learning/blob/master/c_cpp/libzdb3.1/src/db/ConnectionPool.c#L326
用一个Vector保存所有的Connection,如果当前所有Connection都被使用,那么在不超过连接池最大配置数的情况下,
可以再申请新Connection,并添加到Vector。进一步思考,如果超过连接池最大配置数的情况下,调用者只能根据返回值去等待了。
https://github.com/lzueclipse/learning/blob/master/c_cpp/libzdb3.1/src/db/ConnectionPool.c#L289
启动一个线程,定时去ping 数据库,探测这个Connection是否还Alive。
_doSweep()----->_reapConnections()------>Connection_ping()。
具体看了下代码,mysql用的是 mysql_ping(); postgresql用的是 PQstatus().