【Memcached】数据缓存一致性问题详解

写在前面的

   首先来纠正一下我的观点错误，在之前的Memcached文章中介绍了一些基本的概念，其中有一条写到了“如果可以增加（或者无限制的增加）很多个结点的话，我们的存储压力会大大减小，丢失率会大大降低，某种意义上讲我们的存储效率就提高了很多。”但是当我偶然间看到一篇关于mem结点对效率的影响的文章的时候才发现之前的认识是错误的。无限制的增加Memcached的结点并不能提高我们数据的访问效率，相反，还有可能增大我们的存储压力。为什么这么说呢？我们往下看。

FaceBook的问题

   具体的例子就是FaceBook，大家都知道，世界上几大社交公司都在使用memcached，在FaceBook的官方对这个问题的描述是这样的：FaceBook在2009年以后，memcached结点就已经在飞速的增长，就是因为我们对结点的增加对存储效率也会产生积极影响这方面存在误区，所以到了2010年左右，我们的mem结点就已经突破了3000个，缓存的数据已经超过了几个T。但是，我们发现了一个问题，mem链接频率，和效率下降了，基于之前的认知，于是增加memcached结点，结果发现链接频率导致的问题仍然存在，并且几乎没有好转的迹象。

出现这种问题的原因

   首先我们从头来分析，对于我所了解的一些支持分布式存储的软件，比如：Mysql（数据库），Redis（缓存），Memcached（缓存），当然还有一些其他的软件基本都遵循了“高性能，高并发”的基本原则，并且通过取模或者一致性HASH来实现对不同“端口或IP”的存取。那么问题就来了，由于存储的数据是“分散化”存储，所以每一次的操作就可能存在需要和不同的结点进行交互来完成整个的操作，所以假设现在我们需要进行的操作需要和N多个结点进行交互，那么即使我们的数据库和缓存的性能再高，和N多个结点之间的互动也会降低效率，部署的结点越多，对性能的影响就越大，而这样的情况会在系统硬件性能不变的情况下更为突出。

解决的办法

   由于自己才学疏浅，自己去GITHUB和百度上找了找方法，总体来讲有两个方面：

• 1.优化数据分布
     通过进一步了解自己数据所属的业务范围，我们可以把数据存储分为两类，一种是适合Hash分布的，一种是范围分布，意思显而易见。

• 2.数据访问方式
     由于在我们的编程过程中对数据库的访问和操作通常会由数据集来承担，所以为了更好的优化性能，所以我们需要一次性尽可能的获取大数据集进行操作，避免多次去获取小数据集，这样就会减小我们的系统开销。

总结

   总之，缓存性能的优化存在于各个方面，像上述这样的情况基本在小型公司或者数据量不大的情况下很难出现，在我的工作环境中也基本不存在这样的情况，毕竟也就只有10多万的数据量，所以一般的操作mem还是可以满足的。但是，当你的数据量有可能超出系统设计预期又不想重新开发的时候就需要对缓存或者数据库进行优化设计了。