笔记.md · Zds2y/Notes

## Ajax的实现流程

**实现一个AJAX异步调用和局部刷新,通常需要以下几个步骤:**

1、**创建XMLHttpRequest对象,也就是创建一个异步调用对象.**

2、**创建一个新的HTTP请求,并指定该HTTP请求的方法、URL及验证信息.**

3、**设置响应HTTP请求状态变化的函数.**

4、**发送HTTP请求.**

5、**获取异步调用返回的数据.**

6、**使用JavaScript和DOM实现局部刷新.**

## Redis缓存

redis速度快的原因：

redis是单线程的，避免了线程之间的上下文切换浪费的时间

redis底部使用的是 异步非阻塞IO

### **什么是redis缓存：**

1、redis是一种非关系型数据库，就是键值对数据库

2、支持五种数据类型，String(字符串)，Hash(key-value格式)，List(列表)，Set(集合)，Zset(Sorted Set有序				集合 )

3、什么是Redis持久化？Redis有哪几种持久化方式？优缺点是什么？

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

Redis 提供了两种持久化方式:RDB（默认） 和AOF

RDB方式：RDB 持久化机制，是对 redis 中的数据执行周期性的持久化。

类似于快照的模式，每隔一段时间，将当前的数据进行快照备份

AOF方式：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启						   的时候，可以通过回放AOF 日志中的写入指令来重新构建整个数据集。

类似于日志的模式，每次执行操作时，就会更新aof文件，来实现持久化的功能

优缺点：

**RDB 优缺点**

- RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis
  的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说 Amazon 的 S3云服务上去，在国内可以是阿里云的 ODPS 分布式存储	上，以预定好的备份策略来定期备份redis中的数据。
- RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能，因为 redis 主进程只需要 fork
  一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
- 相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
- 如果想要在 redis 故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好。一般来说，RDB 数据快照文件，都是每隔 5分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据。
- RDB 每次在 fork 子进程来执行 RDB
  快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

**AOF 优缺点**

- AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次fsync操作，最多丢失 1 秒钟的数据。
- AOF 日志文件以 append-only
  模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
- AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log
  的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge
  后的日志文件 ready 的时候，再交换新老日志文件即可。
- AOF 日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用 flushall
  命令清空了所有数据，只要这个时候后台 rewrite 还没有发生，那么就可以立即拷贝 AOF 文件，将最后一条 flushall
  命令给删了，然后再将该 AOF 文件放回去，就可以通过恢复机制，自动恢复所有数据。
- 对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大。
- AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 fsync
  一次日志文件，当然，每秒一次 fsync，性能也还是很高的。（如果实时写入，那么 QPS 会大降，redis 性能会大大降低）
- 以前 AOF 发生过 bug，就是通过 AOF 记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似 AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug，因此每次 rewrite 并不是基于旧的指令日志进行 merge的，而是**基于当时内存中的数据进行指令的重新构建**，这样健壮性会好很多。

### redis的事务：

https://www.cnblogs.com/DeepInThought/p/10720132.html

### **什么是缓存穿透：**

当有人请求的数据，在缓存中一定不存在，那么就会去数据库中查询，但是数据库中也不存在，这时就会返回一个空对象，那么缓存中还是没有该数据，那么如果同时有大量的这种请求过来，那么都会直接去访问数据库，会导致数据库垮掉，进而导致服务器崩掉。

解决方案（两种）：

1、由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截，不合法就不让这个请求到数据库层！

2、当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。这种情况我们一般会将空对象设置一个较短的过期时间，比如60秒。、

### **什么是缓存雪崩：**

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至宕机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

出现的原因：

1、缓存服务器挂了

2、高峰期缓存局部失效

3、热点缓存失效

**解决方案：**

1、避免缓存集中失效，不同的key设置不同的超时时间

2、增加互斥锁，控制数据库请求，重建缓存  如下图：

互斥锁其实就是一个同步锁，只不过锁对象可以在不同进程之间共用。

![img](https://www.2cto.com/uploadfile/Collfiles/20180417/2018041709052539.png)

3、提高缓存的高可用，如：redis集群。

### **什么是缓存击穿：**

**缓存击穿**，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

**解决方案：**

1、其实，大多数情况下这种爆款很难对数据库服务器造成压垮性的压力。达到这个级别的公司没有几家的。所以，一般对主打商品都是早早的做好了准备，让缓存永不过期。即便某些商品自己发酵成了爆款，也是直接设为永不过期就好了。

2、布隆过滤器（推荐）

bloomfilter就类似于一个hash set，用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。

## 全文检索技术

### solr：

底层基于lucene的全文检索技术

在使用前需要先建立索引库

建立索引库的流程：获取原始文档，创建文档对象--》对原始文档进行分词--》建立索引

solr是一个实时搜索

### ElaticSearch：

ElaticSearch是一个延时搜索(延时是相对的)

### 对比

- solr和Elasticsearch的区别：
  - Solr建立索引时候，搜索效率下降，实时搜索效率不高，es实时搜索效率高
  - Solr利用Zookeeper进行分布式管理，而Elasticsearch自身带有分布式协调管理功能。
  - Solr支持更多格式的数据，比如JSON、XML、CSV，而Elasticsearch仅支持json文件格式。
  - Solr官方提供的功能更多，而Elasticsearch本身更注重于核心功能，高级功能多有第三方插件提供
  - Solr在传统的搜索应用中表现好于Elasticsearch，但在处理实时搜索应用时效率明显低于Elasticsearch。
  - Solr是传统搜索应用的有力解决方案，但Elasticsearch更适用于新兴的实时搜索应用。
  - Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；
  - Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。

- 补充说明：
  - Solr有一个更大、更成熟的用户、开发和贡献者社区
  - Solr支持多种数据格式的索引，比如：JSON、XML、CSV等多种数据格式
  - Solr搜索海量历史数据，速度非常快，毫秒级返回数据
  - es支持分布式，节点对外表现对等，加入节点自动均衡
  - es完全支持Apache Lucene的接近实时的搜索
  - es处理多租户multitenancy不需要特殊配置，而Solr需要更多的高级设置
  - es采用Gateway的概念，使得数据持久化更简单
  - es各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作
- 使用方式：
  - solr一般要部署到web服务器上，比如tomcat，启动tomcat，配置solr和tomcat的关联
  - es一般可以单独启动，然后es和spring整合，调用SpringDataElasticSearch里面提供的方法

## dubbo：

### dubbo的执行流程：

dubbo+zookeeper实现分布式架构：实现模块之间的解耦

**dubbo是服务器容器**

**zookeeper是注册中心**

![img](https://img-blog.csdn.net/20181002113850939?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21vYWt1bg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)

Consumer服务消费者，Provider服务提供者。Container服务容器。Monitor监控中心。

1、服务容器负责启动，加载，运行服务提供者。

2、服务提供者在启动时，向注册中心注册(register)自己提供的服务。

3、服务消费者在启动时，向注册中心订阅(subscribe)自己所需的服务。是通过**@Reference注解的接口的全限定名**去找指定	  的服务

4、注册中心返回服务提供者地址列表(notify)给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

5、服务消费者，从提供者地址列表中，（**搭建了集群的情况下**）基于软负载均衡算法，选一台提供者进行调用，	  如果调用失败，再选另一台调用。

6、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

7、注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

8、注册中心通过长连、接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者

9、注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表

### dubbo有哪些通信协议：

**dubbo协议**

比如：dubbo://192.168.0.1:20188

**默认就是走dubbo协议的，单一长连接，NIO异步通信，基于hessian作为序列化协议**

适用的场景就是：传输数据量很小（每次请求在100kb以内），但是并发量很高

为了要支持高并发场景，一般是服务提供者就几台机器，但是服务消费者有上百台，可能每天调用量达				到上亿次！此时用长连接是最合适的，就是跟每个服务消费者维持一个长连接就可以，可能总共就				100个连接。然后		后面直接基于长连接NIO异步通信，可以支撑高并发请求。

否则如果上亿次请求每次都是短连接的话，服务提供者会扛不住。

而且因为走的是单一长连接，所以传输数据量太大的话，会导致并发能力降低。所以一般建议是**传输				数据量很小，高并发访问的时候使用dubbo协议**。

![img](https://img2018.cnblogs.com/blog/720994/201812/720994-20181206103323155-25824600.png)

**rmi协议**

走java二进制序列化，多个短连接，适合消费者和提供者数量差不多，适用于文件的传输，一般较少用

**hessian协议**

走hessian序列化协议，多个短连接，适用于提供者数量比消费者数量还多，适用于文件的传输，一般较少用

**http协议**

走json序列化

**webservice**

走SOAP文本序列化

### dubbo有哪些序列化协议：

dubbo实际基于不同的通信协议，支持hessian、java二进制序列化、json、SOAP文本序列化多种序列化协		议。但是**hessian是其默认的序列化协议**。

## Webflux：

WebFlux是一个典型非阻塞异步的框架

## 网页静态化技术（freemarker）:

### 介绍：

用于减小数据库的访问压力，可以使用缓存技术和网页静态化技术

缓存技术比较适用于较小规模的数据

网页静态化就适用于较大规模的数据，且变动不太频繁的数据

网页静态化比较适用于SEO(搜索引擎优化)技术

网页静态化后就可以部署在nginx服务器上，nginx比tomcat性能高很多，可以支持更多的并发量

逆向工程的模板也可以使用freemarker来生成

freemarker不仅仅只是用来做网页静态化，freemarker是一个模板引擎，可以用来生成很多模板

freemarker最常用的就是用来做网页静态化

### 指令：

### 内建函数：

### 逻辑运算符：

## 文件服务器：

### FastDFS（分布式文件服务器）:

**FastDFS**由**跟踪服务器(Tracker Server)**、**存储服务器(Storage Server)**和**客户端(Client)**构成。

**跟踪服务器Tracker Server**

和TFS的NameServer相似,负责接收客户端的请求,选择合适的组合StorageServer ，他们与StorageServer之间也用心跳机制来检查对方是否还活着。

Tracker需要管理的信息也都放在内存中，并且里面所有的Tracker都是对等的，很容易扩展
客户端访问集群的时候会随机分配一个Tracker来和客户端交互。

**存储服务器Storage Server**

主要负责提供容量和备份服务。
他们是以group为单位，一个group里面的Storage数据互相备份，也就是数据是一样的。这种方法的好处是可以隔离不同应用的数据，比如一个应用的数据放在一个group里面，而且可用防止一台机器损坏导致数据丢失。
而且部署时候Storage的容量要保持一致，这样可以避免浪费资源

**客户端Client**

主要是上传下载数据的服务器，也就是我们自己的项目所部署在的服务器。**每个客户端服务器都需要安装Nginx**

**FastDFS的集群结构：**

![img](https://img-blog.csdnimg.cn/20190718155820828.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyOTUzNTI5,size_16,color_FFFFFF,t_70)

**文件上传的流程：**

![img](https://img-blog.csdnimg.cn/20190718155831488.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyOTUzNTI5,size_16,color_FFFFFF,t_70)

1、客户端先访问跟踪服务器(Tracker Server)，跟踪服务器通过负载均衡找到一个合适的存储服务器

2、跟踪服务器将该存储服务器的地址返回给客户端

3、然后客户端上传文件，文件上传完成后

4、客户端上传文件后存储服务器将文件ID返回给客户端，此文件ID用于以后访问该文件的索引信息。文件索引信	  息包括：组名，虚拟磁盘路径，数据两级目录，文件名。

![img](https://img-blog.csdnimg.cn/20190718155842168.png)

**文件下载的流程：**

![img](https://img-blog.csdnimg.cn/20190718155852402.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyOTUzNTI5,size_16,color_FFFFFF,t_70)

tracker根据请求的文件路径即文件ID 来快速定义文件。
比如请求下边的文件：

![img](https://img-blog.csdnimg.cn/2019071815590415.png)

1.通过组名tracker能够很快的定位到客户端需要访问的存储服务器组是group1，并选择合适的存储服务器提供客户端访问。
2.存储服务器根据“文件存储虚拟磁盘路径”和“数据文件两级目录”可以很快定位到文件所在目录，并根据文件名找到客户端需要访问的文件。

### 七牛云：

将文件交给第三方公司进行管理

## 消息中间件解决方案

**降低模块与模块之间的耦合性**

**解决模块间异步调用的问题**

### 消息中间件

使用场景：执行时间长，且不需要返回值的服务请求，就可以使用消息中间件

### ActiveMQ

**发送的消息的类型：**

1、TextMessage：字符串文本消息

2、MapMessage：map类型消息

3、ObjectMessage：**可序列化对象**类型的消息

4、BytesMessage：字节类型的消息，多用于传输视频，音乐等数据

5、StreamMessage：流类型的消息

**发送消息的两种方式：**

1、点对点模式：一条消息只能由一个消费者接收，可以延时接收消息。就算发消息的时候，没有接收，当消费者启动时，还是能接收到这条消息。

2、发布/订阅模式：一条消息可以由多个消费者接收，必须实时接收消息，过时不候。类似于广播，在发布消息的时候没接收到，后面就不能再接收到了。

### dubbo和消息中间件的区别：

dubbo解决的是分布式模块之间的调用问题，其实还是同步调用  通过RPC协议。能拿到方法的调用者执行后的结果。

消息中间件解决的是模块间异步调用的问题，是异步调用。消息的生产者拿不到消费者执行后的结果

## SSO(单点登录解决方案)

![1569469405108](C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1569469405108.png)

### CAS：单点登录的一个具体解决技术

![1569469463217](C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1569469463217.png)

**CAS的执行流程：**

单个系统：

1、用户第一次访问系统，此时用户没有Ticket(凭证)，会被重定向到CAS的服务器(类似于一个验证中心)。

2、用户输入账号密码进行身份认证，认证成功后，CAS服务器会生成一个Ticket返回并写道cookie上，然后保存	  到浏览器中。

3、这时用户再带着浏览器中的Ticket去访问系统，那么CAS服务器会验证Ticket的正确性，如果正确，用户登录成	  功，访问到资源。

4、当用户第二次访问该系统时，如果此时浏览器中cookie保存的Ticket还没有过期，那么会拿着这个Ticket去CAS服务器	  中验证Ticket的正确性，如果正确，那么表示有权访问，返回用户请求的资源信息，就可以不用再次登录了。

多个系统：

1、用户访问系统A，此时用户浏览器的cookie中没有ticket(票根),会直接跳转到CAS验证中心，在CAS验证中心通过验证后，验证中心会生成一个ticket(票根)，交给用户(实际上就是保存在浏览器中)，然后用户再带着这个ticket去访问系统A，那么此时验证中心会去验证这个票根是否正确，如果正确，那么重定向回系统A，用户登录成功。

2、如果此时用户再去访问系统B，系统B和系统A都使用同一个CAS系统，然后，在用户访问系统B时，回带上这个存储在浏览器的ticket，然后拿着这个ticket去验证中心，去检验这个ticket是否正确，如果正确那么系统B成功登录。实现一次登录，多处访问。

**SSO 单点登录访问流程主要有以下步骤：**

1、**访问服务**：用户通过浏览器，向SSO 客户端(就是web网站)发送请求访问应用系统提供的服务资源。

2、**定向认证**：SSO 客户端会重定向用户请求到 SSO 服务器(类似于一个认证中心)。

3、**用户认证**：在SSO服务器进行用户身份认证，认证成功(用户名密码正确)后。

4、**发放票据**：SSO 服务器会产生一个随机的 Service Ticket，写入cookie，保存到浏览器中。

5、**验证票据**：SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。

6、**传输用户信息**：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

### 为什么使用CAS和SpringSecurity来结合使用？

1、因为使用原生的CAS，所有的配置都写在web.xml文件中，这样不是很好。

2、结合了之后，CAS的配置都会写在SpringSecurity的配置文件中，而且SpringSecurity和CAS结合之后，在配置文件中有专门配置CAS的标签。

3、CAS验证中心只能验证用户名和密码以及票据是否正确，不能验证用户的权限，而和SpringSecurity结合之后，两者共同协作，CAS验证用户名密码以及票据，SpringSecurity验证用户的权限。

## 跨域请求解决方案：

只要协议、主机(IP地址)/域名、端口有任何一个不同，都被当作是不同的域。

### 跨域请求问题出现场景：

这里说的 js 跨域是指通过 js 在不同的域之间进行数据传输或通信，比如用 ajax 向一个不同的域请求数据，或者通过 js 获取页面中不同域的框架中(iframe)的数据

**只有在前端页面上请求数据，才会出现跨域请求问题，在后端服务器之间进行数据的请求不算是跨域**

### 解决方案：

1、服务器代理解决方案：就是将跨域请求不放在前端页面进行，而是放在服务器上进行跨域请求数据，服务器再将请求到的数据发送给前端页面。

![1568978132282](C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1568978132282.png)

2、jsonP

3、CORS：目前用的比较多，但技术比较新，有的公司用的技术可能比较老，就只能使用前两种方法解决跨域请求问题。

**通过在被请求的方法中设置请求头中的属性值来解决跨域请求问题**

![1568978940126](C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1568978940126.png)

```java
设置信任的域：response.setHeader("Access-Control-Allow-Origin", "需要信任的域"); 
						比如http://localhost:9106	可以使用*代替，表示信任所有的域
是否开启cookie跨域：response.setHeader("Access-Control-Allow-Credentials", "true"); 
```

![1568978579768](C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1568978579768.png)

CORS 请求默认不发送 Cookie 和 HTTP 认证信息。如果要把 Cookie 发到服务器，一方面要服务器同意，指定 Access-Control-Allow-Credentials 字段。另一方面，开发者**必须在 AJAX 请求中打开 withCredentials 属性**。否则，即使服务器同意发送 Cookie，浏览器也不会发送。或者，服务器要求设置 Cookie，浏览器也不会处理

**在springMVC4.2版本后，spring中新增了跨域请求注解 @CrossOrigin**

只需要在跨域的方法上加上这个注解，并配置信任的域就行了，默认是开启cookie跨域的

![1568979007693](C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1568979007693.png)

## 电商项目的购物车模块

**添加购物车的逻辑：**

未登录情况下，将购物车列表存到cookie中，只在本机有效。

登录情况下，将购物车列表存到redis中，可以在各地有效。

**1、未登录情况下：**

①用户点击加入购物车后，将该商品的skuId和商品的数量发送给后台，后台在添加之前查询一下cookie中的购物车列表，将购物车列表，以及skuId和商品数量一起发送给服务层。

②服务层拿到数据后，

（1）先拿着skuId去数据库中查询，判断查询出来的sku对象是否为空，如果为空，那表示选中添加的商品就有问题，那么直接抛出异常；

（2）如果sku对象不为空，再判断sku对象的状态是否为可用，如果不可用抛出异常

③取出商品的商家ID，遍历购物车列表，判断购物车列表中是否已经存在该商家的购物车对象

（1）如果不存在与添加的商品同一个商家，那么创建一个新的购物车对象，并将值sku对象中的值赋给该购物车对象中的商品详情对象。

（2）如果存在与添加的商品同一个商家，再拿着skuId，去商品详情列表中查询是否有相同的商品。

如果有相同的商品，那么将该商品的数量加上前端传来的数量，然后总金额重新合计；

如果没有相同的商品，那么新建一个商品详情对象，将该有的值赋给这个商品详情对象，再将这个商品详情对象添加到商品详情列表中。

**2、登录情况下：**

①先查询cookie中是否有购物车列表数据，如果有，那么将cookie中的购物车列表和redis中的购物车列表进行合并，合并规则和添加购物车列表相似，循环两个购物车列表中的一个，拿着循环的购物车列表中的商品详情对象数据，去另一个购物车列表中判断，如果商家没有相同的，那么将新建一个商家购物车对象，如果有相同的，那么就去判断购物车列表中的商品详情对象是否相同，不同则创建新的商品详情对象，有相同的那么就数量和总金额重新赋值。

②在合并购物车之后，将合并后的购物车存到redis中，并清空cookie中的数据。

③再向合并后的购物车列表中添加选中的商品数据，跟未登录时的流程一致。

## 电商项目订单的生成：

必会：java基础，javaweb基础，ssm框架，redis以及常用的缓存技术

加分点：cas，mq，搜索

## 支付模块：

### 微信支付：

使用了微信提供的支付接口

微信支付流程：

① 用户点击生成订单，会在后台生成一个订单， 后台调用一下微信提供的下单API，从微信支付系统中获取生成的预支付链接(url)。

② 后台将获取到的预支付链接发送给前台，前台使用这个链接生成一个二维码。

③ 用户使用微信扫描二维码，其实就是访问二维码中的预支付链接，微信支付系统验证二维码中url的有效性，如果有效，就会向用户显示微信的支付页面，页面上能看到订单号和需要支付的金额。用户完成付款后，只能看到在微信支付系统上已支付(短信，微信消息告知)，但是并看不到购物网站支付后的效果(页面跳转到支付成功页面)。这时就需要后台进行判断。

④ 后台有两种方式可以获取该订单的支付情况

（1）当用户完成支付后，微信支付系统主动向后台发送用户的支付情况(在开发时，这种方式无效，因为在开发时，服务器是本地服务器，外网无法访问，只有在项目上线部署到公网上时，这个才有用处。)

（2）后台调用查询订单API，向微信支付系统发送查询请求，去查询用户的支付情况

一般在实际开发中会两种结合一起使用，再加定时任务去定时(一个小时左右)的扫描数据库中订单支付情况和支付日志中支付情况和微信支付系统中的用户支付情况进行比对，然后同步数据，以微信支付系统的支付情况为准，同步数据库中的数据，这样基本就能保证支付的同步性，极大的减少了，用户已支付但订单状态为未支付。

细节：

① 后台要持续的向微信支付系统发送查询请求，去查询用户的支付情况，因为后台并不知到用户何时完成了支付操作。但是查询请求又不能太频繁，可以设置没发一次请求，睡眠3秒，再发第二次请求去查询支付情况。如果发送请求的次数到达100次，就是300s(5分钟)后，用户还未支付，那么向前台发送消息“二维码过期”，然后重新生成二维码。

### 支付宝支付：

使用支付宝提供的支付接口

支付宝支付流程：

## 秒杀模块：

① 在实际中，秒杀系统和其他系统是完全分离的，防止当秒杀系统宕机后，不会影响到其余系统的使用

秒杀系统因为高并发，很容易出问题

② 秒杀的首页可以使用网页静态化技术，将大部分数据直接放在静态页面上，将小部分需要变化的数据，放在redis中，可以减少数据的传输量，提高响应速度。

③ 设置一个定时任务，在秒杀开始前将参与秒杀的商品数据存到redis中，因为如果在秒杀开始时再将数据放入缓存中，这个并发太高，还是会将数据库打垮。

### 电商秒杀中的问题：

①

## hibernate和mybatis的区别：

## SpringDate JPA：

**springdata JPA和原生JPA的区别：**

对JPA规范(接口)的进一步封装，但是springdata JPA也还是一种规范(接口)

真正的实现是 hibernate

**配置：**

### lombok注解：

1、导入依赖

2、在idea中安装lombok插件

3、使用注解

@Data  可以在使用在实体类中，不用写getter和setter和toString方法，在编译时自动生成

@NoArgsConstructor  使用在实体类上，在编译时自动生成无参构造

@AllArgsConstructor  使用在实体类上，在编译时自动生成全参构造

### 查询数据库，如果被查询的数据不存在会返回什么？

**在jpa中**

使用find()方法进行查询，如果查询的数据不存在那么会返回一个null

使用getReference()方法进行查询，如果查询的数据不存在那么会抛出异常

**在mbatis中**

如果查询的数据不存在那么会返回一个

### JPA中find方法和getReference的区别：

find方法和getReference的区别：

find方法：立即加载，查询出来的结果是对象本身，不管你用不用查询出来的对象，都会去数据库中进行查询

getReference方法：延迟加载(懒加载)，查询出来的结果是一个动态代理对象，执行查询的时机是在你使用这个对象的属性时，才会去数据库查询数据，意思就是你什么时候用，就什么时候查。

1、find()当查询的数据在数据库中不存在时，会返回null

getReference()当查询的数据在数据库中不存在时，会直接抛出异常

2、find()查询出来的是参数中的对象本身

getReference()查询出来的是参数中的对象的代理对象，而且使用的是cglib代理，基于继承的代理，如果实体类被final修饰了，那么就无法使用动态代理了，延迟加载会失效，就和find是一样了

3、find()是立即加载，当执行查询方法的时候，就会去数据库中将数据查询出来

getReference()是延迟加载(懒加载)，只有当使用到查询的对象时，才会去数据库中查询数据

4、如果想要优化，那么使用getReference()进行延迟加载，使用的时候才会去数据库中查询数据，可以减轻数据库的压力。

### jpql(java持久化查询语言)：

保留了sql语句的关键字，但是语句中**没有**表名，字段名，**只有**类名，属性名。

### SpringData JPA：

1、导入依赖

2、创建实体类，加上JPA的各种注解，比如@Entity，@Table，@Id，@Colum，@Data等

3、Spring集成SpringData JPA  在spring配置文件中配置

4、

## 单例模式：

**饿汉单例模式：**

```java
/**
 * 饿汉单例模式
 */
class Singleton{

//私有化成员变量  直接创建出Singleton对象  你想用直接拿就行了
    private static final Singleton singleton=new Singleton();

//私有化构造方法
    private Singleton(){}

//创建一个静态方法获取对象
    public static Singleton getInstance(){
        return singleton;
    }
}
```

**懒汉单例模式：**

```java
/**
 * 懒汉单例模式  要使用双重检测锁才能保证对象的唯一
 */
class Singleton{

//私有化成员变量  先不给成员变量赋值 等到有人使用的时候再创建，不用就不创建
    private static Singleton singleton=null;

//私有化构造方法
    private Singleton(){}

//创建一个静态方法获取对象  懒汉单例模式会出现没有单例的问题 这时候要使用双重检测锁
    public static Singleton getInstance(){
        //这样主要因为程序执行需要时间 这里进行双重判断就不会出现创建了两个对象
        //先判断singleton对象是否为空
        if (singleton==null){ // 可能 线程1 线程2 同时执行到了这里 都通过了判断为空
            //使用同步锁
            synchronized ("0"){
                //再次判断singleton对象是否为空 如果为空才创建对象
                if (singleton == null){
                    singleton=new Singleton();
                }
            }
        }
        return singleton;
    }
}
```

## final，finally，finalize的区别：

### final（是一个修饰符）

**修饰类：**表示该类无法被继承

**修饰方法：**表示该方法不能被重写

**修饰变量：**表示该变量只能被赋值一次

声明数据为常量

**对于基本数据类型**，final使其数值不变；

**对于引用类型**，final使其引用不变，意思就是该引用只有一次指向对象的机会，也就不能引用其他对										   象，但是被引用的对象本身是可以修改的。

### finally

finally是用于异常处理的场面，无论是否有异常抛出，都会执行

### finalize

finalize是Object的方法，所有类都继承了该方法。当一个对象满足垃圾回收的条件，并且被回收时，该对象的finalize()方法就会被调用。

## 基本数据类型：

字符类型，布尔类型，浮点类型，整数类型

四类八种：byte short int long folat double char boolean

所占字节： 1		2	   4	 8	  4          8		2		 1             一个字节占八位

## 在循环中使用return、break、continue的区别：

### break

立即退出循环或者switch语句，在其他地方使用会导致错误。

### continue

只退出当前循环，还允许下一次循环，continue语句只能用在while语句、do/while语句、for语句、或者for/in语句的循环体内，在其它地方使用都会引起错误！

### return

函数执行return语句后立即停止代码，return语句后的代码不会被执行。return语句应用范围只能出现在函数体内，出现在代码中的其他任何地方都会造成语法错误！

## List，Set，Map的初始容量和加载因子：

### 加载因子：

加载因子的系数小于等于1，不能大于1；作用：当元素个数超过容量长度*加载因子的系数时，进行扩容。

比如：ArrayList的初始容量是10，加载音泽是0.5，当集合中元素的个数超过（10*0.5）时进行扩容

### List

ArrayList的初始容量是10；**扩容容量**：初始容量的1.5倍+1，一次扩容后长度为16   **加载因子**：0.5

Vector的初始容量为10；**扩容容量**：初始容量的2倍，一次扩容后容量为20   **加载因子**：1

### Set

HashSet的初始容量为16，**扩容容量**：初始容量的2倍，一次扩容后容量为32    **加载因子**：0.75

### Map

HashMap的初始容量为16，**扩容容量**：初始容量的2倍，一次扩容后容量为32    **加载因子**：0.75

## 序列化的作用：

解决数据在网络传输过程中的完整性

## MySQL：

### InnoDB 和MYISAM 存储引擎的区别？

**InnoDB:**

InnoDB 存储引擎支持事务、支持外键、支持非锁定读、行锁设计其设计主要面向OLTP 应用。
InnoDB 存储引擎表采用聚集的方式存储，因此每张表的存储顺序都按主键的顺序存放，如果没有指定主键，InnoDB 存储引擎会为每一行生成一个6字节的ROWID并以此作为主键。
InnoDB 存储引擎通过MVCC 获的高并发性，并提供了插入缓冲、二次写、自适应哈希索引和预读等高性能高可用功能
InnoDB 存储引擎默认隔离级别为REPEATABLE_READ（重复读）并采用next-key locking(间隙锁)来避免幻读

**MySIAM:**

MYISAM 存储引擎不支持事务、表锁设计、支持全文索引其设计主要面向OLAP 应用
MYISAM 存储引擎表由frm、MYD 和MYI 组成，frm 文件存放表格定义，MYD 用来存放数据文件，MYI 存放索引文件。MYISAM 存储引擎与众不同的地方在于它的缓冲池只缓存索引文件而不缓存数据文件，数据文件的缓存依赖于操作系统。
操作区别：

MYISAM 保存表的具体行数，不带where 是可直接返回。InnoDB 要扫描全表。
DELETE 表时，InnoDB 是一行一行的删除，MYISAM 是先drop表，然后重建表
InnoDB 跨平台可直接拷贝使用，MYISAM 不行
InnoDB 表格很难被压缩，MYISAM 可以

**选择：**

MyISAM相对简单所以在效率上要优于InnoDB。如果系统读多，写少。对原子性要求低。那么MyISAM最好的选择。且MyISAM恢复速度快。可直接用备份覆盖恢复。
InnoDB 更适合系统读少，写多的时候，尤其是高并发场景。

### 索引：

#### 索引的优点：

#### 哪些情况需要加索引？

1、在经常需要搜索的列上，可以加快搜索的速度；
2、在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；
3、在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；
4、在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；
5、在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；
6、在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。

#### 哪些情况不需要加索引？

1、对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
2、对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
3、对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。
4、当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。

### 事务：

**事务具有ACID 四种特性**，即**原子性(atomicity)**，**一致性(consistency)**，**隔离性(isolation)**，**持久性(durability)**：

1、**原子性**，指的是事务是一个不可分割的操作，要么全都正确执行，要么全都不执行。
2、**一致性**，指的是事务把数据库从一种一致性状态转换成另一种一致性状态，事务开始前和事务结束后，数据库	  的完整性约束没有被破坏。
3、**隔离性**，要求每个读写事务相互之间是分开的，在事务提交前对其他事务是不可见的
4、**持久性**，指的是事务一旦提交，其结果就是永久性的，即使宕机也能恢复。

说一说事务的隔离级别，分别解决了什么问题？

**事务有4 个隔离级别，分别是：**

**读未提交(read uncommit)**
**读已提交(read commit)** 			 解决了脏读
**可重复读(repeatable read)**		解决了不可重读
**和序列化(serializable)**				 解决了幻读
隔离级别依次提高，分别解决了脏读、不可重读和幻读。

**【拓展】**

1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据

2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。

3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表

4、InnoDB 默认隔离级别为repeatable read，但是通过next-key lock 解决了幻读，保证了ACID。

### SQL优化：

### 说一说drop、delete与truncate的区别？

1、drop直接删掉表有关的一切（数据/结构/约束…），不会记录日志，为DDL(Data Definition Language,数据库	  定义语言)操作。
2、truncate 删除表中所有数据（再插入时自增长id又从1开始），该操作也不会记录日志所以比较快，为DDL操	作。只能删table。
3、delete语句执行删除的过程是每次从表中删除一行，需要记录日志，比较缓慢，可以加where语句，为DML。可以删除table(表)和view(视图)。DML是Data Manipulation Language, 数据操纵语言。
4、速度上drop > truncate > delete

一般如果想要快速删除的话，可以将truncate 和drop一起使用，先使用truncate 将表中数据全部删除，然后使用drop将表删除。

### 什么是视图？以及视图的使用场景有哪些？

视图是一种虚拟的表，具有和物理表相同的功能，没有物理存储。可以对视图进行增，改，查，操作，试图通常是有一个表或者多个表的行或列的子集。对视图的修改不影响基本表。它使得我们获取数据更容易，相比多表查询。

使用场景：

1、只希望用户查看特定信息的列

2、来源于多个表，可以创建视图提取我们需要的信息，简化操作。
例如：在公司中，员工查询的表中不会有工资这一数据，但是原表中是由工资这一数据的，但是我们不想让员工能看到工资，就建立一个视图，将工资信息给屏蔽掉。

### Mysql 的几种连接方式？

1、内连接：inner join on
组合两个表中的记录，返回关联字段相符的记录，也就是返回两个表的交集（阴影）部分。

2、左连接：left join on / left outer join on
left join 是left outer join的简写，它的全称是左外连接，是外连接中的一种。
左(外)连接，左表(a_table)的记录将会全部表示出来，而右表(b_table)只会显示符合搜索条件的记录。右表记录不足的地方均为NULL。

3、右连接：right join on / right outer join on

right join是right outer join的简写，它的全称是右外连接，是外连接中的一种。
与左(外)连接相反，右(外)连接，左表(a_table)只会显示符合搜索条件的记录，而右表(b_table)的记录将会全部表示出来。左表记录不足的地方均为NULL。

4、全连接

mysql不支持全连接全连接，使用union连接左连接和右连接，可以实现全连接。

Zds2y/Notes

简介

发行版

贡献者

近期动态

Zds2y/Notes .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

Zds2y/Notes