缓存客户端集群

Memcached Cache是集中式Cache，它仅仅是支持将数据能够分片分区的存储到一台或者多台的Cache Server实例中，但是这些数据并没有作冗余，因此任何一个服务实例不可用，都会导致部分缓存数据丢失。当然很多人采取持久化等方式来保证数据的完整性，但是这种方式对于效率以及恢复的复杂性都会有影响。
简单的来想，为什么不把数据在多保存一份或者多份呢，当其中一份不可用的情况下，就用另外一份补上。这就是最原始的Cache Client Cluster的构想。

这张图上需要注意四个角色：web应用程序（使用Cache的应用），缓存集群（Cache配置的虚拟集群），缓存节点（Cache的虚拟节点，在同一个Cluster中的缓存数据保持完全一致），缓存实例（Cache虚拟节点中实际包含的Memcached Cache服务端实例）。
应用仅仅操作缓存节点，不了解具体数据存储或数据获取是操作哪一个缓存服务端实例。（这点也就是Memcached Cache可扩展性的基础设计）。缓存集群又将多个缓存节点组成了虚拟的集群，通过数据冗余，保证了服务可用性和数据完整性。
缓存客户端集群主要的功能点( 比如缓存客户端集群主要有两种配置模式：active 和 standby)：
1．容错。当被分配到读取或者操作数据的Cache虚拟节点不可用的情况下，集群其他节点支持代替错误节点服务于客户端应用。

2．数据冗余。当操作集群中某一个Cache虚拟节点时，数据会异步传播到其他集群节点。

3．软负载。客户端通过对操作的key作算法（比如采用简单的key hash再取余的方式）选择集群中的节点，达到集群中节点简单的负载分担。同时也由于这种模式，可以使得key都有默认的第一操作节点，此节点的操作保持时时更新，而其他节点可以通过客户端异步更新来实现效率提升。

4. 数据恢复。当集群中某一节点失效后恢复时，其数据可能已经完全丢失，此时通过配置成为Active模式可以将其他节点上冗余的数据Lazy复制到该节点（获取一个复制一个，同时只支持一个冗余节点的数据获取(不采取遍历，防止低效)）。
Active模式拥有1,2,3,4的特性。Standby模式拥用1,2,3特性。Active在key不存在的情况下会有些低效，因为会判断一个冗余节点是否存在内容，然后决定是否修复当前节点。（考虑采用短期失败标示之类的，不过效率不一定高，同时增加了复杂度）

 

运行期动态扩容部署 

Memcached cache客户端算法中比较出名的是Consistent Hashing算法，其目的也就是为了在节点增加或者减少以后，通过算法尽量减小数据重新分布的代价。采用虚拟节点，环状和二叉树等方式可以部分降低节点增加和减少对于数据分布的影响，但是始终还是有部分数据会失效，这点还是由于Memcached Cache是集中式Cache所决定的。
但如果有了Cache Cluster的话，数据有了冗余，就可以通过逐步修改集群中虚拟节点配置，达到对于单个虚拟节点的配置动态扩容。
支持动态部署前提：
配置文件动态加载。（配置文件可以在Classpath中，也可以是Http资源的方式）通过Cache Client 中Cache Manager可以停止Cache 服务，重新加载配置文件，即时生效。
当前动态部署的两种方式：
1.修改集群配置中某一套虚拟节点的服务实例配置，增加或者减少后端数据存储实例。然后动态加载新的配置文件（可以通过指定远端的http配置作为新的配置文件），通过集群的lazy的修复方式，逐渐的将数据从冗余节点复制到新的节点上来，最终实现数据迁移。

2.修改集群配置中某一套虚拟节点的服务实例配置，增加或者减少后端数据存储实例。然后动态加载新的配置文件（可以通过指定远端的http配置作为新的配置文件），在调用Cache Manager主动将数据由某一虚拟节点复制到指定的集群中，实现数据批量迁移，然后根据需要看是否需要修改其他几套虚拟节点配置。

 存在的问题：
1. 当前没有做到不停止服务来动态部署。

2. 不论是lazy复制还是批量数据迁移，都是会将原本有失效时间的数据变成了无失效时间的数据