设计更稳定更可靠的有状态服务-引言
最近总在考虑一个分布式缓存的方案，大概题目叫“设计更稳定更可靠的有状态服务”吧，因为我觉得那些七层负载交换机的功能咱们也能做，而且要构建大压力的在线服务应用，还要保证稳定性和连续的工作能力，需要考虑很多的事情，借此也梳理一下思路，这篇帖子应该只考虑服务的可伸缩性和可用性的提高，不考虑高并发、高吞吐量和高响应性。
大概要解决如下的问题
1、如何更合理的分流：这里要考虑到如何把非常大的请求进行水平分区，分派到不同的服务器上，而且不能让忙的服务器更忙，闲的服务器更闲，而且不能让同一个客户端的请求一会儿到这个服务器，一会儿到另一个服务器，因为这里说的服务器是有状态的，如果请求被分派到了错误的服务器，那个服务器上没有该用户的状态（缓存），就不能为该用户服务了。这里我想做一个自己的负载均衡的服务，要先了解一下application center等软负载和F5等应负载设备的原理
2、状态之间的同步：为了防止一台机器挂掉会让在线用户全部掉线的现象，同一个用户的状态要考虑缓存到多台cache server上，多台cache server上的状态如何同步要设计一个很好的策略。
3、用户如何更准的找到自己的状态：用户登录到一台服务器上，它的状态有可能分布在本机的本进程内，有可能分布在另一台机器上，要设计一种静态哈希算法来解决这个问题，要让用户优先访问本地的缓存，如果本地没有再到远程机器上去拿到状态的副本来为用户的请求服务。或者是不把缓存拉过来，而是把请求重定向到保存它状态的服务器上，然后再想法保证以后用户的请求直接请求到那台服务器上，这里要为每个请求创建动态的路由表。每个cache server应该同时也有处理请求的能力，并且分派到本机的用户请求尽量要访问本地的状态。
4、多台cache server里的一台挂掉了要保证用户不掉线：为了保证服务的可用性，每个用户的状态应该至少保存在两台cache server上，这里肯定要有冗余数据，而且要尽量用内存缓存，而不是数据库缓存或者磁盘缓存。如果请求被分派到一台机器，而这台机器挂了，入口的分派服务器要检测到这种情况，可以用轮询去判断各服务器的可用性，而客户端要有重发机制，如果一个请求迟迟没有应答，可能它的请求被分派到一台不可用的IP上，过会儿重发的时候，分派服务器也许已经知道那个IP已经不可用了，会把本该分派到那个IP的请求分派到一个和那个IP公用cache的另一台机器上，因为另一台机器保存着挂掉的机器的用户状态，所以可以处理那部分用户的请求。但短时间内该机器的负荷会翻倍，它既要处理本来分派给自己的请求，又要处理本来要分派给挂掉机器的请求，所以在要保证平时每台机器的负荷要有一倍的buffer。每台机器既处理分配给自己的请求和保存这些请求的状态，同时又要保存另一台机器的状态副本。
5、挂掉的机器又重新起来后要尽快的拿到请求：离线的机器重新在线后要尽快把原本应该属于自己的流量拿过来，可以在这个服务启动的时候去自己的状态副本服务器上把用户的状态拉过来，然后告诉分派服务器自己可用了，让分配服务器把流量分派过来。
大概想到的就是这几个问题吧，有遗漏的再补充。