.

在限流的时候，要统计每秒钟的QPS，同样是计数。固定时间窗口算法中窗口有很多，其跨度和位置是与时间区间绑定，因此是很多固定不动的窗口。而滑动时间窗口算法中只包含1个固定跨度的窗口，但窗口是可移动动的，与时间区间无关。这就是固定窗口计数算法的问题，它只能统计当前某1个时间窗的请求数量是否到达阈值，无法结合前后的时间窗的数据做综合统计。Sentinel的线程隔离就是基于信号量隔离实现的，而Hystix两种都支持，但默认是基于线程池隔离。sentinel中的限流中的排队等待功能正是基于漏桶算法实现的。

我们知道微服务间远程调用都是有OpenFeign帮我们完成的，甚至帮我们实现了服务列表之间的负载均衡。但具体负载均衡的规则是什么呢？何时做的负载均衡呢？接下来我们一起来分析一下。负载均衡原理在SpringCloud的早期版本中，负载均衡都是有Netflix公司开源的Ribbon组件来实现的，甚至Ribbon被直接集成到了Eureka-client和Nacos-Discovery中。但是自SpringCloud2020版本开始，已经弃用Ribbon，改用Spring自己开源的Spring Cloud Load

Eureka是Netflix公司开源的一个服务注册中心组件，早期版本的SpringCloud都是使用Eureka作为注册中心。由于Eureka和Nacos的starter中提供的功能都是基于SpringCloudCommon规范，因此两者使用起来差别不大。由于存在地域差异，网络传输的速度会有很大不同，因此在做服务治理时需要区分不同机房的实例。还有的企业中，会开发多个项目，共享nacos集群。服务的bootstrap.yml文件，添加服务发现配置，指定其。）的概念，来对应不同机房。也就是说，一个服务（

TCC模式的每个阶段是做什么的？

缓存穿透是指客户端请求的数据在数据库中根本不存在，从而导致请求穿透缓存，直接打到数据库的问题。

与LFU类似，每次需要内存淘汰时，就会抽样一部分KEY，找出其中逻辑访问次数最小的，将其淘汰。Redis的Key都是RedisObject，当启用LRU算法后，Redis会在Key的头信息中使用24个bit记录每个key的最近一次使用的时间。可以发现，当key的TTL到期以后，再次访问name返回的是nil，说明这个key已经不存在了，对应的内存也得到释放从而起到内存回收的目的。惰性删除: 当有命令需要操作一个key的时候，检查该key的存活时间，如果已经过期才执行删除。

StringListSetSortedSetHash还有一些高级数据类型，比如Bitmap、HyperLogLog、GEO等，其底层都是基于上述5种基本数据类型。因此在Redis的源码中，其实只有5种数据类型。

主从模式可以解决高可用、高并发读的问题。海量数据存储高并发写要解决这两个问题就需要用到分片集群了。分片的意思，就是把数据拆分存储到不同节点，这样整个集群的存储数据量就更大了。Redis分片集群的结构如图：集群中有多个master，每个master保存不同分片数据 ，解决海量数据存储问题每个master都可以有多个slave节点 ，确保高可用master之间通过ping监测彼此健康状态 ，类似哨兵作用客户端请求可以访问集群任意节点，最终都会被转发到数据所在节点。

如图所示，集群中有一个master节点、两个slave节点（现在叫replica）。最后，还要配置读写分离，让java客户端将写请求发送到master节点，读请求发送到slave节点。单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。由于采用的是host模式，我们看不到端口映射。Redis提供了哨兵(Sentinel)机制来实现主从集群的自动故障恢复。接下来，我们演示一下当主节点故障时，哨兵是如何完成集群故障恢复（failover）的。

聚合（）可以让我们极其方便的实现对数据的统计、分析、运算。什么品牌的手机最受欢迎？这些手机的平均价格、最高价格、最低价格？这些手机每月的销售情况如何？实现这些统计功能的比数据库的sql要方便的多，而且查询速度非常快，可以实现近实时搜索效果。官方文档：https://www.elastic.co/guide/en/elasticsearch/reference/7.12/search-aggregations.html聚合常见的有三类：桶（Bucket聚合：用来对文档做分组。

需求: 利用lavaRestClient实现搜索功能, 条件如下。使用RestClient客户端进行数据搜索可以分为两步。全文检索的查询条件构造API如下。高亮显示的条件构造API如下。构建复杂查询条件的搜索。

Elasticsearch提供了DSL(Domain SpecificLanguage)查询，就是以SON格式来定义查询条件, 用于实现模糊搜索叶子查询(Leaf query clauses): 一般是在特定的字段里查询特定值，属于简单查询，很少单独使用复合查询(Compound query clauses): 以逻辑方式组合多个叶子查询或者更改叶子查询的行为方式在查询以后，还可以对查询的结果做处理，包括:排序: 按照1个或多个字段值做排序分页: 根据from和size做分页，类似MySQL。

Elasticsearch目前最新版本是8.0，其java客户端有很大变化。不过大多数企业使用的还是8以下版本，所以我们选择使用早期的lavaRestClient客户端来学习。再次写入id一样的文档，就会删除旧文档，添加新文档。与新增的JavaAPI一致。在elasticsearch提供的API中，与elasticsearch一切交互都封装在一个名为。的类中，必须先完成这个对象的初始化，建立与elasticsearch的连接。2）因为SpringBoot默认的ES版本是。，然后将初始化的代码编写在。

索引库和mapping一旦创建无法修改，但是可以添加新的字段，语法如下。keyword(精确值，例如:品牌、国家、ip地址)全量修改，会删除旧文档，添加新文档。增量修改，修改指定字段值。

需要注意的是，数据库模糊查询随着表数据量的增多，查询性能的下降会非常明显，而搜索引擎的性能则不会随着数据增多而下降太多。Elasticsearch的关键就是倒排索引，而倒排索引依赖于对文档内容的分词，而分词则需要高效、精准的分词算法，英文分词比较简单, 用空格分割, 单词就自然分开了。注意，如果采用在线安装的通过，默认是没有config目录的，需要把课前资料提供的ik下的config上传至对应目录。在面临海量数据的搜索，或者有一些复杂搜索需求的时候，推荐使用专门的搜索引擎来实现搜索功能。

延迟消息: 发送者发送消息时指定一个时间，消费者不会立刻收到消息，而是在指定时间之后才收到消息。延迟任务: 设置在一定时间之后才执行的任务在电商的支付业务中，对于一些库存有限的商品，为了更好的用户体验，通常都会在用户下单时立刻扣减商品库存。例如电影院购票、高铁购票，下单后就会锁定座位资源，其他人无法重复购买。但是这样就存在一个问题，假如用户下单后一直不付款，就会一直占有库存资源，导致其他客户无法正常交易，最终导致商户利益受损！对于超过一定时间未支付的订单，应该立刻取消订单并释放占用的库存。

消息到达MQ以后，如果MQ不能及时保存，也会导致消息丢失，所以MQ的可靠性也非常重要。

将来我们开发业务功能的时候，肯定不会在控制台收发消息，而是应该基于编程的方式。RabbitMQRabbitMQRabbitMQ案例需求: 利用SpringAMQP完成消息的收发在之前的案例中，我们都是经过交换机发送消息到队列，不过有时候为了测试方便，我们也可以直接向队列发送消息，跳过交换机。这种模式一般测试使用，很少在生产中使用。

RabbitMQ是一个高性能的异步通讯组件同步调用与异步调用同步调用的特点同步调用的优势是什么?时效性强，等待到结果后才返回。同步调用的问题是什么?拓展性差性能下降级联失败问题异步调用通常是基于消息通知的方式，包含三个角色消息发送者: 投递消息的人，就是原来的调用者消息接收者: 接收和处理消息的人，就是原来的服务提供者消息代理: 管理、暂存、转发消息，你可以把它理解成微信服务器异步调用优缺点支付服务不再同步调用业务关联度低的服务，而是发送消息通知到Broker。

下单业务，前端请求首先进入订单服务，创建订单并写入数据库。购物车服务负责清理购物车信息库存服务负责扣减商品库存下单过程中, 订单服务创建订单, 插入自己的数据库, 执行成功购物车服务, 清理数据库中用户的购物车数据, 执行成功库存服务扣减库存时, 商品库存不够, 那么库存服务就会抛出异常订单创建成功了, 购物车页清理了, 但是库存却没有扣减这就出现了事务的不一致。

通过线程隔离, 可以对服务起到保护作用, 某一个业务出现问题不会影响其他业务, 但是被隔离的这个业务, 一旦出现问题, 还是会出现业务不可用的问题, 影响用户体验, 所以需要通过后备方案, 处理可能出问题的业务。服务熔断:由断路器统计请求的异常比例或慢调用比例，如果超出阈值则会熔断该业务，则拦截该接口的请求。限流可以降低服务器压力，尽量减少因并发流量引起的服务故障的概率，但并不能完全避免服务故障。请求限流: 也叫流量整形, 限制访问微服务的请求的并发量，避免服务因流量激增出现故障。解决问题的思路有哪些?

代码拆分为微服务后, 每个服务都有自己的配置文件, 而这些配置文件中有很多重复的配置, 并且配置变化后需要重启服务, 才能生效, 这样就会影响开发体验和效率配置管理服务可以帮助我们集中管理公共的配置, 并且nacos就可以实现配置管理服务。

GatewayFilter: 路由过滤器，作用于任意指定的路由;默认不生效，要配置到路由后生效GlobalFilter: 全局过滤器，作用范围是所有路由;声明后自动生效两种过滤器的过滤方法签名完全一致:解读全局过滤器的信息定义全局过滤器: 两种过滤器的定义存在差异, 全局过滤器的定义简单一些, 实现GlobalFilter接口即可@Component@Override// 获取请求// 过滤器业务处理。

网关: 就是网络的关口，负责请求的路由、转发、身份校验路由: 前端所有的请求都由网关处理, 网关要判断该请求属于哪个微服务, 这个过程称为路由转发: 路由之后, 网关去注册中心拉取服务列表, 选择一个服务实例, 把请求转发到对应的微服务, 这个过程称为转发身份校验: 校验请求, 解析taoken令牌, 获取用户信息, 拦截不合法的请求, 放行合法的请求, 并且向后传递用户信息优势:有了网关之后, 后端微服务的地址就不需要暴露给前端了, 只暴露网关的地址, 起到保护服务的作用。

OpenFeign 是一个声明式的http客户端，是SpringCloud在Eureka公司开源的Feign基础上改造而来。OpenFeign对Http请求做了优雅的伪装，不过其底层发起http请求，依赖于其它的框架。OpenFeign只会在FeignClient所在包的日志级别为DEBUG时，才会输出日志。方案1: 把OpenFeign客户端封装在每个微服务中, 由服务的开发者进行维护。基于RestTemplate工具的请求, 功能是没问题的, 但是代码十分臃肿。

Nacos是目前企业中占比最多的注册中心组件。它是阿里巴巴的产品，目前已经加入SpringcloudAlibaba中。我们基于Docker来部署Nacos的注册中心，首先要准备MySQL数据库表，用来存储Nacos的数据。消费者需要连接nacos以拉取和订阅服务，因此服务发现的前两步与服务注册一样，后面再加上服务调用。引入nacos discovery依赖。注册中心可以统一管理项目中的所有服务。默认账密: nacos/nacos。

配置启动项, 启动服务, 测试id: 1654779387523936258。在hmall下新建一个module，命名为trade-service。在hmall下新建一个module，命名为user-service。在hmall下新建一个module，命名为pay-service。在支付服务的PayController中添加一个接口方便测试。解决PayOrderServiceImpl报错。解决OrderServiceImpl报错。添加启动类和配置文件。添加启动类和配置文件。添加启动类和配置文件。

集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。comcat服务器的连接数是有限的, 随着并发请求量的上升, 整个系统的响应速度就会变慢。确定的大型项目: 资金充足，目标明确，可以直接选择微服务架构，避免后续拆分的麻烦。随着规模扩大，逐渐拆分。高内聚: 每个微服务的职责要尽量单一，包含的业务相互关联度高、完整度高。低耦合: 每个微服务的功能要相对独立，尽量减少对其它微服务的依赖。单体架构:将业务的所有功能集中在一个项目中开发，打成一个包部署。