谷粒商城高级（二）组件的使用

组件的使用

• 一、Elasticsearch
• • 1.知识梳理
  • • 1.1 基本概念
    • • 1.1.1 Index（索引）
      • 1.1.2 Type（类型）
      • 1.1.3 Document（文档）
      • 1.1.4 倒排索引机制
    • 1.2 相关命令
    • • 1.2.1 _cat
      • 1.2.2 索引一个文档（保存一条记录）
      • 1.2.3 查询文档
      • 1.2.4 更新文档
      • 1.2.5 删除文档和索引
      • 1.2.6 bulk批量API
    • 1.3 进阶检索
    • • 1.3.1 ES中的两种检索方法
      • 1.3.2 Query DSL
      • • 1.3.2.1 基本语法结构
        • 1.3.2.2 针对某个字段结构
        • 1.3.2.3 返回部分字段
        • 1.3.2.4 match查询
        • 1.3.2.5 match_phrase短语匹配
        • 1.3.2.6 multi_match多字段匹配
        • 1.3.2.7 bool复合查询
        • 1.3.2.8 term
    • 1.4 aggregations聚合功能
    • • 1.4.1 基本概念
      • 1.4.2 基本语法
      • 1.4.3 举例
    • 1.5 Mapping映射
    • • 1.5.1 基本概念
      • 1.5.2 相关操作
      • • 1.5.2.1 创建映射规则
        • 1.5.2.2 添加新字段映射
        • 1.5.2.3 映射的更新
        • 1.5.2.4 数据迁移
  • 2. 组件使用
  • • 2.1 全文检索-数据库数据的检索
    • 2.2 ELK技术栈-日志分析检索
• 二、nginx
• • 1. nginx搭建域名访问环境
  • • 1.1 正向代理与反向代理
    • • 1.1.1 正向代理
      • 1.1.2 反向代理
    • 1.2 nginx配置文件简介
    • 1.3 nginx的域名访问环境搭建
    • • 1.3.1 nginx在虚拟机中
      • • 1.3.1.1 修改host文件
        • 1.3.1.2 修改nginx配置文件
      • 1.3.2 nginx在在腾讯云服务器中
      • • 1.3.2.1 修改host文件
        • 1.3.2.2 花生壳进行内网穿透
        • 1.3.2.3 修改nginx配置文件
        • 1.3.2.3 注意
      • 1.3.3 nginx在本地windows系统中（使用）
      • • 1.3.3.1 修改host文件
        • 1.3.3.2 下载一个windows版的nginx
        • 1.3.3.3 修改nginx配置文件
  • 2. nginx实现动静分离
  • • 2.1 动静分离
    • 2.2 实现步骤
    • • 2.2.1 移动静态资源
      • 2.2.2 设置nginx访问规则
      • 2.2.3 修改项目中首页
• 三、Redis做缓存
• • 1. Redis的整合
  • 2. 分布式锁框架Redisson
  • • 2.1 Redisson的引入
    • 2.2 Redisson的使用
    • • 2.2.1 可重入锁(Reentrant Lock)
      • 2.2.2 读写锁(ReadWriteLock)
      • 2.2.3 信号量(Semaphore)
      • 2.2.4 闭锁(CountDownLatch)
  • 3. 缓存数据一致性问题
  • • 3.1 双写模式
    • 3.2 失效模式
    • 3.3 总结
    • 3.4 高效解决：Canal
  • 4. SpringCache简化缓存开发
  • • 4.1 SpringCache的引入
    • 4.2 SpringCache的使用
    • • 4.2.1 前提
      • 4.2.2 @Cacheable注解
      • 4.2.3 @CachEvict注解
      • 4.2.4 @CachePut注解
      • 4.2.5 @Caching注解
    • 4.3 SpringCache总结
    • • 4.3.1 读模式
      • 4.3.2 写模式
      • 4.3.3 总结
  • 5. 缓存小总结
• 四、注册登录
• • 1. 验证码
  • 2. 社交登录
  • • 2.1 OAuth基本概念
    • 2.2 OAuth2.0的社交登录流程
    • 2.3 微博社交登录
    • • 2.3.1 微博授权机制说明
      • 2.3.2 微博登录流程解析
  • 3. 分布式Session
  • • 3.1 Session的工作原理
    • 3.2 Session缺陷及解决
    • • 3.2.1 同一微服务Session共享问题
      • • 3.2.1.1 问题描述
        • 3.2.1.2 解决方案
      • 3.2.2 不同同微服务Session共享
      • • 3.2.2.1 问题描述
        • 3.2.2.2 解决方案（采用）
    • 3.3 整合SpringSession解决问题
    • • 3.3.1 同一微服务Session共享问题
      • 3.3.2 不同同微服务Session共享
      • 3.3.3 附加：采用JSON序列化机制
    • 3.3 SpringSession的核心原理（装饰者模式）
  • 4. 单点登录
  • • 4.1 概述
    • 4.2 实现
    • • 4.2.1 实现前提
      • 4.2.2 实现步骤
      • 4.2.3 要点分析
      • 4.2.4 现成框架
• 五、Seata分布式事务
• • 1. 本地事务
  • • 1.1 本地事务相关基础知识
    • • 1.1.1 本地事务基本概念
      • 1.1.2 @Transactional注解
      • • 1.1.2.1 说明
        • 1.1.2.2 传播行为
      • 1.1.3 SpringBoot中的本地事务
    • 1.2 本地事务在分布式下的问题
  • 2. 分布式事务
  • • 2.1 分布式事务定理
    • • 2.1.1 CAP定理
      • 2.2.2 BASE理论
      • 2.2.3 三种一致性
    • 2.3 分布式事务的解决方案
    • • 2.3.1 刚性事务（ACID）- 2PC模式
      • 2.3.2 柔性事务（BASE）- TCC事务补偿型方案
      • 2.3.3 柔性事务（BASE）- 最大努力通知型方案
      • 2.3.4 柔性事务（BASE）- 可靠消息 + 最终一致性方案
  • 3. Seata
  • • 3.1 Seata的基本介绍
    • 3.2 Seata的环境准备
    • • 3.2.1 建立UNDO_LOG表
      • 3.2.2 下载安装Seata
    • 3.3 Seata的使用（默认为AT模式）
    • • 3.3.1 导入Seata的依赖
      • 3.3.2 修改配置文件
      • • 3.2.1 registry.conf
        • 3.2.2 file.conf
      • 3.3.3 注入DataSourceProxy
      • 3.3.4 复制配置文件
      • 3.3.5 修改配置文件
      • 3.3.6 @GlobalTransactional
• 六、RabbitMQ
• • 1. MQ基础知识
  • • 1.1 使用场景
    • • 1.1.1 异步处理
      • 1.1.2 应用解耦
      • 1.1.3 流量控制
    • 1.2 基础知识
    • • 1.2.1 基本概念
      • • 1.2.1.1 消息代理（message broker）和目的地（destination）
        • 1.2.1.2 消息队列主要有两种形式的目的地
        • 1.2.1.3 两种规范
  • 2. RabbitMQ基本概念
  • • 2.1 RabbitMQ简介
    • 2.2 核心概念
    • • 2.2.1 Message
      • 2.2.2 Publisher
      • 2.2.3 Exchange
      • 2.2.4 Queue
      • 2.2.5 Binding
      • 2.2.6 Connection
      • 2.2.7 Channel
      • 2.2.8 Consumer
      • 2.2.9 Virtual Host
      • 2.2.10 Broker
    • 2.3 Docker下的安装
    • • 2.3.1 安装流程
      • 2.3.2 端口介绍
    • 2.4 RabbitMQ的交换机Exchange
    • • 2.4.1 direct
      • 2.4.2 fanout
      • 2.4.3 topic
    • 2.5 RabbitMQ的整合
    • 2.6 RabbitMQ的具体使用
    • • 2.6.1 AmqpAdmin创建交换机、队列、绑定
      • 2.6.2 RabbitTemplate收发消息
      • 2.6.3 @RabbitListener监听队列
      • • 2.6.3.1 前提：@RabbitListener必须开启@EnableRabbit
        • 2.6.3.2 标注在方法上
        • 2.6.3.3 标注在类上（常用）
      • 2.6.4 @RabbitHandler监听队列
      • • 2.6.4.1 前提：@RabbitHandler必须开启@EnableRabbit
        • 2.6.3.2 标注在方法上
    • 2.7 RabbitMQ的消息确认机制
    • • 2.7.1 概述
      • 2.7.2 发送端确认
      • • 2.7.2.1 confirmaCallback
        • 2.7.2.2 returnCallback
      • 2.7.3 消费端确认
    • 2.8 RabbitMQ的延时队列
    • • 2.8.1 死信
      • • 2.8.1.1 TTL
        • 2.8.1.2 Dead Letter Exchanges（DLX）
      • 2.8.2 延时

一、Elasticsearch

1.知识梳理

全文搜索属于最常见的需求，开源的Elasticsearch是目前全文搜索引擎的首选。它可以快速地储存、搜索和分析海量数据。Elastic的底层是开源库Lucene。但是，Lucene无法直接使用，必须自己写代码去调用它的接口。而Elastic是Lucene的封装，提供了RESTAPI的操作接口，开箱即用。

1.1 基本概念

1.1.1 Index（索引）

• 动词，相当于MySQL中的insert。ES中的索引一条数据等同于MySQL中插入一条数据。
• 名词，相当于MySQL中的Database。ES中的简历一个索引等同于MySQL中建立一个数据库。

1.1.2 Type（类型）

• 在Index（索引）中，可以定义一个或多个类型。
• 类型就类似于MySQL中的Table每一种类型的数据放在一起。

1.1.3 Document（文档）

• 保存在某个索引（Index）下，某种类型（Type）的一个数据（Document）。
• 文档是JSON格式的，Document就像是MySQL中的某个Table里面的内容，一条文档就类似于MySQL中的一条数据。

1.1.4 倒排索引机制

1.2 相关命令

1.2.1 _cat

1.2.2 索引一个文档（保存一条记录）

需要具体指明保存在哪个索引的哪个类型下，可能要指明用哪个唯一标识。

//比如在customer索引下的external类型下保存1号数据：
//1.以PUT方式或POST方式发送如下请求
customer/external/1
//2.请求体内容如下
{ "name": "John Doe"
}

1.PUT和POST都可以完成文档的索引（即数据的插入）。
2.POST，如果不指定id，会自动生成id并新增数据；指定id如果id不存在就会新增这条数据，存在则会修改这个数据，并新增版本号。
3.PUT，PUT必须指定id，如果id不存在则为新增，存在则为修改。一般用PUT做修改操作。

1.2.3 查询文档

需要指明查询哪个索引的哪个类型下的哪个文档

//比如查询customer索引下的external类型下的1号数据：
//1.以GET方式发送如下请求：
customer/external/1
//2.查询结果如下：
{"_index": "customer", //在哪个索引"_type": "external", //在哪个类型"_id": "1", //记录 id"_version": 2, //版本号"_seq_no": 1, //并发控制字段，每次更新就会+1，用来做乐观锁"_primary_term": 1, //同上，主分片重新分配，如重启，就会变化"found": true, "_source": { //真正的内容"name": "John Doe"}
}
//3.如何实现乐观锁？
更新时，发送的请求后面携带"?if_seq_no=最新信息&if_primary_term=1"即可

1.2.4 更新文档

1.方式一：POST方式带_update

//比如更新customer索引下的external类型下的1号数据
//POST方式发送请求customer/external/1/_update
{"doc":{"name": "John Doew"}
}
//该方式会对比源文档数据，如果相同不会进行任何操作，版本号等信息都不变。

2.方式二

//比如更新customer索引下的external类型下的1号数据
//POST方式发送请求customer/external/1
{"name": "John Doe2"
}
//该方式就是不论数据是否不变，都会直接更新

3.方式三

//比如更新customer索引下的external类型下的1号数据
//PUT方式发送请求customer/external/1
{"name": "John Doe2"
}
//该方式就是不论数据是否不变，都会直接更新

4.注解：以上方式都允许更新的同时增加属性，比如

//POST方式发送请求customer/external/1/_update
{"doc": {"name": "Jane Doe", "age": 20 }
}

1.2.5 删除文档和索引

1.删除文档

//比如删除customer索引下的external类型下的1号数据
//DELETE方式发送请求customer/external/1

2.删除索引

//比如删除customer索引
//DELETE方式发送请求customer

1.2.6 bulk批量API

//1.语法格式：以POST方式发送_bulk请求，携带以下请求体
{ action: { metadata }}
{ request body }
{ action: { metadata }}
{ request body }

1.说明：bulkAPI以此按顺序执行所有的action（动作）。如果一个单个的动作因任何原因而失败，它将继续处理它后面剩余的动作。当bulkAPI 返回时，它将提供每个动作的状态（与发送的顺序相同），所以可以检查是否一个指定的动作是不是失败了。
2.注意：可以在请求中携带对哪个索引的哪个类型进行操作，如果请求中没有携带，则需要在metadata中指明，否则会报错找不到索引。

1.3 进阶检索

1.3.1 ES中的两种检索方法

1.检索的所有条件放在请求中

GET bank/_search?q=*&sort=account_number:asc

2.利用uri和请求体进行检索

GET bank/_search
{"query": {"match_all": {}},"sort": [{"account_number": { "order": "desc"}}]
}

3.结果分析

took：Elasticsearch 执行搜索的时间（毫秒）。
time_out：告诉我们搜索是否超时。
_shards：告诉我们多少个分片被搜索了，以及统计了成功/失败的搜索分片。
hits：搜索结果。
hits.total：搜索结果。
hits.hits：实际的搜索结果数组（默认为前10的文档）。
sort：结果的排序 key（键）（没有则按score排序）。
score和max_score：相关性得分和最高得分（全文检索用）。

1.3.2 Query DSL

利用uri和请求体检索时，请求体其实就是我们所说的Query DSL，他要遵循指定的规则。

1.3.2.1 基本语法结构

1.基本语法：

{QUERY_NAME: {ARGUMENT: VALUE, ARGUMENT: VALUE,... }
}

2.举例：

GET bank/_search
{ "query": {"match_all": {}}
}

1.3.2.2 针对某个字段结构

1.基本语法：

{QUERY_NAME: {FIELD_NAME: {ARGUMENT: VALUE, ARGUMENT: VALUE,... }}
}

2.举例：

{"query": {"match_all": {}},"from": 0, "size": 5,"sort": [{ "account_number": {"order": "desc"}}]
}

解释：

query定义如何查询，match_all查询类型（代表查询所有的所有），es中可以在query中组合非常多的查询类型完成复杂查询。
除了query参数之外，我们也可以传递其它的参数以改变查询结果，如 sort，size等。
from+size限定，完成分页功能。
sort 排序，多字段排序，会在前序字段相等时后续字段内部排序，否则以前序为准。

1.3.2.3 返回部分字段

1.使用方法：在_source中以数组方式指明需要返回的字段即可。
2.举例：

{"query": {"match_all": {}},"from": 0, "size": 5, "_source": ["age","balance"]
}

1.3.2.4 match查询

1.基本语法：

{ "query":{"match": {"FIELD": "TEST"}}
}

2.举例：

//例1
{ "query": {"match": {"account_number": "20"}}
}
//例2
{ "query": {"match": {"address": "mill"}}
}
//例3
{ "query": {"match": {"address": "mill road"}}
}

3.注意：查询的属性值为基本类型时，为精确匹配；查询属性值为字符串时，为全文检索；查询属性值为字符串多个单次时，还会进行分词。最后查询得到的结果会按照相关性得分由高到低的顺序返回。

1.3.2.5 match_phrase短语匹配

1.说明：当match检索查询的属性值为字符串多个单词时，会开启分词检索。而采用match_phrase则将要匹配的值当成一个整体单词（不分词）进行检索
2.举例：

{ "query": {"match_phrase": {"address": "mill road"}}
}

1.3.2.6 multi_match多字段匹配

1.说明：只要指定的属性中包含要查询的值，则该条数据就会被返回。
2.举例：

//state或者address包含mill
{"query": {"multi_match": { "query": "mill","fields": ["state","address"]}}
}

1.3.2.7 bool复合查询

1.基本概念：bool用来做复合查询，复合语句可以合并任何其它查询语句，包括复合语句，了解这一点是很重要的。这就意味着，复合语句之间可以互相嵌套，可以表达非常复杂的逻辑。
2.说明：① must：必须达到must列举的所有条件，must会贡献相关性得分。② should：应该达到should列举的条件，如果达到会增加相关文档的评分，并不会改变查询的结果。但如果query中只有should且只有一种匹配规则，那么should的条件就会被作为默认匹配条件而去改变查询结果。③ must_not必须不是指定的情况。④ filter：和must功能一样，唯一的区别是，它不会贡献相关性得分。
3.举例：

{ "query": {"bool": {"must": [{ "match": { "address": "mill" } },{ "match": { "gender": "M" } }],"should": [{"match": { "address": "lane" }}],"must_not": [{"match": { "email": "baluba.com" }}],"filter": { "range": { "balance": { "gte": 10000,"lte": 20000}}}}}
}

1.3.2.8 term

1.说明：term和match一样，用于匹配某个属性的值。一般来说，全文检索字段用match，其他非text字段匹配（即精确检索）用term。
2.举例：

{ "query": {"bool": {"must": [{"term": { "age": { "value": "28"}}},{"match": { "address": "990 Mill Road"}}]}}
}

1.4 aggregations聚合功能

1.4.1 基本概念

1.4.2 基本语法

"aggs": { "aggs_name 这次聚合的名字，方便展示在结果集中": { "AGG_TYPE 聚合的类型（avg,term,terms）": {聚合的具体字段}
}

1.4.3 举例

1.搜索address中包含mill的所有人的年龄分布以及平均年龄，但不显示这些人的详情。

{"query": {"match": {"address": "mill"}},"aggs": {"group_by_state": {"terms": {"field": "age"}},"avg_age": {"avg": {"field": "age"}}},"size": 0
}

2.按照年龄聚合，并且请求这些年龄段的这些人的平均薪资。

{"query": {"match_all": {}},"aggs": {"age_avg": {"terms": {"field": "age","size": 1000},"aggs": {"banlances_avg": {"avg": {"field": "balance"}}}}},"size": 1000
}

3.查出所有年龄分布，并且这些年龄段中M的平均薪资和F的平均薪资以及这个年龄段的总体平均薪资。

{"query": {"match_all": {}},"aggs": {"age_agg": {"terms": {"field": "age","size": 100},"aggs": {"gender_agg": { "terms": { "field": "gender.keyword","size": 100},"aggs": {"balance_avg": {"avg": {"field": "balance"}}}},"balance_avg":{"avg": {"field": "balance"}}}}},"size": 1000
}

1.5 Mapping映射

1.5.1 基本概念

映射指的就是文档中的每个属性的数据类型，在第一次存放文档时，ES就会为每个文档中的每一个属性猜测一个数据类型。

1.5.2 相关操作

1.5.2.1 创建映射规则

//创建索引并指定映射
PUT /my-index
{"mappings": {"properties": {"age": { "type": "integer" },"email": { "type": "keyword" },"name": { "type": "text" }}}
}

1.5.2.2 添加新字段映射

//在已有索引my-index中添加新属性及其映射
PUT /my-index/_mapping
{"properties": {"employee-id": { "type": "keyword", }}
}

1.5.2.3 映射的更新

对于已经存在的映射字段，我们不能更新，更新必须创建新的索引进行数据迁移。

1.5.2.4 数据迁移

首先明确，在ES6以后，开始逐步移除type（注意，此时的type代表SQL中的表，而不是属性的数据类型）
1.ES6之前的写法

POST _reindex
{"source": {"index": "原索引","type": "类型（代表SQL中的表）"},"dest": {"index": "目的索引"}
}

2.ES6之后的写法

POST _reindex
{"source": {"index": "原索引"},"dest": {"index": "目的索引"}
}

2. 组件使用

2.1 全文检索-数据库数据的检索

2.2 ELK技术栈-日志分析检索

二、nginx

1. nginx搭建域名访问环境

1.1 正向代理与反向代理

1.1.1 正向代理

1.概念：正向代理功能是用于帮助当前主机进行访问外界，当我们的主机无法访问目标服务器时，我们可以选择购买一台正向代理服务器，我们的主机只需要访问代理服务器即可，由代理服务器来代替我们访问目标服务器，并将访问得到的结果返回给我们的主机。
2.功能：由于当前主机对于目标服务器的访问都是通过代理服务器进行的，目标服务器与代理服务器进行交互，获取查询到代理服务器的信息，所以，正向代理可以很好的隐藏客户端信息。

1.1.2 反向代理

1.概念：反向代理功能是用于帮助外界主机访问当前服务器，当外界主机需要访问当前服务器时，可以让主机访问当前服务器所指定的代理服务器，由代理服务器来访问当前服务器，当前服务器会将返回的信息传递给代理服务器并由代理服务器返回给主机。
2.功能：反向代理可以很好的隐藏服务器信息，对外界屏蔽内网服务器信息。此外，反向代理还可以实现负载均衡访问的功能。

1.2 nginx配置文件简介

1.3 nginx的域名访问环境搭建

1.3.1 nginx在虚拟机中

1.3.1.1 修改host文件

在host文件中，将gulimall.com与指定的ip地址进行绑定。

1.3.1.2 修改nginx配置文件

让nginx进行反向代理，将所有来自gulimall.com的请求都转到网关。

1.3.2 nginx在在腾讯云服务器中

1.3.2.1 修改host文件

在host文件中，将gulimall.com与指定的ip地址进行绑定。

1.3.2.2 花生壳进行内网穿透

此时，需要进行内网穿透，让本机的web服务，可以被腾讯云所访问，需要下载一个花生壳，花6块钱进行http认证。得到一个属于本机的，外网可访问的域名。建立一个映射，实现 “外网域名:外网端口”<===>“本机的ip:网关端口” 的绑定关系。

1.3.2.3 修改nginx配置文件

与虚拟机中配置步骤一样，只需要将nginx配置文件中的"虚拟机ip:端口"改为"本机外网域名:外网端口"即可。

1.3.2.3 注意

有坑，一开始配置可以正常使用，但是一旦配置了proxy_set_header，并采用上游服务器作为proxy_pass，再利用gulimall.com进行访问，nginx就会报错404，找不到页面。

1.3.3 nginx在本地windows系统中（使用）

1.3.3.1 修改host文件

在host文件中，将gulimall.com与指定的ip地址进行绑定。

1.3.3.2 下载一个windows版的nginx

具体步骤详见：https://blog.csdn.net/GyaoG/article/details/124081770

1.3.3.3 修改nginx配置文件

与虚拟机中配置步骤一样，此时，由于部署在本地windows系统中，只需要让nginx监听访问域名为gulimall.com的、访问端口为80端口的请求，并将其转到本机的88端口。

2. nginx实现动静分离

2.1 动静分离

由于一开始，所有的静态资源也放在项目的各个模块中，所以，当我们发送首页请求时，无论是查数据库的动态请求，还是申请静态资源的请求都需要交给Tomcat服务器进行处理，这就导致静态请求占用了很大一部分Tomcat的资源，从而导致吞吐量的急剧下降。为了避免这种情况的发生，我们利用nginx进行动静分离，将静态资源从项目的各个模块中分离出去，放在nginx中，并指定哪些访问属于静态资源的请求，此后，当nginx收到动态请求时，才转交给网关进行后续处理，如果收到了静态请求，由nginx直接进行返回，不再需要转交给后台服务。

2.2 实现步骤

2.2.1 移动静态资源

将项目中类路径下的static中的文件全部转移到nginx的html文件夹中自创的static文件夹中。

2.2.2 设置nginx访问规则

在nginx的nginx.conf文件中，添加如下配置，使对nginx的所有以/static/开头的请求，都直接访问nginx文件夹的html/static/中的文件。

2.2.3 修改项目中首页

将首页中所有的超链接前都加上/static/路径。

三、Redis做缓存

1. Redis的整合

1.在gulimall-product模块的pom文件中引入Redis的场景启动器。

org.springframework.bootspring-boot-starter-data-redis

2.在application.yml文件中对Redis进行相关配置。

spring: redis:host: 101.43.199.148port: 6379

3.可以使用springboot自动配置好的StringRedisTemplate来操作Redis。

2. 分布式锁框架Redisson

2.1 Redisson的引入

1.导入依赖

org.redissonredisson3.12.0

2.配置Redisson

@Configuration
public class MyRedissonConfig {/*** 所有对Redisson的使用都是通过RedissonClient对象* @return*/@Beanpublic RedissonClient redisson(){//1.创建配置Config config = new Config();config.useSingleServer().setAddress("redis://101.43.199.148:6379");//2.根据配置创建RedissonClient实例RedissonClient redissonClient = Redisson.create(config);return redissonClient;}
}

2.2 Redisson的使用

2.2.1 可重入锁(Reentrant Lock)

//第一种加锁方式
@ResponseBody
@GetMapping(value = "/hello")
public String hello() {//1、获取一把锁，只要锁的名字一样，就是同一把锁RLock myLock = redisson.getLock("my-lock");//2、加锁//阻塞式等待。默认加的锁都设置了过期时间是30s//① 锁的自动续期，如果业务超长，运行期间自动锁上新的30s。不用担心业务时间长，锁自动过期被删掉。//② 加锁的业务只要运行完成，就不会给当前锁续期，即使不手动解锁，锁默认会在30s内自动过期，不会产生死锁问题。myLock.lock(); try {System.out.println("加锁成功，执行业务..." + Thread.currentThread().getId());try {TimeUnit.SECONDS.sleep(20); } catch (InterruptedException e) {e.printStackTrace(); }} catch (Exception ex) {ex.printStackTrace();} finally {//3、解锁  假设解锁代码没有运行，Redisson会不会出现死锁System.out.println("释放锁..." + Thread.currentThread().getId());myLock.unlock();}return "hello";
}

//第二种加锁方式：实际上，我们就是用这种方式
@ResponseBody
@GetMapping(value = "/hello")
public String hello() {//1、获取一把锁，只要锁的名字一样，就是同一把锁RLock myLock = redisson.getLock("my-lock");//2、加锁//10秒钟自动解锁，在锁时间到了以后，不会自动续期，因此要求自动解锁时间一定要大于业务执行时间。//原理：① 如果我们传递了锁的超时时间，就发送给redis执行脚本，进行占锁，默认超时就是我们制定的时间。//原理：② 如果我们未指定锁的超时时间，就使用看门狗的默认时间（lockWatchdogTimeout = 30 * 1000）作为锁的超//时时间，并且只要占锁成功，就会启动一个定时任务，每隔一段时间（默认为看门狗默认时间的三分之一）用来重新设//置锁的过期时间为看门狗的默认时间。最终实现的效果就是，每隔10s，看门狗就重新将过期时间续为30s。myLock.lock(10,TimeUnit.SECONDS); try {System.out.println("加锁成功，执行业务..." + Thread.currentThread().getId());try {TimeUnit.SECONDS.sleep(20); } catch (InterruptedException e) {e.printStackTrace(); }} catch (Exception ex) {ex.printStackTrace();} finally {//3、解锁 System.out.println("释放锁..." + Thread.currentThread().getId());myLock.unlock();}return "hello";
}

2.2.2 读写锁(ReadWriteLock)

/*** 保证一定能读到最新数据，修改期间，写锁是一个排它锁（互斥锁、独享锁），读锁是一个共享锁* 写锁没释放读锁必须等待* 读 + 读 ：相当于无锁，并发读，只会在Redis中记录好，所有当前的读锁。他们都会同时加锁成功* 写 + 读 ：必须等待写锁释放* 写 + 写 ：阻塞方式* 读 + 写 ：有读锁。写也需要等待* 只要有写的存在都必须等待* @return*/
@GetMapping(value = "/write")
@ResponseBody
public String writeValue() {String s = "";RReadWriteLock readWriteLock = redisson.getReadWriteLock("rw-lock");RLock rLock = readWriteLock.writeLock();try {//改数据加写锁rLock.lock();s = UUID.randomUUID().toString();ValueOperations ops = stringRedisTemplate.opsForValue();ops.set("writeValue",s);TimeUnit.SECONDS.sleep(10);} catch (InterruptedException e) {e.printStackTrace();} finally {rLock.unlock();}return s;
}@GetMapping(value = "/read")
@ResponseBody
public String readValue() {String s = "";RReadWriteLock readWriteLock = redisson.getReadWriteLock("rw-lock");//读数据加读锁RLock rLock = readWriteLock.readLock();try {rLock.lock();ValueOperations ops = stringRedisTemplate.opsForValue();s = ops.get("writeValue");try { TimeUnit.SECONDS.sleep(10);} catch (InterruptedException e) { e.printStackTrace(); }} catch (Exception e) {e.printStackTrace();} finally {rLock.unlock();}return s;
}

2.2.3 信号量(Semaphore)

/*** Redis中存储value的值为3*/
@GetMapping(value = "/acquire")
@ResponseBody
public String acquireTest() throws InterruptedException {RSemaphore semaphore= redisson.getSemaphore("value");semaphore.acquire();//阻塞式的获取一个信号，Redis中的value值减1/*** 非阻塞式的获取信号，获取成功返回true，Redis中的value值减1；获取失败返回false，Redis中的value值不变* 据此方式，可以利用信号量来进行限流* boolean flag = semaphore.tryAcquire();* if (flag) {*     //执行业务* } else {*    return "error";* }*/return "ok==>park";
}@GetMapping(value = "/release")
@ResponseBody
public String releaseTest() {RSemaphore semaphore= redisson.getSemaphore("value");semaphore.release();  //阻塞式的释放一个信号，Redis中的value值加1return "ok==>release";
}

2.2.4 闭锁(CountDownLatch)

 /*** 放假、锁门* 1班没人了* 5个班，全部走完，我们才可以锁大门* 分布式闭锁*/@GetMapping(value = "/lockDoor")
@ResponseBody
public String lockDoor() throws InterruptedException {RCountDownLatch door = redisson.getCountDownLatch("door");door.trySetCount(5);//设置闭锁的值是5door.await();       //等待闭锁完成，即计数值减为0return "放假了...";
}@GetMapping(value = "/gogogo/{id}")
@ResponseBody
public String gogogo(@PathVariable("id") Long id) {RCountDownLatch door = redisson.getCountDownLatch("door");door.countDown(); //闭锁的值计数减1return id + "班的人都走了...";
}

3. 缓存数据一致性问题

由于缓存都是存在Redis中，而数据都是存在MySQL数据库中，所以不可避免的会出现缓存一致性问题，也就是说，在数据库数据更新之后，缓存不会得到及时的更新更新，导致两者的数据不一致，此时如果用户从缓存中读取数据，读取到的实际上是脏数据。

3.1 双写模式

双写模式就是在更新数据库时写缓存，将缓存中的数据也进行更新。双写模式依然存在脏数据的问题，但由于设置了过期时间，总能保证数据的最终一致性。

3.2 失效模式

失效模式就是在更新数据库时删缓存，等待下次用户查询数据时，再将新数据更新到缓存中。失效模式依然存在脏数据的问题，但由于设置了过期时间，总能保证数据的最终一致性。

3.3 总结

无论是双写模式还是失效模式，都会导致缓存的不一致问题，即多个实例同时更新会出现问题，为此，可以有以下几个解决方案：
1.如果是用户维度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，正常缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。
2.如果是菜单、商品介绍等基础数据，一般允许长时间的数据不一致问题，只需要正常缓存数据加上过期时间，每隔一段时间触发读的主动更新即可（但是，也可以去使用canal订阅binlog的方彻底解决此问题）。
3.缓存数据+过期时间足够解决大部分业务其他对于缓存的要求。
4.某些一致性要求高的场景，可以通过对整个操作（更新数据库+更新缓存或更新数据库+删除缓存）加读写锁来保证并发读写，写写的时候按顺序排好队，读读无需处理。

3.4 高效解决：Canal

Canal是阿里的开源中间件，它的工作原理是伪装成了数据库的从库，来对缓存进行同步更新。比如当数据库为MySQL时，它就伪装成MySQL的从库，随后通过读取数据库的binlog日志，来判定数据是否改变，如果改变则同步更新缓存，保证数据的一致性。

4. SpringCache简化缓存开发

4.1 SpringCache的引入

1.引入SpringCache的场景启动器。

org.springframework.bootspring-boot-starter-cache

2.进行配置。
在application.properties中配置缓存类型。

spring.cache.type=redis

其余的springboot会自动帮我们进行配置，比如CacheAutoConfiguration会根据我们配置文件中设置的缓存类型自动导入RedisCacaheConfiguration，自动配置好缓存管理器RedisCacheManager等。
3.注意：如果Redis没有提前配置，则还需配置Redis。

4.2 SpringCache的使用

4.2.1 前提

在主类上加注解@EnableCaching开启缓存功能。

4.2.2 @Cacheable注解

1.基本使用
@Cacheable注解标注在方法上，表明当前方法的结果需要缓存，如果缓存中有，则方法不调用，如果缓存中没有，则调用方法。可以通过设置其value属性，属性值为数组，来指明缓存的数据要放到那个名字的缓存中。
2. 默认行为
① 如果缓存有，方法不被调用。
② key自动生成，默认为缓存名字::SimpleKey[]（自动生成的key值）。
③ 缓存的value值默认使用jdk序列化机制将序列化后的数据保存在Redis中。
④ 默认ttl为-1，即永久有效。
3. 自定义简单配置
① 指定生成缓存使用的key：通过该注解的key属性指定，该属性接收一个SPEL表达式。此时，key会被调整为缓存名字::自定义部分。
② 指定缓存数据的存活时间：在配置文件中指定ttl==>spring.cache.redis.time-to-live=360000，单位为ms。
4. 自定义复杂配置
4.1 原理分析
① CacheAutoConfiguraion自动配置了RedisCacheConfiguration。
② RedisCacheConfiguration自动配置了RedisCacheManager。
③ RedisCacheManager会调用determineConfiguration方法，该方法中会决定每个缓存用什么样的配置。在该方法中，会判断容器中是否有用户自定义的RedisCacheConfiguration，如果有就用用户自定义的，否则，就用默认的配置类（默认的配置类中指定了一部分规则）并在determineConfiguration方法中将默认配置类绑定配置文件中的设置。
④ 因此，想修改缓存的配置，只需要自定义RedisCacheConfiguration并注册到容器中即可，注意，此时也要将自定义的配置类中的配置与配置文件中的配置认为绑定，否则配置文件中的配置会失效。
4.2 开始配置

//由于CacheAutoConfiguration已经添加了注解@EnableConfigurationProperties(CacheProperties.class)
//所以在此无需添加该注解，容器中就有CacheProperties配置类
@EnableCaching
@Configuration
public class MyCacheConfig {//    @Autowired
//    private CacheProperties cacheProperties;@Beanpublic RedisCacheConfiguration redisCacheConfiguration(CacheProperties cacheProperties){RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig();//认为指定将数据转换为json格式存在缓存中config = config.serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()));config = config.serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));//必须在此添加如下配置，才能将配置文件中的所有配置都生效，否则所有配置文件中的配置都会失效CacheProperties.Redis redisProperties = cacheProperties.getRedis();if (redisProperties.getTimeToLive() != null) {config = config.entryTtl(redisProperties.getTimeToLive());}if (redisProperties.getKeyPrefix() != null) {config = config.prefixCacheNameWith(redisProperties.getKeyPrefix());}if (!redisProperties.isCacheNullValues()) {config = config.disableCachingNullValues();}if (!redisProperties.isUseKeyPrefix()) {config = config.disableKeyPrefix();}return config;}
}

5. 其他配置

# 指定Redis中key的前缀，如果没有就默认用缓存名字::作为前缀
spring.cache.redis.key-prefix=CACHE_
# 指定Redis中key的命名是否使用前缀，默认为true（使用）
spring.cache.redis.use-key-prefix=true
# 指定Redis中是否可以缓存控制，默认为true（可以），可以防止缓存穿透
spring.cache.redis.cache-null-values=true

4.2.3 @CachEvict注解

1. 基本使用
失效模式，标注在更新方法上，value属性指定要删除的缓存的片区，key属性指定要删除的缓存的key，在当进行更新时，会将缓存中的指定value片区的键为key的缓存清除。还可以设置allEntries为true表明更新时，删除指定的value片区的所有缓存内容。

4.2.4 @CachePut注解

1. 基本使用
双写模式，如果修改方法返回的数据正好是修改后最新的数据对象，则可以标注此注解，表明此次修改的结果更新到缓存中。注意，该注解标注的方法必须有返回值。

4.2.5 @Caching注解

1. 基本使用
通过对该注解的属性的设置，可以组合多个SpringCache的注解。比如

@Caching(evict = {@CacheEvict(value = {"category"}, key = "'getLevel1Categorys'"),@CacheEvict(value = {"category"}, key = "'getCatalogJson'")})

4.3 SpringCache总结

4.3.1 读模式

使用缓存的读模式中，一共存在三个问题：缓存穿透、缓存击穿、缓存雪崩。
① 缓存穿透：查询一个数据库不存在的数据，SpringCache采用cache-null-value=true解决。
② 缓存击穿：大量并发进来同时查询一个正好过期的数据，SpringCache可以通过设置@Cachable注解的属性sync=true解决（注意，加此注解时，读取数据的方法会加上本地锁，虽然不如分布式锁完美，但是也可以解决这个问题）。
③ 缓存雪崩：大量key同时过期，SpringCache为每一个key加上过期时间就可以解决了（由于每个key存入缓存的时间不同，所以加上过期时间就可以保证数据失效的时间离散形式，也没必要加随机时间，容易弄巧成拙）。

4.3.2 写模式

写模式中，SpringCache可以通过@CachEvict和@CachePut注解来片面地解决缓存一致性问题，之所以说片面，是因为仍然只能保证数据的最终一致性，如果需要更高标准的一致性，则还需要采用其他手段，比如加入读写锁、引入Canal、或者在读多写多的情况下直接去数据库查询。

4.3.3 总结

常规数据一般读多写少，即时性和一致性要求不高，因此完全可以使用SpringCache。
特殊数据要进行特殊设计。

5. 缓存小总结

1.自己使用StringRedisTemplate引入了缓存。
2.自己使用StringRedisTemplate实现了本地锁和分布式锁解决读模式的缓存击穿问题。
3.自己使用Redisson实现了分布式锁解决读模式的缓存击穿问题。
4.利用SpringCache的注解来使用缓存，并解决读模式下的缓存击穿问题。
5.利用SpringCache的注解来初步解决写模式下的缓存一致性问题（最终一致性）。
6.从头到尾，没有真正的利用读写锁完全解决缓存一致性问题。

四、注册登录

1. 验证码

2. 社交登录

2.1 OAuth基本概念

• OAuth：OAuth（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容。
• OAuth2.0：对于用户相关的OpenAPI（例如获取用户信息，动态同步，照片，日志，分享等），为了保护用户数据的安全和隐私，第三方网站访问用户数据前都需要显式的向用户征求授权。

2.2 OAuth2.0的社交登录流程

1.当重新获取了新的Code以后，原来的Code会失效。
2.同一个用户的AccessToken一段时间内是不会变化的，过期时间内多次获取则会获取相同的值。

2.3 微博社交登录

2.3.1 微博授权机制说明

https://open.weibo.com/wiki/%E6%8E%88%E6%9D%83%E6%9C%BA%E5%88%B6

2.3.2 微博登录流程解析

3. 分布式Session

3.1 Session的工作原理

3.2 Session缺陷及解决

3.2.1 同一微服务Session共享问题

3.2.1.1 问题描述

当果我们对于同一个服务进行集群搭建后，多个服务器会共同组成一个服务模块，由于Session是存在于每一个服务器的内存中，这会导致用户保存在单个服务器的信息无法共享到同样从属于该服务模块的其他服务器上。

3.2.1.2 解决方案

• 方案一：session复制
  

• 方案二：客户端存储
  

• 方案三：Hash一致性
  

• 方案四：统一存储（采用）
  

3.2.2 不同同微服务Session共享

3.2.2.1 问题描述

在分布式情况下，一个完整的服务系统是由多个不同的微服务模块组成的，不同的微服务模块父域名相同但子域名是不同的，由于Session是依赖于Cookie实现的，而Cookie是针对域名进行存储（即，只有域名相同才可以共享同一个Cookie），这就导致不同的微服务之间不能共享用户保存的信息。

3.2.2.2 解决方案（采用）

人为设置Cookie信息，扩大Session所依赖的Cookie的作用范围。

3.3 整合SpringSession解决问题

3.3.1 同一微服务Session共享问题

1.在需要Session存储的微服务的pom文件中引入依赖

org.springframework.sessionspring-session-data-redis

2.在配置文件中配置Session所用数据库类型和数据库设置以及一些其他配置（本次使用redis）

# 配置redis
spring.redis.host=自己的服务器
spring.redis.port=6379
# 配置session
spring.session.store-type=redis
# session的其他相关配置
spring.session.timeout=30m

3.在主类上标注注解@EnableRedisHttpSession（以整合redis作为Session存储为例）
4.注意：如果不配置使用默认的JDK序列化机制，则需要实现序列化接口Serializable

3.3.2 不同同微服务Session共享

通过自定义CookieSerializer来人为设置Cookie的作用域

@Configuration
public class GilimallSessionConfig {@Beanpublic CookieSerializer cookieSerializer(){DefaultCookieSerializer cookieSerializer = new DefaultCookieSerializer();cookieSerializer.setDomainName("gulimall.com");cookieSerializer.setCookieName("GULISESSION");return cookieSerializer;}
}

3.3.3 附加：采用JSON序列化机制

通过设置RedisSerializer来人为指定序列化机制

@Configuration
public class GilimallSessionConfig {@Beanpublic CookieSerializer cookieSerializer(){DefaultCookieSerializer cookieSerializer = new DefaultCookieSerializer();cookieSerializer.setDomainName("gulimall.com");cookieSerializer.setCookieName("GULISESSION");return cookieSerializer;}@Beanpublic RedisSerializer