基于keepalived和ServiceStack.Redis组件的redis链接分析

参考资料：http://zh.linuxvirtualserver.org/node/65和ServiceStack.Redis连接池的实现
通过ServiceStack.Redis连接池可以创建固定数量到redis服务的链接，节省链接创建成本和内存对象资源。
而keepalived有一个特性，针对同一个ip和端口或者同一个ip的链接基于某些特定服务（如ssl、ftp）的持续性考虑而不会依据算法分配，而是依据lvs内部的保存链接分配的哈希表里建立一个模板，所有符合模版的请求多会分配同一台服务器而不会由算法确定。
以上两点结合，就会表现出一个特性，同一台上ServiceStack.Redis发出的链接可能大量的集中到同一台redis服务器上，而不是均匀的分配到多台redis服务器上。而且由于ServiceStack.Redis以建立长连接的方式创建，所以链接集中的情况更严重一些。
使用keepalived做redis代理还有一个比较坑的问题，就是网络波动产生的大量无效连接在redis中的堆积。在网络波动时客户端可能和keepalived断开链接而没有发出FIN包，但是keepalived和redis之间却没有断开链接，那么就会悲剧的在redis积累大量CLOSE_WAIT或者ESTABLISHED状态的链接字而占用redis的client连接量不释放。所以redis的timeout配置文件不要设置为0，而要依据并发量设置一定的值。太短会造成链接的频繁断开在客户端产生大量错误，过长又会有占用问题产生，设置30秒应该适用访问量较低的应用了。

使用keepalived还有一个常见错误就是realserver设置arp相应参数错误，造成已经绑定了端口的链接在不同realserver来回飘产生大量“远程服务器强制关闭已有链接”的错误。vip的一个端口如果已经被一个realserver绑定了话，另外的realserver再响应一定会出错的。