Memcached缓存,深入分析解读MySQL锁,解决幻读问题

最近版本,增加了虚拟节点的设计,进一步提升了可用性。

memcached仅支持基础的key-value键值对类型数据存储

在memcached内存结构中有两个非常重要的概念:slab和chunk

Memcached缓存,深入分析解读MySQL锁,解决幻读问题

slab是一个内存块,是memcached一次申请内存的最小单位

在启动memcached的时候一般会使用参数-m指定其可用内存,但并非在启动的那一刻所有的内存就全部分配,只有在需要的时候才会去申请,而且每次申请一定是一个slab

slab的大小固定为1M,一个slab由若干个大小相等的chunk组成

每个chunk中都保存了一个item结构体、一对key/value

虽然在同一个slab中chunk的大小相等的,但是在不同的slab中chunk的大小并不一定相等

在memcached中按照chunk的大小不同,可以把slab分为很多种类(class),默认情况下memcached把slab分为40类(class1~class40),在class 1中,chunk的大小为80字节,由于一个slab的大小是固定的1M,因此在class1中最多可以有13107个chunk(也就是这个slab能存最多13107个小于80字节的key-value数据)

memcached内存管理采取预分配、分组管理

  • 分组管理就是我们上面提到的slab class,按照chunk的大小slab被分为很多种类

  • 内存预分配过程是怎样的呢?

向memcached添加一个item时候,memcached首先会根据item的大小,来选择最合适的slab class

计算好所要放入的chunk之后

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

,memcached会去检查该类大小的chunk还有没有空闲

  • 如果没有,将会申请1M(1个slab)的空间并划分为该种类chunk

例如我们第一次向memcached中放入一个190字节的item时,memcached会产生一个slab class 2(也叫一个page),并会用去一个chunk,剩余5241个chunk供下次有适合大小item时使用,当我们用完这所有的5242个chunk之后,下次再有一个在160~200字节之间的item添加进来时,memcached会再次产生一个class 5的slab(这样就存在了2个pages)

总结来看,memcached内存管理需要注意

  • chunk是在page里面划分的,page固定为1m,所以chunk最大不能超过1m

  • chunk实际占用内存要加48B,因为chunk数据结构本身需要占用48B

  • 如果用户数据大于1m,则memcached会将其切割,放到多个chunk内

  • 已分配出去的page不能回收

**对于key/value信息,最好不要超过1m的大小

同时信息长度最好相对是比较均衡稳定的,这样能够保障最大限度的使用内存

同时,memcached采用的LRU清理策略,合理甚至过期时间,提高命中率**

无特殊场景下,key-value能满足需求的前提下,使用memcached分布式集群是较好的选择,搭建与操作使用都比较简单

分布式集群在单点故障时,只影响小部分数据异常,目前还可以通过Magent缓存代理模式,做单点备份,提升高可用

整个缓存都是基于内存的,因此响应时间是很快,不需要额外的序列化、反序列化的程序,但同时由于基于内存,数据没有持久化,集群故障重启数据无法恢复

上一篇:完成Pipeline。-- 代码源自虎哥博客。感谢


下一篇:学习笔记——SAM