维持网络连接，心跳是最愚蠢的办法

在网间做交易，都希望连接可靠，基于网络的复杂性，这个“可靠”是无法保证的，于是人们想尽办法对连接“保活”。
心跳法，就是人们常常使用的办法。
为什么说这是最愚蠢的方法呢？
1.心跳时活，不一定应用时也活。
2.这个连接活，不一定其他连接活（交易系统常常使用连接池，在两个节点间建立许多连接）。
3.发现死了，你也没有合适的办法让他活过来，也不知道什么时候能活过来。。
4.即使重新连接成功，通知应用者，让他们注意到连接已更换，注意交易上下文的连续性、完整性，也是个困难的任务。
5.使心跳活动与业务活动互不干扰，是个麻烦事。
6.在长时间的业务活动中一直保持连接，不管业务的忙与闲，那么连接的损坏和死亡就是必然事件，上述问题就必然产生。
那么我们怎样解决这些问题呢？
一个系统的死亡是自然规律，你阻止不了。一个系统是否死亡，从外部也不能及时准确的判断。就是说心跳没有应答了，系统未必就是死了，可能是忙，没工夫理你。也可能是应答了，你没收到。
因此，保活，是个无解的题目。
变通的做法是“保证交易完整性”，即，我没办法保证交易过程不出故障，我也保证不了交易一定能完成，是力保交易完整，即，要么全部完成，要么全部不完成。
保证交易完整性 的手段不是“保活”，而是“保死”。
就是使每一个交易应用的开发者明白，任何网络连接，随时都可能出故障，你交易的每一步都可能失败。对于每个失败你都要做好准备，rollback，redo的规则和策略，都是你的责任。
在SDBC交易中间件里，采用的技术称为“自愈”技术，就是说，后台服务器可以随时死亡，如果正好在交易活跃期发生，通信平台会向应用报告故障，由应用系统进行善后处理。当服务器恢复，系统自动恢复正常。这中间无需人工干预。
这里采用了“保死”的技术，具体的：
1.连接池初始化时，一个都不连，保证是死的。
2.应用者获取连接时，如果连接没有打开，就打开它，这一步保活，打不开返回错误，通知应用，自己想办法，
3.如果使用中发生故障，应用负责以该故障码归还连接，回收程序对严重故障要关闭连接，并完成资源回收。这是保死的第二步。应用应该以适当的周期进行redo，可以及时发现系统恢复。
4.单独的线程定时进行连接池健康检查。发现那些长时间空闲的连接，关闭之。这是保死的第三步。这样与应用不冲突，也没有复杂的协调工作。
    如果是稀疏业务，最好保证在业务间隙关闭连接（这样在业务活动期应对后台服务器故障就是低概率事件）。它对系统的健康保障策略是简单的，故障的善后和恢复是自动的。
这个策略在很多关键业务系统得到应用，它保证了系统的极度可靠，保证了系统长期安全稳定的运行。