阿鑫的博客ッ

第1章 课程介绍 本章对课程内容、知识点、授课过程进行引导性说明。 1. 问卷调查 你真的搞懂MySQL底层原理了吗? 你知道如何改善慢查询性能吗? 你知道如何架设高性能集群吗? 你知道未来数据库的发展趋势吗? 这些问题很重要! 因为…. 工作中:MySQL高性能集群越来越流行 面试中:深入考察MySQL原理、性能调优 职业规划:需要根据技术发展方向选择职业路径 2. 精通MySQL 应该怎么学?从理论到实战 从数据表逻辑结构，到优化数据表的性能 从数据查询原理，到改善慢SQL性能 从单点到集群 从学习单点原理，到掌握集群原理 从高性能单点，到高性能集群 从单点快速部署，到集群快速部署 从现在到未来 从5.x版本，到8.0版本 从原生单体数据库，到原生分布式数据库 从学习技术原理，到理解技术趋势 以上三点就是本课程的主线 以技术原理作为坚实基础 以真实场景作为学习环境 以架构思维作为学习目标 3. 什么是“三高” 高并发:同时处理的事务数高 高性能:事务/SQL的执行速度高 高可用:系统可用时间高 为什么不直接讲“三高”“三高”只是目的，并不是手段，手段有 ...

如何设计高可用系统架构-系统熔断、降级、限流

MYSQL alter操作alter应该不会锁表吧 就会加一个MDL锁 innoDB支持在线DDL alter的时候不会阻塞对表的读写，然后百度 alert千万数据表的时候需要使用percona的 pt-online-schema-change ，他会建立一个与原来表结构相同的新表，然后把数据全部复制过去，最后替换表来完成大数据量表新增一个字段。 volatile这个是为了各个核心数据一致性的，有修改缓冲区和失效队列，但是修改缓冲区的内容什么时候刷新到主内存，核心什么时候操作失效队列，这个是核心自己来控制的在并发场景下，核心自己控制就会出问题所以需要屏障来告诉核心什么时候操作。java提供了关键字对底层原理封装，由开发人员来决定怎么做,volatile就是屏障，来告诉核心这个时候该刷新主内存，操作失效队列了 7．常见的MESI协议就是基于总线嘎探实现的。 8.MESI解决了缓存一致性问题，但是还是不能将CPU性能压榨到极致。 9.为了进一步压榨CPU，所以引入了 store buffer 和invalidate queue。 10.store buffer和invalidate q ...

MySQL读写分离及主从时延面试题 如何实现mysql的读写分离？ MySQL主从复制原理的是啥？ 如何解决mysql主从同步的延时问题？ 前言这个，高并发这个阶段，那肯定是需要做读写分离的，啥意思？因为实际上大部分的互联网公司，一些网站，或者是app，其实都是读多写少。所以针对这个情况，就是写一个主库，但是主库挂多个从库，然后从多个从库来读，那不就可以支撑更高的读并发压力了吗？ 如何实现mysql的读写分离？其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。一般情况下，主库可以挂4-5个从库 MySQL主从复制原理的是啥？MySQL里有一个概念，叫binlog日志，就是每个增删改类的操作，会改变数据的操作，除了更新数据以外，对这个增删改操作还会写入一个日志文件，记录这个操作的日志。 主库将变更写binlog日志，然后从库连接到主库之后，从库有一个IO线程，将主库的binlog日志拷贝到自己本地，写入一个中继日志中。接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的 ...

数据库分库分表的面试连环炮面试题 为什么要分库分表？（设计高并发系统的时候，数据库层面该如何设计） 用过哪些分库分表中间件？ 不同的分库分表中间件都有什么优缺点？ 你们具体是如何对数据库如何进行垂直拆分或水平拆分的？ 现在有一个未分库分表的系统，未来要分库分表，如何设计才可以让系统从未分库分表动态切换到分库分表上？ 如何设计可以动态扩容缩容的分库分表方案？ 分库分表后，ID主键如何处理？ 为什么要分库分表？说白了，分库分表是两回事儿，大家可别搞混了，可能是光分库不分表，也可能是光分表不分库，都有可能。我先给大家抛出来一个场景。 假如我们现在是一个小创业公司（或者是一个BAT公司刚兴起的一个新部门），现在注册用户就20万，每天活跃用户就1万，每天单表数据量就1000，然后高峰期每秒钟并发请求最多就10。。。天，就这种系统，随便找一个有几年工作经验的，然后带几个刚培训出来的，随便干干都可以。 结果没想到我们运气居然这么好，碰上个CEO带着我们走上了康庄大道，业务发展迅猛，过了几个月，注册用户数达到了2000万！每天活跃用户数100万！每天单表数据量10万条！高峰期每秒最大请求达到1000 ...

如何设计一个高并发系统前言假设你在某知名电商公司干过高并发系统，用户上亿，一天流量几十亿，高峰期并发量上万，甚至是十万。那么人家一定会仔细盘问你的系统架构，你们系统啥架构？怎么部署的？部署了多少台机器？缓存咋用的？MQ咋用的？数据库咋用的？就是深挖你到底是如何抗下高并发的。 因为真正干过高并发的人一定知道，脱离了业务的系统架构都是在纸上谈兵，真正在复杂业务场景而且还高并发的时候，那系统架构一定不是那么简单的，用个redis，用mq就能搞定？当然不是，真实的系统架构搭配上业务之后，会比这种简单的所谓“高并发架构”要复杂很多倍。 如果有面试官问你个问题说，如何设计一个高并发系统？那么不好意思，一定是因为你实际上没干过高并发系统。面试官看你简历就没啥出彩的，感觉就不咋地，所以就会问问你，如何设计一个高并发系统？其实说白了本质就是看看你有没有自己研究过，有没有一定的知识积累。 面试题剖析其实所谓的高并发，如果你要理解这个问题呢，其实就得从高并发的根源出发，为啥会有高并发？ 浅显一点，很简单，就是因为刚开始系统都是连接数据库的，但是要知道数据库支撑到每秒并发两三千的时候，基本就快完了。所以才有 ...

分布式事务解决方案 分布式事务了解吗 你如何解决分布式事务问题 两阶段提交方案/XA方案 TCC方案 本地消费表 可靠消息最终一致性方案 最大努力通知方案 公司如何处理分布式事务 分布式事务只要聊到你做了分布式系统，必问分布式事务，你对分布式事务一无所知的话，确实会很坑，你起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。 现在面试，分布式系统成了标配，而分布式系统带来的分布式事务也成了标配了。因为你做系统肯定要用事务吧，那你用事务的话，分布式系统之后肯定要用分布式事务吧。先不说你搞过没有，起码你得明白有哪几种方案，每种方案可能有啥坑？比如TCC方案的网络问题、XA方案的一致性问题 单机系统下的事务 分布式系统下的事务 两阶段提交方案/XA方案 也叫做两阶段提交事务方案，这个举个例子，比如说咱们公司里经常tb是吧（就是团建），然后一般会有个tb主席（就是负责组织团建的那个人）。 tb，team building，团建 第一个阶段，一般tb主席会提前一周问一下团队里的每个人，说，大家伙，下周六我们去滑雪+烧烤，去吗？这个时候tb主席开始等待每个人的回答 ...

Spring中的事务来源：https://www.bilibili.com/video/BV1EE411p7dD 什么是事务事务：是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作，这些操作作为一个整体像系统提交，要么都执行，要么都不执行；事务是一组不可再分割的操作集合（工作逻辑单元） 通俗点说就是为了达到某个目的而做的一系列的操作要么一起成功（事务提交），要么一起失败（事务回滚） 最常见的例子就是转账： 小明给如花转账： 1234开启事务-------① 从小明的账户扣除1000元② 给如花的账户增加1000元事务提交------- 从上面的例子的任何步骤一旦出现问题，都会导致事务回滚。 从搭讪到结婚就是事务提交，女方要求男方重新追求她一次就是事务回滚~ 事务的四大特征ACID是事务的基本特征：口诀（一原持久隔离） 原子性（Atomicity）：事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用。 一致性（Consistency）：事务执行后，数据库状态与其它业务规则保持一致，如转账业务，无论事务执行成功与否，参与转账的两个 ...

分布式Session方案什么是Session session是啥？浏览器有个cookie，在一段时间内这个cookie都存在，然后每次发请求过来都带上一个特殊的jsessionid cookie，就根据这个东西，在服务端可以维护一个对应的session域，里面可以放点儿数据。 一般只要你没关掉浏览器，cookie还在，那么对应的那个session就在，但是cookie没了，session就没了。常见于什么购物车之类的东西，还有登录状态保存之类的。 但是你单块系统的时候这么玩儿session没问题啊，但是你要是分布式系统了呢，那么多的服务，session状态在哪儿维护啊？ 其实方法很多，但是常见常用的是两种 tomcat + redis这个其实还挺方便的，就是使用session的代码跟以前一样，还是基于tomcat原生的session支持即可，然后就是用一个叫做Tomcat RedisSessionManager的东西，让所有我们部署的tomcat都将session数据存储到redis即可。 在tomcat的配置文件中，配置一下 1234567891011<Valve clas ...

如何解决大文件上传问题？如果你的项目涉及到文件上传的话，面试官很可能会问你这个问题。 我们先看第一个场景：大文件上传中途，突然失败！ 试想一个，你想上传一个 5g 的视频，上传进度到 99% 的时候，特么的，突然网络断了，这个时候，你发现自己竟然需要重新上传。我就问你抓狂不？ 有没有解决办法呢？ 答案就是：分片上传！ 什么是分片上传呢？ 简单来说，我们只需要先将文件切分成多个文件分片（就像我下面绘制的图片所展示的那样），然后再上传这些小的文件分片。 前端发送了所有文件分片之后，服务端再将这些文件分片进行合并即可，这样就得到的一个完整的文件。 大致流程如下： 生成要上传文件的唯一标识（如SHA-256）； 将需要上传的文件按照一定的分割规则，分割成相同大小的分片； 初始化一个分片上传任务，返回本次分片上传的唯一标识； 每个分片在发送前，客户端会计算其哈希值（如SHA-256），并将这个哈希值与分片一起发送给服务器； 按照一定的策略（串行或并行）发送各个分片； 服务器接收到分片后，会重新计算分片的哈希值，并与客户端发送的哈希值进行比对； 如果哈希值匹配，则认为该分片有效，服务器会存储该 ...