阿里架构师经验分享！java个人简历录入程序

前言

前几日有个小老弟找我哭诉，挤破脑袋进Alibaba，三轮技术下来倒在了**缓存技术（Redis+MongDB）**上。听完我这小老弟的一番肺腑之言，这…缓存架构技术：Redis+MongDB，不就是阿里P7面试必跳的坑？跳不过去那就只能say godbye了，在坑里“等死”呀…紧接着…吾日三省吾身，突然发现自己掌握的好像也不咋滴，不得不回家好好“补一补”。

熬了三天三夜，四处收集缓存架构相关的：Redis+MongDB面试、实战等等笔记资料，完事之后感觉还不错呢，今天特地拿出来献宝~~

InnoDB总体结构

首先我们来看官网的一张图(图片来源于MySQL官网)：

从上图中可以看出其主要分为两部分结构，一部分为内存中的结构(上图左边)，一部分为磁盘中的结构(上图右边)

内存结构

InnoDB内存中的结构主要分为：Buffer Pool,Change Buffer和Log Buffer三部分。

Buffer Pool

Buffer Pool是InnoDB缓存表和索引的一块主内存区域，Buffer Pool允许直接从内存中处理经常使用的数据，从而加快处理速度，带来一定的性能提升。 但是缓存总有放满的时候，当缓存满了新来的数据怎么处理呢？Bufer Pool中采用的是LRU(least recently used，最近最少使用)算法，LRU列表中最前面存的是高频使用页，尾部放的是最少使用的页。当有新数据过来而缓存满了就会覆盖尾部数据。

假如我们有一条查询语句非常大，返回的结果集直接就超过了Buffer Pool的大小，而这种语句使用场景又是极少的，可能查询这一次之后很久不会查询，而这一次就将缓存占满了，将一些热点数据全部覆盖了。为了避免这种情况发生，InnoDB对传统的LRU算法又做了改进，将LRU列表分拆分为2个，如下图(图片来源于MySQL官网)：

该算法在new子列表中保留大量页面(5/8),old子列表包含较少使用的页面(3/8);old子列表中数据可能会被覆盖，该算法具体操作如下：

• 3/8的Buffer Pool空间用于old子列表

• 列表的中点是new子列表的尾部与old子