Spring Boot 的约定优于配置，你的理解是什么？
首先，约定优于配置是一种软件设计的范式，他的核心思想是减少软件开发人员对于配置项的维护，从而让开发人员更加聚焦在业务逻辑上。
其次，Spring Boot 就是约定优于配置这一理念下的产物，他类似于Spring 框架下的一个脚手架，通过Spring boot ，我们可以快速开发基于Spring 生态下的应用程序。
再次，基于传统的Spring 框架开发web应用，我们需要做很多和业务开发无关并且只需要做一次的配置，比如
1，管理jar包依赖
2， web.xml维护
3， Dispatch-Servlet.xml 配置项维护
- 应用部署到web 容器。
5，第三方组件集成到Spring IOC容器中的配置项维护
而在Spring Boot中，我们不需要在去做这些繁琐的配置，Spring Boot已经自动帮我们完成了，这就是约定优先于配置思想的体现。
6，Spring Boot 约定优于配置的体现有很多，比如：
1，Spring Boot Starter 启动依赖，他能帮助我们管理所有jar
2， 如果当前应用依赖了spring mvc 相关的jar 那么springboot 会自动内置
Tomcat容器来运行web应用，我们不需要去做单独应用部署
3， Spring Boot 的自动装配机制的实现中，通过扫描约定路径下的spring.factories 文件夹识别配置类，实现bean的自动装配。
4， 默认加载的配置文件application.properties 等等
总的来说，约定优于配置是一个比较常见的软件设计思想，他的核心本质都是为了更高效以及便捷的实现软件系统的开发维护。
Spring Boot 中自动装配机制的原理
自动装配，简单的来说就是自动把第三方组件的Bean 装载到Spring IOC 容器里面，不需要开发人员再去写Bean 的装配配置。
在Spring Boot 应用里面，只需要在启动类上加上@SpringBootApplication 注解就可以实现自动装配
@SpringBootApplication 是一个符合注解，真正实现自动装配的注解是
@EnableAutoConfiguration
自动装配的实现主要依靠三个核心关键技术
1，引入 Starter 启动依赖组件的时候，这个组件里面必须包含@Configuration 配置类，在这个配置类里面通过 @Bean 注解声明需要装配到IOC容器的Bean对象
2， 这个配置类是放在第三方jar包里面，通过SpringBoot中的约定于配置思想，把这个配置类的全路径放在 classpath:/META-INF/spring.factories 文件中。这样Springboot就可以知道第三方jar包里的配置类的位置。这个步骤主要是用到了Spring 里面的SpringFactoriesLoader 来完成的。
3， SpringBoot拿到第三方jar 包里面声明的配置类以后，再通过Spring 提供的ImportSelector接口，实现对这些配置类的动态加载。
springBoot是约定优于配置这一理念下的产物，所以在很多的地方，都会看到这类的思想，他的出现，让开发人员更加聚集在了业务代码的编写上，而不需要去关心和业务无关的配置
其实，自动装配的思想，在Spring Framework3.x 版本里的@Enable注解，就有了实现的模型。@Eanble 注解是模块驱动的意思，我们只需要增加某个@Eanble 注解，就自动打开某个功能，而不需要针对这个功能去做Bean的配置，@Enable底层也是帮我们去自动完成这个模块相关Bean的注入。
MySQL优化相关问题
MySQL的性能优化可以分为4个部分
1，硬件和操作系统层面的优化
2，架构设计层面的优化
3，MySQL程序配置优化
4，SQL 优化
硬件操作系统层面的优化
从硬件层面来说，影响MySQL性能的因素有，CPU,可用内存大小，硬盘读写速度，网络宽带
从操作系统层面来说，应用文件句柄数，操作系统网络的配置都会影响到mysql性能，这部分的优化一般由DBA或者运维工程师去完成。
在硬件基础资源中，我们重点应该关注服务本身承载的体量，然后提出合理的指标要求，避免出现资源浪费。
架构设计层面的优化
MySQL 是一个磁盘Io访问量非常频繁的关系型数据库。
在高并发和高性能的场景中，MySQL数据库必然会承受巨大的并发压力，而此时，我们的优化方式可以分为几个部分。
1，搭建MySQL主从集群，单个MySQL服务容易单点故障，一旦服务器宕机，将会导致依赖MySQL的数据库的应用全部无法响应。主从集群或者主主集群可以保证服务的高可用性
2， 读写分离设计，在读多写少的场景中，通过读写分离的方案，可以避免读写冲突导致的性能影响。
3.针对分库分表机制，通过分库可以降低单个服务器节点的IO压力，通过分表的方式可以降低单表数据量，从而提升sql查询效率
4， 针对热点数据，可以引入更为高效的分布式数据库，比如Redis，MongoDB等，他们可以很好的缓解MySQL的访问压力，同时还能提升数据检索性能。
MySQL 程序配置优化
MySQL是一个经过互联网大厂验证过的生产级别的成熟数据库，对于MySQL数据库本身的优化，一般通过MySql中的配置文件mv.cnf来完成的，比如：
MySQL5.7版本默认的最大连接数是151个，这个值可以在my.cnf中修改
binlog日志，默认是不开启
缓存池 bufferpoll的默认大小配置等
由于这些配置一般都和用户安装的硬件环境以及使用场景有关系，因此这些配置官方只会提供一个默认值，具体情况还得由使用者修改
关于配置项的修改，需要关注2个方面
配置的作用域，分为绘画级别和全局
是否支持热加载
因此，针对这2个点，需要注意的是：
全局参数的设定对于已经存在的绘画无法生效
会话参数的设定随着会话的销毁而失效
全局类的统一配置建议配置在默认配置文件中，否则重启服务会导致配置失效。
SQL优化
SQL 优化又分为三部曲
1，慢SQL的定位和排查
我们可以通过慢查询日志和慢查询日志分析工具得到有问题的SQL列表
2， 执行计划分析
针对慢SQL, ，我们可以使用关键字explain 来查看当前sql的执行计划，可以重点关注type,key,rows,filterd 等字段，从而定位该sql执行慢的根本原因，再有的放矢的进行优化。
3，使用show profile 工具
Show Profile 是 MySQL 提供的可以用来分析当前会话中，SQL 语句资源消耗情况的
工具，可用于 SQL 调优的测量。在当前会话中.默认情况下处于 show profile 是关闭状
态，打开之后保存最近 15 次的运行结果
针对运行慢的 SQL，通过 profile 工具进行详细分析.可以得到 SQL 执行过程中所有的
资源开销情况.
如Io开销，cpu开销，内存开销等
常见的sql优化规则
1，SQL的查询一定要基于索引来进行数据扫描
2，避免索引列上使用函数或者运算，这样会导致索引失效
- where 字句中like %号，尽量放置右边
4， 使用索引扫描，联合索引中的列从左到右，命中越多越好
5，尽可能使用SQL语句用到的索引完成排序，避免使用文件排序的方式’
6，查询有效的列信息即可，少用 *代替列信息
7，永远用小结果集驱动大结果集。
分布式事务的原理
分布式事务是指事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于分布式系统的不同节点之上。
本质上说，分布式事务就是为了保证不同数据库的数据一致性。
基于CAP定理可以知道，对于上述情况产生的分布式事务问题，我们要么采用强一致性方案，要么采用弱一致性方案。
所谓强一致性，就是通过第三方的事务管理器来协调多个节点的事务，保证每个节点的事务到达同时成功，同时失败，为了实现这样一个需求，我们会引入Xopen/DTP 模型提供的XA协议，基于2pc或者3pc的方式实现。但是，在如果全局事务管理器中的多个节点中，如果任意一个节点在进行事务提交确认时，由于网络通信延迟导致阻塞，就会影响到所有节点事务的提交，这个阻塞过程也会影响阻塞用户的请求线程，这对于用户体验以及整体性能的影响较大。
而弱一致性方案，就是针对强一致性方案所衍生于出来性能和数据一致性平衡的一个方案，简单的来说就是损失掉强一致性，数据在某一个时刻会存在不一致的状态，但是最终这些数据会达成一致，这样的好处是提升了系统的性能。
在弱一致性方案中，常见的解决方案
1， 使用分布式消息队列，来实现最终一致性
2，基于TCc事务，通过演进版本的二阶段提交实现最终一致性。
3使用Seata 事务框架，他提供能提供了多种事务模式，如AT，XA，Sega，TCc等
网友评论