上课复习

复习

复习计划：
1.Spring
2.SpringMVC
3.SpringBoot
4.MyBatis
5.SpringCloud
6.Redis——重点
7.MQ

2.12上午：Spring

单例：提高程序的性能和以后程序的维护只针对业务的维护就行。



属性注入：

构造函数注入：（官方推荐）效率高


super本质上就是父类构造器，隐式的调用父类的super：说明父类实例化了，

2.12下午：springMVC,mybatis

springMVC
架构流程

转发重定向区别：
转发在服务器端完成的；重定向是在客户端完成的
转发的速度快；重定向速度慢
转发的是同一次请求；重定向是两次不同请求
转发不会执行转发后的代码；重定向会执行重定向之后的代码
转发地址栏没有变化；重定向地址栏有变化
转发必须是在同一台服务器下完成；重定向可以在不同的服务器下完成

数据校验
分组校验：注册、登录接口，注册接口需要验证的数据量更大: 名字, 密码, 年龄, 手机号等等，登陆接口: 名字和密码，如果不分组，登陆的时候数据校验不通过，所以分注册 登录组。用户名和密码都需要验证，两个组都需要加上，age, phone 只会在注册的时候需要，只需要加上注册组。

异常处理：@RestControllerAdvice

filter–>DispathcerServlet–>Interceptor–>Controller：filter 过滤的是请求，DispathcerServlet 接收请求，filter 在DispatcherServlet之前，Interceptor 拦截的是控制器里面的方法（后端的处理器中）

mybatis
当我调用findAll方法的时候，为什么就能执行对应的SQL语句？
当项目启动的时候：
会去解析mybatis相关的配置文件
1.没有整合
2.和spring整合之后 => SqlSessionFactory => 配置相应的连接参数，加载对应相关的配置
3.扫描mapper.xml => map1 => 标签的id->标签里面的sql语句
mapper接口 => map2 => mapper的名字 -> mapper的代理对象
4.调用findAll的时候 -> 方法的名字.getName() -> Map1的key
Map1.get(方法的名字) -> SQL语句

持久层框架
参数的输入映射, 结果的映射
框架帮我们做了
1.映射处理, 帮我们处理了
2.表与表之间的关系处理
一对一, 一对多, 多对多
通过一些标签就可以实现关联处理
3. 效率问题
4. 一级缓存和二级缓存：一级缓存默认开启, 二级缓存 需要手动开启
一级缓存: sqlSession级别, 同一个session 在查询相同的sql，只会执行依次，一次，效率提升。
二级缓存: mapper级别, 不同session执行相同的mapper里面对应的方法 只会执行一次，效率也提升了。
什么时候会清空缓存？
缓存的作用就是 不让你去执行第二次查询，这个操作有一个前提: 两次查询的数据必须是一样的。所以缓存在什么时候失效? 数据发生改变(增删改)会自动失效。

#{} 会进行预处理 相当于 ? 可以防止sql注入
${} 不会进行预处理 相当于是字符串拼接 不能防止sql注入

传参数: @Param，然后在sql里面直接使用即可
foreach标签，where in(1,2,3,4)，就用foreach，
多条删除的时候，不可能每次只删除一条，需要一次性删除多条delete from user where id in(1,2,3,4,5)，in(1,2,3,4,5) 就通过 foreach标签去拼接。

2.13上午：mybatis，SpringBoot

mybatis
关于mybatis使用XML还是使用注解？
优势，设计初衷？
相比其他框架的优势？（mybatis半ORM，hibernate全ORM）
1.mybatis相当灵活（sql自定义）
2.代码和sql分离（XML的配置上）
3.大部分用到的还是XML配置方式

1.mybatis的关联查询：（依赖一个标签ResultMap）
一对一association，一对多collection，多对多(需要借助中间表，找第三张表主要在中间表配置collection)
2.延迟加载
目的：减轻数据的访问压力
User=>关联了=> Role
< resultMap>
…

</ resultMap>
如果不做延迟加载:每次查询，都会去关联Role，那么就会有两次访问数据库。
加上延迟加载：每次查询，只会去查询User，当我们]需要用到Role里面相关的数据的时候，才回去查询Role。减少一些没有必要的访问。

逆向工程

mybatis拓展：
分页->pageHelper
公共mapper
mybatisPlus–>可能遇到

SpringBoot
出现原因：整合SSM配置复杂繁琐，容易出错，配置好之后，不用去更改。
springboot宗旨：干掉配置，有很多默认配置。启动项目快

1. 静态资源的查找顺序：resources–>static–>public
2. 文件上传：
   和SpringMVC一致，如果需要访问上传的资源，我们应该怎么办?
   2.1单独搭建一个文件服务器 -->直接把问加你暴露成了一个网络资源
   2.2借助云存储（七牛云）–>推荐，速度快，缺点：东西存在别人的服务器上
   2.3单独配置今天资源文件夹
   2.4可以存在数据库，二进制的形式存储，这种方式：查询效率极低，会把数据库搞得很大 -->不推荐
   2.5文件安全性的问题，如果需要访问一个文件，这个文件必须是一个网络资源。
   我们上传文件，存储的目录，相对服务器来说，是一个绝对路径：/var/upload
   比如我们上传一个header.png
   存储的目录: String filePath = “/var/upload/ 2020/02/13/2342sfasdfds . png”
   这个路径肯定要存到数据库：filePath的字段

从浏览器访问一张图片？浏览器解析的是？服务器响应的是？
服务器：response的是 字节输出流，response.setHeader(“image/jpeg”)，告诉浏览器这是一张图片

File file = new File(filePath);
转换成字节流
在控制器的方法中，通过HttpServletResponse.getWriter().write(字节流）
好处：至少可以拦截，我们可以判断Token，这样做 文件就更加安全。
知识点：建立在IO/JavaWEB

3. JPA
   SpringDataJPA
   JDBC是啥? Java官方推出的一个访问数据库的规范。不同的数据库驱动要想去通过JDBC的方式去连接不同的数据库，必须去实现规范。对于开发者来说，好处就是，方法是一样的，只需要记住一套方法就Ok。
   JPA到底是啥?存在意义是啥?JPA存在的意义也是一样，java官方为了统一ORM框架规范，使得所有的ORM都必须安装这个规范，Hibernate
   Hibernate 会发现很多和SpringDataJPA一样的方法， 一样的操作，相比Hibernate有一个很好的地方:
   自定义方法=> findByUserNameAndUserAge()
   select * from user where user_ name=? and user_age=?

4. 定时任务
   使用场景：短信通知，节日问候，数据库备份，仓库预警，货物过期检测…
   重点掌握: cron 这种形式的定时任务配置:可以精确，每天的具体的一个时间/每个月/每周

5. 异步任务
   原理是啥？多线程
   只要是要影响主线程执行时间，都可以用异步任务
   使用场景：邮件通知，短信发送，log日志记录（不能影响主线程），检测余额，优惠券

定时任务和异步任务要结合起来：定时在用户生日当天8点 发生日祝福短信；20200213 8:00，移动用户好几亿，当天生日的用户也有很多万，不用异步任务 => 效率相当的低下 => 同步阻塞（第一条短信发送完成之后，才会进入第二条的发送）；用了异步任务 => 效率会提升很多，异步 不会阻塞 => 调用发送短信的方法的时候，不用去关心执行结果

2.13下午：SpringCloud

微服务：分布式的一种SOA
微服务技术栈：SpringBoot+SpringCloud， SpringBoot+Double+zookeeper
SOA技术栈：Double+zookeeper
什么是分布式？什么是集群？

https://www.zhihu.com/question/20004877
整个项目所有的服务都由这台服务器提供。这就是单机结构。单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式。
单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用微服务结构了。
分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。
这样的好处有很多：
1 系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
2 系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。
3 服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。

简单项目=> 单机形式即可
访问量增大，用户量提升明显，日Pv明显提升，单机有点扛不住了=>用户访问体验很差，反应慢=>用户的流失
考虑集群

所以说：分布式配置中心在实际的项目中，必不可少的

2.18上午：Redis

2.18下午：rabbitMQ

微信通知服务，物流服务…
这些服务，我们可以把他们独立开，他们之间没有任何关系，当我们处理业务订单的时候，他们又必须组合起来，才能完成对应的功能。