用好Cache，优化应用

核心提示： 4．数据恢复，当集群中某一节点失效后恢复时，用好Cache，优化应用(5)，其数据可能已经完全丢失，此时通过配置成为Active模式可以将其他节点上冗余的数据Lazy复制到该节点（获取一个复制一个，通过集群的lazy的修复方式，逐渐的将数据从冗余节点复制到新的节点上来，同时只支持一个冗余节

4．　数据恢复。当集群中某一节点失效后恢复时，其数据可能已经完全丢失，此时通过配置成为Active模式可以将其他节点上冗余的数据Lazy复制到该节点（获取一个复制一个，同时只支持一个冗余节点的数据获取(不采取遍历，防止低效)）。

Active模式拥有1,2,3,4的特性。Standby模式拥用1,2,3特性。（其实本来只考虑让Standby拥有1特性）。未来不排除还会有更多需要的特性加入。Active在key不存在的情况下会有些低效，因为会判断一个冗余节点是否存在内容，然后决定是否修复当前节点。（考虑采用短期失败标示之类的，不过效率不一定高，同时增加了复杂度）

运行期动态扩容部署

Memcached cache客户端算法中比较出名的是Concurrent Hashing算法，其目的也就是为了在节点增加或者减少以后，通过算法尽量减小数据重新分布的代价。采用虚拟节点，环状和二叉树等方式可以部分降低节点增加和减少对于数据分布的影响，但是始终还是有部分数据会失效，这点还是由于Memcached Cache是集中式Cache所决定的。

但如果有了Cache Cluster的话，数据有了冗余，就可以通过逐步修改集群中虚拟节点配置，达到对于单个虚拟节点的配置动态扩容。

支持动态部署前提：

配置文件动态加载。（配置文件可以在Classpath中，也可以是Http资源的方式）通过Cache Client 中Cache Manager可以停止Cache 服务，重新加载配置文件，即时生效。

当前动态部署的两种方式：

1.　　　　　　　　　　　　　 修改集群配置中某一套虚拟节点的服务实例配置（socketPool配置），增加或者减少后端数据存储实例。然后动态加载新的配置文件（可以通过指定远端的http配置作为新的配置文件），通过集群的lazy的修复方式，逐渐的将数据从冗余节点复制到新的节点上来，最终实现数据迁移。