心跳保活---TeamTalk心跳保活机制分析

由于蘑菇街的TeamServer包含了login_server ,msg_server等几个不同的服务端，本文会逐步进行分析，并持续更新。。。。。

首先分析为什么需要应用层的心跳机制

对应IM使用TCP协议还是UDP协议还是个有争议的话题，仁者见仁智者见智，不过个人觉得这得看实际应用场景，根据应用场景的不同用不同的协议。在TCP协议实现的IM中，需要考虑一个很重要的问题就是心跳保活，那么什么是心跳保活呢？

简单的理解就是在使用TCP协议的IM中，TCP连接的某一端定时向对端发送自定义消息，以确定双方是否存活，类似于心跳因此叫做心跳指令或者心跳保活。

读者可能有一个疑问：TCP协议中不是有一个字段用于KeepAlive吗？为什么还需要一个应用层的心跳机制？难道不能利用协议层的KeepAlive机制吗？

要回答这些问题首先要回答为什么IM中保持有效长连接的必要性。

对于客户端而言，保持长连接的长连接的有效性可以使得每次请求都只是简单的数据发送和接受，而不必要每次重新建立一个连接，重新解析DNS，省去连接建立的时间，加快了于服务器之间的通信速度，有利于接收服务器的实时消息，前提都是连接必须可用。

对于服务器而言，保持连接的有效性可以让服务器降低负载，及时清除无效的连接。

那么为什么TCP协议的KeepAlive无法实现确保连接的有效性呢？TCP的KeepAlive功能是定时间隔发送一个KeepAlive探针来确认连接的有效性,一般为7200s，失败后重试10次，每次间隔75s，由于移动网络的特殊性，这个时间是不能满足IM通信的要求的。那么如果修改KeepAlive时间后呢？答案仍然是否定的。KeepAlive仅用于检测连接的死活，而应用层心跳机制还有一个目的是检测简练的存活状态。考虑一个场景：当某台服务器处理负载过高，CPU利用率100%，无法处理任何业务请求，在这种情况下，TCP探针仍然确认对方可用，而实际上，服务器已经不能处理任何请求了，这种情况下应该断开当前连接，重新建立连接，而不是认为服务器仍然可用。因此，从这个角度出发，应用层心跳机制也是必然需要的。

蘑菇街TeamTalk中Login_Server的心跳保活使用方法。

蘑菇街的心跳保活的方法采取了一种简单的方法--定时心跳。由login_Server每隔5秒向消息服务器发送心跳信息，如果30秒内没有收