先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024b (备注Java)
正文
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子列表的头部之间的边界
- 当InnoDB将一个页面读入缓冲池时,它首先将它插入到中间点(old子列表的头)。读取的页面是由用户发起的操作(比如SQL查询)或InnoDB自动执行的预读操作
- 访问old子列表中的页面使其“young”,并将其移动到new子列表的头部。如果读取的页是由用户发起的操作,那么就会立即进行第一次访问,并使页面处于young状态;如果读取的页是由预读发起的操作,那么第一次访问不会立即发生,而且可能直到覆盖都不会发生。
- 操作数据时,Buffer Pool中未被访问的页会逐渐移到尾部,最终会被覆盖。
默认情况下,查询读取的页面会立即移动到新的子列表中,这意味着它们在缓冲池中停留的时间更长。
Change Buffer
Change Buffer是一种特殊的缓存结构,用来缓存不在Buffer Pool中的辅助索引页, 支持insert, update,delete(DML)操作的缓存(注意,这个在MySQL5.5之前叫做Insert Buffer,仅支持insert操作的缓存)。当这些数据页被其他查询加载到Buffer Pool后,则会将数据进行merge到索引数据叶中。
InnoDB在进行DML操作非聚集非唯一索引时,会先判断要操作的数据页是不是在Buffer Pool中,如果不在就会先放到Change Buffer进行操作,然后再以一定的频率将数据和辅助索引数据页进行merge。这时候通常都能将多个操作合并到一次操作,减少了IO操作,尤其是辅助索引的操作大部分都是IO操作,可以大大提高DML性能。
如果Change Buffer中存储了大量的数据,那么可能merge操作会需要消耗大量时间。
为什么Change Buffer只能针对非聚集非唯一索引
因为如果是主键索引或者唯一索引,需要判断数据是否唯一,这时候就需要去索引页中加载数据判断而不能仅仅只操作缓存。
Change Buffer什么时候会merge
总体来说,Change Buffer的merge操作发生在以下三种情况:
- 辅助索引页被读取到Buffer Pool时。 当执行一条select语句时,会去检查当前数据页是否在Change Buffer中,如果在,就会把数据merge到索引页
- 该辅助索引页没有可用空间时。 InnoDB内部会检测辅助索引页是否还有可用空间(至少有1/32页),如果检测到当前操作之后,当前索引页剩余空间不足1/32时,会进行一次强制merge操作
- 后台线程Master Thread定时merge。 Master Thread是一个非常核心的后台线程,主要负责将缓冲池中的数据异步刷新到磁盘,保证数据的一致性。
Adaptive Hash Index
Adaptive Hash Index,自适应哈希索引。InnoDB引擎会监控对索引页的查询,如果发现建立哈希索引可以带来性能上的提升,就会建立哈希索引,这种称之为自适应哈希索引,InnoDB引擎不支持手动创建哈希索引。
Log Buffer
日志缓冲区是存储要写入磁盘日志文件的一块数据内存区域,大小由变量innodb_log_buffer_size 控制,默认大小为16MB(5.6版本是8MB):
SHOW VARIABLES LIKE 'innodb_log_buffer_size';-- global级别,无session级别
上文讲述update语句更新流程一文中,我们只提到了Buffer Pool用来代替缓存区,通过本文对内存结构的分析,实际上Buffer Pool中严格来说还有Change Buffer,Log Buffer和Adaptive Hash Index三个部分,DML操作会缓存在Change Buffer区域,而写redo log之前会先写入Log Buffer,所以Log Buffer又可以称之为redo Log Buffer。
Log Buffer什么时候写入redo log
一个大的Log Buffer空间大允许运行大型事务,而无需在事务提交之前将redo log数据写入磁盘。Log Buffer中的数据会定期刷新到磁盘,那么Log Buffer的数据又是如何写入磁盘的呢?Log Buffer数据flush到磁盘有三种方式,通过变量innodb_flush_log_at_trx_commit 控制,默认为1。 |value|描述|
- 当设置为0时,由于数据还在内存,所以崩溃后数据基本会被丢失
- 当设置为2时,由于数据已经实时写到redo log了,如果磁盘文件没有被损坏,还是可以恢复的
另外,Mast Thread默认1s进行一次刷盘操作,这个可以通过变量innodb_flush_log_at_timeout控制,默认1s。
SHOW VARIABLES LIKE 'innodb_flush_log_at_timeout';-- global级别,无session级别
磁盘结构
InnoDB引擎的磁盘结构,从大的方面来说可以分为Tablespace和redo log两部分
Tablespace
Tablespace可以分为4大类,分别是:System Tablespace,File-Per-Table Tablespaces,General Tablespaces,Undo Tablespaces
System Tablespace
系统表空间中包括了 InnoDB data dictionary,doublewrite buffer, change buffer, undo logs 4个部分,默认情况下InnoDB存储引擎有一个共享表空间ibdata1,如果我们创建表没有指定表空间,则表和索引数据也会存储在这个文件当中,可以通过一个变量控制(后面会介绍)。
ibdata1文件默认大小为12MB,可以通过变量innodb_data_file_path来控制,改变其大小的最好方式就是设置为自动扩展。
innodb_data_file_path=ibdata1:12M:autoextend
上面表示默认表空间ibdata1大小为12MB,支持自动扩展大小。
当我们的文件达到一定的大小之后,比如达到了998MB,我们就可以另外开启一个表空间文件:
innodb_data_home_dir=
innodb_data_file_path=/ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
## 最后
既已说到spring cloud alibaba,那对于整个微服务架构,如果想要进一步地向上提升自己,到底应该掌握哪些核心技能呢?
就个人而言,对于整个微服务架构,像RPC、Dubbo、Spring Boot、Spring Cloud Alibaba、Docker、kubernetes、Spring Cloud Netflix、Service Mesh等这些都是最最核心的知识,架构师必经之路!下图,是自绘的微服务架构路线体系大纲,如果有还不知道自己该掌握些啥技术的朋友,可根据小编手绘的大纲进行一个参考。
![image](https://img-blog.csdnimg.cn/img_convert/d6507c812bfbd9c4d3cf54ce3112c724.webp?x-oss-process=image/format,png)
如果觉得图片不够清晰,也可来找小编分享原件的xmind文档!
且除此份微服务体系大纲外,我也有整理与其每个专题核心知识点对应的最强学习笔记:
* 出神入化——SpringCloudAlibaba.pdf
* SpringCloud微服务架构笔记(一).pdf
* SpringCloud微服务架构笔记(二).pdf
* SpringCloud微服务架构笔记(三).pdf
* SpringCloud微服务架构笔记(四).pdf
* Dubbo框架RPC实现原理.pdf
* Dubbo最新全面深度解读.pdf
* Spring Boot学习教程.pdf
* SpringBoo核心宝典.pdf
* 第一本Docker书-完整版.pdf
* 使用SpringCloud和Docker实战微服务.pdf
* K8S(kubernetes)学习指南.pdf
![image](https://img-blog.csdnimg.cn/img_convert/893a0f10671b57eceb55f0c6435170f3.webp?x-oss-process=image/format,png)
另外,如果不知道从何下手开始学习呢,小编这边也有对每个微服务的核心知识点手绘了其对应的知识架构体系大纲,不过全是导出的xmind文件,全部的源文件也都在此!
![image](https://img-blog.csdnimg.cn/img_convert/2ded47587d7b64e9419a5f5a8eda3330.webp?x-oss-process=image/format,png)
**网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**
**需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注Java)**
![img](https://img-blog.csdnimg.cn/img_convert/36ffee380fcf642942f8e6a83f8d2893.jpeg)
**一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**
不再深入研究,那么很难做到真正的技术提升。**
**需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注Java)**
[外链图片转存中...(img-h4mtlimk-1713547678114)]
**一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**