。可 能这些东西都太高深了，我们暂不做研究。
虽然Memcached作为一个分布式缓存数据服务，但是每个服务之间根本没有进行相互通信，这里可能与 我理解的分布式有点区别，可能是我才疏学浅，也可能是每个人思考问题的角度不同。Memcached客户端就是通过一种分布式算法将数据保存到不同的Memcached服务器上，将数据进行缓存。
Memcached分布式环境下，每个服务器端本身没有相互相连的关系，数据分布其实是由客户端来维持的（通俗点说，是客户端按照自己的分布算法，将数据分配 给指定的服务端去存储，取值的时候，客户端再找指定的服务器拿数据。任何环境下，服务端都不可能主动去找客户端拿“东西”或者去操作客户端。B/S模式也 是的，web服务器不可能主动找浏览器拿东西，更不可能对浏览器端做任何操作）。memcached的服务端更不会这么聪明，自动去查找、匹配当前环境 中分布的其他服务器。
而且，据我所知，Memcached本身并没有为集群提供真的高可用方案，因为我个人认为，使用集群环境，通常是为了满足以下的需求：
1.压力分载 （负载均衡） 2.失效转发（故障转移）。
而memcached本身并不具备这两点，这对于以“分布式缓存”号称的memcached来说，是非常致命的。对于笔者来说，也是一种沉痛的打击啊（o(∩_∩)o 哈哈）。
理论上来讲，客户端连接多个memcached服务端的时候，，默认的数据分布是这样的：
理论上的，%33+33%+34%=100%，看上去数据分布还还很均衡，读取的时候，分别访问从三台服务器内存，再组成完整的数据。这样的数据分发架构，倒真正做到了“负载均衡”。降低了三台服务器的内存使用率，让三台服务器同时为客户端提供服务，这难道不是完美的负载均衡吗？如果没有配置监视工具，也可以参照下面的代码：
public void testMemcachedProviders(){int runs = 100;int start = 200;string keyBase = "testKey";string obj = "This is a test of an object blah blah es, serialization does not seem to slow things down so much. The gzip compression is horrible horrible performance, so we only use it for very large objects. I have not done any heavy benchmarking recently";//Response.Write(obj);//循环记时往服务器缓存上插入数据 等会我们要观察一下数据都存到哪个服务器上的Memcached server上了long begin = DateTime.Now.Ticks;for (int i = start; i < start + runs; i++){// DistCache.Add(keyBase + i, obj);}long end = DateTime.Now.Ticks;long time = end – begin;//计算存储这些数据花了多长时间//Response.Write(runs + " sets: " + new TimeSpan(time).ToString() + "ms"+"<br/>");//开始取数据，并记时begin = DateTime.Now.Ticks;int hits = 0;int misses = 0;for (int i = start; i < start + runs; i++){string str = (string)DistCache.Get(keyBase + i);if (str != null)++hits; //成功取到数据else++misses; //丢失次数}end = DateTime.Now.Ticks;time = end – begin;//获取这些数据花了多长时间Response.Write(runs + " gets: " + new TimeSpan(time).ToString() + "ms"+"<br/>");Response.Write("Cache hits: " + hits.ToString() + "<br/>");Response.Write("Cache misses: " + misses.ToString() + "<br/>");Response.Write("——————————————————–\r\n");}使用上面的测试代码，可以打印输出处理时间，get/set次数。分别注释掉配置文件中指定memcached服务器配置后，再读取测试，可以清楚的看到数据分布比例。
我本地开启了3个memcached服务，分别指向不同端口，数据的分布比例是这样的： 37%，43%，20%。没有理论上的那么均衡。
有过分布式集群架构的朋友，肯定会想到，那万一发生了“单点故障”（就像sqlserver集群中的，单个节点上的数据库服务器宕机），那不是玩完了？
按照上图所示，一台服务器宕机了，就有33%的数据丢失了。那不就玩完了。如果是某银行采用这种架构，发生如此杯具，那架构师岂不是要被群众拿刀砍死。
那到底该如何解决这个问题呢？我翻阅了很多中文甚至英文的资料，好像真的没有官方或者很权威的解决方案。提供了如下两种思路。
解决方案1：本地备份缓存 在本地放一份缓存，同时也在分布式Memcached上放一份缓存，如果当其中一台节点当机了，客户端程序直接读取本地的缓存，本地客户端维护一个HashMap即可，这样的方案虽然很简陋，但是可以满足一部分场景的需要，当你很急需的时候可以作为临时方案暂时替代一下。
解决方案2：采用缓存代理服务器 采用 Magent 缓存代理，防止单点现象，缓存代理也可以做备份，通过客户端连接到缓存代理服务器，缓存代理服务器连接缓存服务器，缓存代理服务器可以连接多台Memcached机器可以将每台Memcached机器进行数据同步。这样的架构比较完善了，如果其中一台缓存代理服务器down机，系统依然可以继续工作，如果其中一台Memcached机器down掉，数据不会丢失并且可以保证数据的完整性，以上描述的系统架构如图所示：
在笔者的实践中，沿袭了第一种方案的思想。由于笔者项目使用的是windows的服务器，而第二种方案中的magent代理软件，好像只支持linux平台。
在客户端还是配置多台服务器，但是让其中任意的一台服务器做备份，去读取并append另外几台服务器的数据，这样依赖，该台备份服务器上就始终存储了一份完整的数据。当发生意外情况的时候，直接读取备份服务器上的数据。等服务器故障恢复后，再从客户端，将数据合理的分发出去。
有一些喷着香水闻不到的空气，有一些在写字楼里永远遇不见的人。
