【严选】JAVA互联网架构师专题/分布式/高并发/微服务

【严选】JAVA互联网架构师专题/分布式/高并发/微服务
点点我download：JAVA互联网架构师专题/分布式/高并发/微服务  

提娶马：f6r5

  01 学习攻略

  02亿级流量中台微服务电商平台、电商项目总体架构详解、秒杀系统-商品详情多级缓存优化实战（一）、电商项目微服务架构拆分及受权中心实战、从零到一实战高性能网关服务及受权中心对接、商品搜索实战（上）。

  03秒杀系统-订单交易全链路优化实战（一）、订单交易系统分布式事务实战、分库分表&分布式事务&分布式主键(上)、(下)、电商项目并发编程实战与总结、电商项目微服务中台架构落地实战。

  04亿级流量中台微服务电商平台、电商项目领域驱动开发DDD探索及实战、Docker详解与部署微服务实战、电商项目Docker Compose总体部署实战（上）、（下）、Kubernetes快速实战与核心原理剖析（上）、（下）、Kubernetes微服务电商后台部署实战、电商项目压测与性能调优（上）、（下）、电商项目秒杀全链路压测。

  05电商推荐系统、电商推荐系统实战1、2、3、4、五。

  06微信亿级IM后台系统、微信亿级IM后台系统架构实战1、2、3、四。

课件 1：

MVCC多版本并发控制机制
Mysql在可重复读隔离级别下如何保证事务交流V（cmL46679910）较高的隔离性，咱们上节课给你们演示过，一样的sql查询语句在一个事务里屡次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果。这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的，对一行数据的读和写两个操做默认是不会经过加锁互斥来保证隔离性，避免了频繁加锁互斥，而在串行化隔离级别为了保证较高的隔离性是经过将全部操做加锁互斥来实现的。
Mysql在读已提交和可重复读隔离级别下都实现了MVCC机制。

undo日志版本链与read view机制详解

undo日志版本链是指一行数据被多个事务依次修改事后，在每一个事务修改完后，Mysql会保留修改前的数据undo回滚日志，而且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来造成一个历史记录版本链(见下图，需参考视频里的例子理解)。

在可重复读隔离级别，当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view，该视图在事务结束
以前都不会变化(若是是读已提交隔离级别在每次执行查询sql时都会从新生成)，这个视图由执行查询时全部未提交事
务id数组（数组里最小的id为min_id）和已建立的最大事务id（max_id）组成，事务里的任何sql查询结果须要从对应
版本链里的最新数据开始逐条跟read-view作比对从而获得最终的快照结果。
版本链比对规则：
1. 若是 row 的 trx_id 落在绿色部分( trx_id<min_id )，表示这个版本是已提交的事务生成的，这个数据是可见的；
2. 若是 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由未来启动的事务生成的，是不可见的(若
row 的 trx_id 就是当前本身的事务是可见的）；
3. 若是 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种状况
a. 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自
己的事务是可见的)；
b. 若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。
对于删除的状况能够认为是update的交流V（cmL46679910）特殊状况，会将版本链上最新的数据复制一份，而后将trx_id修改为删除操做的
trx_id，同时在该条记录的头信息（record header）里的（deleted_flag）标记位写上true，来表示当前记录已经被
删除，在查询时按照上面的规则查到对应的记录若是delete_flag标记位为true，意味着记录已被删除，则不返回数
据。
注意：begin/start transaction 命令并非一个事务的起点，在执行到它们以后的第一个修改操做InnoDB表的语句，
事务才真正启动，才会向mysql申请事务id，mysql内部是严格按照事务的启动顺序来分配事务id的。
总结：
MVCC机制的实现就是经过read-view机制与undo版本链比对机制，使得不一样的事务会根据数据版本链对比规则读取
同一条数据在版本链上的不一样版本数据。

Innodb引擎SQL执行的BufferPool缓存机制

为何Mysql不能直接更新磁盘上的数据并且设置这么一套复杂的机制来执行SQL了？
由于来一个请求就直接对磁盘文件进行随机读写，而后更新磁盘文件里的数据性能可能至关差。
由于磁盘随机读写的性能是很是差的，交流V（cmL46679910）因此直接更新磁盘文件是不能让数据库抗住很高并发的。
Mysql这套机制看起来复杂，但它能够保证每一个更新请求都是更新内存BufferPool，而后顺序写日志文件，同时还能
保证各类异常状况下的数据一致性。

更新内存的性能是极高的，而后顺序写磁盘上的日志文件的性能也是很是高的，要远高于随机读写磁盘文件。正是经过这套机制，才能让咱们的MySQL数据库在较高配置的机器上每秒能够抗下几干的读写请求。