比较重要的其实是timeout的前三个选项的时间定义，因为hive运算请求时间会比较长，通常都会超过一个tcp包正常的session响应时间。所以，hive需要一个长连接来等待数据返回，在TCP里面应该是TIME_WAIT我记得。如果设置太短了，SQL可以提交成功，但是你将不会获得任何返回值。因为被提交的session已经关闭了。所以普通的tcp代理转发并不适合hive的应用。这点在做定时任务的时候尤其重要，你可能会提交一个任务，但是不会获得任何返回，又查不出任何结果，就很头疼。作为hive的任务开发者，不了解tcp协议的工作情况，作为运维又不了解hive，所以如果这里出了错误，会很难发现。我写的1d是1天的意思，正常的话，当hive执行完毕，会自己发送关闭TCP的指令。这点倒是不用太担心累计连接数超过限定。
1d标志1天，类似的还有1h表示1小时，1s表示1秒，1ms表示1ms。
另外配合我之前写过的python daemon程序，稍加修改，用来监控hive的server进程，就基本可保证hive server集群的高可用了。
目前这个高可用方案在公司内部的phpHiveAdmin中已经可以使用了，查询和结果获取正常无误，thrift连接IP和端口只要指向到Haproxy的IP和端口就可以了。