RPC的keep alive与心跳

先啰嗦两句，RPC。

随着微服务与中台思想的普及，RPC的使用更加普遍。

 

RPC可以将别人的服务当本地的来用，做到了轻量、无感知通信。简单易用，说明背后有强大的支持，耳熟能详的Dubbo、SpringCloud都提供了一系列诸如服务注册、发现、路由、负载均衡等能力，用来支持RPC。

 

RPC连上别人服务的方式还是“tcp 三次握手”，当然和平分手的方式，还是“四次挥手”。

 

三次握手：

第一次：我喜欢B（SYN seq=x）

第二次：我喜欢A（SYN seq=y）,我就是B呀！（ACK=x+1）

第三次:   我就是A呀！（ACK=y+1）

在一起了...

 

连上之后就是各种对字节流的序列化与反序列化，简单来说就是二者都拿“密码本”说“暗语”，在此，就不多啰嗦了。

 

我们来关心下，连接是如何保持住的。

 

Keep alive

这里的keep alive是tcp的，与我们在http请求上看到的Connection: Keep-Alive是两回事。

 

• http的keep-alive

 

就是浏览器上，去访问站点会碰到的东西。通过内容长度（事先说好花了多少钱后就分手）、 传输编码（约定好一个分手暗号）、超时（不秒回消息就分手）判断要不要关闭连接。一般连接的存在时长是秒级的。虽然它叫长连接。

 

• tcp的keep alive

 

是通过“光吐口水不说话”（传空包）来检测对方是否还活着。如果对方不吐回来就分手了。

 

tcp的默认超时时间是2小时，就是最多冷战2小时，就要一起做点啥，如果啥都不想做，就吐口水。

 

一般长则1、2分钟，短则十几秒就要互相吐一次口水。比http的爱更持久。

 

因为时间明显长了，矛盾就会多，所以经常会发生“被分手”的情况。

如果使用了sockes 代理的话，会造成tcp的keep alive失效，代理就如同发微信语音谈恋爱一样，微信不能传递口水。

 

除此以外，还有一些复杂的情况也会导致失效。

 

特点：

内核层支持，高效

资源损耗小

 

心  跳

用户在闲置的时候，定期发送约定好的心跳信号给服务端，让对方知道自己还活着。时效性更好，相当于你爱人一直盯着你的心跳图看，随时关心你的身体健康。

 

springcloud里有的Eureka Server来发送心跳。但是Dubbo的心跳则是双向心跳，两个人互相盯着对方心跳图。比谁活得久。

 

需要注意的是，心跳不要记到相关业务场景的qps中，总不能说“我和你一起心跳过200下，所以我们的爱有200分”。

 

特点：

可完全自己掌握，灵活，可靠，资源开销大

 

 

从特点上看，二者有所互补，他们同时存在的情况很多。想了解更多，后台给我留言吧。嘿嘿。

 

更多有趣内容敬请关注“码农在中年”公众号 ⬇️