首页 > 代码库 > 关于memcached的那些事儿
关于memcached的那些事儿
一、前言
目前,memcached + mysql的这种存储组合,被广泛地应用到“读多写少”的应用场景上。那么在使用memcached的时候,我们需要注意哪些问题呢?
下面我们来探讨下使用memcached时候应该注意的问题或者可能遇到的问题。(以下简称mc)
- 什么时候需要引入mc
- 使用什么样的内容更新策略
- 内容批量读取的问题如何处理
- 如何扩展mc
- 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的服务进行调整。
例如:
缓存命中率下降,但是内存的利用率很高时,我们需要如何进行处理?
缓存命中率下降的同时,内存的利用率也在下降的时候,我们需要如何进行处理?
关于memcached的那些事儿