需求：redis中缓存了一些状态量，业务需要时刻关注状态量变化

方案一：轮询检查（各方面性能太差）

方案二：redis提供的键空间通知机制（redis主动推送，优选）

1、发布与订阅

SUBSCRIBE /UNSUBSCRIBE/PUBLISH 三个命令实现了发布与订阅信息泛型（Publish/Subscribe messaging paradigm)，在这个实现中，发送者（发送信息的客户端）不是将信息直接发送给特定的接收者（接收信息的客户端），而是将信息发送给频道（channel），然后由频道将信息转发给所有对这个频道感兴趣的订阅者。

发送者无须知道任何关于订阅者的信息，而订阅者也无须知道是那个客户端给它发送信息，它只要关注自己感兴趣的频道即可。

redis的数据持久化功能默认是没有开启的，当我们kill掉redis-server进程并重启后，此前所有的缓存数据都会丢失，所以为了防止redis服务器宕机而造成数据丢失，我们应该打开redis的数据持久化功能。

redis持久化方式有两种：RDB 和 AOF，本文将围绕这两种持久化方式展开。

1、持久化原理

• RDB的原理是生成当前数据集的快照文件dump.rdb，当服务器宕机重启后，服务器会根据该备份文件恢复数据，备份的是数据。
• AOF的原理是维护一个数据写入日志（aof文件），在服务器执行写入命令的时候，在aof文件尾部添加命令。服务器宕机重启后，自动执行aof文件中的数据写入命令恢复数据。

MySQL8.0和MySQL5.7具有众多不同之处，此处不述。这里，只简单讲讲在安装过程中遇到的问题之一和解决办法：
MySQL8.0安装完成之后的默认密码是多少？如何修改初始密码？

1. 安装MySQL8.0

• yum仓库下载MySQL：

1

shell> yum localinstall https://repo.mysql.com//mysql80-community-release-el7-1.noarch.rpm

在微服务系统中，随着业务的发展，系统会变得越来越大，那么各个服务之间的调用关系也就变得越来越复杂。一个 HTTP 请求会调用多个不同的微服务来处理返回最后的结果，在这个调用过程中，可能会因为某个服务出现网络延迟过高或发送错误导致请求失败，这个时候，对请求调用的监控就显得尤为重要了。Spring Cloud Sleuth 提供了分布式服务链路监控的解决方案。下面介绍 Spring Cloud Sleuth 整合 Zipkin 的解决方案。

Zipkin 是 Twitter 的一个开源项目，它基于 Google Dapper 实现的。我们可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的 REST API 接口来辅助查询跟踪数据以实现对分布式系统的监控程序，从而及时发现系统中出现的延迟过高问题。除了面向开发的 API 接口之外，它还提供了方便的 UI 组件来帮助我们直观地搜索跟踪信息和分析请求链路明细，比如可以查询某段时间内各用户请求的处理时间等。

Zipkin 和 Config 结构类似，分为服务端 Server，客户端 Client，客户端就是各个微服务应用。

Spring Cloud提供ZipKin组件

SpringCloud Zipkin 与Sleuth
Zipkin 是一个开放源代码分布式的跟踪系统，由Twitter公司开源，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。
每个服务向zipkin报告计时数据，例如用户每次请求服务的处理时间等，可方便的监测系统中存在的瓶颈。
zipkin会根据调用关系通过Zipkin UI生成依赖关系图。

Spring-Cloud-Gateway的过滤器接口分为两种：

1. GlobalFilter : 全局过滤器，不需要在配置文件中配置，作用在所有的路由上，最终通过GatewayFilterAdapter包装成GatewayFilterChain可识别的过滤器
2. GatewayFilter : 需要通过spring.cloud.routes.filters 配置在具体路由下，只作用在当前路由上或通过spring.cloud.default-filters配置在全局，作用在所有路由上

为什么需要配置中心？

分布式微服务架构，当一个服务存在多个实例分布在不同的服务器上，需要对该服务进行配置变更时，需要逐个服务器进行配置，并需要重启服务。配置中心就是为了解决这个问题，让配置一处变更，处处生效。

开源的配置中心：

• Diamond(super)

在微服务架构中，每个服务都是一个可以独立开发和运行的组件，而一个完整的微服务架构由一系列独 立运行的微服务组成。其中每个服务都只会完成特定领域的功能，比如订单服务提供与订单业务场景有 关的功能、商品服务提供商品展示功能等。各个微服务之间通过轻量级通信机制 REST API 或者 RPC 完 成通信。 微服务之后在某些层面会带来一定的影响，比如，一个用户查看一个商品的详情，对于客户端 来说，可能需要调用商品服务、评论服务、库存服务、营销服务等多个服务来完成数据的渲染

在这个场景中，客户端虽然能通过调用多个服务实现数据的获取，但是会存在一 些问题，比如:

• 客户端需要发起多次请求，增加了网络通信的成本及客户端处理的复杂性。
• 服务的鉴权会分布在每个微服务中处理，客户端对于每个服务的调用都需要重复鉴权。

Hystrix实现核心

• 可配置化的降级策略
  • 信号量、线程实现资源隔离，超时降级，熔断降级
  • HystrixCommandProperty

1. 实体对象分类

1.1 领域模型中的实体分类

VO (View Object) 视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

DTO (Data Transfer Object) 数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。

DO (Domain Object) 领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。会包含属性和方法。

PO (Persistent Object) 持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。

各种实体类用于不同业务层次间的交互，并会在层次内实现实体类之间的转化。

由于 RabbitMQ 实现了 AMQP 协议，所以 RabbitMQ 的工作模型也是基于 AMQP 的，理解这张图片至关重要。

rabbit的概念

Broker–主机节点，中文翻译是代理/中介，因为 MQ 服务器帮助我们做的事 情就是存储、转发消息。

Connection–无论是生产者发送消息，还是消费者接收消息，都必须要跟 Broker 之间建立一个连接，这个连接是一个 TCP 的长连接。

Channel–如果所有的生产者发送消息和消费者接收消息，都直接创建和释放 TCP 长连接的话， 对于 Broker 来说肯定会造成很大的性能损耗，因为 TCP 连接是非常宝贵的资源，创建和 释放也要消耗时间。