一直都是memcachedb+magent处理一个存储的需求，达到400G的内容，都是一个db，我发现这个已经导致了两块硬盘的ba gong，不知道是因为他们比较老了折腾不了了还是这个架构的问题导致大数据文件的读写有难度而崩垮了。。

原先的方案是：



A和B都备有500G左右的空间，可也挺浪费的，500G空间做备份，而很不幸，如果发生问题，切换到备用的服务器后，再建立一个新的备用就得复制这500G的文件了，这个并不是好事情，而且这里面不好的地方是，只有一半的空间有用。

改良方案：

利用分布式存储的优势，建立magent的多源方式



也就是用多个服务器解决存储的问题，这样500G的数据，分到一个数据库的数据压力都平分了，不担心大文件的问题，也可以在一个节点出问题的时候换上另外一个服务器，但这里就导致备份的问题了。

一些问题：

1 magent有备份服务器的时候，所有的写操作都会发送到备份，那备份的机器就并没法达到减小文件的作用了。
2 magent是hash算法，key对应固定的节点，对应的是A则永久的对应为A，不会在A机器挂掉后自动调节对应关系，而是请求备份机器，如果没有备份，单节点失败则影响该节点的存储

也就是说，备份是必须的，但如果使用一样的方式，备份并没有改善。
那可以启用memcached作为备份，有下面的好处：

1 只占用固定的内存数量
2 可以应对不断的存储需求，自动把前面的存储内容清理掉
3 可以应对短时间的节点失败

我们看看这个方案的过程：

1 存储key1时magent会计算那个服务器(A)存储key1，存储key1到A，存储到备份E
2 存储key2时要存到B，但B节点失败，存储到E
3 读取key1，从A读取
4 读取key2，从B读取，节点失败，从E读取
5 B恢复后，读写B，备份只存储

注意到一个问题，备份只保持存储的数据有一定的时效，如果存储请求很多并且分配的内存很小，可能在短时间就被替换了，而读取会失败，所以备份只是保证访问能够一定程度正常，并非保证数据的完整性。