微服务知识点

1.Vant

什么是Vant

Vant是一个轻量，可靠的移动端组件库，2017开源

目前 Vant 官方提供了 Vue 2 版本、Vue 3 版本和微信小程序版本，并由社区团队维护 React 版本和支付宝小程序版本。

课程中使用Vant 2.x版本可以浏览网站

https://youzan.github.io/vant/v2/#/zh-CN/

Vant的优势

ElementUI是开发电脑浏览器页面的组件库

而Vant是开发移动端显示页面的组件库

酷鲨商城前台设计的是手机来访问，所以使用移动端更合适也就是使用Vant

Vant特性

• 🚀 性能极佳，组件平均体积小于 1KB（min+gzip）

• 🚀 65+ 个高质量组件，覆盖移动端主流场景

• 💪 使用 TypeScript 编写，提供完整的类型定义

• 💪 单元测试覆盖率超过 90%，提供稳定性保障

• 📖 提供完善的中英文文档和组件示例

• …

2.微服务概述

什么是微服务

微服务的概念是由Martin Fowler（马丁·福勒）在2014年提出的

微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理能力，服务可以用不同的编程语言与数据库等组件实现。

简单来说,微服务就是将一个大型项目的各个业务代码,拆分成多个互不干扰的小项目,而这些小项目专心完成自己的功能,而且可以调用别的小项目的方法,从而完成整体功能

京东\淘宝这样的大型互联网应用程序,基本每个操作都是一个单独的微服务在支持:

• 登录服务器
• 搜索服务器
• 商品信息服务器
• 购物车服务器
• 订单服务器
• 支付服务器
• 物流服务器
• …

怎么搭建微服务项目

在微服务概念提出之前(2014年),每个厂商都有自己的解决方案

但是Martin Fowler（马丁·福勒）提出了微服务的标准之后,为了技术统一和兼容性,很多企业开始支持这个标准

现在业界中开发微服务项目,大多数都是在这个标准下的

如果我们自己编写支持这个标准的代码是不现实的,必须通过现成的框架或组件完成满足这个微服务标准的项目结构和格式

当今程序员要想快速完成微服务标准的程序,首选SpringCloud

3.Spring Cloud

什么是Spring Cloud

SpringCloud是由Spring提供的一套能够快速搭建微服务架构程序的框架集

框架集表示SpringCloud不是一个框架,而是很多框架的统称

SpringCloud是为了搭建微服务架构的程序而出现的

有人将SpringCloud称之为"Spring全家桶",广义上指代所有Spring的产品

SpringCloud的内容

从内容提供者角度

• Spring自己编写的框架和软件
• Netflix(奈非):早期提供了很多(全套)微服务架构组件
• alibaba(阿里巴巴):新版本SpringCloud推荐使用(正在迅速占领市场)

课程中大量使用alibaba的微服务组件

从功能上分类

• 微服务的注册中心
• 微服务间的调用
• 微服务的分布式事务
• 微服务的限流
• 微服务的网关
• …

4.Nacos注册中心

什么Nacos

Nacos是Spring Cloud Alibaba提供的一个软件

这个软件主要具有注册中心和配置中心的功能

我们先学习它注册中心的功能

微服务中所有项目都必须注册到注册中心才能成为微服务的一部分

注册中心和企业中的人力资源管理部门有相似

Nacos心跳机制

常见面试题

Nacos内部注册的服务分为两大类

1.临时实例(默认)

2.持久化实例(永久实例)

我们可以通过设置属性来确定它是临时还是永久

cloud:
  nacos:
    discovery:
      # ephemeral设置当前项目启动时注册到nacos的类型 true(默认):临时实例 false:永久实例
      ephemeral: true 

临时实例和永久实例的区别

临时实例

默认情况下,启动服务后,每隔5秒会向nacos发送一个"心跳包",这个心跳包中包含了当前服务的基本信息

Nacos收到这个"心跳包"如果发现这个服务的信息不在注册列表中,就进行注册,如果这个服务的信息在注册列表中就表明这个服务还是健康的

如果Nacos15秒内没接收到某个服务的心跳包,Nacos会将这个服务标记为不健康的状态

如果30秒内没有接收到这个服务的心跳包,Nacos会将这个服务从注册列表中剔除

这些时间都是可以通过配置修改的

持久化实例(永久实例)

持久化实例启动时向nacos注册,nacos会对这个实例进行持久化处理

心跳包的规则和临时实例一致,只是不会将该服务从列表中剔除

各类型使用时机

一般情况下,我们创建的服务都是临时实例

只有项目的主干业务才会设置为永久实例

5.Dubbo概述

什么是RPC

RPC是Remote Procedure Call的缩写 翻译为:远程过程调用

目标是为了实现两台(多台)计算机\服务器,互相调用方法\通信的解决方案

RPC的概念主要定义了两部分内容

1.序列化协议

2.通信协议

通信协议

通信协议指的就是远程调用的通信方式

序列化协议

序列化协议指通信内容的格式,双方都要理解这个格式

什么是Dubbo

理解了RPC再学习Dubbo就会简单一些了

Dubbo是一套RPC框架。既然是框架，我们可以在框架结构高度，定义Dubbo中使用的通信协议，使用的序列化框架技术，而数据格式由Dubbo定义，我们负责配置之后直接通过客户端调用服务端代码。

简单来说,Dubbo就是RPC概念的实现

Dubbo是Spring Cloud Alibaba提供的一个框架

能够实现微服务项目的互相调用

Dubbo的发展历程

2012年底dubbo停止更新后到2017年dubbo继续更新之前

2015SpringCloud开始兴起,当时没有阿里的框架

国内公司要从SpringCloud和Dubbo中抉择使用哪个微服务方案

在2012年dubbo停止更新后国内的当当网在dubbo的基础上开发了dubboX框架,并进行维护

2019年后,SpringCloud和Dubbo才能共同使用

Dubbo的协议支持

RPC框架分通信协议和序列化协议

Dubbo框架支持多种通信协议和序列化协议,可以通过配置文件进行修改

支持的通信协议有

• dubbo协议(默认)
• rmi协议
• hessian协议
• http协议
• webservice
• …

支持的序列化协议

• hessian2(默认)
• java序列化
• compactedjava
• nativejava
• fastjson
• dubbo
• fst
• kryo

Dubbo默认情况下,协议的特征如下

• 采用NIO单一长连接
• 优秀的并发性能,但是大型文件的处理差
• Dubbo开发简单,有助于提升开发效率

Dubbo服务的注册与发现

在Dubbo的调用过程中,必须包含注册中心的支持

注册中心推荐使用Nacos,但是如果使用其他软件也能实现例如(Redis,zookeeper等)

服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP 地址的情况下实现通信。

上面的示例中,服务器的发现者,它能够获取所有功能列表

一旦调用服务就完成了Dubbo的调用

consumer服务的消费者,指服务的调用者(使用者)

provider服务的提供者,指服务的拥有者(生产者)

在Dubbo中,远程调用依据是服务的提供者在Nacos中注册的服务名称

一个服务名称,可能有多个运行的实例,任何一个空闲的实例都可以提供服务

常见面试题:Dubbo的注册发现流程

1.首先服务的提供者启动服务到注册中心注册,包括各种ip端口信息,Dubbo会同时注册该项目提供的远程调用的方法

2.服务的消费者(使用者)注册到注册中心,订阅发现

3.当有新的远程调用方法注册到注册中心时,注册中心会通知服务的消费者有哪些新的方法,如何调用的信息

4.RPC调用,在上面条件满足的情况下,服务的调用者无需知道ip和端口号,只需要服务名称就可以调用到服务提供者的方法

负载均衡

什么是负载均衡

在实际开发中,一个服务基本都是集群模式的,也就是多个功能相同的项目在运行,这样才能承受更高的并发

这时一个请求到这个服务,就需要确定访问哪一个服务器

Dubbo框架内部支持负载均衡算法,能够尽可能的让请求在相对空闲的服务器上运行

我们要实现设置好负载均衡的策略算法,并设置好每个服务器的运行权重

才能更好的实现负载均衡的效果

Loadbalance:就是负载均衡的意思

Dubbo内置负载均衡策略算法

Dubbo内置4种负载均衡算法

• random loadbalance:随机分配策略(默认)
• round Robin Loadbalance:权重平均分配
• leastactive Loadbalance:活跃度自动感知分配
• consistanthash Loadbalance:一致性hash算法分配

dubbo内置负载均衡策略算法

Dubbo内置4种负载均衡算法

• random loadbalance:随机分配策略(默认)
• round Robin Loadbalance:权重平均分配
• leastactive Loadbalance:活跃度自动感知分配
• consistanthash Loadbalance:一致性hash算法分配

实际运行过程中,每个服务器性能不同

在负载均衡时,都会有性能权重,这些策略算法都考虑权重问题

随机分配策略(默认)

随机生成随机数

在哪个范围内让哪个服务器运行

优点:

算法简单,效率高,长时间运行下,任务分配比例准确

缺点:

偶然性高,如果连续的几个随机请求发送到性能弱的服务器,会导致异常甚至宕机

权重平均分配

如果几个服务器权重一致,那么就是依次运行

3个服务器 1>1 2>2 3>3 4>1

但是服务器的性能权重一致的可能性很小

所以我们需要权重评价分配

Dubbo2.6.4之前平均分配权重算法是有问题的

如果3个服务器的权重比5:3:1

1>1 2>1 3>1 4>1 5>1 6>2 7>2 8>2 9>3

10>1

Dubbo2.7之后更新了这个算法使用"平滑加权算法"优化权重平均分配策略

活跃度自动感知

记录每个服务器处理一次请求的时间

安装时间比例来分配任务数,运行一次需要时间多的分配的请求数较少

一致性Hash算法

根据请求的参数进行hash运算

以后每次相同参数的请求都会访问固定服务器

因为根据参数选择服务器,不能平均分配到每台服务器上

使用的也不多

6.Seata概述

什么是Seata

Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务

也是Spring Cloud Alibaba提供的组件

Seata官方文档

https://seata.io/zh-cn/

更多信息可以通过官方文档获取

为什么需要Seata

我们首先简单复习一下事务的概念

事务的4个特性:ACID特性

• 原子性
• 一致性
• 隔离性
• 永久性

我们再业务中,必须保证数据库操作的原子性,也就是当前业务的所有数据库操作要么都成功,要么都失败

之前我们使用Spring声明式事务来解决本地的事务问题

但是现在是微服务环境,一个业务可能涉及多个模块的数据库操作

这种情况就需要专门的微服务状态下解决事务问题的"分布式事务"解决方案

我们学习的Seata就是这样的产品

Seata将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案。

Seata的运行原理(AT模式)

观察下面事务模型

上面结构是比较典型的远程调用结构

如果account操作数据库失败需要让order模块和storage模块撤销(回滚)操作

声明式事务不能完成这个操作

需要Seata来解决

解决模型如下

Seata构成部分包含

• 事务协调器TC
• 事务管理器TM
• 资源管理器RM

我们项目使用AT(自动)模式完成分布式事务的解决

AT模式运行过程

1.事务的发起方™会向事务协调器(TC)申请一个全局事务id,并保存

2.Seata会管理事务中所有相关的参与方的数据源,将数据操作之前和之后的镜像都保存在undo_log表中,这个表是seata框架规定的,方便提交(commit)或回滚(roll back)

3.事务的发起方™会连同全局id一起通过远程调用运行资源管理器(RM)中的方法

4.资源管理器(RM)接收到全局id,并运行指定的方法,将运行的状态同步到事务协调器(TC)

5.如果运行整体没有发生异常,发起方™会通过事务协调器通知所有分支,将本次事务所有对数据库的影响真正生效,反之如果任何一个RM运行发生异常,那么都会通知事务协调器,再由事务协调器通知所有分支,回滚数据中的数据

回滚时可以使用undo_log表中的数据来实现回滚

其他模式简介

AT模式运行有一个非常明显的条件

就是事务分支都必须是操作关系型数据库(mysql\MariaDB\Oracle)

但是如果一个事务中有操作例如Redis这样的非关系型数据库时就不能使用AT模式了

除了AT模式之外还有TCC、SAGA 和 XA 事务模式

TCC模式

这个模式简单来说就是自己编写代码进行事务的提交和回滚

我们需要在各个分支业务逻辑层代码中编写一组三个方法(prepare\commit\rollback)

prepare:准备 commit:提交 rollback:回滚

prepare方法是无论事务成功与否都会运行的代码

commit当整体事务运行成功时运行的方法

rollback当整体事务运行失败是运行的方法

优点:虽然代码是自己写的,但是事务整体提交或回滚的机制仍然可用

缺点:每个业务都要编写3个方法来对应,代码冗余,而且业务入侵量大

SAGA模式

SAGA模式的思想是编写一个类,当指定的事务发生问题时,运行SAGA编写的回滚类

这样编写代码不影响已经编写好的业务逻辑代码

一般用于修改已经编写完成的老代码

缺点是每个事务分支都要编写一个类来回滚业务,

类数量多,开发量大

XA模式

支持XA协议的数据库分布式事务,使用比较少

7.Sentinel 介绍

什么是Sentinel

Sentinel也是Spring Cloud Alibaba的组件

Sentinel英文翻译"哨兵\门卫"

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

官网地址

https://sentinelguard.io/zh-cn/

为什么需要Sentinel

• 丰富的应用场景

  双11,秒杀,12306抢火车票

• 完备的实时状态监控

  可以支持显示当前项目各个服务的运行和压力状态,分析出每台服务器处理的秒级别的数据

• 广泛的开源生态

  很多技术可以和Sentinel进行整合,SpringCloud,Dubbo,而且依赖少配置简单

• 完善的SPI扩展

  Sentinel支持程序设置各种自定义的规则

8.SpringGateway 网关

奈非框架简介

早期(2020年前)奈非提供的微服务组件和框架受到了很多开发者的欢迎

这些框架和Spring Cloud Alibaba的对应关系我们要知道

Nacos对应Eureka 都是注册中心

Dubbo对应ribbon+feign都是实现微服务间调用

Sentinel对应Hystrix都是项目限流熔断降级组件

Gateway对应zuul都是项目的网关

Gateway不是阿里巴巴的而是Spring提供的

什么是网关

"网关"网是网络,关是关口\关卡

关口\关卡的意思就是"统一入口"

网关:就是网络中的统一入口

程序中的网关就是微服务项目提供的外界所有请求统一访问的微服务项目

因为提供了统一入口之后,方便对所有请求进行统一的检查和管理

网关的主要功能有

• 将所有请求统一由经过网关
• 网关可以对这些请求进行检查
• 网关方便记录所有请求的日志
• 网关可以统一将所有请求路由到正确的模块\服务上

路由的近义词就是"分配"

Spring Gateway简介

我们使用Spring Gateway作为当前项目的网关框架

Spring Gateway是Spring自己编写的,也是SpringCloud中的组件

SpringGateway官网

https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/

9.Elasticsearch概述

什么是Elasticsearch

elastic:富有弹性的

search:搜索

在计算机开发界简称ES

这个软件不是SpringCloud的组件,甚至其他语言都可以使用它

是一个java开发的软件,所以启动需要java环境变量

功能是从大量数据中根据指定的关键字搜索出匹配的结果

这样的软件有一个名称全文搜索引擎

使用它的方式是访问它提供的控制器方法,它开发了多种控制器方法

访问不同方法实现对数据的增删改查

ES也是将数据保存在硬盘上的

常见面试题ES的实现结构

java有一套名为Lucene的API

是搜索引擎的核心支持,Elasticsearch在Lucene的基础上开发出了一个功能全面的开箱即用的全文搜索引擎

市面上ES的竞品有

Solr/MongoDB

为什么使用Elasticsearch

因为我们之前学习的所有关系型数据库都有一个严重的性能缺陷

mysql\mariaDB\oracle\DB2等

就是前模糊的模糊查询不能使用索引

select * from spu where spu_name like '%鼠标%'

测试证明一张千万级别的数据库表进行模糊查询需要20秒以上

当今需求"三高"的需求下,不能接受这样的性能

我们使用ES来优化后同样的查询我们能将效率提高100倍

将大型的查询也能控制在毫秒级别

Elasticsearch查询原理

如果不使用ES让数据库查询,没有索引加持的模糊查询就是全表搜索性能差

但是Elasticsearch可以利用添加数据库完成对数据的分词倒排索引形成索引库

在查询时直接查询索引库,获得符合查询条件的数据信息

关于数据库的索引

所谓索引其实就是数据库中数据的目录

目的是能够提高查询的效率

数据库索引分类

• 聚集索引
• 非聚集索引

聚集索引就是数据库保存数据的物理顺序,一般都是id,所以按物理顺序查询也就是按id查询效率非常高

如果再定义其他索引,就是非聚集索引了

如果数据表中有一个姓名列,我们为姓名列创建索引

例如有"张三"这个姓名,添加索引后,查询的话效率会明显提升

但是如果不创建索引,去查询张三,就只能逐行检索姓名列是否为张三,查询效率低

常见面试题:索引的使用规则和注意事项

1. 索引会占用数据库空间
2. 对数据进行增删改操作,可能会引起索引的更新,效率会低
3. 操作数据库时先添加数据,再创建索引
4. 不要对数据样本少的列添加索引
5. 每次查询从数据库中查询结果越多,索引的效果越低
6. 使用where字句查询时,将具有索引的列放在第一个条件

经过我们对索引的简单了解,我们需要知道索引的基本概念和使用

所有关系型数据库都有一个缺陷,就是模糊查询时(查询条件前模糊),是不能利用索引进行查询的

一定会引起全表搜索,查询效率非常低

ik分词插件的使用

我们安装的ik实际上不只一个分词器

实际上除了ik_smart之外还有ik_max_word

总体来说区别如下

ik_smart

• 优点:特征是粗略快速的将文字进行分词,占用空间小,查询速度快
• 缺点:分词的颗粒度大,可能跳过一些分词,导致查询结果不全面

ik_max_word

• 优点:特征是详细的文字片段进行分词,查询时查全率高,不容易遗漏数据
• 缺点:因为分词太过详细,导致有一些无用分词,占用空间较大,查询速度慢

10.Spring Security

Spring Security框架用于实现登录

同时还可以将当前登录用户的权限信息保存

我们需要花费一些精力将Spring Security的登录过程要记忆,应对面试提问

我们在项目中要验证当前用户是否具备某个权限时

可以再控制器方法代码前添加@PreAuthorize(“[权限名称]”)SpringSecurity在运行该方法之前进行核查

如果不具备这个权限会返回403状态码

关于单点登录

微服务的会话保持问题

我们在微服务的架构下,完成登录,和单机模式的登录是有很大区别的

首先我们分析一下普通登录和微服务登录的区别

上面的图片,表示我们在微服务系统中登录时遇到的问题

我们在用户模块中登录,只是将用户信息保存在用户模块的session中

而这个session不会和其他模块共享

所以在我们访问订单模块或其他模块时,通过sessionid并不能获得在用户模块中登录成功的信息

这样就丢失的用户信息,不能完成业务

市面上现在大多使用JWT来实现微服务架构下的会话保持

也就是在一个服务器上登录成功后,微服务的其他模块也能识别用户的登录信息

这个技术就是单点登录

单点登录解决方案

Session共享

这种方式的核心思想是将用户的登录信息共享给其他模块

适用于小型的,用户量不大的微服务项目

将登录成功的用户信息共享给Redis

其他模块根据sessionId获得Redis中保存的用户信息即可

• 这样做最大的缺点就是内存严重冗余,不适合大量用户的微服务项目

JWT令牌

这种登录方式,最大的优点就是不占用内存

生成的JWT由客户端自己保存,不占用服务器内存

在需要表明自己用户身份\信息时,将JWT信息保存到请求头中发送请求即可

Jwt登录流程图

SpringSecurity验证规则

SpringSecurity框架登录后,一定会有一个权限列表

在userDetails对象中

我们登录用户的这个对象的值可能是

{“authorities”:[“ROLE_user”],“id”:1,“userType”:“USER”,“username”:“jackson”}

sso模块前台用户登录时,会authorities属性中添加ROLE_user权限

而后台管理用户登录时会向authorities属性中添加下面属性

[“/pms/product/read”,“/pms/product/update”,“/pms/product/delete”]

所以想要在控制器运行前判断权限时就可以使用下面的写法

@PreAuthorize(“hasAuthority(‘ROLE_user’)”)

hasRole判断是专用于判断当前用户角色的指令

hasRole会自动在我们判断的内容前添加ROLE_

@PreAuthorize(“hasRole(‘ROLE_user’)”)

13.Quartz

什么是Quartz

quartz:石英钟的意思

是一个当今市面上流行的高效的任务调用管理工具

由OpenSymphony开源组织开发

Symphony:交响乐

是java编写的,我们使用费时需要导入依赖即可

为什么需要Quartz

什么是任务调度

所谓任务调用,就是执行某些具体动作的时间计划

我们使用过的最简单的调度方法就是Timer

但是Timer的调度功能过于单一,只能是指定时间的延时调用和周期运行

而Quartz可以更详细的指定时间,进行计划调用

Quartz核心组件

调度器:Scheduler

任务:Job

触发器:Trigger

调度器来配置\计划什么时间触发什么任务

简单来说就是调度器规定什么时间做什么事情

• job(工作\任务):Quartz 实现过程中是一个接口,接口中有一个方法execute(执行的意思)

我们创建一个类,实现这个接口,在方法中编写要进行的操作(执行具体任务)

我们还需要一个JobDetail的类型的对象,Quartz每次执行job时

会实例化job类型对象,去调用这个方法,JobDetail是用来描述Job实现类

的静态信息, 比如任务运行时在Quartz中的名称

• Trigger(触发器):能够描述触发指定job的规则,分为简单触发和复杂触发

  简单触发可以使用SimplTrigger实现类.功能类似timer

  复杂触发可以使用CronTrigger实现类,内部利用cron表达式描述各种复杂的时间调度计划

• Scheduler(调度器):一个可以规定哪个触发器绑定哪个job的容器

  在调度器中保存全部的Quartz 保存的任务

  SpringBoot框架下,添加Quartz依赖后,调度器由SpringBoot管理,我们不需要编写

Cron表达式

• * 表示任何值,如果在分的字段上编写*,表示每分钟都会触发

• , 是个分割符如果秒字段我想20秒和40秒时触发两次就写 20,40

• - 表示一个区间 秒字段5-10 表示 5,6,7,8,9,10

• / 表示递增触发 秒字段 5/10表示5秒开始每隔10秒触发一次

  日字段编写1/3表示从每月1日起每隔3天触发一次

• ? 表示不确定值, 因为我们在定日期时,一般确定日期就不确定是周几,相反确定周几时就不确定日期

• L 表示last最后的意思,我们可以设置当月的最后一天,就会在日字段用L表示,

  周字段使用L表示最后一周,一般会和1-7的数字组合

  例如6L表示本月最后一周的周五

• W 表示最近的工作日(单纯的周一到周五) 如果日字段编写15W表示

  每月15日最近的工作日触发,如果15日是周六就14日触发,如果15日是周日就16日触发

LW通常一起使用,表示本月的最后一个工作日

• # 表示第几个,只能使用在周字段上 6#3表示每月的第三个周五

  如果#后面数字写大了,是一个不存在的日期,那就不运行了

  适合设计在母亲节或父亲节这样的日期运行

双11的触发

如果是11月11日0时触发

“0 0 0 11 11 ?”

每个月10日最近的工作日早上9点发工资

0 0 9 10W * ?

网络上可用的Cron表达式生成器很多

推荐一个http://cron.ciding.cc/

0 0 0 5/3 * ?

14.Redis 强化

缓存淘汰策略

Redis服务器繁忙时,有大量信息要保存

如果Redis服务器内存全满,再要往Redis中保存新的数据,就需要淘汰老数据,才能保存新数据

noeviction：返回错误**(默认)**

allkeys-random：所有数据中随机删除数据

volatile-random：有过期时间的数据库中随机删除数据

volatile-ttl：删除剩余有效时间最少的数据

allkeys-lru：所有数据中删除上次使用时间最久的数据

volatile-lru：有过期时间的数据中删除上次使用时间最久的数据

allkeys-lfu：所有数据中删除使用频率最少的

volatile-lfu：有过期时间的数据中删除使用频率最少的

缓存穿透

正常业务下,从数据库查询出的数据可以保存在Redis中

下次查询时直接从Redis中获得,大幅提高响应速度,提高系统性能

所谓缓存穿透,就是查询了一个数据库中都不存在的数据

我们Redis中没有这个数据,它到数据库查,也没有

如果这样的请求多了,那么数据库压力就会很大

前面阶段我们使用向Redis中保存null值,来防止一个查询反复穿透

但是这样的策略有问题

如果用户不断更换查询关键字,反复穿透,也是对数据库性能极大的威胁

使用布隆过滤器来解决这个问题

事先创建好布隆过滤器,它可以在进入业务逻辑层时判断用户查询的信息数据库中是否存在,如果不存在于数据库中,直接终止查询返回

缓存击穿

正常运行的情况,我们设计的应该在Redis中保存的数据,如果有请求访问到Redis而Redis没有这个数据

导致请求从数据库中查询这种现象就是缓存击穿

但是这个情况也不是异常情况,因为我们大多数数据都需要设置过期时间,而过期时间到时这些数据一定会从数据库中同步

击穿只是这个现象的名称,并不是不允许的

缓存雪崩

上面讲到击穿现象

同一时间发生少量击穿是正常的

但是如果出现同一时间大量击穿现象就会如下图

这种情况下,Mysql会短时间出现很多新的查询请求,这样就会发生性能问题

如何避免这样的问题?

因为出现这个问题的原因通常是同时加载的数据设置了相同的有效期

我们需要在设置有效期时添加一个随机数,大量数据就不会同时失效了,

Redis持久化

Redis将信息保存在内存

内存的特征就是一旦断电,所有信息都丢失,Redis来讲,所有数据丢失,就需要从数据库从新查询所有数据,这个是慢的

更有可能,Redis本身是有新数据的,还没有和数据库同步就断电了

所以Redis支持了持久化方案,在当前服务器将Redis中的数据保存在当地硬盘上

Redis恢复策略有两种

RDB:(Redis Database Backup)

数据库快照,(将当前数据库转换为二进制的数据保存在硬盘上),Redis生成一个dump.rdb的文件

我们可以在Redis安装程序的配置文件中进行配置

空白位置编写如下内容

save 60 5

60表示秒数,既1分钟

5表示key被修改的次数

配置效果:1分钟内如果有5个key以上被修改,就启动rdb数据库快照程序

优点:

因为是整体Redis数据的二进制格式,数据恢复是整体恢复的

缺点:

生成的rdb文件是一个硬盘上的文件,读写效率是较低的

如果突然断电,只能恢复最后一次生成的rdb中的数据

AOF(Append Only File):

AOF策略是将Redis运行过的所有命令(日志)备份下来

这样即使信息丢失,我们也可能根据运行过的日志,恢复为断电前的样子

它的配置如下

appendonly yes

特点:只保存命令不保存数据

理论上Redis运行过的命令都可以保存下来

但是实际情况下,Redis非常繁忙时,我们会将日志命令缓存之后,整体发送给备份,减少io次数以提高备份的性能和对Redis性能的影响

实际开发中,配置一般会采用每秒将日志文件发送一次的策略,断电最多丢失1秒数据

为了减少日志的大小

Redis支持AOF rewrite

将一些已经进行删除的数据的新增命令也从日志中移除,达到减少日志容量的目的

Redis存储原理

Redis将内存划分为16384个槽(类似hash槽)

将数据(key)使用CRC16算法计算出一个在0~16383之间的值

将数据存到这个槽中

当再次使用这个key计算时,直接从这个槽获取,大幅提高查询效率

实际上这就是最基本"散列算法"

Redis集群

最小状态Redis是一台服务器

这台服务器的状态直接决定的Redis的运行状态

如果它宕机了,那么Redis服务就没了

系统面临崩溃风险

我们可以在主机运行时使用一台备机

主从复制

也就是主机(master)工作时,安排一台备用机(slave)实时同步数据,万一主机宕机,我们可以切换到备机运行

缺点,这样的方案,slave节点没有任何实质作用,只要master不宕机它就和没有一样,没有体现价值

读写分离

这样slave在master正常工作时也能分担Master的工作了

但是如果master宕机,实际上主备机的切换,实际上还是需要人工介入的,这还是需要时间的

那么如果想实现故障是自动切换,一定是有配置好的固定策略的

哨兵模式:故障自动切换

哨兵节点每隔固定时间向所有节点发送请求

如果正常响应认为该节点正常

如果没有响应,认为该节点出现问题,哨兵能自动切换主备机

如果主机master下线,自动切换到备机运行

但是这样的模式存在问题

但是如果哨兵判断节点状态时发生了误判,那么就会错误将master下线,降低整体运行性能

哨兵集群

如果哨兵服务器是一个节点,它误判master节点出现了故障,将master节点下线

但是master其实是正常工作的,整体系统效率就会大打折扣

我们可以将哨兵节点做成集群,由多个哨兵投票决定是否下线某一个节点

哨兵集群中,每个节点都会定时向master和slave发送ping请求

如果ping请求有2个(集群的半数节点)以上的哨兵节点没有收到正常响应,会认为该节点下线

分片集群

当业务不断扩展,并发不断增高时

有可能一个Master节点做写操作性能不足,称为了系统性能的瓶颈

这时,就可以部署多个Master节点,每个节点也支持主从复制

只是每个节点负责不同的分片

Redis0~16383号槽,

例如MasterA复制0~5000

MasterB复制5001~10000

MasterC复制10001~16383

一个key根据CRC16算法只能得到固定的结果,一定在指定的服务器上找到数据

有了这个集群结构,我们就能更加稳定和更加高效的处理业务请求了

为了节省哨兵服务器的成本,有些工作在Redis集群中直接添加哨兵功能,既master/slave节点完成数据读写任务的同时也都互相检测它们的健康状态

14.消息队列

Dubbo远程调用的性能问题

Dubbo调用在微服务项目中普遍存在

这些Dubbo调用都是同步的

"同步"指:A(消费者)调用B(生产者)的服务A在发起调用后,在B返回之前只能等待

直到B返回结果后A才能运行

Dubbo消费者发送调用后进入阻塞状态,这个状态表示改线程仍占用内存资源,但是什么动作都不做

如果生产者运行耗时较久,消费者就一直等待,如果消费者利用这个时间,那么可以处理更多请求,业务整体效率

实际情况下,Dubbo有些必要的返回值必须等待,但是不必要等待的服务返回值,我们可以不等待去做别的事情

这种情况下我们就要使用消息队列

什么是消息队列

消息队列(Message Queue)简称MQ

消息队列是采用"异步(两个微服务项目并不需要同时完成请求)"的方式来传递数据完成业务操作流程的业务处理方式

消息队列的特征

常见面试题:消息队列的特征

• 利用异步的特性,提高服务器的运行效率,减少因为远程调用出现的线程等待\阻塞
• 削峰填谷:在并发峰值超过当前系统处理能力时,我们将没处理的信息保存在消息队列中,在后面出现的较闲的时间中去处理,直到所有数据依次处理完成,能够防止在并发峰值时短时间大量请求而导致的系统不稳定
• 消息队列的延时:因为是异步执行,请求的发起者并不知道消息何时能处理完,如果业务不能接收这种延迟,就不要使用消息队列

常见消息队列

• Kafka:性能好\功能弱:适合大数据量,高并发的情况,大数据领域使用较多
• RabbitMQ:功能强\性能一般:适合发送需求复杂的消息队列,java业务中使用较多
• RocketMQ:阿里的
• ActiveMQ:前几年流行的,老项目可能用到

常见面试题:消息队列异常处理

如果我们真的将上面生成订单业务里,减少库存的操作从正常流程中剥离到消息队列

那么如果库存减少过程中发送异常,就不能由Seata接收了,因为异步的处理无法和Seata通信

意思是如果使用了消息队列,队列中处理数据过程发送异常,那么就要用特殊的方法处理问题

处理方式就是手写代码进行回滚,一般情况就是在stock,模块再向order模块发送消息,order模块接收到消息后进行进一步处理

如果order模块进一步处理时又发生异常,我们可以再向一个实现设置好的消息队列中发送消息

这个消息队列没有处理者,我们称之为"死信队列",一个正常运行的程序,会定期有人处理死信队列信息

15.Kafka

什么是Kafka

Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。Kafka最初是由LinkedIn开发，并随后于2011年初开源。

kafka软件结构

Kafka Cluster(Kafka集群)

Partition(分片)

Producer:消息的发送方,也就是消息的来源,Kafka中的生产者

order就是消息的发送方

Consumer:消息的接收方,也是消息的目标,Kafka中的消费者

stock就是消息的接收方法

Topic:话题或主题的意思,消息的收发双方要依据同一个话题名称,才不会将信息错发给别人

Record:消息记录,就是生产者和消费者传递的信息内容,保存在指定的Topic中

Kafka的特征与优势

Kafka作为消息队列,它和其他同类产品相比,突出的特点就是性能强大

Kafka将消息队列中的信息保存在硬盘中

Kafka对硬盘的读取规则进行优化后,效率能够接近内存

硬盘的优化规则主要依靠"顺序读写,零拷贝,日志压缩等技术"

Kafka处理队列中数据的默认设置:

• Kafka队列信息能够一直向硬盘中保存(理论上没有大小限制)
• Kafka默认队列中的信息保存7天,可以配置这个时间,缩短这个时间可以减少Kafka的磁盘消耗

16.RabbitMQ

什么是RabbitMQ

RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。 AMQP ：Advanced Message Queue，高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。 RabbitMQ 最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

RabbitMQ特征

1.可靠性（Reliability） RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。

2.灵活的路由（Flexible Routing） 在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。

3.消息集群（Clustering） 多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker

4.高可用（Highly Available Queues） 队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。

5.多种协议（Multi-protocol） RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等。

6.多语言客户端（Many Clients） RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。

7.管理界面（Management UI） RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。

8.跟踪机制（Tracing） 如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。

9.插件机制（Plugin System） RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。

RabbitMQ的结构

和Kafka不同,Kafka是使用话题名称来收发信息,结构简单

RabbitMQ是使用交换机\路由key指定要发送消息的队列

消息的发送者发送消息时,需要指定交换机和路由key名称

消息的接收方接收消息时,只需要指定队列的名称

在编写代码上,相比于Kafka,每个业务要编写一个配置类

这个配置类中要绑定交换机和路由key的关系,以及路由Key和队列的关系

17.布隆过滤器介绍

什么是布隆过滤器

布隆过滤器能够实现使用较少的空间来判断一个指定的元素是否包含在一个集合中

布隆过滤器并不保存这些数据,所以只能判断是否存在,而并不能取出改元素

布隆过滤器常见使用场景

1. idea中编写代码,一个单词是否包含在正确拼写的词库中(拼写不正确划绿线的提示)
2. 公安系统,根据身份证号\人脸信息,判断该人是否在追逃名单中
3. 爬虫检查一个网址是否被爬取过

…

宗旨凡是判断一个元素是否在一个集合中的操作,都可以使用它

为什么使用布隆过滤器

常规的检查一个元素是否在一个集合中的思路是遍历集合,判断元素是否相等

这样的查询效率非常低下

要保证快速确定一个元素是否在一个集合中,我们可以使用HashMap

因为HashMap内部的散列机制,保证更快更高效的找到元素

所以当数据量较小时,用HashMap或HashSet保存对象然后使用它来判定元素是否存在是不错的选择

但是如果数据量太大,每个元素都要生成哈希值来保存,我们也要依靠哈希值来判定是否存在,一般情况下,我们为了保证尽量少的哈希值冲突需要8字节哈希值做保存

long取值范围:-9223372036854775808-----9223372036854775807

5亿条数据 每条8字节计算后结果为需要3.72G内存,随着内存数增长,这个数字可能更大

所以Hash散列或类似算法可以保证高效判断元素是否存在,但是消耗内存较多

所以我们使用布隆过滤器实现,高效判断是否存在的同时,还能节省内存的效果

但是布隆过滤器的算法天生会有误判情况,需要能够容忍,才能使用

布隆过滤器原理

• 巴顿.布隆于⼀九七零年提出
• ⼀个很长的⼆进制向量（位数组）
• ⼀系列随机函数 (哈希)
• 空间效率和查询效率⾼
• 有⼀定的误判率（哈希表是精确匹配）

semlinker

我们使用不同的3个hash算法为例

算法1:semlinker–>2

算法2:semlinker–>6

算法3:semlinker–>4

会在布隆过滤器中产生如下影响

查询"Good"在不在布隆过滤器中

算法1:Good–>7

算法2:Good–>3

算法3:Good–>6

我们判断Good单词生成的3,6,7三个位置,只要有一个位置是0

就表示当前集合中没有Good这个单词

一个布隆过滤器不可能存一个单词,一般布隆过滤器都是保存大量数据的

如果有新的元素保存在布隆过滤器中

kakuqo

算法1:kakuqo–>3

算法2:kakuqo–>4

算法3:kakuqo–>7

新的单词生成3,4,7个位置

那么现在这个布隆过滤器中2,3,4,6,7都是一个了

如果又有单词bad

bad

算法1:bad–>2

算法2:bad–>3

算法3:bad–>6

判断布隆过滤器2,3,6都是1,所以布隆过滤器会认为bad是存在于这个集合中的

误判就是这样产生的

布隆过滤器误判的效果:

• 布隆过滤器判断不存在的,一定不在集合中
• 布隆过滤器判断存在的,有可能不在集合中

过短的布隆过滤器如果保存了很多的数据,可能造成二进制位置值都是1的情况,一旦发送这种情况,布隆过滤器就会判断任何元素都在当前集合中,布隆过滤器也就失效了

所以我们要给布隆过滤器一个合适的大小才能让它更好的为程序服务

• 优点

空间效率和查询效率⾼，

• 缺点
  • 有⼀定误判率即可（在可接受范围内）。
  • 删除元素困难(不能将该元素hash算法结果位置修改为0,因为可能会影响其他元素)
  • 极端情况下,如果布隆过滤器所有为位置都是1,那么任何元素都会被判断为存在于集合中

设计布隆过滤器

我们在启动布隆过滤器时,需要给它分配一个合理大小的内存

这个大小应该满足

1.一个可接受范围的大小

2.不能有太高的误判率

内存约节省,误判率越高

内存越大,误判率越低

数学家已经给我们了公式计算误判率

上面是根据误判率计算布隆过滤器长度的公式

n 是已经添加元素的数量；

k 哈希的次数；

m 布隆过滤器的长度(位数的大小)

计算结果就是误判率

如果我们已经确定可接受的误判率,想计算需要多少 布隆过滤器的长度

布隆过滤器计算器

https://hur.st/bloomfilter

windows安装redisbloom布隆过滤器

https://blog.csdn.net/weixin_44770915/article/details/107918770