在Cache系统中使用负载均衡服务的探讨

Cache软件自带数据服务和应用服务。在实际使用中会将Cache数据服务和应用服务分别安装在不同的服务器上面，作为数据库服务器和应用服务器。数据库服务器和应用服务器通过ECP（企业缓存协议）进行数据交换。在应用服务器部署上web服务，让数据交换和应用处理分开，实现瘦数据和胖应用的系统模式。

这种早已存在于互联网行业的基础级模式，虽然解决计算资源和存储资源的合理分配的问题，但也常用来扩展了用户许可数。毕竟将数据服务和应用服务装在一台服务器上面只能满足百级的用户需求，而将数据服务和应用服务分开的二层模式，就可以满足千级的用户需求。

在二层模式下，大量用户必须访问同一个应用源地址，才能在日常繁杂的应用维护中，减少维护的成本。这样，就在所有的应用服务器和客户端之间，加上了负载均衡，这种网络服务器。它通过SNAT发布的虚拟地址，满足了上面的需求。

但同时，也将客户与应用服务器的直接对话，替换成了，负载均衡服务器与客户端，和负载均衡服务器与应用服务器段的通话。

在客户端访问负载均衡的虚拟地址的时候，通过网络的三次握手协议建立连接。

在负载均衡确认了客户端的真实性后，负载均衡再与应用服务器，也是通过网络的三次握手协议，建立连接，将应用服务器作为负载均衡的服务器池成员。再将客户端的数据转发到应用服务器。

这个看似满足解决了当下所有应用需求的方案，也存在的些不确定。

因为存在用户许可的情况下，应用服务器上的许可是视传递到的报文内的客户端个数。一般客户端直连服务器，是不可能达到应用服务器上的许可限制。但是，在存在负载均衡的两段握手协议的时候，对于应用服务器来说，传过来的报文，都是负载均衡一个客户端传来的报文。这样，一台应用服务器的许可就会很容易达到。为了解决这个问题，一是在客户端的csp程序中，增加了“X_FORWARDED_FOR”，如：if %request.GetCgiEnv("HTTP_X_FORWARDED_FOR")'="" s %request.CgiEnvs("REMOTE_ADDR")=%request.GetCgiEnv("HTTP_X_FORWARDED_FOR")；二是在负载均衡中增加配置。让应用服务器能够辨析真正的客户端源地址。

在负载均衡上配置客户端源

在这样的优化后，但还是由于存在两段握手协议，对于服务器来说，并不知道客户端是否还真实存在。在实际使用中，存在客户端已经与负载均衡失去连接，但是负载均衡与应用服务器还是存在连接，占据着之前的许可的情况。为了减少许可误占用的情况，不得使用在客户端和负载均衡上减少了连接有效期的方法，但是也存在不同应用对连接有效期有不同的需求，比如：检验系统不是经常需要客户操作的。

在csp上配置session有效期

在负载均衡上配置连接有效期

  要全面的解决这些问题，系统架构还有待进一步的优化。

  注：在实际使用中，有时会用csp sessions和负载均衡的show session来对照，客户端ip到应用服务器端的情况。这偶尔也有助于定位应用服务器连接的问题。