关于memcached的那些事儿

一、前言

目前，memcached + mysql的这种存储组合，被广泛地应用到“读多写少”的应用场景上。那么在使用memcached的时候，我们需要注意哪些问题呢？

下面我们来探讨下使用memcached时候应该注意的问题或者可能遇到的问题。（以下简称mc）

二、什么时候需要引入mc

这是一个非常简单的问题，当我们的系统性能下降的时候，我们首先要做的就是找出系统的性能瓶颈在哪里。

如何发现cache可以帮助解决问题，那我们就可以考虑引入mc。

一般来讲，mc的作用在于提高响应时间和提高服务的并发性能。

从响应时间的角度看，mc的一次存取时间大概是1-2ms，而mysql的存取时间很多时候是与硬盘的存取时间相关。

mysql本身也有自己的cache，如果存取操作不涉及磁盘的访问，那么mysql的响应时间和mc的响应时间相差无几。

但是如果mysql的cache失效，那么mysql的响应时间则很大程度上依赖于硬盘的访问时间。目前，一块普通的机械硬盘的随机访问时间大概是8-10ms。

从并发性能的角度看，mc单个实例的并发处理性能大概在40w/s左右，而mysql的单实例并发处理性能仅为2000/s左右。

注：这里的处理性能和系统的资源也是相关。

三、使用什么样的内容更新策略

一般来讲，mc的缓存更新策略主要有write-back和write-through两种。

对于，这两种策略的具体流程这里不在累述。

write-back只有在数据被访问到的时候才会被写入cache，所以这种策略相对来讲会节省内存，数据更新操作的时候时间也会比较短。

但是，它势必会影响缓存的命中率，在高并发的情况下尤其突出。

write-through则是在数据被创建或者更新的时候就直接写入cache，所以数据更新操作的时间会略长，内存的使用量也较多。

但是，如果并发很高，而且更新的数据很快会被使用，那么这种策略是一种不错的选择。

四、如何处理批量读取的问题

在mc的实际应用中，我们可能需要多次读取缓存中的数据才能够获取我们所需要的资源，也即multiget问题。

当我们需要获取100份缓存数据的时候，以一次读取1ms的时间进行计算，如果是同步进行处理需要100ms，所以为了提高并发读取的性能，我们可以选择异步读取的机制。

五、如何扩展mc

当我们的系统运行一段时间后，不可避免地会出现扩容或者减少mc服务器的情况，那么我们应该如何设计mc服务的扩展性呢？

一个很普通的策略就是使用一致性hash策略，但是普通的一致性hash策略会导致memcached服务器的分布不均匀，memcached黑洞问题，memcached闪断造成的数据不一致等问题。

因此我们使用memcached的时候需要设计好如何对memcached进行扩展。

六、mc上线后如何进行评估和监控

mc上线后，我们需要评估我们的缓存是否提高了系统的整体性能，mc的缓存命中率是多少，是否符合我们的预期，内存的利用率是多少。

同时，随着mc性能指标的变化，我们还需要对mc的服务进行调整。

例如：

缓存命中率下降，但是内存的利用率很高时，我们需要如何进行处理？

缓存命中率下降的同时，内存的利用率也在下降的时候，我们需要如何进行处理？

巴特西