配置客户机到服务器的对象持久性

　　在一些情况下,比如对应用服务器的负载均衡,从一个用户通常会发出多个连接来完成整个交易。一些网站就需要将同一个客户端发出的多个连接分配到同一台服务器上。比如,需要将A客户机与一号服务器相对应,B客户机与二号服务器相对应,而C客户机则可对应任何服务器,等等。
　　导致如此进行配置的因素多种多样,最常见是由“会话”(session)或“会话状态”(session state)引起的。想象一个访问某电子商务网站的用户,正在将各类中意的商品装进“购物车”中。如果这个网站是由数台原始服务器向客户提供服务的,那么在一个访客“购物”期间,就必须存在这样一个规定——即所有对其服务的原始服务器都该对“购物车”中有什么物品有明确了解。否则,已存入“购物车”中的商品就会因每次对客户进行服务的原始服务器的不同时而出现,时而消失。你可以想象,这样的状况会给购物之中的客户造成多大的困扰啊!
　　从专业角度讲,上述情况中的这个购物者在将第一件选中的商品放入“购物车”时就创造了一个包含所选商品的会话状态。只要他可以随机任意地向不同的原始服务器提出请求(当然购物者自己意识不到这一点),对话状况就必须以某种方式在服务器之间进行复制,以使它们都对其“购物车”中有什么物品有明确了解。就目前而言,快速而可靠地完成这项任务并非易事,极大的牵扯到一个站点的基础设施和代码问题。
　　幸运的是,aiCache对这个用户请求在服务器间分配的难题有了更简单的解决方法:只需要在用户进行某项操作(如选了一件商品放入购物车)后,将其客户机与指定的一台服务器相连。当我们利用这项通常被称为“原始服务器的对象持久性”技术(origin server persistence)时,一台给定的客户机往往将与特定的一台原始服务器相对应连接,而其它用户机则与其他的原始服务器对应相连,最终依然由所有的服务器分担网络负载,不会出现负载不均的情况。
　　虽然发起这种对应关系的事件各不相同,但大部分都有一个共同点,即发起的请求和响应往往都是不可缓存的。
　　为了配置原始服务器的对象持久性(origin server persistence),你需要在aiCache配置文件的websete部分指定参数os_persist的值。该参数的值(即cookie名称)是可选的,默认情况下是“x_aicache_osp”。
　　下面我们为您介绍它是如何工作。当客户进行第一次请求时,客户HTTP请求(不带cookie)进入aiCache,aiCachee将请求发送至该服务器,并将后端服务器响应的信息作为作为cookie的值发给请求的客户机。当客户请求再次发生时,客户HTTP请求(带有上次aiCache重写的cookie)进入aiCache,然后aiCache读出cookie里的保存的值,将HTTP请求(带有与上面同样的cookie)尽可能地直接发到指定的服务器。而对于那些可缓存的请求,当需要第一次缓存或者刷新缓存,仍然被aiCache的负载均衡机制合理的发送到其中一个服务器。
　　如果请求的服务器不可用——健康检查(health check)未启用或者请求无法成功到达该服务器,aiCache就会通过常规循环选出一个新的服务器,发出请求的访问者也会因为新的Cookie响应报头而发现是另一台服务器在为自己服务。当然,如果原始服务器无法响应,存在的会话状态就会丢失,用户就需要重新登入,重新挑选商品了,但幸好原始服务器响应失败的情况并不常见,概率极低。与之相比,使用这项技术的好处要大得多——原始服务器之间再也不需要复制会话状态,整个系统得到很好的简化。