参考资料: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再响应一定会出错的。