版本：haproxy 1.4.24，通过centos base的yum repo安装，centos 6.4 x86_64
用了几天，似乎有重大bug，问题表现：
一、 10几个用户的并发能把HTTP模块搞挂
连stat页面（用mode http运行的stat）都看不了，进程还在，stat socket也在，重启后就正常，过会儿又挂。
maxconn是3000（有点小，但10几个用户远远达不到这个上限啊）
二、无故丢失backend server。
mode tcp
刚启动时正常，stat页面能看到backend server，能显示状态
几乎无任何访问，12小时内，后台server没了，注意，不是health check检测不到backend server了，是stat页面里backend列表为空，就跟配置文件里从来没写过这台backend server一样。
用debug模式启动，丢失后台server的时候无任何日志输出，连xxx server is DOWN 都没有（如果是health check 失败会有这个提示）
更加奇怪的是，丢失的是sphinx和redis（还没正式使用，几乎没有客户端访问），mysql,php-fpm从来不丢，难道是haproxy自动把没流量的backend server list清空？这不科学啊
执行haproxy reload后正常。
之前用低版本的haproxy没遇到这个问题
怀疑是haproxy有bug，有同行遇到类似问题吗？
这个问题太诡异了，恐怕很难得到答案。
我的解决方案是：
1.换其它版本的haproxy
比如以前用过的低版本，或者6月24号刚刚发布的1.5.1
2.换LVS
为什么不是nginx呢，因为我全部做的layer 4负载均衡
由于我花了几十小时把haproxy的安装配置写成puppet自动化脚本，不想就这样放弃，所以，我选择了方案1，自己下载1.5.1的源码打包了个rpm，测试看看会不会重现
-- 进展 --
测试过程中发现：
haproxy init.d脚本有问题，restart和reload 的时候，没有正确处理pid文件，起了一个新的进程
新的进程没能将正确的config文件载入（机制不清楚，观察到新进程一直都没把sphinx和redis两个cluster配置加进来，其它三个都加进来了），访问时，随机访问了一个进程，如果恰好就是新进程，就访问不到redis了，如果是老进程，可能就没问题
-- 初步结论 --
haproxy没有bug，但有一点跟apache/nginx等守护tcp端口的daemon都不一样，它允许以完全相同的配置文件同时运行多个进程，而不会报端口冲突。
我所提的【bug】，根本原因是我写puppet脚本时疏忽了，puppet默认是不分先后的（写在最后一行的，不一定是最后一个执行），我在puppet里，生成haproxy/conf.d/xxx.cfg和启动haproxy service，没有指定先后顺序，配置文件还没完全生成好，service就起来了。
改掉这个问题后，稳定运行了10个小时了，也可以反推出来故障过程。特地来更新答案，是我学艺不精，不能冤枉了haproxy。