缓冲buffer

缓冲池(buffer pool)，这次彻底懂了！！！_shenjian58的博客-CSDN博客

应用系统分层架构，为了加速数据访问，会把最常访问的数据，放在缓存(cache)里，避免每次都去访问数据库。

 

操作系统，会有缓冲池(buffer pool)机制，避免每次访问磁盘，以加速数据的访问。

 

MySQL作为一个存储系统，同样具有缓冲池(buffer pool)机制，以避免每次查询数据都进行磁盘IO。

今天，和大家聊一聊InnoDB的缓冲池。

 

InnoDB的缓冲池缓存什么？有什么用？

缓存表数据与索引数据，把磁盘上的数据加载到缓冲池，避免每次访问都进行磁盘IO，起到加速访问的作用。

 

速度快，那为啥不把所有数据都放到缓冲池里？

凡事都具备两面性，抛开数据易失性不说，访问快速的反面是存储容量小：

（1）缓存访问快，但容量小，数据库存储了200G数据，缓存容量可能只有64G；

（2）内存访问快，但容量小，买一台笔记本磁盘有2T，内存可能只有16G；

因此，只能把“最热”的数据放到“最近”的地方，以“最大限度”的降低磁盘访问。

 

如何管理与淘汰缓冲池，使得性能最大化呢？

 

在介绍具体细节之前，先介绍下“预读”的概念。

 

什么是预读？

磁盘读写，并不是按需读取，而是按页读取，一次至少读一页数据（一般是4K），如果未来要读取的数据就在页中，就能够省去后续的磁盘IO，提高效率。

 

预读为什么有效？

数据访问，通常都遵循“集中读写”的原则，使用一些数据，大概率会使用附近的数据，这就是所谓的“局部性原理”，它表明提前加载是有效的，确实能够减少磁盘IO。

 

按页(4K)读取，和InnoDB的缓冲池设计有啥关系？

（1）磁盘访问按页读取能够提高性能，所以缓冲池一般也是按页缓存数据；

（2）预读机制启示了我们，能把一些“可能要访问”的页提前加入缓冲池，避免未来的磁盘IO操作；

 

InnoDB是以什么算法，来管理这些缓冲页呢？

最容易想到的，就是LRU(Least recently used)。

画外音：memcache，OS都会用LRU来进行页置换管理，但MySQL的玩法并不一样。

 

传统的LRU是如何进行缓冲页管理？

 

最常见的玩法是，把入缓冲池的页放到LRU的头部，作为最近访问的元素，从而最晚被淘汰。这里又分两种情况：

（1）页已经在缓冲池里，那就只做“移至”LRU头部的动作，而没有页被淘汰；

（2）页不在缓冲池里，除了做“放入”LRU头部的动作，还要做“淘汰”LRU尾部页的动作；

 

如上图，假如管理缓冲池的LRU长度为10，缓冲了页号为1，3，5…，40，7的页。

 

假如，接下来要访问的数据在页号为4的页中：

（1）页号为4的页，本来就在缓冲池里；

（2）把页号为4的页，放到LRU的头部即可，没有页被淘汰；

画外音：为了减少数据移动，LRU一般用链表实现。

 

假如，再接下来要访问的数据在页号为50的页中：

（1）页号为50的页，原来不在缓冲池里；

（2）把页号为50的页，放到LRU头部，同时淘汰尾部页号为7的页；

 

传统的LRU缓冲池算法十分直观，OS，memcache等很多软件都在用，MySQL为啥这么矫情，不能直接用呢？

这里有两个问题：

（1）预读失效；

（2）缓冲池污染；

 

什么是预读失效？

由于预读(Read-Ahead)，提前把页放入了缓冲池，但最终MySQL并没有从页中读取数据，称为预读失效。

 

如何对预读失效进行优化？

要优化预读失效，思路是：

（1）让预读失败的页，停留在缓冲池LRU里的时间尽可能短；

（2）让真正被读取的页，才挪到缓冲池LRU的头部；

以保证，真正被读取的热数据留在缓冲池里的时间尽可能长。

 

具体方法是：

（1）将LRU分为两个部分：

• 新生代(new sublist)

• 老生代(old sublist)

（2）新老生代收尾相连，即：新生代的尾(tail)连接着老生代的头(head)；

（3）新页（例如被预读的页）加入缓冲池时，只加入到老生代头部：

• 如果数据真正被读取（预读成功），才会加入到新生代的头部

• 如果数据没有被读取，则会比新生代里的“热数据页”更早被淘汰出缓冲池

 

举个例子，整个缓冲池LRU如上图：

（1）整个LRU长度是10；

（2）前70%是新生代；

（3）后30%是老生代；

（4）新老生代首尾相连；

 

假如有一个页号为50的新页被预读加入缓冲池：

（1）50只会从老生代头部插入，老生代尾部（也是整体尾部）的页会被淘汰掉；

（2）假设50这一页不会被真正读取，即预读失败，它将比新生代的数据更早淘汰出缓冲池；

 

假如50这一页立刻被读取到，例如SQL访问了页内的行row数据：

（1）它会被立刻加入到新生代的头部；

（2）新生代的页会被挤到老生代，此时并不会有页面被真正淘汰；

 

改进版缓冲池LRU能够很好的解决“预读失败”的问题。

画外音：但也不要因噎废食，因为害怕预读失败而取消预读策略，大部分情况下，局部性原理是成立的，预读是有效的。

 

新老生代改进版LRU仍然解决不了缓冲池污染的问题。

 

什么是MySQL缓冲池污染？

当某一个SQL语句，要批量扫描大量数据时，可能导致把缓冲池的所有页都替换出去，导致大量热数据被换出，MySQL性能急剧下降，这种情况叫缓冲池污染。

 

例如，有一个数据量较大的用户表，当执行：

select * from user where name like "%shenjian%";

虽然结果集可能只有少量数据，但这类like不能命中索引，必须全表扫描，就需要访问大量的页：

（1）把页加到缓冲池（插入老生代头部）；

（2）从页里读出相关的row（插入新生代头部）；

（3）row里的name字段和字符串shenjian进行比较，如果符合条件，加入到结果集中；

（4）…直到扫描完所有页中的所有row…

 

如此一来，所有的数据页都会被加载到新生代的头部，但只会访问一次，真正的热数据被大量换出。

 

怎么这类扫码大量数据导致的缓冲池污染问题呢？

MySQL缓冲池加入了一个“老生代停留时间窗口”的机制：

（1）假设T=老生代停留时间窗口；

（2）插入老生代头部的页，即使立刻被访问，并不会立刻放入新生代头部；

（3）只有满足“被访问”并且“在老生代停留时间”大于T，才会被放入新生代头部；

 

继续举例，假如批量数据扫描，有51，52，53，54，55等五个页面将要依次被访问。

 

如果没有“老生代停留时间窗口”的策略，这些批量被访问的页面，会换出大量热数据。

 

加入“老生代停留时间窗口”策略后，短时间内被大量加载的页，并不会立刻插入新生代头部，而是优先淘汰那些，短期内仅仅访问了一次的页。

 

而只有在老生代呆的时间足够久，停留时间大于T，才会被插入新生代头部。

 

上述原理，对应InnoDB里哪些参数？

有三个比较重要的参数。

参数：innodb_buffer_pool_size

介绍：配置缓冲池的大小，在内存允许的情况下，DBA往往会建议调大这个参数，越多数据和索引放到内存里，数据库的性能会越好。

 

参数：innodb_old_blocks_pct

介绍：老生代占整个LRU链长度的比例，默认是37，即整个LRU中新生代与老生代长度比例是63:37。

画外音：如果把这个参数设为100，就退化为普通LRU了。

 

参数：innodb_old_blocks_time

介绍：老生代停留时间窗口，单位是毫秒，默认是1000，即同时满足“被访问”与“在老生代停留时间超过1秒”两个条件，才会被插入到新生代头部。

 

总结

（1）缓冲池(buffer pool)是一种常见的降低磁盘访问的机制；

（2）缓冲池通常以页(page)为单位缓存数据；

（3）缓冲池的常见管理算法是LRU，memcache，OS，InnoDB都使用了这种算法；

（4）InnoDB对普通LRU进行了优化：

• 将缓冲池分为老生代和新生代，入缓冲池的页，优先进入老生代，页被访问，才进入新生代，以解决预读失效的问题

• 页被访问，且在老生代停留时间超过配置阈值的，才进入新生代，以解决批量数据访问，大量热数据淘汰的问题

 

思路，比结论重要。

解决了什么问题，比方案重要。

写缓冲(change buffer)，这次彻底懂了！！！_shenjian58的博客-CSDN博客

上篇《缓冲池(buffer pool)，彻底懂了！》介绍了InnoDB缓冲池的工作原理。

 

简单回顾一下：

（1）MySQL数据存储包含内存与磁盘两个部分；

（2）内存缓冲池(buffer pool)以页为单位，缓存最热的数据页(data page)与索引页(index page)；

（3）InnoDB以变种LRU算法管理缓冲池，并能够解决“预读失效”与“缓冲池污染”的问题；

画外音：细节详见《缓冲池(buffer pool)，彻底懂了！》。

 

毫无疑问，对于读请求，缓冲池能够减少磁盘IO，提升性能。问题来了，那写请求呢？

 

情况一

假如要修改页号为4的索引页，而这个页正好在缓冲池内。

如上图序号1-2：

（1）直接修改缓冲池中的页，一次内存操作；

（2）写入redo log，一次磁盘顺序写操作；

这样的效率是最高的。

画外音：像写日志这种顺序写，每秒几万次没问题。

 

是否会出现一致性问题呢？

并不会。

（1）读取，会命中缓冲池的页；

（2）缓冲池LRU数据淘汰，会将“脏页”刷回磁盘；

（3）数据库异常奔溃，能够从redo log中恢复数据；

 

什么时候缓冲池中的页，会刷到磁盘上呢？

定期刷磁盘，而不是每次刷磁盘，能够降低磁盘IO，提升MySQL的性能。

画外音：批量写，是常见的优化手段。

 

情况二

假如要修改页号为40的索引页，而这个页正好不在缓冲池内。

此时麻烦一点，如上图需要1-3：

（1）先把需要为40的索引页，从磁盘加载到缓冲池，一次磁盘随机读操作；

（2）修改缓冲池中的页，一次内存操作；

（3）写入redo log，一次磁盘顺序写操作；

 

没有命中缓冲池的时候，至少产生一次磁盘IO，对于写多读少的业务场景，是否还有优化的空间呢？

 

这即是InnoDB考虑的问题，又是本文将要讨论的写缓冲(change buffer)。

画外音：从名字容易看出，写缓冲是降低磁盘IO，提升数据库写性能的一种机制。

 

什么是InnoDB的写缓冲？

在MySQL5.5之前，叫插入缓冲(insert buffer)，只针对insert做了优化；现在对delete和update也有效，叫做写缓冲(change buffer)。

 

它是一种应用在非唯一普通索引页(non-unique secondary index page)不在缓冲池中，对页进行了写操作，并不会立刻将磁盘页加载到缓冲池，而仅仅记录缓冲变更(buffer changes)，等未来数据被读取时，再将数据合并(merge)恢复到缓冲池中的技术。写缓冲的目的是降低写操作的磁盘IO，提升数据库性能。

画外音：R了狗了，这个句子，好长。

 

InnoDB加入写缓冲优化，上文“情况二”流程会有什么变化？

假如要修改页号为40的索引页，而这个页正好不在缓冲池内。

加入写缓冲优化后，流程优化为：

（1）在写缓冲中记录这个操作，一次内存操作；

（2）写入redo log，一次磁盘顺序写操作；

其性能与，这个索引页在缓冲池中，相近。

画外音：可以看到，40这一页，并没有加载到缓冲池中。

 

是否会出现一致性问题呢？

也不会。

（1）数据库异常奔溃，能够从redo log中恢复数据；

（2）写缓冲不只是一个内存结构，它也会被定期刷盘到写缓冲系统表空间；

（3）数据读取时，有另外的流程，将数据合并到缓冲池；

 

不妨设，稍后的一个时间，有请求查询索引页40的数据。

此时的流程如序号1-3：

（1）载入索引页，缓冲池未命中，这次磁盘IO不可避免；

（2）从写缓冲读取相关信息；

（3）恢复索引页，放到缓冲池LRU里；

画外音：可以看到，40这一页，在真正被读取时，才会被加载到缓冲池中。

 

还有一个遗漏问题，为什么写缓冲优化，仅适用于非唯一普通索引页呢？

InnoDB里，聚集索引(clustered index)和普通索引(secondary index)的异同，《1分钟了解MyISAM与InnoDB的索引差异》有详尽的叙述，不再展开。

 

如果索引设置了唯一(unique)属性，在进行修改操作时，InnoDB必须进行唯一性检查。也就是说，索引页即使不在缓冲池，磁盘上的页读取无法避免(否则怎么校验是否唯一？)，此时就应该直接把相应的页放入缓冲池再进行修改，而不应该再整写缓冲这个幺蛾子。

 

除了数据页被访问，还有哪些场景会触发刷写缓冲中的数据呢？

还有这么几种情况，会刷写缓冲中的数据：

（1）有一个后台线程，会认为数据库空闲时；

（2）数据库缓冲池不够用时；

（3）数据库正常关闭时；

（4）redo log写满时；

画外音：几乎不会出现redo log写满，此时整个数据库处于无法写入的不可用状态。

 

什么业务场景，适合开启InnoDB的写缓冲机制？

先说什么时候不适合，如上文分析，当：

（1）数据库都是唯一索引；

（2）或者，写入一个数据后，会立刻读取它；

这两类场景，在写操作进行时（进行后），本来就要进行进行页读取，本来相应页面就要入缓冲池，此时写缓存反倒成了负担，增加了复杂度。

 

什么时候适合使用写缓冲，如果：

（1）数据库大部分是非唯一索引；

（2）业务是写多读少，或者不是写后立刻读取；

可以使用写缓冲，将原本每次写入都需要进行磁盘IO的SQL，优化定期批量写磁盘。

画外音：例如，账单流水业务。

 

上述原理，对应InnoDB里哪些参数？

有两个比较重要的参数。

参数：innodb_change_buffer_max_size

介绍：配置写缓冲的大小，占整个缓冲池的比例，默认值是25%，最大值是50%。

画外音：写多读少的业务，才需要调大这个值，读多写少的业务，25%其实也多了。

 

参数：innodb_change_buffering

介绍：配置哪些写操作启用写缓冲，可以设置成all/none/inserts/deletes等。

1分钟了解MyISAM与InnoDB的索引差异_shenjian58的博客-CSDN博客

《数据库索引，到底是什么做的？》介绍了B+树，它是一种非常适合用来做数据库索引的数据结构：

(1)很适合磁盘存储，能够充分利用局部性原理，磁盘预读；

(2)很低的树高度，能够存储大量数据；

(3)索引本身占用的内存很小；

(4)能够很好的支持单点查询，范围查询，有序性查询；

 

数据库的索引分为主键索引（Primary Inkex）与普通索引（Secondary Index）。InnoDB和MyISAM是怎么利用B+树来实现这两类索引，其又有什么差异呢？这是今天要聊的内容。

 

一，MyISAM的索引

MyISAM的索引与行记录是分开存储的，叫做非聚集索引（UnClustered Index）。

其主键索引与普通索引没有本质差异：

• 有连续聚集的区域单独存储行记录

• 主键索引的叶子节点，存储主键，与对应行记录的指针

• 普通索引的叶子结点，存储索引列，与对应行记录的指针

画外音：MyISAM的表可以没有主键。

 

主键索引与普通索引是两棵独立的索引B+树，通过索引列查找时，先定位到B+树的叶子节点，再通过指针定位到行记录。

 

举个例子，MyISAM：

t(id PK, name KEY, sex, flag);

 

表中有四条记录：

1, shenjian, m, A

3, zhangsan, m, A

5, lisi, m, A

9, wangwu, f, B

其B+树索引构造如上图：

• 行记录单独存储

• id为PK，有一棵id的索引树，叶子指向行记录

• name为KEY，有一棵name的索引树，叶子也指向行记录

 

二、InnoDB的索引

InnoDB的主键索引与行记录是存储在一起的，故叫做聚集索引（Clustered Index）：

• 没有单独区域存储行记录

• 主键索引的叶子节点，存储主键，与对应行记录（而不是指针）

画外音：因此，InnoDB的PK查询是非常快的。

 

因为这个特性，InnoDB的表必须要有聚集索引：

(1)如果表定义了PK，则PK就是聚集索引；

(2)如果表没有定义PK，则第一个非空unique列是聚集索引；

(3)否则，InnoDB会创建一个隐藏的row-id作为聚集索引；

 

聚集索引，也只能够有一个，因为数据行在物理磁盘上只能有一份聚集存储。

 

InnoDB的普通索引可以有多个，它与聚集索引是不同的：

• 普通索引的叶子节点，存储主键（也不是指针）

 

对于InnoDB表，这里的启示是：

(1)不建议使用较长的列做主键，例如char(64)，因为所有的普通索引都会存储主键，会导致普通索引过于庞大；

(2)建议使用趋势递增的key做主键，由于数据行与索引一体，这样不至于插入记录时，有大量索引分裂，行记录移动；

 

仍是上面的例子，只是存储引擎换成InnoDB：

t(id PK, name KEY, sex, flag);

 

表中还是四条记录：

1, shenjian, m, A

3, zhangsan, m, A

5, lisi, m, A

9, wangwu, f, B

 

其B+树索引构造如上图：

• id为PK，行记录和id索引树存储在一起

• name为KEY，有一棵name的索引树，叶子存储id

 

当：

select * from t where name=‘lisi’;

会先通过name辅助索引定位到B+树的叶子节点得到id=5，再通过聚集索引定位到行记录。

画外音：所以，其实扫了2遍索引树。

 

三，总结

MyISAM和InnoDB都使用B+树来实现索引：

• MyISAM的索引与数据分开存储

• MyISAM的索引叶子存储指针，主键索引与普通索引无太大区别

• InnoDB的聚集索引和数据行统一存储

• InnoDB的聚集索引存储数据行本身，普通索引存储主键

• InnoDB一定有且只有一个聚集索引

• InnoDB建议使用趋势递增整数作为PK，而不宜使用较长的列作为PK

 数据库索引，到底是什么做的？_shenjian58的博客-CSDN博客

近期写数据库，不少朋友留言问MySQL索引底层的实现，今天简单聊一聊，少讲“是怎么样”，更多说说“为什么设计成这样”。

 

问题1. 数据库为什么要设计索引？

图书馆存了1000W本图书，要从中找到《架构师之路》，一本本查，要查到什么时候去？

于是，图书管理员设计了一套规则：

(1)一楼放历史类，二楼放文学类，三楼放IT类…

(2)IT类，又分软件类，硬件类…

(3)软件类，又按照书名音序排序…

以便快速找到一本书。

 

与之类比，数据库存储了1000W条数据，要从中找到name=”shenjian”的记录，一条条查，要查到什么时候去？

于是，要有索引，用于提升数据库的查找速度。

 

问题2. 哈希(hash)比树(tree)更快，索引结构为什么要设计成树型？

加速查找速度的数据结构，常见的有两类：

(1)哈希，例如HashMap，查询/插入/修改/删除的平均时间复杂度都是O(1)；

(2)树，例如平衡二叉搜索树，查询/插入/修改/删除的平均时间复杂度都是O(lg(n))；

 

可以看到，不管是读请求，还是写请求，哈希类型的索引，都要比树型的索引更快一些，那为什么，索引结构要设计成树型呢？

画外音：80%的同学，面试都答不出来。

 

索引设计成树形，和SQL的需求相关。

 

对于这样一个单行查询的SQL需求：

select * from t where name=”shenjian”;

确实是哈希索引更快，因为每次都只查询一条记录。

画外音：所以，如果业务需求都是单行访问，例如passport，确实可以使用哈希索引。

 

但是对于排序查询的SQL需求：

• 分组：group by

• 排序：order by

• 比较：<、>

• …

哈希型的索引，时间复杂度会退化为O(n)，而树型的“有序”特性，依然能够保持O(log(n)) 的高效率。

 

任何脱离需求的设计都是耍流氓。

 

多说一句，InnoDB并不支持哈希索引。

 

问题3. 数据库索引为什么使用B+树？

为了保持知识体系的完整性，简单介绍下几种树。

 

第一种：二叉搜索树

二叉搜索树，如上图，是最为大家所熟知的一种数据结构，就不展开介绍了，它为什么不适合用作数据库索引？

(1)当数据量大的时候，树的高度会比较高，数据量大的时候，查询会比较慢；

(2)每个节点只存储一个记录，可能导致一次查询有很多次磁盘IO；

画外音：这个树经常出现在大学课本里，所以最为大家所熟知。

 

第二种：B树

B树，如上图，它的特点是：

(1)不再是二叉搜索，而是m叉搜索；

(2)叶子节点，非叶子节点，都存储数据；

(3)中序遍历，可以获得所有节点；

画外音，实在不想介绍这个特性：非根节点包含的关键字个数j满足，(┌m/2┐)-1 <= j <= m-1，节点分裂时要满足这个条件。

 

B树被作为实现索引的数据结构被创造出来，是因为它能够完美的利用“局部性原理”。

 

什么是局部性原理？

局部性原理的逻辑是这样的：

(1)内存读写块，磁盘读写慢，而且慢很多；

(2)磁盘预读：磁盘读写并不是按需读取，而是按页预读，一次会读一页的数据，每次加载更多的数据，如果未来要读取的数据就在这一页中，可以避免未来的磁盘IO，提高效率；

画外音：通常，一页数据是4K。

(3)局部性原理：软件设计要尽量遵循“数据读取集中”与“使用到一个数据，大概率会使用其附近的数据”，这样磁盘预读能充分提高磁盘IO；

 

B树为何适合做索引？

(1)由于是m分叉的，高度能够大大降低；

(2)每个节点可以存储j个记录，如果将节点大小设置为页大小，例如4K，能够充分的利用预读的特性，极大减少磁盘IO；

 

第三种：B+树

B+树，如上图，仍是m叉搜索树，在B树的基础上，做了一些改进：

(1)非叶子节点不再存储数据，数据只存储在同一层的叶子节点上；

画外音：B+树中根到每一个节点的路径长度一样，而B树不是这样。

(2)叶子之间，增加了链表，获取所有节点，不再需要中序遍历；

 

这些改进让B+树比B树有更优的特性：

(1)范围查找，定位min与max之后，中间叶子节点，就是结果集，不用中序回溯；

画外音：范围查询在SQL中用得很多，这是B+树比B树最大的优势。

(2)叶子节点存储实际记录行，记录行相对比较紧密的存储，适合大数据量磁盘存储；非叶子节点存储记录的PK，用于查询加速，适合内存存储；

(3)非叶子节点，不存储实际记录，而只存储记录的KEY的话，那么在相同内存的情况下，B+树能够存储更多索引；

 

最后，量化说下，为什么m叉的B+树比二叉搜索树的高度大大大大降低？

大概计算一下：

(1)局部性原理，将一个节点的大小设为一页，一页4K，假设一个KEY有8字节，一个节点可以存储500个KEY，即j=500

(2)m叉树，大概m/2<= j <=m，即可以差不多是1000叉树

(3)那么：

一层树：1个节点，1*500个KEY，大小4K

二层树：1000个节点，1000*500=50W个KEY，大小1000*4K=4M

三层树：1000*1000个节点，1000*1000*500=5亿个KEY，大小1000*1000*4K=4G

画外音：额，帮忙看下有没有算错。

可以看到，存储大量的数据（5亿），并不需要太高树的深度（高度3），索引也不是太占内存（4G）。

总结

• 数据库索引用于加速查询

• 虽然哈希索引是O(1)，树索引是O(log(n))，但SQL有很多“有序”需求，故数据库使用树型索引

• InnoDB不支持哈希索引

• 数据预读的思路是：磁盘读写并不是按需读取，而是按页预读，一次会读一页的数据，每次加载更多的数据，以便未来减少磁盘IO

• 局部性原理：软件设计要尽量遵循“数据读取集中”与“使用到一个数据，大概率会使用其附近的数据”，这样磁盘预读能充分提高磁盘IO

• 数据库的索引最常用B+树：

(1)很适合磁盘存储，能够充分利用局部性原理，磁盘预读；

(2)很低的树高度，能够存储大量数据；

(3)索引本身占用的内存很小；

(4)能够很好的支持单点查询，范围查询，有序性查询；

虽然都是B+树，下一章，聊聊InnoDB和MyISAM的索引实现差异。

memcache内核，一文搞定！面试再也不怕了！！！（值得收藏）

memcache是互联网分层架构中，使用最多的的KV缓存。面试的过程中，memcache相关的问题几乎是必问的，关于memcache的面试提问，你能回答到哪一个层次呢？

画外音：很可能关乎，你拿到offer的薪酬档位。

 

第一类问题：知道不知道

这一类问题，考察用没用过，知不知道，相对比较好回答。

 

关于memcache一些基础特性，使用过的小伙伴基本都能回答出来：

（1）mc的核心职能是KV内存管理，value存储最大为1M，它不支持复杂数据结构（哈希、列表、集合、有序集合等）；

（2）mc不支持持久化；

（3）mc支持key过期；

（4）mc持续运行很少会出现内存碎片，速度不会随着服务运行时间降低；

（5）mc使用非阻塞IO复用网络模型，使用监听线程/工作线程的多线程模型；

 

面对这类封闭性的问题，一定要斩钉截铁，毫无犹豫的给出回答。

 

第二类问题：为什么(why)，什么(what)

这一类问题，考察对于一个工具，只停留在使用层面，还是有原理性的思考。

 

memcache为什么不支持复杂数据结构？为什么不支持持久化？

业务决定技术方案，mc的诞生，以“以服务的方式，而不是库的方式管理KV内存”为设计目标，它颠覆的是，KV内存管理组件库，复杂数据结构与持久化并不是它的初衷。

 

当然，用“颠覆”这个词未必不合适，库和服务各有使用场景，只是在分布式的环境下，服务的使用范围更广。设计目标，诞生背景很重要，这一定程度上决定了实现方案，就如redis的出现，是为了有一个更好用，更多功能的缓存服务。

画外音：我很喜欢问这个问题，大部分候选人面对这个没有标准答案的问题，状态可能是蒙圈。

 

memcache是用什么技术实现key过期的？

懒淘汰(lazy expiration)。

 

memcache为什么能保证运行性能，且很少会出现内存碎片？

提前分配内存。

 

memcache为什么要使用非阻塞IO复用网络模型，使用监听线程/工作线程的多线程模型，有什么优缺点？

目的是提高吞吐量。

多线程能够充分的利用多核，但会带来一些锁冲突。

 

面对这类半开放的问题，有些并没有标准答案，一定要回答出自己的思考和见解。

 

第三类问题：怎么做(how) | 文本刚开始

这一类问题，探测候选人理解得有多透，掌握得有多细，对技术有多刨根究底。

画外音：所谓“好奇心”，真的很重要，只想要“一份工作”的技术人很难有这种好奇心。

 

memcache是什么实现内存管理，以减小内存碎片，是怎么实现分配内存的？

 

开讲之前，先解释几个非常重要的概念：

chunk：它是将内存分配给用户使用的最小单元。

item：用户要存储的数据，包含key和value，最终都存储在chunk里。

slab：它会管理一个固定chunk size的若干个chunk，而mc的内存管理，由若干个slab组成。

画外音：为了避免复杂性，本文先不引入page的概念了。

 

如上图所示，一系列slab，分别管理128B，256B，512B…的chunk内存单元。

 

将上图中管理128B的slab0放大：

能够发现slab中的一些核心数据结构是：

• chunk_size：该slab管理的是128B的chunk

• free_chunk_list：用于快速找到空闲的chunk

• chunk[]：已经预分配好，用于存放用户item数据的实际chunk空间

画外音：其实还有lru_list。

 

假如用户要存储一个100B的item，是如何找到对应的可用chunk的呢？

会从最接近item大小的slab的chunk[]中，通过free_chunk_list快速找到对应的chunk，如上图所示，与item大小最接近的chunk是128B。

 

为什么不会出现内存碎片呢？

拿到一个128B的chunk，去存储一个100B的item，余下的28B不会再被其他的item所使用，即：实际上浪费了存储空间，来减少内存碎片，保证访问的速度。

画外音：理论上，内存碎片几乎不存在。

 

memcache通过slab，chunk，free_chunk_list来快速分配内存，存储用户的item，那它又是如何快速实现key的查找的呢？

没有什么特别算法：

• 通过hash表实现快速查找

• 通过链表来解决冲突

 

用最朴素的方式，实现key的快速查找。

 

随着item的个数不断增多，hash冲突越来越大，hash表如何保证查询效率呢？

当item总数达到hash表长度的1.5倍时，hash表会动态扩容，rehash将数据重新分布，以保证查找效率不会不断降低。

 

扩展hash表之后，同一个key在新旧hash表内的位置会发生变化，如何保证数据的一致性，以及如何保证迁移过程服务的可用性呢（肯定不能加一把大锁，迁移完成数据，再重新服务吧）？

 

哈希表扩展，数据迁移是一个耗时的操作，会有一个专门的线程来实施，为了避免大锁，采用的是“分段迁移”的策略。

 

当item数量达到阈值时，迁移线程会分段迁移，对hash表中的一部分桶进行加锁，迁移数据，解锁：

• 一来，保证不会有长时间的阻塞，影响服务的可用性

• 二来，保证item不会在新旧hash表里不一致

 

新的问题来了，对于已经存在与旧hash表中的item，可以通过上述方式迁移，那么在item迁移的过程中，如果有新的item插入，是应该插入旧hash表还是新hash表呢？

memcache的做法是，判断旧hash表中，item应该插入的桶，是否已经迁移至新表中：

• 如果已经迁移，则item直接插入新hash表

• 如果还没有被迁移，则直接插入旧hash表，未来等待迁移线程来迁移至新hash表

 

为什么要这么做呢，不能直接插入新hash表吗？

memcache没有给出官方的解释，楼主揣测，这种方法能够保证一个桶内的数据，只在一个hash表中（要么新表，要么旧表），任何场景下都不会出现，旧表新表查询两次，以提升查询速度。

 

memcache是怎么实现key过期的，懒淘汰(lazy expiration)具体是怎么玩的？

 

实现“超时”和“过期”，最常见的两种方法是：

• 启动一个超时线程，对所有item进行扫描，如果发现超时，则进行超时回调处理

• 每个item设定一个超时信号通知，通知触发超时回调处理

这两种方法，都需要有额外的资源消耗。

 

mc的查询业务非常简单，只会返回cache hit与cache miss两种结果，这种场景下，非常适合使用懒淘汰的方式。

 

懒淘汰的核心是：

• item不会被主动淘汰，即没有超时线程，也没有信号通知来主动检查

• item每次会查询(get)时，检查一下时间戳，如果已经过期，被动淘汰，并返回cache miss

 

举个例子，假如set了一个key，有效期100s：

• 在第50s的时候，有用户查询(get)了这个key，判断未过期，返回对应的value值

• 在第200s的时候，又有用户查询(get)了这个key，判断已过期，将item所在的chunk释放，返回cache miss

 

这种方式的实现代价很小，消耗资源非常低：

• 在item里，加入一个过期时间属性

• 在get时，加入一个时间判断

 

内存总是有限的，chunk数量有限的情况下，能够存储的item个数是有限的，假如chunk被用完了，该怎么办？

 

仍然是上面的例子，假如128B的chunk都用完了，用户又set了一个100B的item，要不要挤掉已有的item？

要。

 

这里的启示是：

（1）即使item的有效期设置为“永久”，也可能被淘汰；

（2）如果要做全量数据缓存，一定要仔细评估，cache的内存大小，必须大于，全量数据的总大小，否则很容易采坑；

 

挤掉哪一个item？怎么挤？

这里涉及LRU淘汰机制。

 

如果操作系统的内存管理，最常见的淘汰算法是FIFO和LRU：

• FIFO(first in first out)：最先被set的item，最先被淘汰

• LRU(least recently used)：最近最少被使用(get/set)的item，最先被淘汰

 

使用LRU算法挤掉item，需要增加两个属性：

• 最近item访问计数

• 最近item访问时间

并增加一个LRU链表，就能够快速实现。

画外音：所以，管理chunk的每个slab，除了free_chunk_list，还有lru_list。