pxyp123
pxyp123

分布式springcloud

Sentinel 流量组件

雪崩问题

微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。服务器支持的线程和并发数有限，到来的请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用。

综上，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，导致整个微服务无法使用，这就是雪崩问题。

分布式springcloud_第1张图片

解决雪崩问题的常见方式有四种

  1. 超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。但是当请求速度大于超时时间时，随着时间推移，必然会导致服务器的资源耗尽，没有解决根本问题。

  2. 线程隔离：是一种舱壁模式，我们可以限定每个业务能使用的线程数，避免耗尽整个 tomcat 的资源，因此也叫线程隔离。这种模式的问题会空耗服务器资源，服务 C 已经宕机，但是还是有请求不断访问服务 C，空耗资源。

    分布式springcloud_第2张图片

  3. 降级熔断：是一种断路器模式，由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

    分布式springcloud_第3张图片

  4. 限流

    流量控制：限制业务访问的 QPS，避免服务因流量的突增而故障。

    分布式springcloud_第4张图片

限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。

超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。

Sentinel Hystrix
隔离策略 信号量隔离 线程池隔离/信号量隔离
熔断降级策略 基于慢调用比例或异常比例 基于失败比率
实时指标实现 滑动窗口 滑动窗口（基于 RxJava）
规则配置 支持多种数据源 支持多种数据源
扩展性 多个扩展点 插件的形式
基于注解的支持 支持 支持
限流 基于 QPS，支持基于调用关系的限流 有限的支持
流量整形 支持慢启动、匀速排队模式 不支持
系统自适应保护 支持 不支持
控制台 开箱即用，可配置规则、查看秒级监控、机器发现等 不完善
常见框架的适配 Servlet、Spring Cloud、Dubbo、gRPC 等 Servlet、Spring Cloud Netflix

初识 Sentinel

Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址：home | Sentinel

Sentinel 具有以下特征

  • 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。

  • 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。

  • 广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。

  • 完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

整合 Sentinel

下载后 jar 包后，运行代码：java -jar sentinel-dashboard-1.8.1.jar

如果要修改 Sentinel 的默认端口、账户、密码，可以通过下列配置：

配置项 默认值 说明
server.port 8080 服务端口
sentinel.dashboard.auth.username sentinel 默认用户名
sentinel.dashboard.auth.password sentinel 默认密码

例如，修改端口：

java -Dserver.port=8090 -jar sentinel-dashboard-1.8.1.jar

我们在 order-service 中整合 Sentinel，并连接 Sentinel 的控制台，步骤如下

1）引入 Sentinel 依赖



    com.alibaba.cloud 
    spring-cloud-starter-alibaba-sentinel

2）配置控制台

修改 application.yml 文件，添加下面内容：

server:
  port: 8088
spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8080

3）访问 order-service 的任意端点

打开浏览器，访问 http://localhost:10010/order/101，多访问几次，多点几次刷新，这样才能触发 Sentinel 的监控。

然后再访问 Sentinel 的控制台，查看效果。

分布式springcloud_第5张图片

流量控制

雪崩问题虽有四种方案，但是限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。

限流算法

1、滑动窗口

在介绍滑动窗口之前，先介绍一种计数器算法

计数器算法是限流算法里最简单也是最容易实现的一种算法。比如我们规定，对于A接口来说，我们1分钟的访问次数不能超过100个。那么我们可以这么做：在一开 始的时候，我们可以设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个 请求的间隔时间还在1分钟之内，那么说明请求数过多；如果该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置 counter，具体算法的示意图如下：

分布式springcloud_第6张图片

这个算法虽然简单，但是有一个十分致命的问题，那就是临界问题：

分布式springcloud_第7张图片

从上图中我们可以看到，假设有一个恶意用户，他在0:59时，瞬间发送了100个请求，并且1:00又瞬间发送了100个请求，那么其实这个用户在 1秒里面，瞬间发送了200个请求。我们刚才规定的是1分钟最多100个请求，也就是每秒钟最多1.7个请求，用户通过在时间窗口的重置节点处突发请求， 可以瞬间超过我们的速率限制。用户有可能通过算法的这个漏洞，瞬间压垮我们的应用。

刚才的问题其实是因为我们统计的精度太低，为了解决这个问题，引出滑动窗口算法。

分布式springcloud_第8张图片

在上图中，整个红色的矩形框表示一个时间窗口，在我们的例子中，一个时间窗口就是一分钟，一分钟内最大访问数为 100，即一个时间窗口的最大访问数为 100。然后我们将时间窗口进行划分，比如图中，我们就将滑动窗口 划成了6格，所以每格代表的是10秒钟。每过10秒钟，我们的时间窗口就会往右滑动一格。每一个格子都有自己独立的计数器counter，比如当一个请求 在0:35秒的时候到达，那么0:30~0:39对应的counter就会加1。

同样是临界问题，若0:59到达的100个请求落在灰色的格子中，而1:00到达的请求落在橘黄色的格 子中。当时间到达1:00时，我们的窗口会往右移动一格，那么此时时间窗口内的总请求数量一共是200个，超过了限定的100个，所以此时能够检测出来触 发了限流。

我们可以发现，计数器算法其实就是滑动窗口算法。只是它没有对时间窗口做进一步地划分，所以只有1格。

由此可见，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

2、令牌桶算法

按一定额定的速率产生令牌，存入令牌桶，桶有最大容量（应该为微服务最大承载）；服务过来时需要请求到一个令牌才可以进入服务执行；服务里就可以保持基本不会超过承载值。【保护服务】

1）、所有的请求在处理之前都需要拿到一个可用的令牌才会被处理； 2）、根据限流大小，设置按照一定的速率往桶里添加令牌； 3）、桶设置最大的放置令牌限制，当桶满时、新添加的令牌就被丢弃或者拒绝； 4）、请求达到后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除； 5）、令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流；

分布式springcloud_第9张图片

3、漏桶算法

维持一个队列，所有请求先进队列，然后从队列取出请求的速率是固定。【保护请求】

漏桶算法其实很简单，可以粗略的认为就是注水漏水过程，往桶中以一定速率流出水，以任意速率流入水，当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。

当请求进来时，相当于水倒入漏斗，然后从下端小口慢慢匀速的流出。不管上面流量多大，下面流出的速度始终保持不变。不管服务调用方多么不稳定，通过漏桶算法进行限流，每10毫秒处理一次请求。因为处理的速度是固定的，请求进来的速度是未知的，可能突然进来很多请求，没来得及处理的请求就先放在桶里，既然是个桶，肯定是有容量上限，如果桶满了，那么新进来的请求就丢弃。漏桶算法存在一个缺陷，无法应对短时间的突发流量，比如双十一抢购、秒杀活动开始。

分布式springcloud_第10张图片

簇点链路

当请求进入微服务时，首先会访问 DispatcherServlet，然后进入 Controller、Service、Mapper，这样的一个调用链就叫做 簇点链路。

簇点链路中被监控的每一个接口就是一个资源。默认情况下 Sentinel 会监控 SpringMVC 的每一个端点（Endpoint，也就是 Controller 中的方法），因此 SpringMVC 的每一个端点（Endpoint）就是调用链路中的一个资源。

例如，我们刚才访问的 order-service 中的 OrderController 中的端点：/order/{orderId}

分布式springcloud_第11张图片

流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

  • 流控：流量控制

  • 降级：降级熔断

  • 热点：热点参数限流，是限流的一种

  • 授权：请求的权限控制

点击资源 /order/{orderId} 后面的流控按钮，就可以弹出表单。

分布式springcloud_第12张图片

分布式springcloud_第13张图片

其含义是限制 /order/{orderId} 这个资源的单机 QPS 为 1，即每秒只允许 1 次请求，超出的请求会被拦截并报错。

流控模式

在添加限流规则时，点击高级选项，可以选择三种流控模式

  • 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式

    • 直接对当前资源限流

  • 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

    • 相当于高优先级资源触发阈值，对低优先级资源限流。

  • 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

直接模式

统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式

关联模式

统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。

使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

满足下面条件可使用关联模式：

  • 两个有竞争关系的资源

  • 一个优先级高，一个优先级低

分布式springcloud_第14张图片

链路模式

只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值。

例如有两条请求链路

  • /test1 --> /common

  • /test2 --> /common

如果只希望统计从 /test2 进入到 /common 的请求，则可以这样配置

分布式springcloud_第15张图片

默认情况下，OrderService 中的方法是不被 Sentinel 监控的，需要我们自己通过注解来标记要监控的方法。

给 OrderService 的 queryGoods 方法添加 @SentinelResource 注解。

@SentinelResource("goods")
public void queryGoods(){
    System.err.println("查询商品");
}

链路模式中，是对不同来源的两个链路做监控。但是 Sentinel 默认会给进入 SpringMVC 的所有请求设置同一个 root 资源，会导致链路模式失效。我们需要关闭这种对 SpringMVC 的资源聚合，修改 order-service 服务的 application.yml 文件

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

重启服务，访问 /order/query 和 /order/save，可以查看到 Sentinel 的簇点链路规则中，出现了新的资源

分布式springcloud_第16张图片

添加新的流控规则如下

分布式springcloud_第17张图片

只统计从 /order/query 进入 /goods 的资源，QPS 阈值为 2，超出则被限流。

流控效果

流控效果是指请求达到流控阈值时应该采取的措施，包括三种

  • 快速失败：达到阈值后，新的请求会被立即拒绝并抛出 FlowException 异常，是默认的处理方式。滑动时间窗口算法

  • Warm Up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。漏桶算法

  • 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长。令牌桶算法

快速失败

超过设置的 QPS 直接拒绝

Warm up

阈值一般是一个微服务能承担的最大 QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），如果直接将 QPS 跑到最大值，可能导致服务瞬间宕机。

Warm Up 也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 maxThreshold / coldFactor，持续指定时长后，逐渐提高到 maxThreshold 值。而 coldFactor 的默认值是 3.

例如，我设置 QPS 的 maxThreshold 为 10，预热时间为 5 秒，那么初始阈值就是 10 / 3 = 3，然后在 5 秒后逐渐增长到 10

分布式springcloud_第18张图片

排队等待

当请求超过 QPS 阈值时，「快速失败」和 「Warm Up」会拒绝新的请求并抛出异常。

而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。

例如：QPS = 5，意味着每 200ms 处理一个队列中的请求；timeout = 2000，意味着预期等待时长超过 2000ms 的请求会被拒绝并抛出异常。

比如现在一下子来了 12 个请求，因为每 200ms 执行一个请求，那么预期等待时长就是：

  • 第6个请求的预期等待时长 = 200 * (6 - 1) = 1000ms

  • 第12个请求的预期等待时长 = 200 * (12-1) = 2200ms

又比如下图：

分布式springcloud_第19张图片

现在，第 1 秒同时接收到 10 个请求，但第 2 秒只有 1 个请求，此时 QPS 的曲线这样的

分布式springcloud_第20张图片

如果使用排队等待的流控效果，所有进入的请求都要排队，以固定的 200ms 的间隔执行，QPS 会变的很平滑

分布式springcloud_第21张图片

这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。起到了流量整形效果。

热点参数限流

之前的限流是统计访问某个资源的所有请求，判断是否超过 QPS 阈值。而「热点参数限流」是分别统计参数值相同的请求，判断是否超过 QPS 阈值。

全局参数限流

例如，一个根据 id 查询商品的接口

访问/goods/{id} 的请求中，id 参数值会有变化，「热点参数限流」会根据参数值分别统计 QPS，统计结果：

分布式springcloud_第22张图片

当 id=1 的请求触发阈值被限流时，id值不为1的请求则不受影响。

配置示例：对 hot 这个资源的 0 号参数（也就是第一个参数）做统计，每 1s 相同参数值的请求数不能超过 5

分布式springcloud_第23张图片

热点参数限流

在实际开发中，可能部分商品是热点商品，例如秒杀商品，我们希望这部分商品的 QPS 限制与其它商品不一样，高一些。那就需要配置「热点参数限流」的高级选项了。

分布式springcloud_第24张图片

结合上一个配置，这里的含义是对 0 号的 long 类型参数限流，每 1 个相同参数的 QPS 不能超过 5，有如下两个例外

  • 如果参数值是 100，则每 1s 允许的 QPS 为 10

  • 如果参数值是 101，则每 1s 允许的 QPS 为 15

注意事项：热点参数限流对默认的 SpringMVC 资源无效，需要利用 @SentinelResource 注解在 controller 对应方法上标记资源。

分布式springcloud_第25张图片

隔离和降级

限流只是一种预防措施，虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。

而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。Sentinel 支持的雪崩解决方案为线程隔离和熔断降级。

线程隔离：调用者在调用服务提供者时，给每个调用的请求分配独立线程池，出现故障时，最多消耗这个线程池内资源，避免把调用者的所有资源耗尽。

分布式springcloud_第26张图片

熔断降级：是在调用方这边加入断路器，统计对服务提供者的调用，如果调用的失败比例过高，则熔断该业务，不允许访问该服务的提供者了。

分布式springcloud_第27张图片

可以看到，不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护。需要在调用方发起远程调用时做线程隔离、或者服务熔断。

而我们的微服务远程调用都是基于 Feign 来完成的，因此我们需要将 Feign 与 Sentinel 整合，在 Feign 里面实现线程隔离和服务熔断。

Feign 整合 Sentinel

SpringCloud中，微服务调用都是通过Feign来实现的，因此做客户端保护必须整合 Feign 和 Sentinel

修改配置，开启 Sentinel 功能，修改 OrderService 的 application.yml 文件，开启 Feign 的 Sentinel 功能

feign:
  sentinel:
    enabled: true # 开启feign对sentinel的支持

服务降级：访问失败后，服务编写失败降级逻辑代码，业务失败后，不能直接报错，而应该返回用户一个友好提示或者默认结果，这个就是失败降级逻辑。

给 FeignClient 编写失败后的降级逻辑

①方式一：FallbackClass，但无法对远程调用的异常做处理。

②方式二：FallbackFactory，可以对远程调用的异常做处理，通常使用这种

步骤一：

编写 FallbackFactory 接口的实现类 UserClientFallbackFactory

分布式springcloud_第28张图片

@Slf4j
public class UserClientFallbackFactory implements FallbackFactory {
    @Override
    public UserClient create(Throwable throwable) {
       return userClient -> {
           log.error("查询用户失败",throwable);
           return new User();
       };
    }
}

步骤二：

将 UserClientFallbackFactory 注册为 bean

@Bean
public UserClientFallbackFactory userClientFallbackFactory(){
    return new UserClientFallbackFactory();
}

步骤三：

在 client 接口上添加 fallbackFactory 选项

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {
    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

线程隔离

线程隔离（舱壁模式）有两种方式实现

  • 线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果。

  • 信号量隔离（Sentinel默认采用）：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求。

分布式springcloud_第29张图片

两者的优缺点

  • 线程池隔离：基于线程池模式，有额外开销，但隔离控制更强

  • 信号量隔离：基于计数器模式，简单，开销小

分布式springcloud_第30张图片

Sentinel 使用的是信号量隔离，而 Hystrix 则两种线程隔离都可以，18 年Hystrix已经停止更新。

如何使用呢，在添加限流规则时，可以选择两种阈值类型

分布式springcloud_第31张图片

  • QPS：就是每秒的请求数，之前已经演示过。

  • 线程数：是该资源能使用的 Tomcat 线程数的最大值。也就是通过限制线程数量，实现线程隔离（舱壁模式）。

熔断降级

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

断路器控制熔断和放行是通过状态机来完成的，如下图就是一个断路器的状态机

分布式springcloud_第32张图片

状态机包括三个状态

  • closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。会去判断是否达到熔断条件，这一步我们叫做「熔断策略」，达到该条件则切换到 open 状态，打开断路器。

  • open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open 状态 5 秒后会进入 half-open 状态。

  • half-open：半开状态，会一段时间放行一次请求，根据执行结果来判断接下来的操作。请求成功：则切换到 closed 状态；请求失败：则切换到 open 状态。

断路器熔断策略有三种：慢调用、异常比例、异常数

慢调用

业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。

例如下图，设置 RT 超过 500ms 的调用是慢调用，统计最近 10000ms 内的请求，如果请求量超过 10 次，并且慢调用比例不低于 0.5，则触发熔断，熔断时长为 5s，然后进入 half-open 状态，放行一次请求做测试。

分布式springcloud_第33张图片

异常

异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。

例如，异常比例设置如下，统计最近 1000ms 内的请求，如果请求量超过 10 次，并且异常比例不低于 0.4，则触发熔断。

分布式springcloud_第34张图片

异常数设置如下，统计最近 1000ms 内的请求，如果请求量超过 10 次，并且异常数不低于 2 次，则触发熔断。

分布式springcloud_第35张图片

授权规则

之前在 SpringCloud 网关中，可通过网关来判断访问是否可通行，但是若微服务的内部地址泄露，直接通过地址访问，便绕过了网关，这时网关无法判断。授权规则可以对请求方来源做判断和控制。授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式。

比如我们希望控制对资源 test 的访问设置白名单，只有来源为 appA 和 appB 的请求才可通过。

  • 白名单：来源（origin）在白名单内的调用者允许访问

  • 黑名单：来源（origin）在黑名单内的调用者不允许访问

点击左侧菜单的授权，可以看到授权规则

分布式springcloud_第36张图片

  • 资源名：就是受保护的资源，例如 /order/{orderId}

  • 流控应用：是来源者的名单

    • 如果是勾选白名单，则名单中的来源被许可访问。

    • 如果是勾选黑名单，则名单中的来源被禁止访问。

比如我们允许请求从 gateway 到 order-service，不允许浏览器访问 order-service，那么白名单中就要填写网关的来源名称（origin）。

分布式springcloud_第37张图片

Sentinel 是通过 RequestOriginParser 这个接口的 parseOrigin() 方法来获取请求的来源的。

这个方法的作用就是从 request 对象中，获取请求者的 origin 值并返回。默认情况下，Sentinel 不管请求者从哪里来，返回值永远是 default，也就是说一切请求的来源都被认为是一样的值 default

因此，我们需要自定义这个接口的实现，让不同的请求，返回不同的 origin

例如 order-service 服务中，我们定义一个 RequestOriginParser 的实现类

@Component
public class HeaderOriginParser implements RequestOriginParser {
    @Override
    public String parseOrigin(HttpServletRequest request) {
        // 1.获取请求头
        String origin = request.getHeader("origin");
        // 2.非空判断
        if (StringUtils.isEmpty(origin)) {
            origin = "blank";
        }
        return origin;
    }
}

我们必须让所有从 Gateway 路由到微服务的请求都带上 origin 头。这个需要利用之前学习的一个 GatewayFilter 来实现，使用 AddRequestHeaderGatewayFilter，修改 Gateway 服务中的 application.yml

spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=origin,gateway #origin前面不能带空格，这表示 origin 的值为 gateway

这样，从 Gateway 路由的所有请求都会带上 origin 头，值为 gateway。而从其它地方到达微服务的请求一般没有这个头。

接下来，我们添加一个授权规则，放行 origin 值为 gateway 的请求。那么跳过网关直接访问将会被 Sentinel 拦截，通过网关访问的将会放行。

分布式springcloud_第38张图片

自定义异常结果

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。异常结果都是 flow limmiting（限流）。这样不够友好，无法得知是限流还是降级还是授权拦截。

而如果要自定义异常时的返回结果，需要实现 BlockExceptionHandler 接口

public interface BlockExceptionHandler {
    /**
     * 处理请求被限流、降级、授权拦截时抛出的异常：BlockException
     */
    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}

这个方法有三个参数：

  • HttpServletRequest request：request 对象

  • HttpServletResponse response：response 对象

  • BlockException e：被 Sentinel 拦截时抛出的异常

这里的 BlockException 包含多个不同的子类

异常 说明
FlowException 限流异常
ParamFlowException 热点参数限流的异常
DegradeException 降级异常
AuthorityException 授权规则异常
SystemBlockException 系统规则异常

自定义异常处理，下面我们就在 order-service 定义一个自定义异常处理类

@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
        String msg = "未知异常";
        int status = 429;

        if (e instanceof FlowException) {
            msg = "请求被限流了";
        } else if (e instanceof ParamFlowException) {
            msg = "请求被热点参数限流";
        } else if (e instanceof DegradeException) {
            msg = "请求被降级了";
        } else if (e instanceof AuthorityException) {
            msg = "没有权限访问";
            status = 401;
        }

        response.setContentType("application/json;charset=utf-8");
        response.setStatus(status);
        response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");
    }
}

规则持久化

现在，Sentinel 的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。

规则是否能持久化，取决于规则管理模式，Sentinel 支持三种规则管理模式

  • 原始模式：Sentinel 的默认模式，将规则保存在内存，重启服务会丢失。

  • pull 模式

  • push 模式

pull模式

pull 模式：控制台将配置的规则推送到 Sentinel 客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。

分布式springcloud_第39张图片

push模式

push 模式：控制台将配置规则推送到远程配置中心，例如 Nacos，Sentinel 客户端监听 Nacos，获取配置变更的推送消息，完成本地配置更新。这种模式是比较好的一种。

分布式事务

概述

随着互联网的快速发展，软件系统由原来的单体应用转变为分布式应用，下图描述了单体应用向微服务的演变：

分布式springcloud_第40张图片

分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，例如用户注册送积分事务、创建订单减库存事务，银行转账事务等都是分布式事务。

在分布式环境下，如下场景：

begin transaction；
    //1.本地数据库操作：张三减少金额
    //2.远程调用：让李四增加金额
commit transation;

可以设想，当远程调用让李四增加金额成功了，由于网络问题远程调用并没有返回，此时本地事务提交失败就回滚了张三减少金额的操作，此时张三和李四的数据就不一致了。

分布式事务产生的场景

1、跨JVM进程产生分布式事务

典型的场景就是微服务架构：微服务之间通过远程调用完成事务操作。比如：订单微服务和库存微服务，下单的同时订单微服务请求库存微服务减少库存。

分布式springcloud_第41张图片

2、跨数据库实例产生分布式事务

单体系统访问多个数据库实例当单体系统需要访问多个数据库（实例）时就会产生分布式事务。比如：用户信息和订单信息分别在两个MySQL实例存储。

分布式springcloud_第42张图片

3、多服务访问同一个数据库实例

订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，原因就是跨JVM进程，两个微服务持有了不同的数据库链接进行数据库操作，此时产生分布式事务。

分布式springcloud_第43张图片

分布式事务基础理论

CAP理论

CAP 是 Consistency、Availability、Partition tolerance 三个单词的缩写，分别表示一致性、可用性、分区容忍性。

如下图，是商品信息管理的执行流程：

分布式springcloud_第44张图片

整体执行流程如下

  1. 商品服务请求主数据库写入商品信息（添加商品、修改商品、删除商品）

  2. 主数据库向商品服务响应写入成功

  3. 商品服务请求从数据库读取商品信息

C - Consistency

一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。

上图中，商品信息的读写要满足一致性就是要实现如下目标：

  1. 商品服务写入主数据库成功，则向从数据库查询新数据也成功。

  2. 商品服务写入主数据库失败，则向从数据库查询新数据也失败。

如何实现一致性？

  1. 写入主数据库后要将数据同步到从数据库。

  2. 写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功后，从数据库查询到旧的数据。

分布式系统一致性的特点：

  1. 由于存在数据同步的过程，写操作的响应会有一定的延迟。

  2. 为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。

  3. 对于请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据。

A - Availability

可用性是指任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。

上图中，商品信息读取满足可用性就是要实现如下目标：

  1. 从数据库接收到数据查询的请求则立即能够响应数据查询结果。

  2. 从数据库不允许出现响应超时或响应错误。

如何实现可用性

  1. 写入主数据库后要将数据同步到从数据库。

  2. 由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。

  3. 即时数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但不能返回错误或响应超时。

分布式系统可用性的特点：所有请求都有响应，且不会出现响应超时或响应错误

P - Partition tolerance

通常分布式系统的各个结点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致结点之间通信失败，此时仍可对外提供服务，这叫分区容忍性。

上图中，商品信息读写满足分区容忍性就是要实现如下目标：

  1. 主数据库向从数据库同步数据失败不影响读写操作。

  2. 其一个结点挂掉不影响另一个结点对外提供服务。

如何实现分区容忍性？

  1. 尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样结点之间能有效的实现松耦合。

  2. 添加从数据库结点，其中一个从结点挂掉其它从结点提供服务。

分布式分区容忍性的特点：分区容忍性分是分布式系统具备的基本能力

CAP 组合方式

在所有分布式事务场景中不会同时具备 CAP 三个特性，因为在具备了P的前提下C和A是不能共存的

分布式springcloud_第45张图片

满足分区容忍性，含义是：

  1. 主数据库通过网络向从数据库同步数据，可以认为主从数据库部署在不同的分区，通过网络进行交互。

  2. 当主数据库和从数据库之间的网络出现问题不影响主数据库和从数据库对外提供服务。

  3. 其中一个节点挂掉不影响另一个节点对外提供服务。

如果要实现 C 则必须保证数据一致性，在数据同步的时候为防止向从数据库查询不一致的数据则需要将从数据库数据锁定，待同步完成后解锁，如果同步失败从数据库要返回错误信息或超时信息。

如果要实现 A 则必须保证数据可用性，在主数据库向从数据库进行同步信息时不能加同步锁，不管任何时候都可以向从数据查询数据，则不会响应超时或返回错误信息。通过分析发现在满足P的前提下 C 和 A 存在矛盾性。

  1. AP 放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。 例如：上边的商品管理，完全可以实现 AP，前提是只要用户可以接受所查询到的数据在一定时间内不是最新的即可。 通常实现 AP 都会保证最终一致性，后面将的 BASE 理论就是根据 AP 来扩展的，一些业务场景比如：订单退款，今日退款成功，明日账户到账，只要用户可以接受在一定的时间内到账即可。

  2. CP 放弃可用性，追求一致性和分区容错性，zookeeper 其实就是追求的强一致，又比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。

  3. CA 放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统，最常用的关系型数据就满足了 CA。

CAP 是一个已经被证实的理论，一个分布式系统最多只能同时满足：一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证 P 和 A ，舍弃 C 强一致，保证最终一致性。

BASE 理论

强一致性和最终一致性

CAP 理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项，其中AP在实际应用中较多，AP 即舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，比如前边我们举的例子主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和 CAP 中的一致性不同，CAP 中的一致性要求 在任何时间查询每个结点数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内每个结点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。

Base 理论介绍

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent （最终一致性）三个短语的缩写。BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。

  1. 基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如电商网站交易付款出现问题了，商品依然可以正常浏览。

  2. 软状态：由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的"支付中"、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。

  3. 最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变 为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。

分布式事务解决方案 2PC

原理

针对不同的分布式场景业界常见的解决方案有 2PC、3PC、TCC、可靠消息最终一致性、最大努力通知这几种。

2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。

举例：张三和李四好久不见，老友约起聚餐，饭店老板要求先买单，才能出票。这时张三和李四分别抱怨近况不如意，囊中羞涩，都不愿意请客，这时只能AA。只有张三和李四都付款，老板才能出票安排就餐。但由于张三和李四都是铁公鸡，形成了尴尬的一幕：

准备阶段：老板要求张三付款，张三付款。老板要求李四付款，李四付款。

提交阶段：老板出票，两人拿票纷纷落座就餐。

例子中形成了一个事务，若张三或李四其中一人拒绝付款，或钱不够，店老板都不会给出票，并且会把已收款退回。

整个事务过程由事务管理器和参与者组成，店老板就是事务管理器，张三、李四就是事务参与者，事务管理器负责决策整个分布式事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚。

在计算机中部分关系数据库如 Oracle、MySQL 支持两阶段提交协议，如下图：

  1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送 Prepare 消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo 日志，此时事务没有提交。（Undo 日志是记录修改前的数据，用于数据库回滚，Redo 日志是记录修改后的数据，用于提交事务后写入数据文件）

  2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚（Rollback）消息；否则，发送提交（Commit）消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意：必须在最后阶段释放锁资源。

下图展示了2PC的两个阶段，分成功和失败两个情况说明：

成功情况

分布式springcloud_第46张图片

失败情况

分布式springcloud_第47张图片

解决方案

XA 方案

2PC 的传统方案是在数据库层面实现的，如 Oracle、MySQL 都支持 2PC 协议。国际开放标准组织 Open Group 定义了分布式事务处理模型 DTP。

以新用户注册送积分为例：

分布式springcloud_第48张图片

执行流程如下：

  1. 应用程序（AP）持有用户库和积分库两个数据源。

  2. 应用程序（AP）通过 TM 通知用户库 RM 新增用户，同时通知积分库RM为该用户新增积分，RM 此时并未提交事务，此时用户和积分资源锁定。

  3. TM 收到执行回复，只要有一方失败则分别向其他 RM 发起回滚事务，回滚完毕，资源锁释放。

  4. TM 收到执行回复，全部成功，此时向所有 RM 发起提交事务，提交完毕，资源锁释放。

DTP 模型定义如下角色：

  • AP（Application Program）：即应用程序，可以理解为使用 DTP 分布式事务的程序。

  • RM（Resource Manager）：即资源管理器，可以理解为事务的参与者，一般情况下是指一个数据库实例，通过资源管理器对该数据库进行控制，资源管理器控制着分支事务。

  • TM（Transaction Manager）：事务管理器，负责协调和管理事务，事务管理器控制着全局事务，管理事务生命周期，并协调各个 RM。全局事务是指分布式事务处理环境中，需要操作多个数据库共同完成一个工作，这个工作即是一个全局事务。

DTP 模型定义TM和RM之间通讯的接口规范叫 XA，简单理解为数据库提供的 2PC 接口协议，基于数据库的 XA 协议来实现 2PC 又称为 XA 方案

以上三个角色之间的交互方式如下：

  1. TM 向 AP 提供 应用程序编程接口，AP 通过 TM 提交及回滚事务。

  2. TM 交易中间件通过 XA 接口来通知 RM 数据库事务的开始、结束以及提交、回滚等。

总结

整个 2PC 的事务流程涉及到三个角色 AP、RM、TM。AP 指的是使用 2PC 分布式事务的应用程序；RM 指的是资源管理器，它控制着分支事务；TM 指的是事务管理器，它控制着整个全局事务。

（1）准备阶段： RM 执行实际的业务操作，但不提交事务，资源锁定

（2）提交阶段： TM 会接受 RM 在准备阶段的执行回复，只要有任一个RM执行失败，TM 会通知所有 RM 执行回滚操作，否则，TM 将会通知所有 RM 提交该事务。提交阶段结束资源锁释放。

XA方案的问题

  1. 需要本地数据库支持XA协议。

  2. 资源锁需要等到两个阶段结束才释放，性能较差。

Seata 方案

Seata 是由阿里中间件团队发起的开源项目 Fescar，后更名为 Seata，它是一个开源的分布式事务框架。

传统 2PC 的问题在 Seata 中得到了解决，它通过对本地关系数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务 0 侵入的方式解决微服务场景下面临的分布式事务问题，它目前提供 AT 模式（即 2PC）及 TCC 模式的分布式事务解决方案。

Seata 的设计思想如下：

Seata 把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务，下图是全局事务与分支事务的关系图：

分布式springcloud_第49张图片

与传统 2PC 的模型类似，Seata 定义了 3 个组件来协议分布式事务的处理过程：

  • Transaction Coordinator（TC）：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收 TM 指令发起全局事务的提交与回滚，负责与 RM 通信协调各各分支事务的提交或回滚。

  • Transaction Manager（TM）： 事务管理器，TM 需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向 TC 发起全局提交或全局回滚的指令。

  • Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器 TC 的指令，驱动分支（本地）事务的提交和回滚。

Seata实现2PC与传统2PC的差别：

架构层次方面：传统 2PC 方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身，通过 XA 协议实现，而 Seata 的 RM 是以 jar 包的形式作为中间件层部署在应用程序这一侧的。

两阶段提交方面：传统 2PC无论第二阶段的决议是 commit 还是 rollback ，事务性资源的锁都要保持到 Phase2 完成才释放。而 Seata 的做法是在 Phase1 就将本地事务提交，这样就可以省去 Phase2 持锁的时间，整体提高效率。

小结

对于传统 2PC（基于数据库 XA 协议）和 Seata 实现 2PC 的两种方案，于 Seata 的 0 侵入性并且解决了传统 2PC 长期锁资源的问题，推荐采用 Seata 实现 2PC。

分布式事务解决方案 TCC

原理

TCC 是 Try、Confirm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm、撤销 Cancel。Try 操作做业务检查及资源预留，Confirm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。

TM 首先发起所有的分支事务的 Try 操作，任何一个分支事务的Try操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 Try 操作全部成功，TM 将会发起所有分支事务的 Confirm 操作，其中 Confirm/Cancel 操作若执行失败，TM 会进行重试。

TCC 分为三个阶段：

  1. Try 阶段是做完业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的 Confirm 一起才能真正构成一个完整的业务逻辑。

  2. Confirm 阶段是做确认提交，Try 阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用 TCC 则认为 Confirm 阶段是不会出错的。即：只要 Try 成功，Confirm 一定成功。若 Confirm 阶段真的出错了，需引入重试机制或人工处理。

  3. Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用 TCC 则认为 Cancel 阶段也是一定成功的。若 Cancel 阶段真的出错了，需引入重试机制或人工处理。

TCC 异常处理

TCC需要注意三种异常处理分别是空回滚、幂等、悬挂

空回滚

在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，直接返回成功。

出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行 Try 阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的 Cancel 方法，从而形成空回滚。

解决思路的关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。

前面已经说过 TM 在发起全局事务时生成全局事务记录，全局事务 ID 贯穿整个分布式事务调用链条。再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。

幂等

通过前面介绍已经了解到，为了保证 TCC 二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。

对于同一个业务操作，无论执行多少次，最终的结果都是一样的。

解决思路在上述"分支事务记录"中增加执行状态，每次执行前都查询该状态。(类似redo日志？)

悬挂

悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行，导致 Try 执行后预留的业务资源无法被继续处理。

出现原因是在 RPC 调用分支事务 Try 时，先注册分支事务，再执行 RPC 调用，如果此时 RPC 调用的网络发生拥堵，通常 RPC 调用是有超时时间的，RPC 超时以后，TM 就会通知 RM 回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者真正执行，而一个 Try 方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。

解决思路是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，"分支事务记录"表中是否已经有二阶段事务记录，如果有则不执行 Try。

RPC是远程过程调用（Remote Procedure Call）的缩写形式

小结

如果拿 TCC 事务的处理流程与 2PC 两阶段提交做比较，2PC 通常都是在跨库的 DB 层面，而 TCC 则在应用层面的处理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使得降低锁冲突、提高吞吐量成为可能。

而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现 Try、Confirm、Cancel 三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。

分布式事务解决方案 可靠消息最终一致性

原理

可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方（消息消费者）一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。

可靠消息最终一致性方案要解决以下几个问题：

1、本地事务与消息发送的原子性问题 本地事务与消息发送的原子性问题即：事务发起方在本地事务执行成功后消息必须发出去，否则就丢弃消息。即实现本地事务和消息发送的原子性，要么都成功，要么都失败。

2、事务参与方接收消息的可靠性

事务参与方必须能够从消息队列接收到消息，如果接收消息失败可以重复接收消息。

3、消息重复消费的问题

由于网络2的存在，若某一个消费节点超时但是消费成功，此时消息中间件会重复投递此消息，就导致了消息的重复消费。

解决方案

本地消息表

通过本地事务保证数据业务操作和消息的一致性，然后通过定时任务将消息发送至消息中间件，待确认消息发送给消费方成功再将消息删除。

本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。核心思想是将分布式事务拆分成本地事务进行处理。

本地消息表顾名思义就是会有一张存放本地消息的表，一般都是放在数据库中，然后在执行业务的时候 将业务的执行和将消息放入消息表中的操作放在同一个事务中，这样就能保证消息放入本地表中业务肯定是执行成功的。

  1. 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。

  2. 之后将本地消息表中的消息转发到消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。

  3. 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。

优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。在 .NET中 有现成的解决方案。

缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

小结

可靠消息最终一致性就是保证消息从生产方经过消息中间件传递到消费方的一致性：

  1. 本地事务与消息发送的原子性问题。

  2. 事务参与方接收消息的可靠性。

可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。

分布式事务解决方案 最大努力通知

原理

以充值为例

分布式springcloud_第50张图片

  1. 账户系统调用充值系统接口

  2. 充值系统完成支付处理向账户发起充值结果通知，若通知失败，则充值系统按策略进行重复通知

  3. 账户系统接收到充值结果通知修改充值状态

  4. 账户系统未接收到通知会主动调用充值系统的接口查询充值结果

最大努力通知方案的目标：发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。

具体包括：

  1. 有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知

  2. 消息校对机制。如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。

最大努力通知与可靠消息一致性有什么不同？

  1. 解决方案思想不同 可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接 收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。

  2. 两者的业务应用场景不同 可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易。最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。

  3. 技术解决方向不同 可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到。最大努力通知无法保证消息从发出到接收的一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力的将消息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）

解决方案

消息队列的 ack 机制

采用 MQ 的 ack 机制就可以实现最大努力通知。

方案1：

  1. 发起方将通知发给 MQ。使用普通消息机制将通知发给MQ。 注意：如果消息没有发出去可由接收方主动请求发起通知方查询业务执行结果。（后边会讲）

  2. 接收方监听 MQ。

  3. 接收方接收消息，业务处理完成回应 ack。

  4. 接收方若没有回应 ack 则 MQ 会重复通知。 MQ会按照间隔 1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔，直到达到通知要求的时间窗口上限。

  5. 接收方可通过消息校对接口来校对消息的一致性。

方案 2：

  1. 发起通知方将消息发给 MQ。

  2. 通知程序监听 MQ，接收 MQ 的消息。

    方案 1 中接收通知方直接监听 MQ，方案 2 中由通知程序监听 MQ。通知程序若没有回应 ack 则 MQ 会重复通知。

  3. 通知程序通过互联网接口协议（如 http、webservice）调用接收通知方案接口，完成通知。

  4. 接收通知方可通过消息校对接口来校对消息的一致性。

方案1和方案2的不同点：

  1. 方案 1 中接收方监听 MQ，此方案主要应用与内部应用之间的通知。

  2. 方案 2 中由通知程序监听 MQ，收到 MQ 的消息后由通知程序通过互联网接口协议调用接收方。此方案主要应用于外部应用之间的通知，例如支付宝、微信的支付结果通知。

小结

2PC：最大的诟病是一个阻塞协议。这种设计不能适应随着事务涉及的服务数量增加而扩展的需要，很难用于并发较高以及子事务生命周期较长 的分布式服务中。

TCC：典型的使用场景：满减，登录送优惠券等。

可靠消息最终一致性：典型的使用场景：注册送积分，登录送优惠券等。

最大努力通知：典型的使用场景：银行通知、支付结果通知等。

分布式springcloud_第51张图片

参考资料：

  • SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务_哔哩哔哩_bilibili

  • 微服务技术栈 - 乐心湖's Blog | 技术小白的技术博客

  • 分布式事务有这一篇就够了！ - 知乎

Redis 分布式缓存

Redis 支持三种集群方案

  • 主从复制模式

  • Sentinel（哨兵）模式

  • Cluster 模式

主从复制原理

基本原理

主从复制模式中包含一个主数据库实例（master）与一个或多个从数据库实例（slave）

分布式springcloud_第52张图片

客户端可对主数据库进行读写操作，对从数据库进行读操作，主数据库写入的数据会实时自动同步给从数据库。

具体工作机制为：

  • slave启动后，向master发送SYNC命令，master接收到SYNC命令后通过bgsave保存快照，并使用缓冲区记录保存快照这段时间内执行的写命令

  • master将保存的快照文件发送给slave，并继续记录执行的写命令

  • slave接收到快照文件后，加载快照文件，载入数据

  • master快照发送完后开始向slave发送缓冲区的写命令，slave接收命令并执行，完成复制初始化

  • 此后master每次执行一个写命令都会同步发送给slave，保持master与slave之间数据的一致性

优缺点

优点：

  • master能自动将数据同步到slave，可以进行读写分离，分担master的读压力

  • master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求

缺点：

  • 不具备自动容错与恢复功能，master或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复

  • master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题

  • 难以支持在线扩容，Redis的容量受限于单机配置

Sentinel（哨兵）模式

基本原理

哨兵模式基于主从复制模式，只是引入了哨兵来监控与自动处理故障

分布式springcloud_第53张图片

哨兵顾名思义，就是来为Redis集群站哨的，一旦发现问题能做出相应的应对处理。其功能包括

  • 监控master、slave是否正常运行

  • 当master出现故障时，能自动将一个slave转换为master

  • 多个哨兵可以监控同一个Redis，哨兵之间也会自动监控

当 master 宕机时，有如下动作

  • 将宕机的master下线

  • 找一个slave作为master

  • 通知所有的slave连接新的master

  • 全量数据或者部分数据同步

Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务，以及这些主服务器属下的所有从服务，并在被监视的主服务进入下线（不可服务）状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

哨兵作用

  • 集群监控

  • 消息通知

  • 自动故障转移

注意：哨兵也是一台Redis服务器，只是不提供数据服务，通常哨兵配置的数量为单数。

集群监控

1、哨兵 1 连接到 Redis 集群

  • 发送info命令到master，并建立cmd连接；

  • 哨兵端保存哨兵状态（SentinelStatus），保存所有哨兵状态，主节点和从节点的信息；master端会记录 redis 实例的信息（SentinelRedisInstance）；

  • 哨兵根据master中获取的每个slave信息，去连接每个slave，发送同样也是info命令。

2、其他哨兵连接到 Redis 集群

  • 发送info命令到master节点，并建立cmd连接；

  • 发现master中存在其他哨兵节点的信息，新加入的哨兵将会保存其他哨兵信息

  • 为了每个哨兵的信息都一致它们之间建立了一个发布订阅。为了哨兵之间的信息长期对称它们之间也会互发 ping 命令。

  • Sentinel会向master、slave以及其他Sentinel获取状态

  • Sentinel之间会组建“对应频道”，大家一起发布信息、订阅信息、收信息、同步信息等。

消息通知

1）Sentinel节点会通过master/slave 节点建立的cmd连接获取其工作状态

2）Sentinel收到反馈结果之后，会在哨兵内部进行信息的互通

分布式springcloud_第54张图片

故障转移

关于故障转移，严格来讲可划分两个步骤：故障判定、故障转移。

Q1：如何判断一个节点出现故障？

  • 哨兵会一直给主节点发送 publish sentinel：hello

直到主节点故障，哨兵报出 sdown，同时此哨兵还会向其他哨兵发布消息说这个主节点挂了。发送的指令是 sentinel is-master-down-by-address-port。

  • 其余的哨兵接收到指令后，主节点挂了吗？让我去看看到底挂没挂。发送的信息也是 hello。

其余的哨兵也会发送他们收到的信息并且发送指令 sentinel is-master-down-by-address-port 到自己的内网，确认一下第一个发送 sentinel is-master-down-by-address-port 的哨兵说你说的对，这个家伙确实挂了。

  • 当所有人都认为主节点挂了后就会修改其状态为 odown。

当一个哨兵认为主节点挂了标记的是 sdown，当半数哨兵都认为挂了其标记的状态是 odown。

一个哨兵认为master节点挂了称为主观下线（sdown），超半数哨兵认为master节点挂了则称为客观下线（odown）。

Q2：如何进行故障转移？

1）首先，哨兵选举出哨兵Leader去处理故障转移

2）其次，哨兵Leader从所有的slave节点找出一个作为master节点

主要的规则：

  • 选择在线的节点，pass掉已下线的节点；

  • 选择响应速度快的，pass掉响应慢的节点

  • 选择与原master断开时间短的，pass掉断开时间较长的；

假如以上优先级均一致，会考虑其他优先原则：

  • 偏移量较大

假如说 slave1 的 offset 为 50，slave2 偏移量为 55，则哨兵就会选择 slave2 为新的主节点。

  • runid偏大的

这点类似于职场中的论资排辈，也就说根据 runid 的创建时间来判断，时间早的先上位。

3）数据转移

  • 新master上任：Sentinel向新的master发送slaveof no one

  • 其他slave周知：向其他slave发送slaveof 新master IP端口

优缺点

优点：

  • 哨兵模式基于主从复制模式，所以主从复制模式有的优点，哨兵模式也有

  • 哨兵模式下，master挂掉可以自动进行切换，系统可用性更高

缺点：

  • 同样也继承了主从模式难以在线扩容的缺点，Redis的容量受限于单机配置

  • 需要额外的资源来启动sentinel进程，实现相对复杂一点，同时slave节点作为备份节点不提供服务

Cluster模式

基本原理

Redis哨兵模式实现了高可用，读写分离，但是其主节点仍然只有一个，即写入操作都是在主节点中，这也成为了性能的瓶颈。存在难以扩容，Redis容量受限于单机配置的问题。Cluster模式实现了Redis的分布式存储，即每台节点存储不同的内容，来解决在线扩容的问题。

分布式springcloud_第55张图片

Cluster采用无中心结构,它的特点如下：

  • 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽

  • 节点的fail是通过集群中超过半数的节点检测失效时才生效

  • 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

  • 相比较sentinel模式，多个master节点保证主要业务（比如master节点主要负责写）稳定性，不需要搭建多个sentinel实例监控一个master节点；

  • 相比较一主多从的模式，不需要手动切换，具有自我故障检测，故障转移的特点；

  • 相比较其他两个模式而言，对数据进行分片（sharding），不同节点存储的数据是不一样的；

  • 从某种程度上来说，Sentinel模式主要针对高可用（HA），而Cluster模式是不仅针对大数据量，高并发，同时也支持HA。

Cluster模式的具体工作机制：

  • 在Redis的每个节点上，都有一个插槽（slot），取值范围为0-16383（不是一致性哈希）

  • 当我们存取key的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的主节点，然后进行存取操作

    CRC16是CRC算法中常用的一种，使用16位的二进制多项式进行除法。

  • 为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点

  • 当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了

Redis Cluser是如何保证高可用

Redis Cluster保证高可用主要还是依靠：故障检测与故障转移两种策略

故障转移

举例说明：包含7000、7001、7002、7003四个主节点的集群，我们此时加入7004、7005两个节点，并当做7000的主节点的两个从节点。

分布式springcloud_第56张图片

如果此时主节点7000下线（宕机），则 7000 的从节点将从他们中间选择一个作为主节点，用来处理客户端的读写请求。如下，7004 作为主节点，7005 作为了 7004 的从节点

分布式springcloud_第57张图片

若 7000 再次上线，则他将作为 7004 的从节点

分布式springcloud_第58张图片

当一个从节点发现自己正在复制的主节点下线时，从节点将开始对下线主节点进行故障转移：

　　1） 在该下线主节点的所有从节点中，选择一个做主节点

　　2） 被选中的从节点会执行SLAVEOF no one命令，成为新的主节点；

　　3） 新的主节点会撤销对所有对已下线主节点的槽指派，并将这些槽全部派给自己。

　　4） 新的主节点向集群广播一条PONG消息，让其他节点知道“我已经变成主节点了，并且我会接管已下线节点负责的处理的槽”；

　　5） 新主节点开始接收和自己负责处理的槽有关的命令请求，故障转移完成。

选举新的主节点步骤：

　　1）集群里的每个负责处理槽的主节点都有一次投票的机会，而第一个向主节点要求投票的从节点将获得主节点的投票。

　　2）当从节点发现自己正在复制的主节点进入已下线状态时，从节点会向集群广播消息：要求所有收到这条消息、并且具有投票权的主节点向这个从节点投票。如果一个主节点具有投票权，并且这个主节点尚未投票跟其它从节点，则返回给从节点 ACK 消息，表示投票给该从节点

　　3）每个主节点只有一次投票机会，所有有N个主节点的话，那么具有大于N/2+1张支持票的从节点只有一个，成为新的主节点

　　4）如果在一个配置纪元里没有从节点能收集到足够多的支持票，那么集群进入一个新的配置纪元，并再次进行选举，直到选出新的主节点为止。

故障检测

集群中每个节点都会定期地向集群中的其他节点发送PING消息，以此检测对方是否在线；如果接收PING消息的节点没有在规定的时间内，向发送PING消息的节点返回PONG消息，那么发送PING消息的节点就会将PING消息节点标记为疑似下线（possible fail，PFAIL）。

如果在集群中，超过半数以上负责处理槽的主节点都将某个节点X标记为PFAIL，则某个主节点就会将这个主节点X就会被标记为已下线（FAIL），并且广播到这条消息，这样其他所有的节点都会立即将主节点X标记为FAIL。

分布式锁

基本介绍

一个应用被部署到多个机器上做负载均衡。为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，我们该如何解决这个问题呢？

分布式springcloud_第59张图片

在传统单体应用单机部署的情况下，可以使用并发处理相关的功能（如Java并发处理相关的API：ReentrantLcok或synchronized）进行互斥控制来解决。但是，随着业务的发展，系统架构也会逐步优化升级，原本单体单机部署的系统被演化成分布式集群系统，由于分布式系统多线程、多进程并且分布在多个不同机器上，这将使原单机部署情况下的并发控制锁策略无法满足，并不能提供分布式锁的能力。为了解决这个问题就需要一种跨机器的互斥机制来控制共享资源的访问，需要使用分布式锁。

1、处理效率提升：应用分布式锁，可以减少重复任务的执行，避免资源处理效率的浪费；

2、数据准确性保障：使用分布式锁可以放在数据资源的并发访问，避免数据不一致情况，甚至数据损失等。

实现方式

关于分布式锁的实现，可以分别控制在不同的环节。

分布式springcloud_第60张图片

1、开源组件锁控制：ZooKeeper

ZooKeeper 是一个分布式协调服务的开源框架。主要用来解决分布式集群中应用系统的一致性的问题，例如怎样避免同时操作同一数据造成脏读的问题。ZooKeeper 本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。

分布式springcloud_第61张图片

1、客户端获取锁时，在 lock 节点（节点名可自定义）下创建临时顺序节点。

2、客户端获取到 lock 节点下的所有子节点，判断自己创建的临时顺序节点的序号是否最小，若是，则表示此客户端获取到了该锁。使用完后将其删除。

3、若发现自己创建的临时顺序节点序号不是最小，则说明未获取到锁，此时客户端监听比自己小的节点，对其注册事件监听器，监听删除事件。

4、若发现比自己小的节点被删除，则 Watcher 会受到相应通知，再次判断临时顺序节点的序号是否最小，根据上面的规则获取锁。

以上步骤中，应该注意的是，对于监听节点来说，当最小节点被删除后，之后监听该节点的 Watcher 会受到相应通知，其余不会收到通知。例如上图中，/lock/2 监听 /lock/1，当 /lock/1 删除后，/lock/3 不会收到通知。

ZooKeeper分布式锁方式，性能相对Redis方式较差，主要原因是写操作（获取锁释放锁）都需要在Leader上执行，然后同步到follower。

2、任务处理锁控制：Redis

优势：

  • 性能极高 – Redis能读的速度是11w+次/s,写的速度是8w+次/s

  • 丰富的数据类型 – Redis主要支持 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型

  • 原子性 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行

  • 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

Redis实现简单分布式锁过程：

（1）获取锁：使用 setnx 加锁，并使用 expire 命令为锁添加一个超时时间，超过该时间则自动释放锁，通常 value 为一个随机生成的UUID，通过此在释放锁的时候进行判断。若未获取到锁，设置一个获取的超时时间，若超过这个时间则放弃获取锁。

SETNX key value // 并没有设置过期时间
set key val EX 过期时间(秒) nx

当且仅当 key 不存在时，将 key 的值设为 value。

返回整数，具体为

  • - 1，当 key 的值被设置

  • - 0，当 key 的值没被设置

多个进程执行以下Redis命令：

SETNX lock.foo

  • 如果 SETNX 返回1，说明该进程获得锁，SETNX将键 lock.foo 的值设置为锁的超时时间（当前时间 + 锁的有效时间）。

  • 如果 SETNX 返回0，说明其他进程已经获得了锁，进程不能进入临界区。进程可以在一个循环中不断地尝试 SETNX 操作，以获得锁。

（2）释放锁：通过UUID（通用唯一识别码（Universally Unique Identifier））判断是不是该锁，若是该锁，则执行delete进行锁释放。

利用Redis实现分布式锁，实现可能存在的缺点：

1、redis 过期时间问题：在执行delete进行释放锁的时候，假如操作删除锁动作失败，那此 Key-Value 过期时间则不好控制，可能会一直存在，可能对后续数据验证造成影响。

2、使用 set 设置 key - value 和过期时间应为原子操作，这个可以使用 set key value Ex 过期时间 nx 解决

3、当需要删除 key 时，由于 value 为 uuid，因此先对比是否为本线程加的锁，即对比 get 到的 uuid，是否相同，但是仍然存在问题，例如 redis 中的过期时间为 10s，业务代码执行了 9.5s，当从 redis 中 get 到本线程 uuid 后，花费 0.5s，那么此时 redis 将自动删除 key，之后若其他线程将 key - value 存入，此时第一个线程将会执行 delete 删除 key，那么删除了第二个线程 key - value，出现错误。这需要 get 和 delete 为原子操作，需要使用 lua 脚本进行原子解锁，参考官网文档，如下：

String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
// 原子解锁
stringRedisTemplate.execute(new DefaultRedisScript(script, Long.class), Arrays.asList("lock"), uuid);

上面由自己实现貌似有点麻烦，因此可使用 Redission 在 Redis 的基础上实现 Java 内存数据网络，提供分布式服务，提供 Redis 的分布式锁。也就是说，使用 Redission 实现 Redis 分布式锁的控制。参考 https://github.com/redisson/redisson

分布式springcloud_第62张图片

Redission 如何实现 Redis 分布式锁

Redission 的 Lock 方法

Redission 的加锁方法 lock 继承了 juc 包下的 Lock，因此使用和可重入锁 ReentrantLock 相同，Redission 的 getLock("锁的名字") 进行分布式并发控制，这里锁的名字可以用来控制锁的粒度。

Redission 使用看门狗实现了锁的自动续期，因为 Redission 基于 Redis 的 setnx 实现，将此线程的 key - value 存入到 redis 中，若业务代码执行时间较长，则会默认更新 TTL 为 30s，即使在业务代码程序崩溃，没有手动解锁，也会由于超时时间（默认 30s）redis 自动删除 key，不会出现死锁问题。

当然我们也可使用 redission.lock(10, TimeUnit.SECONDS) 来自己指定时间，但是这种需要注意，这种方式 Redission 不会自动对 TTL 进行续期，也就是说，指定的时间必须大于业务方法的执行时间。

通常我们使用指定时间的方式加锁和手动解锁来显式控制。

Redission 的信号量

在 juc 包下，有信号量 Semaphore，因此 Redission 也有信号量的方法 getSemaphore("这个 Semaphore 的名称")，和 juc 包下的 Semaphore 相同，用来限流。

Redission 的 CountDownLatch

在 Redisssion 中，和 juc 相同的 CountDownLatch 为 getCountDownLatch("这个CountDownLatch 的名称")

注意，这些分布式并发锁都是基于 Redis 实现的，将特定的 key-val 存入到 Redis 中用来控制并发过程。

3、数据写入锁控制：MySQL

数据库层面是最终数据写入的时候，对数据做写入控制处理，算是分布式锁的最终末端环节。

实现方式一：唯一索引

UNIQUE KEY `uidx_name` (`name`) USING BTREE；

上述case中，我们对 name 字段做了索引的唯一性约束，当存在多个新增数据请求同时提交到数据库的话，数据库自身则会利用唯一索引，来保证数据的唯一性。

实现方式二：排他锁

执行以下SQL：

SELECT status FROM users WHERE id = 3 FOR UPDATE；

假如，在另一个事务中再次执行：

SELECT status FROM users WHERE id = 3 FOR UPDATE；

则第二个事务会一直等待上一个事务的提交，此时第二个查询处于阻塞的状态。

排它锁的应用：

在进行事务操作时，通过 “FOR UPDATE” 语句，MySQL会对查询结果集中每行数据都添加排他锁，其他线程对该记录的更新与删除操作都会阻塞。排他锁包含行锁、表锁。

实现方式三：乐观锁

实现逻辑：乐观锁每次在执行数据修改操作时，都会带上一个数据版本号，一旦版本号和数据的版本号一致就可以执行修改操作并对版本号执行+1 操作，否则就执行失败。因为每次操作的版本号都会随之增加，所以不会出现 ABA 问题。

除了 version 以外，还可以使用时间戳，因为时间戳天然具有顺序递增性。

比较麻烦的一点：就是在操作业务前，需要先查询出当前的 version 版本。

数据库分布式锁实现可能存在的缺点：

  • DB操作性能较差，并且有锁表的风险；

  • 非阻塞操作失败后，需要轮询，占用cpu资源;

  • 长时间不commit或者长时间轮询，可能会占用较多连接资源

比较

  1. 理解的难易程度 数据库 > Redis > Zookeeper

  2. 实现的复杂程度 Zookeeper >= Redis > 数据库

  3. 性能高低 Redis > Zookeeper > 数据库

  4. 可靠性 Zookeeper > Redis > 数据库

分布式 Session

参考 https://www.cnblogs.com/study-everyday/p/7853145.html

分布式 Session 存在的问题

单服务器web应用中，session信息只需存在该服务器中，因此单个服务下服务器可在一次会话中获得 session 存储的内容，但是在分布式场景中，可能存在通过负载均衡方式路由到不同的服务器中，那么就存在 session 存储在其中某一台服务器而其他服务器不知道该 session 的情况。存在 session 一致性的问题。

分布式springcloud_第63张图片

Session 一致性的解决方案

1、Session 复制（同步）

分布式springcloud_第64张图片

思路：多个web-server之间相互同步session，这样每个web-server之间都包含全部的session

优点：web-server支持的功能，应用程序不需要修改代码

不足：

  • session的同步需要数据传输，占内网带宽，有时延

  • 所有web-server都包含所有session数据，数据量受内存限制，无法水平扩展

2、客户端存储

分布式springcloud_第65张图片

思路：服务端存储所有用户的 session，内存占用较大，可以将session存储到浏览器cookie中，每个端只要存储一个用户的数据了

优点：服务端不需要存储

缺点：

  • 每次http请求都携带session，占外网带宽

  • 数据存储在端上，并在网络传输，存在泄漏、篡改、窃取等安全隐患

  • session存储的数据大小受cookie限制

“端存储”的方案虽然不常用，但确实是一种思路。

3、反向代理 hash

分布式springcloud_第66张图片

思路：web-server为了保证高可用，有多台冗余，反向代理服务器通过一些策略让 同一个用户的请求保证落在一台web-server

有如下方案：

方案一：四层代理 hash

反向代理层使用用户ip来做hash，以保证同一个ip的请求落在同一个web-server上

方案二：七层代理 hash

反向代理使用http协议中的某些业务属性来做hash，例如sid，city_id，user_id等，能够更加灵活的实施hash策略，以保证同一个浏览器用户的请求落在同一个web-server上

优点：

  • 只需要改nginx配置，不需要修改应用代码

  • 负载均衡，只要hash属性是均匀的，多台web-server的负载是均衡的

  • 可以支持web-server水平扩展（session同步法是不行的，受内存限制）

不足：

  • 如果web-server重启，一部分session会丢失，产生业务影响，例如部分用户重新登录

  • 如果web-server水平扩展，rehash后session重新分布，也会有一部分用户路由不到正确的session

4、后端统一集中存储

分布式springcloud_第67张图片

思路：将session存储在web-server后端的存储层，数据库或者缓存

优点：

  • 没有安全隐患

  • 可以水平扩展，数据库/缓存水平切分即可

  • web-server重启或者扩容都不会有session丢失

不足：增加了一次网络调用，并且需要修改应用代码

对于db存储还是cache，个人推荐后者：session读取的频率会很高，数据库压力会比较大。如果有session高可用需求，cache可以做高可用，但大部分情况下session可以丢失，一般也不需要考虑高可用。

Docker实用篇

1.初识Docker

1.1.什么是Docker

微服务虽然具备各种各样的优势，但服务的拆分通用给部署带来了很大的麻烦。

  • 分布式系统中，依赖的组件非常多，不同组件之间部署时往往会产生一些冲突。

  • 在数百上千台服务中重复部署，环境不一定一致，会遇到各种问题

1.1.1.应用部署的环境问题

大型项目组件较多，运行环境也较为复杂，部署时会碰到一些问题：

  • 依赖关系复杂，容易出现兼容性问题

  • 开发、测试、生产环境有差异

分布式springcloud_第68张图片

例如一个项目中，部署时需要依赖于node.js、Redis、RabbitMQ、MySQL等，这些服务部署时所需要的函数库、依赖项各不相同，甚至会有冲突。给部署带来了极大的困难。

1.1.2.Docker解决依赖兼容问题

而Docker确巧妙的解决了这些问题，Docker是如何实现的呢？

Docker为了解决依赖的兼容问题的，采用了两个手段：

  • 将应用的Libs（函数库）、Deps（依赖）、配置与应用一起打包

  • 将每个应用放到一个隔离容器去运行，避免互相干扰

分布式springcloud_第69张图片

这样打包好的应用包中，既包含应用本身，也保护应用所需要的Libs、Deps，无需再操作系统上安装这些，自然就不存在不同应用之间的兼容问题了。

虽然解决了不同应用的兼容问题，但是开发、测试等环境会存在差异，操作系统版本也会有差异，怎么解决这些问题呢？

1.1.3.Docker解决操作系统环境差异

要解决不同操作系统环境差异问题，必须先了解操作系统结构。以一个Ubuntu操作系统为例，结构如下：

分布式springcloud_第70张图片

结构包括：

  • 计算机硬件：例如CPU、内存、磁盘等

  • 系统内核：所有Linux发行版的内核都是Linux，例如CentOS、Ubuntu、Fedora等。内核可以与计算机硬件交互，对外提供内核指令，用于操作计算机硬件。

  • 系统应用：操作系统本身提供的应用、函数库。这些函数库是对内核指令的封装，使用更加方便。

应用于计算机交互的流程如下：

1）应用调用操作系统应用（函数库），实现各种功能

2）系统函数库是对内核指令集的封装，会调用内核指令

3）内核指令操作计算机硬件

Ubuntu和CentOSpringBoot都是基于Linux内核，无非是系统应用不同，提供的函数库有差异：

分布式springcloud_第71张图片

此时，如果将一个Ubuntu版本的MySQL应用安装到CentOS系统，MySQL在调用Ubuntu函数库时，会发现找不到或者不匹配，就会报错了：

分布式springcloud_第72张图片

Docker如何解决不同系统环境的问题？

  • Docker将用户程序与所需要调用的系统(比如Ubuntu)函数库一起打包

  • Docker运行到不同操作系统时，直接基于打包的函数库，借助于操作系统的Linux内核来运行

如图：

分布式springcloud_第73张图片

1.1.4.小结

Docker如何解决大型项目依赖关系复杂，不同组件依赖的兼容性问题？

  • Docker允许开发中将应用、依赖、函数库、配置一起打包，形成可移植镜像

  • Docker应用运行在容器中，使用沙箱机制，相互隔离

Docker如何解决开发、测试、生产环境有差异的问题？

  • Docker镜像中包含完整运行环境，包括系统函数库，仅依赖系统的Linux内核，因此可以在任意Linux操作系统上运行

Docker是一个快速交付应用、运行应用的技术，具备下列优势：

  • 可以将程序及其依赖、运行环境一起打包为一个镜像，可以迁移到任意Linux操作系统

  • 运行时利用沙箱机制形成隔离容器，各个应用互不干扰

  • 启动、移除都可以通过一行命令完成，方便快捷

1.2.Docker和虚拟机的区别

Docker可以让一个应用在任何操作系统中非常方便的运行。而以前我们接触的虚拟机，也能在一个操作系统中，运行另外一个操作系统，保护系统中的任何应用。

两者有什么差异呢？

虚拟机（virtual machine）是在操作系统中模拟硬件设备，然后运行另一个操作系统，比如在 Windows 系统里面运行 Ubuntu 系统，这样就可以运行任意的Ubuntu应用了。

Docker仅仅是封装函数库，并没有模拟完整的操作系统，如图：

分布式springcloud_第74张图片

对比来看：

分布式springcloud_第75张图片

小结：

Docker和虚拟机的差异：

  • docker是一个系统进程；虚拟机是在操作系统中的操作系统

  • docker体积小、启动速度快、性能好；虚拟机体积大、启动速度慢、性能一般

1.3.Docker架构

1.3.1.镜像和容器

Docker中有几个重要的概念：

镜像（Image）：Docker将应用程序及其所需的依赖、函数库、环境、配置等文件打包在一起，称为镜像。

容器（Container）：镜像中的应用程序运行后形成的进程就是容器，只是Docker会给容器进程做隔离，对外不可见。

一切应用最终都是代码组成，都是硬盘中的一个个的字节形成的文件。只有运行时，才会加载到内存，形成进程。

而镜像，就是把一个应用在硬盘上的文件、及其运行环境、部分系统函数库文件一起打包形成的文件包。这个文件包是只读的。

容器呢，就是将这些文件中编写的程序、函数加载到内存中允许，形成进程，只不过要隔离起来。因此一个镜像可以启动多次，形成多个容器进程。

分布式springcloud_第76张图片

例如你下载了一个QQ，如果我们将QQ在磁盘上的运行文件及其运行的操作系统依赖打包，形成QQ镜像。然后你可以启动多次，双开、甚至三开QQ，跟多个妹子聊天。

1.3.2.DockerHub

开源应用程序非常多，打包这些应用往往是重复的劳动。为了避免这些重复劳动，人们就会将自己打包的应用镜像，例如Redis、MySQL镜像放到网络上，共享使用，就像GitHub的代码共享一样。

  • DockerHub：DockerHub是一个官方的Docker镜像的托管平台。这样的平台称为Docker Registry。

  • 国内也有类似于DockerHub 的公开服务，比如 网易云镜像服务、阿里云镜像库等。

我们一方面可以将自己的镜像共享到DockerHub，另一方面也可以从DockerHub拉取镜像：

分布式springcloud_第77张图片

1.3.3.Docker架构

我们要使用Docker来操作镜像、容器，就必须要安装Docker。

Docker是一个CS架构的程序，由两部分组成：

  • 服务端(server)：Docker守护进程，负责处理Docker指令，管理镜像、容器等

  • 客户端(client)：通过命令或RestAPI向Docker服务端发送指令。可以在本地或远程向服务端发送指令。

如图：

分布式springcloud_第78张图片

1.3.4.小结

镜像：

  • 将应用程序及其依赖、环境、配置打包在一起

容器：

  • 镜像运行起来就是容器，一个镜像可以运行多个容器

Docker结构：

  • 服务端：接收命令或远程请求，操作镜像或容器

  • 客户端：发送命令或者请求到Docker服务端

DockerHub：

  • 一个镜像托管的服务器，类似的还有阿里云镜像服务，统称为DockerRegistry

1.4.安装Docker

企业部署一般都是采用Linux操作系统，而其中又数CentOS发行版占比最多，因此我们在CentOS下安装Docker。参考课前资料中的文档：

分布式springcloud_第79张图片

2.Docker的基本操作

2.1.镜像操作

2.1.1.镜像名称

首先来看下镜像的名称组成：

  • 镜名称一般分两部分组成：[repository]:[tag]。

  • 在没有指定tag时，默认是latest，代表最新版本的镜像

如图：

分布式springcloud_第80张图片

这里的mysql就是repository，5.7就是tag，合一起就是镜像名称，代表5.7版本的MySQL镜像。

2.1.2.镜像命令

常见的镜像操作命令如图：

分布式springcloud_第81张图片

2.1.3.案例1-拉取、查看镜像

需求：从DockerHub中拉取一个nginx镜像并查看

1）首先去镜像仓库搜索nginx镜像，比如DockerHub:

分布式springcloud_第82张图片

2）根据查看到的镜像名称，拉取自己需要的镜像，通过命令：docker pull nginx

分布式springcloud_第83张图片

3）通过命令：docker images 查看拉取到的镜像

分布式springcloud_第84张图片

2.1.4.案例2-保存、导入镜像

需求：利用docker save将nginx镜像导出磁盘，然后再通过load加载回来

1）利用docker xx --help命令查看docker save和docker load的语法

例如，查看save命令用法，可以输入命令：

docker save --help

结果：

分布式springcloud_第85张图片

命令格式：

docker save -o [保存的目标文件名称] [镜像名称]

2）使用docker save导出镜像到磁盘

运行命令：

docker save -o nginx.tar nginx:latest

结果如图：

分布式springcloud_第86张图片

3）使用docker load加载镜像

先删除本地的nginx镜像：

docker rmi nginx:latest

然后运行命令，加载本地文件：

docker load -i nginx.tar

结果：

分布式springcloud_第87张图片

2.1.5.练习

需求：去DockerHub搜索并拉取一个Redis镜像

目标：

1）去DockerHub搜索Redis镜像

2）查看Redis镜像的名称和版本

3）利用docker pull命令拉取镜像

4）利用docker save命令将 redis:latest打包为一个redis.tar包

5）利用docker rmi 删除本地的redis:latest

6）利用docker load 重新加载 redis.tar文件

2.2.容器操作

2.2.1.容器相关命令

容器操作的命令如图：

分布式springcloud_第88张图片

容器保护三个状态：

  • 运行：进程正常运行

  • 暂停：进程暂停，CPU不再运行，并不释放内存

  • 停止：进程终止，回收进程占用的内存、CPU等资源

其中：

  • docker run：创建并运行一个容器，处于运行状态

  • docker pause：让一个运行的容器暂停

  • docker unpause：让一个容器从暂停状态恢复运行

  • docker stop：停止一个运行的容器

  • docker start：让一个停止的容器再次运行

  • docker rm：删除一个容器

2.2.2.案例-创建并运行一个容器

创建并运行nginx容器的命令：

docker run --name containerName -p 80:80 -d nginx

命令解读：

  • docker run ：创建并运行一个容器

  • --name : 给容器起一个名字，比如叫做mn

  • -p ：将宿主机端口与容器端口映射，冒号左侧是宿主机端口，右侧是容器端口

  • -d：后台运行容器

  • nginx：镜像名称，例如nginx

这里的-p参数，是将容器端口映射到宿主机端口。

默认情况下，容器是隔离环境，我们直接访问宿主机的80端口，肯定访问不到容器中的nginx。

现在，将容器的80与宿主机的80关联起来，当我们访问宿主机的80端口时，就会被映射到容器的80，这样就能访问到nginx了：

分布式springcloud_第89张图片

2.2.3.案例-进入容器，修改文件

需求：进入Nginx容器，修改HTML文件内容，添加“传智教育欢迎您”

提示：进入容器要用到docker exec命令。

步骤：

1）进入容器。进入我们刚刚创建的nginx容器的命令为：

docker exec -it mn bash

命令解读：

  • docker exec ：进入容器内部，执行一个命令

  • -it : 给当前进入的容器创建一个标准输入、输出终端，允许我们与容器交互

  • mn ：要进入的容器的名称

  • bash：进入容器后执行的命令，bash是一个linux终端交互命令

2）进入nginx的HTML所在目录 /usr/share/nginx/html

容器内部会模拟一个独立的Linux文件系统，看起来如同一个linux服务器一样：

分布式springcloud_第90张图片

nginx的环境、配置、运行文件全部都在这个文件系统中，包括我们要修改的html文件。

查看DockerHub网站中的nginx页面，可以知道nginx的html目录位置在/usr/share/nginx/html

我们执行命令，进入该目录：

cd /usr/share/nginx/html

查看目录下文件：

分布式springcloud_第91张图片

3）修改index.html的内容

容器内没有vi命令，无法直接修改，我们用下面的命令来修改：

sed -i -e 's#Welcome to nginx#传智教育欢迎您#g' -e 's###g' index.html

在浏览器访问自己的虚拟机地址，例如我的是：http://192.168.150.101，即可看到结果：

分布式springcloud_第92张图片

2.2.4.小结

docker run命令的常见参数有哪些？

  • --name：指定容器名称

  • -p：指定端口映射

  • -d：让容器后台运行

查看容器日志的命令：

  • docker logs

  • 添加 -f 参数可以持续查看日志

查看容器状态：

  • docker ps

  • docker ps -a 查看所有容器，包括已经停止的

2.3.数据卷（容器数据管理）

在之前的nginx案例中，修改nginx的html页面时，需要进入nginx内部。并且因为没有编辑器，修改文件也很麻烦。

这就是因为容器与数据（容器内文件）耦合带来的后果。

分布式springcloud_第93张图片

要解决这个问题，必须将数据与容器解耦，这就要用到数据卷了。

2.3.1.什么是数据卷

数据卷（volume）是一个虚拟目录，指向宿主机文件系统中的某个目录。

分布式springcloud_第94张图片

一旦完成数据卷挂载，对容器的一切操作都会作用在数据卷对应的宿主机目录了。

这样，我们操作宿主机的/var/lib/docker/volumes/html目录，就等于操作容器内的/usr/share/nginx/html目录了

2.3.2.数据集操作命令

数据卷操作的基本语法如下：

docker volume [COMMAND]

docker volume命令是数据卷操作，根据命令后跟随的command来确定下一步的操作：

  • create 创建一个volume

  • inspect 显示一个或多个volume的信息

  • ls 列出所有的volume

  • prune 删除未使用的volume

  • rm 删除一个或多个指定的volume

2.3.3.创建和查看数据卷

需求：创建一个数据卷，并查看数据卷在宿主机的目录位置

① 创建数据卷

docker volume create html

② 查看所有数据

docker volume ls

结果：

分布式springcloud_第95张图片

③ 查看数据卷详细信息卷

docker volume inspect html

结果：

分布式springcloud_第96张图片

可以看到，我们创建的html这个数据卷关联的宿主机目录为/var/lib/docker/volumes/html/_data目录。

小结：

数据卷的作用：

  • 将容器与数据分离，解耦合，方便操作容器内数据，保证数据安全

数据卷操作：

  • docker volume create：创建数据卷

  • docker volume ls：查看所有数据卷

  • docker volume inspect：查看数据卷详细信息，包括关联的宿主机目录位置

  • docker volume rm：删除指定数据卷

  • docker volume prune：删除所有未使用的数据卷

2.3.4.挂载数据卷

我们在创建容器时，可以通过 -v 参数来挂载一个数据卷到某个容器内目录，命令格式如下：

docker run \
  --name mn \
  -v html:/root/html \
  -p 8080:80
  nginx \

这里的-v就是挂载数据卷的命令：

  • -v html:/root/html ：把html数据卷挂载到容器内的/root/html这个目录中

2.3.5.案例-给nginx挂载数据卷

需求：创建一个nginx容器，修改容器内的html目录内的index.html内容

分析：上个案例中，我们进入nginx容器内部，已经知道nginx的html目录所在位置/usr/share/nginx/html ，我们需要把这个目录挂载到html这个数据卷上，方便操作其中的内容。

提示：运行容器时使用 -v 参数挂载数据卷

步骤：

① 创建容器并挂载数据卷到容器内的HTML目录

docker run --name mn -v html:/usr/share/nginx/html -p 80:80 -d nginx

② 进入html数据卷所在位置，并修改HTML内容

# 查看html数据卷的位置
docker volume inspect html
# 进入该目录
cd /var/lib/docker/volumes/html/_data
# 修改文件
vi index.html

2.3.6.案例-给MySQL挂载本地目录

容器不仅仅可以挂载数据卷，也可以直接挂载到宿主机目录上。关联关系如下：

  • 带数据卷模式：宿主机目录 --> 数据卷 ---> 容器内目录

  • 直接挂载模式：宿主机目录 ---> 容器内目录

如图：

分布式springcloud_第97张图片

语法：

目录挂载与数据卷挂载的语法是类似的：

  • -v [宿主机目录]:[容器内目录]

  • -v [宿主机文件]:[容器内文件]

需求：创建并运行一个MySQL容器，将宿主机目录直接挂载到容器

实现思路如下：

1）在将课前资料中的mysql.tar文件上传到虚拟机，通过load命令加载为镜像

2）创建目录/tmp/mysql/data

3）创建目录/tmp/mysql/conf，将课前资料提供的hmy.cnf文件上传到/tmp/mysql/conf

4）去DockerHub查阅资料，创建并运行MySQL容器，要求：

① 挂载/tmp/mysql/data到mysql容器内数据存储目录

② 挂载/tmp/mysql/conf/hmy.cnf到mysql容器的配置文件

③ 设置MySQL密码

2.3.7.小结

docker run的命令中通过 -v 参数挂载文件或目录到容器中：

  • -v volume名称:容器内目录

  • -v 宿主机文件:容器内文件

  • -v 宿主机目录:容器内目录

数据卷挂载与目录直接挂载的

  • 数据卷挂载耦合度低，由docker来管理目录，但是目录较深，不好找

  • 目录挂载耦合度高，需要我们自己管理目录，不过目录容易寻找查看

3.Dockerfile自定义镜像

常见的镜像在DockerHub就能找到，但是我们自己写的项目就必须自己构建镜像了。

而要自定义镜像，就必须先了解镜像的结构才行。

3.1.镜像结构

镜像是将应用程序及其需要的系统函数库、环境、配置、依赖打包而成。

我们以MySQL为例，来看看镜像的组成结构：

分布式springcloud_第98张图片

简单来说，镜像就是在系统函数库、运行环境基础上，添加应用程序文件、配置文件、依赖文件等组合，然后编写好启动脚本打包在一起形成的文件。

我们要构建镜像，其实就是实现上述打包的过程。

3.2.Dockerfile语法

构建自定义的镜像时，并不需要一个个文件去拷贝，打包。

我们只需要告诉Docker，我们的镜像的组成，需要哪些BaseImage、需要拷贝什么文件、需要安装什么依赖、启动脚本是什么，将来Docker会帮助我们构建镜像。

而描述上述信息的文件就是Dockerfile文件。

Dockerfile就是一个文本文件，其中包含一个个的指令(Instruction)，用指令来说明要执行什么操作来构建镜像。每一个指令都会形成一层Layer。

分布式springcloud_第99张图片

更新详细语法说明，请参考官网文档： Dockerfile reference | Docker Docs

3.3.构建Java项目

3.3.1.基于Ubuntu构建Java项目

需求：基于Ubuntu镜像构建一个新镜像，运行一个java项目

  • 步骤1：新建一个空文件夹docker-demo

    分布式springcloud_第100张图片

  • 步骤2：拷贝课前资料中的docker-demo.jar文件到docker-demo这个目录

    分布式springcloud_第101张图片

  • 步骤3：拷贝课前资料中的jdk8.tar.gz文件到docker-demo这个目录

    分布式springcloud_第102张图片

  • 步骤4：拷贝课前资料提供的Dockerfile到docker-demo这个目录

    分布式springcloud_第103张图片

    其中的内容如下：

    # 指定基础镜像
FROM ubuntu:16.04
# 配置环境变量，JDK的安装目录
ENV JAVA_DIR=/usr/local

# 拷贝jdk和java项目的包
COPY ./jdk8.tar.gz $JAVA_DIR/
COPY ./docker-demo.jar /tmp/app.jar

# 安装JDK
RUN cd $JAVA_DIR \
 && tar -xf ./jdk8.tar.gz \
 && mv ./jdk1.8.0_144 ./java8

# 配置环境变量
ENV JAVA_HOME=$JAVA_DIR/java8
ENV PATH=$PATH:$JAVA_HOME/bin

# 暴露端口
EXPOSE 8090
# 入口，java项目的启动命令
ENTRYPOINT java -jar /tmp/app.jar

  • 步骤5：进入docker-demo

    将准备好的docker-demo上传到虚拟机任意目录，然后进入docker-demo目录下

  • 步骤6：运行命令：

    docker build -t javaweb:1.0 .

最后访问 http://192.168.150.101:8090/hello/count，其中的ip改成你的虚拟机ip

3.3.2.基于java8构建Java项目

虽然我们可以基于Ubuntu基础镜像，添加任意自己需要的安装包，构建镜像，但是却比较麻烦。所以大多数情况下，我们都可以在一些安装了部分软件的基础镜像上做改造。

例如，构建java项目的镜像，可以在已经准备了JDK的基础镜像基础上构建。

需求：基于java:8-alpine镜像，将一个Java项目构建为镜像

实现思路如下：

  • ① 新建一个空的目录，然后在目录中新建一个文件，命名为Dockerfile

  • ② 拷贝课前资料提供的docker-demo.jar到这个目录中

  • ③ 编写Dockerfile文件：

    • a ）基于java:8-alpine作为基础镜像

    • b ）将app.jar拷贝到镜像中

    • c ）暴露端口

    • d ）编写入口ENTRYPOINT

      内容如下：

      FROM java:8-alpine
COPY ./app.jar /tmp/app.jar
EXPOSE 8090
ENTRYPOINT java -jar /tmp/app.jar

  • ④ 使用docker build命令构建镜像

  • ⑤ 使用docker run创建容器并运行

3.4.小结

小结：

  1. Dockerfile的本质是一个文件，通过指令描述镜像的构建过程

  2. Dockerfile的第一行必须是FROM，从一个基础镜像来构建

  3. 基础镜像可以是基本操作系统，如Ubuntu。也可以是其他人制作好的镜像，例如：java:8-alpine

4.Docker-Compose

Docker Compose可以基于Compose文件帮我们快速的部署分布式应用，而无需手动一个个创建和运行容器！

分布式springcloud_第104张图片

4.1.初识DockerCompose

Compose文件是一个文本文件，通过指令定义集群中的每个容器如何运行。格式如下：

version: "3.8"
 services:
  mysql:
    image: mysql:5.7.25
    environment:
     MYSQL_ROOT_PASSWORD: 123 
    volumes:
     - "/tmp/mysql/data:/var/lib/mysql"
     - "/tmp/mysql/conf/hmy.cnf:/etc/mysql/conf.d/hmy.cnf"
  web:
    build: .
    ports:
     - "8090:8090"

上面的Compose文件就描述一个项目，其中包含两个容器：

  • mysql：一个基于mysql:5.7.25镜像构建的容器，并且挂载了两个目录

  • web：一个基于docker build临时构建的镜像容器，映射端口时8090

DockerCompose的详细语法参考官网：Overview | Docker Docs

其实DockerCompose文件可以看做是将多个docker run命令写到一个文件，只是语法稍有差异。

4.2.安装DockerCompose

参考课前资料

4.3.部署微服务集群

需求：将之前学习的cloud-demo微服务集群利用DockerCompose部署

实现思路：

① 查看课前资料提供的cloud-demo文件夹，里面已经编写好了docker-compose文件

② 修改自己的cloud-demo项目，将数据库、nacos地址都命名为docker-compose中的服务名

③ 使用maven打包工具，将项目中的每个微服务都打包为app.jar

④ 将打包好的app.jar拷贝到cloud-demo中的每一个对应的子目录中

⑤ 将cloud-demo上传至虚拟机，利用 docker-compose up -d 来部署

4.3.1.compose文件

查看课前资料提供的cloud-demo文件夹，里面已经编写好了docker-compose文件，而且每个微服务都准备了一个独立的目录：

分布式springcloud_第105张图片

内容如下：

version: "3.2"

services:
  nacos:
    image: nacos/nacos-server
    environment:
      MODE: standalone
    ports:
      - "8848:8848"
  mysql:
    image: mysql:5.7.25
    environment:
      MYSQL_ROOT_PASSWORD: 123
    volumes:
      - "$PWD/mysql/data:/var/lib/mysql"
      - "$PWD/mysql/conf:/etc/mysql/conf.d/"
  userservice:
    build: ./user-service
  orderservice:
    build: ./order-service
  gateway:
    build: ./gateway
    ports:
      - "10010:10010"

可以看到，其中包含5个service服务：

  • nacos：作为注册中心和配置中心

    • image: nacos/nacos-server： 基于nacos/nacos-server镜像构建

    • environment：环境变量

      • MODE: standalone：单点模式启动

    • ports：端口映射，这里暴露了8848端口

  • mysql：数据库

    • image: mysql:5.7.25：镜像版本是mysql:5.7.25

    • environment：环境变量

      • MYSQL_ROOT_PASSWORD: 123：设置数据库root账户的密码为123

    • volumes：数据卷挂载，这里挂载了mysql的data、conf目录，其中有我提前准备好的数据

  • userservice、orderservice、gateway：都是基于Dockerfile临时构建的

查看mysql目录，可以看到其中已经准备好了cloud_order、cloud_user表：

分布式springcloud_第106张图片

查看微服务目录，可以看到都包含Dockerfile文件：

分布式springcloud_第107张图片

内容如下：

FROM java:8-alpine
COPY ./app.jar /tmp/app.jar
ENTRYPOINT java -jar /tmp/app.jar

4.3.2.修改微服务配置

因为微服务将来要部署为docker容器，而容器之间互联不是通过IP地址，而是通过容器名。这里我们将order-service、user-service、gateway服务的mysql、nacos地址都修改为基于容器名的访问。

如下所示：

spring:
  datasource:
    url: jdbc:mysql://mysql:3306/cloud_order?useSSL=false
    username: root
    password: 123
    driver-class-name: com.mysql.jdbc.Driver
  application:
    name: orderservice
  cloud:
    nacos:
      server-addr: nacos:8848 # nacos服务地址

4.3.3.打包

接下来需要将我们的每个微服务都打包。因为之前查看到Dockerfile中的jar包名称都是app.jar，因此我们的每个微服务都需要用这个名称。

可以通过修改pom.xml中的打包名称来实现，每个微服务都需要修改：


  
  app
  
    
      org.springframework.boot
      spring-boot-maven-plugin

打包后：

分布式springcloud_第108张图片

4.3.4.拷贝jar包到部署目录

编译打包好的app.jar文件，需要放到Dockerfile的同级目录中。注意：每个微服务的app.jar放到与服务名称对应的目录，别搞错了。

user-service：

分布式springcloud_第109张图片

order-service：

分布式springcloud_第110张图片

gateway：

分布式springcloud_第111张图片

4.3.5.部署

最后，我们需要将文件整个cloud-demo文件夹上传到虚拟机中，理由DockerCompose部署。

上传到任意目录：

分布式springcloud_第112张图片

部署：

进入cloud-demo目录，然后运行下面的命令：

docker-compose up -d

5.Docker镜像仓库

5.1.搭建私有镜像仓库

参考课前资料《CentOS7安装Docker.md》

5.2.推送、拉取镜像

推送镜像到私有镜像服务必须先tag，步骤如下：

① 重新tag本地镜像，名称前缀为私有仓库的地址：192.168.150.101:8080/

docker tag nginx:latest 192.168.150.101:8080/nginx:1.0

② 推送镜像

docker push 192.168.150.101:8080/nginx:1.0

③ 拉取镜像

docker pull 192.168.150.101:8080/nginx:1.0

你可能感兴趣的:(面试,#,Docker使用,#,spring框架,分布式,spring,cloud,spring)

  • element实现动态路由+面包屑 软件技术NINI vue案例vue.js前端
    el-breadcrumb是ElementUI组件库中的一个面包屑导航组件，它用于显示当前页面的路径，帮助用户快速理解和导航到应用的各个部分。在Vue.js项目中，如果你已经安装了ElementUI，就可以很方便地使用el-breadcrumb组件。以下是一个基本的使用示例：安装ElementUI（如果你还没有安装的话）:你可以通过npm或yarn来安装ElementUI。bash复制代码npmi
  • C语言宏函数 南林yan C语言c语言
    一、什么是宏函数？通过宏定义的函数是宏函数。如下，编译器在预处理阶段会将Add(x,y)替换为((x)*(y))#defineAdd(x,y)((x)*(y))#defineAdd(x,y)((x)*(y))intmain(){inta=10;intb=20;intd=10;intc=Add(a+d,b)*2;cout<
  • C语言如何定义宏函数？ 小九格物 c语言
    在C语言中，宏函数是通过预处理器定义的，它在编译之前替换代码中的宏调用。宏函数可以模拟函数的行为，但它们不是真正的函数，因为它们在编译时不会进行类型检查，也不会分配存储空间。宏函数的定义通常使用#define指令，后面跟着宏的名称和参数列表，以及宏展开后的代码。宏函数的定义方式：1.基本宏函数：这是最简单的宏函数形式，它直接定义一个表达式。#defineSQUARE(x)((x)*(x))2.带参
  • c++ 的iostream 和 c++的stdio的区别和联系 黄卷青灯77 c++算法开发语言iostreamstdio
    在C++中，iostream和C语言的stdio.h都是用于处理输入输出的库，但它们在设计、用法和功能上有许多不同。以下是两者的区别和联系：区别1.编程风格iostream（C++风格）：C++标准库中的输入输出流类库，支持面向对象的输入输出操作。典型用法是cin（输入）和cout（输出），使用>操作符来处理数据。更加类型安全，支持用户自定义类型的输入输出。#includeintmain(){in
  • Long类型前后端数据不一致 igotyback 前端
    响应给前端的数据浏览器控制台中response中看到的Long类型的数据是正常的到前端数据不一致前后端数据类型不匹配是一个常见问题，尤其是当后端使用Java的Long类型（64位）与前端JavaScript的Number类型（最大安全整数为2^53-1，即16位）进行数据交互时，很容易出现精度丢失的问题。这是因为JavaScript中的Number类型无法安全地表示超过16位的整数。为了解决这个问
  • 消息中间件有哪些常见类型 xmh-sxh-1314 java
    消息中间件根据其设计理念和用途，可以大致分为以下几种常见类型：点对点消息队列（Point-to-PointMessagingQueues）：在这种模型中，消息被发送到特定的队列中，消费者从队列中取出并处理消息。队列中的消息只能被一个消费者消费，消费后即被删除。常见的实现包括IBM的MQSeries、RabbitMQ的部分使用场景等。适用于任务分发、负载均衡等场景。发布/订阅消息模型（Pub/Sub
  • html 中如何使用 uniapp 的部分方法 某公司摸鱼前端 htmluni-app前端
    示例代码：Documentconsole.log(window);效果展示：好了，现在就可以uni.使用相关的方法了
  • ArcGIS栅格计算器常见公式（赋值、0和空值的转换、补充栅格空值） 研学随笔 arcgis经验分享
    我们在使用ArcGIS时通常经常用到栅格计算器，今天主要给大家介绍我日常中经常用到的几个公式，供大家参考学习。将特定值（-9999）赋值为0，例如-9999.Con("raster"==-9999,0,"raster")2.给空值赋予特定的值（如0）Con(IsNull("raster"),0,"raster")3.将特定的栅格值(如1)赋值为空值，其他保留原值SetNull("raster"==
  • 高级编程--XML+socket练习题 masa010 java开发语言
    1.北京华北2114.8万人上海华东2,500万人广州华南1292.68万人成都华西1417万人（1）使用dom4j将信息存入xml中（2）读取信息，并打印控制台（3）添加一个city节点与子节点（4）使用socketTCP协议编写服务端与客户端，客户端输入城市ID，服务器响应相应城市信息（5）使用socketTCP协议编写服务端与客户端，客户端要求用户输入city对象，服务端接收并使用dom4j
  • 水平垂直居中的几种方法（总结） LJ小番茄 CSS_玄学语言htmljavascript前端csscss3
    1.使用flexbox的justify-content和align-items.parent{display:flex;justify-content:center;/*水平居中*/align-items:center;/*垂直居中*/height:100vh;/*需要指定高度*/}2.使用grid的place-items:center.parent{display:grid;place-item
  • 【一起学Rust | 设计模式】习惯语法——使用借用类型作为参数、格式化拼接字符串、构造函数 广龙宇 一起学Rust#Rust设计模式rust设计模式开发语言
    提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档文章目录前言一、使用借用类型作为参数二、格式化拼接字符串三、使用构造函数总结前言Rust不是传统的面向对象编程语言，它的所有特性，使其独一无二。因此，学习特定于Rust的设计模式是必要的。本系列文章为作者学习《Rust设计模式》的学习笔记以及自己的见解。因此，本系列文章的结构也与此书的结构相同（后续可能会调成结构），基本上分为三个部分
  • Python数据分析与可视化实战指南 William数据分析 pythonpython数据
    在数据驱动的时代，Python因其简洁的语法、强大的库生态系统以及活跃的社区，成为了数据分析与可视化的首选语言。本文将通过一个详细的案例，带领大家学习如何使用Python进行数据分析，并通过可视化来直观呈现分析结果。一、环境准备1.1安装必要库在开始数据分析和可视化之前，我们需要安装一些常用的库。主要包括pandas、numpy、matplotlib和seaborn等。这些库分别用于数据处理、数学
  • C#中使用split分割字符串 互联网打工人no1 c#
    1、用字符串分隔：usingSystem.Text.RegularExpressions;stringstr="aaajsbbbjsccc";string[]sArray=Regex.Split(str,"js",RegexOptions.IgnoreCase);foreach(stringiinsArray)Response.Write(i.ToString()+"");输出结果：aaabbbc
  • Python中os.environ基本介绍及使用方法 鹤冲天Pro #Pythonpython服务器开发语言
    文章目录python中os.environos.environ简介os.environ进行环境变量的增删改查python中os.environ的使用详解1.简介2.key字段详解2.1常见key字段3.os.environ.get()用法4.环境变量的增删改查和判断是否存在4.1新增环境变量4.2更新环境变量4.3获取环境变量4.4删除环境变量4.5判断环境变量是否存在python中os.envi
  • Python教程：一文了解使用Python处理XPath 旦莫 Python进阶python开发语言
    目录1.环境准备1.1安装lxml1.2验证安装2.XPath基础2.1什么是XPath？2.2XPath语法2.3示例XML文档3.使用lxml解析XML3.1解析XML文档3.2查看解析结果4.XPath查询4.1基本路径查询4.2使用属性查询4.3查询多个节点5.XPath的高级用法5.1使用逻辑运算符5.2使用函数6.实战案例6.1从网页抓取数据6.1.1安装Requests库6.1.2代
  • Google earth studio 简介 陟彼高冈yu 旅游
    GoogleEarthStudio是一个基于Web的动画工具，专为创作使用GoogleEarth数据的动画和视频而设计。它利用了GoogleEarth强大的三维地图和卫星影像数据库，使用户能够轻松地创建逼真的地球动画、航拍视频和动态地图可视化。网址为https://www.google.com/earth/studio/。GoogleEarthStudio是一个基于Web的动画工具，专为创作使用G
  • linux中sdl的使用教程,sdl使用入门 Melissa Corvinus linux中sdl的使用教程
    本文通过一个简单示例讲解SDL的基本使用流程。示例中展示一个窗口，窗口里面有个随机颜色快随机移动。当我们鼠标点击关闭按钮时间窗口关闭。基本步骤如下：1.初始化SDL并创建一个窗口。SDL_Init()初始化SDL_CreateWindow()创建窗口2.纹理渲染存储RGB和存储纹理的区别：比如一个从左到右由红色渐变到蓝色的矩形，用存储RGB的话就需要把矩形中每个点的具体颜色值存储下来；而纹理只是一
  • LLM 词汇表 落难Coder LLMsNLP大语言模型大模型llama人工智能
    Contextwindow“上下文窗口”是指语言模型在生成新文本时能够回溯和参考的文本量。这不同于语言模型训练时所使用的大量数据集，而是代表了模型的“工作记忆”。较大的上下文窗口可以让模型理解和响应更复杂和更长的提示，而较小的上下文窗口可能会限制模型处理较长提示或在长时间对话中保持连贯性的能力。Fine-tuning微调是使用额外的数据进一步训练预训练语言模型的过程。这使得模型开始表示和模仿微调数
  • PHP环境搭建详细教程 好看资源平台 前端php
    PHP是一个流行的服务器端脚本语言，广泛用于Web开发。为了使PHP能够在本地或服务器上运行，我们需要搭建一个合适的PHP环境。本教程将结合最新资料，介绍在不同操作系统上搭建PHP开发环境的多种方法，包括Windows、macOS和Linux系统的安装步骤，以及本地和Docker环境的配置。1.PHP环境搭建概述PHP环境的搭建主要分为以下几类：集成开发环境：例如XAMPP、WAMP、MAMP，这
  • 下载github patch到本地 小米人er 我的博客gitpatch
    以下是几种从GitHub上下载以.patch结尾的补丁文件的方法：通过浏览器直接下载打开包含该.patch文件的GitHub仓库。在仓库的文件列表中找到对应的.patch文件。点击该文件，浏览器会显示文件的内容，在页面的右上角通常会有一个“Raw”按钮，点击它可以获取原始文件内容。然后在浏览器中使用快捷键（如Ctrl+S或者Command+S）将原始文件保存到本地，选择保存的文件名并确保后缀为.p
  • 使用 FinalShell 进行远程连接（ssh 远程连接 Linux 服务器） 编程经验分享 开发工具服务器sshlinux
    目录前言基本使用教程新建远程连接连接主机自定义命令路由追踪前言后端开发，必然需要和服务器打交道，部署应用，排查问题，查看运行日志等等。一般服务器都是集中部署在机房中，也有一些直接是云服务器，总而言之，程序员不可能直接和服务器直接操作，一般都是通过ssh连接来登录服务器。刚接触远程连接时，使用的是XSHELL来远程连接服务器，连接上就能够操作远程服务器了，但是仅用XSHELL并没有上传下载文件的功能
  • 直返最高等级与直返APP：无需邀请码的返利新体验 古楼
    随着互联网的普及和电商的兴起，直返模式逐渐成为一种流行的商业模式。在这种模式下，消费者通过购买产品或服务，获得一定的返利，并可以分享给更多的人。其中，直返最高等级和直返APP是直返模式中的重要概念和工具。本文将详细介绍直返最高等级的概念、直返APP的使用以及与邀请码的关系。【高省】APP（高佣金领导者）是一个自用省钱佣金高，分享推广赚钱多的平台，百度有几百万篇报道，运行三年，稳定可靠。高省APP，
  • SQL Server_查询某一数据库中的所有表的内容 qq_42772833 SQLServer数据库sqlserver
    1.查看所有表的表名要列出CrabFarmDB数据库中的所有表（名），可以使用以下SQL语句：USECrabFarmDB;--切换到目标数据库GOSELECTTABLE_NAMEFROMINFORMATION_SCHEMA.TABLESWHERETABLE_TYPE='BASETABLE';对这段SQL脚本的解释：SELECTTABLE_NAME：这个语句的作用是从查询结果中选择TABLE_NAM
  • 四章-32-点要素的聚合 彩云飘过
    本文基于腾讯课堂老胡的课《跟我学Openlayers--基础实例详解》做的学习笔记，使用的openlayers5.3.xapi。源码见1032.html，对应的官网示例https://openlayers.org/en/latest/examples/cluster.htmlhttps://openlayers.org/en/latest/examples/earthquake-clusters.
  • 2020-04-12每天三百字之连接与替代 冷眼看潮
    不知道是不是好为人师，有时候还真想和别人分享一下我对某些现象的看法或者解释。人类社会不断发展进步的过程，就是不断连接与替代的过程。人类发现了火并应用火以后，告别了茹毛饮血的野兽般的原始生活（火烧、烹饪替代了生食）人类用石器代替了完全手工，工具的使用使人类进步一大步。类似这样的替代还有很多，随着科技的发展，有更多的原始的事物被替代，代之以更高效、更先进的技术。在近现代，汽车替代了马车，高速公路和铁路
  • 【加密社】Solidity 中的事件机制及其应用 加密社 闲侃区块链智能合约区块链
    加密社引言在Solidity合约开发过程中，事件（Events）是一种非常重要的机制。它们不仅能够让开发者记录智能合约的重要状态变更，还能够让外部系统（如前端应用）监听这些状态的变化。本文将详细介绍Solidity中的事件机制以及如何利用不同的手段来触发、监听和获取这些事件。事件存储的地方当我们在Solidity合约中使用emit关键字触发事件时，该事件会被记录在区块链的交易收据中。具体而言，事件
  • 探索OpenAI和LangChain的适配器集成：轻松切换模型提供商 nseejrukjhad langchaineasyui前端python
    #探索OpenAI和LangChain的适配器集成：轻松切换模型提供商##引言在人工智能和自然语言处理的世界中，OpenAI的模型提供了强大的能力。然而，随着技术的发展，许多人开始探索其他模型以满足特定需求。LangChain作为一个强大的工具，集成了多种模型提供商，通过提供适配器，简化了不同模型之间的转换。本篇文章将介绍如何使用LangChain的适配器与OpenAI集成，以便轻松切换模型提供商
  • 使用Faiss进行高效相似度搜索 llzwxh888 faisspython
    在现代AI应用中，快速和高效的相似度搜索是至关重要的。Faiss（FacebookAISimilaritySearch）是一个专门用于快速相似度搜索和聚类的库，特别适用于高维向量。本文将介绍如何使用Faiss来进行相似度搜索，并结合Python代码演示其基本用法。什么是Faiss？Faiss是一个由FacebookAIResearch团队开发的开源库，主要用于高维向量的相似性搜索和聚类。Faiss
  • 使用LLaVa和Ollama实现多模态RAG示例 llzwxh888 python人工智能开发语言
    本文将详细介绍如何使用LLaVa和Ollama实现多模态RAG（检索增强生成），通过提取图像中的结构化数据、生成图像字幕等功能来展示这一技术的强大之处。安装环境首先，您需要安装以下依赖包：!pipinstallllama-index-multi-modal-llms-ollama!pipinstallllama-index-readers-file!pipinstallunstructured!p
  • python是什么意思中文-在python中%是什么意思 编程大乐趣
    Python中%有两种：1、数值运算：%代表取模，返回除法的余数。如：>>>7%212、%操作符（字符串格式化，stringformatting），说明如下：%[(name)][flags][width].[precision]typecode(name)为命名flags可以有+，-，''或0。+表示右对齐。-表示左对齐。''为一个空格，表示在正数的左侧填充一个空格，从而与负数对齐。0表示使用0填
  • java杨辉三角 3213213333332132 java基础
    package com.algorithm; /** * @Description 杨辉三角 * @author FuJianyong * 2015-1-22上午10:10:59 */ public class YangHui { public static void main(String[] args) { //初始化二维数组长度 int[][] y
  • 《大话重构》之大布局的辛酸历史 白糖_ 重构
    《大话重构》中提到“大布局你伤不起”，如果企图重构一个陈旧的大型系统是有非常大的风险，重构不是想象中那么简单。我目前所在公司正好对产品做了一次“大布局重构”，下面我就分享这个“大布局”项目经验给大家。   背景         公司专注于企业级管理产品软件，企业有大中小之分，在2000年初公司用JSP/Servlet开发了一套针对中
  • 电驴链接在线视频播放源码 dubinwei 源码电驴播放器视频ed2k
    本项目是个搜索电驴（ed2k）链接的应用,借助于磁力视频播放器（官网： http://loveandroid.duapp.com/ 开放平台），可以实现在线播放视频，也可以用迅雷或者其他下载工具下载。 项目源码： http://git.oschina.net/svo/Emule,动态更新。也可从附件中下载。 项目源码依赖于两个库项目，库项目一链接： http://git.oschina.
  • Javascript中函数的toString()方法 周凡杨 JavaScriptjstoStringfunctionobject
    简述     The toString() method returns a string representing the source code of the function.     简译之，Javascript的toString()方法返回一个代表函数源代码的字符串。 句法     function.
  • struts处理自定义异常 g21121 struts
    很多时候我们会用到自定义异常来表示特定的错误情况，自定义异常比较简单，只要分清是运行时异常还是非运行时异常即可，运行时异常不需要捕获，继承自RuntimeException，是由容器自己抛出，例如空指针异常。 非运行时异常继承自Exception，在抛出后需要捕获，例如文件未找到异常。 此处我们用的是非运行时异常，首先定义一个异常LoginException: /** * 类描述：登录相
  • Linux中find常见用法示例 510888780 linux
    Linux中find常见用法示例 ·find   path   -option   [   -print ]   [ -exec   -ok   command ]   {} \; find命令的参数；
  • SpringMVC的各种参数绑定方式 Harry642 springMVC绑定表单
    1. 基本数据类型(以int为例，其他类似)： Controller代码： @RequestMapping("saysth.do") public void test(int count) { } 表单代码： <form action="saysth.do" method="post&q
  • Java 获取Oracle ROWID aijuans javaoracle
    A ROWID is an identification tag unique for each row of an Oracle Database table. The ROWID can be thought of as a virtual column, containing the ID for each row. The oracle.sql.ROWID class i
  • java获取方法的参数名 antlove javajdkparametermethodreflect
    reflect.ClassInformationUtil.java package reflect; import javassist.ClassPool; import javassist.CtClass; import javassist.CtMethod; import javassist.Modifier; import javassist.bytecode.CodeAtt
  • JAVA正则表达式匹配 查找 替换 提取操作 百合不是茶 java正则表达式替换提取查找
    正则表达式的查找;主要是用到String类中的split();       String str;      str.split();方法中传入按照什么规则截取,返回一个String数组   常见的截取规则: str.split("\\.")按照.来截取 str.
  • Java中equals()与hashCode()方法详解 bijian1013 javasetequals()hashCode()
    一.equals()方法详解     equals()方法在object类中定义如下：  public boolean equals(Object obj) { return (this == obj); }    很明显是对两个对象的地址值进行的比较（即比较引用是否相同）。但是我们知道，String 、Math、I
  • 精通Oracle10编程SQL(4)使用SQL语句 bijian1013 oracle数据库plsql
    --工资级别表 create table SALGRADE ( GRADE NUMBER(10), LOSAL NUMBER(10,2), HISAL NUMBER(10,2) ) insert into SALGRADE values(1,0,100); insert into SALGRADE values(2,100,200); inser
  • 【Nginx二】Nginx作为静态文件HTTP服务器 bit1129 HTTP服务器
     Nginx作为静态文件HTTP服务器 在本地系统中创建/data/www目录，存放html文件(包括index.html) 创建/data/images目录，存放imags图片 在主配置文件中添加http指令   http { server { listen 80; server_name
  • kafka获得最新partition offset blackproof kafkapartitionoffset最新
    kafka获得partition下标，需要用到kafka的simpleconsumer   import java.util.ArrayList; import java.util.Collections; import java.util.Date; import java.util.HashMap; import java.util.List; import java.
  • centos 7安装docker两种方式 ronin47
          第一种是采用yum 方式              yum install -y docker           
  • java-60-在O(1)时间删除链表结点 bylijinnan java
    public class DeleteNode_O1_Time { /** * Q 60 在O(1)时间删除链表结点 * 给定链表的头指针和一个结点指针(!!)，在O(1)时间删除该结点 * * Assume the list is: * head->...->nodeToDelete->mNode->nNode->..
  • nginx利用proxy_cache来缓存文件 cfyme cache
    user  zhangy users; worker_processes 10; error_log  /var/vlogs/nginx_error.log  crit; pid        /var/vlogs/nginx.pid; #Specifies the value for ma
  • [JWFD开源工作流]JWFD嵌入式语法分析器负号的使用问题 comsci 嵌入式
        假如我们需要用JWFD的语法分析模块定义一个带负号的方程式，直接在方程式之前添加负号是不正确的，而必须这样做：     string str01 = "a=3.14;b=2.71;c=0;c-((a*a)+(b*b))"     定义一个0整数c,然后用这个整数c去
  • 如何集成支付宝官方文档 dai_lm android
    官方文档下载地址 https://b.alipay.com/order/productDetail.htm?productId=2012120700377310&tabId=4#ps-tabinfo-hash 集成的必要条件 1. 需要有自己的Server接收支付宝的消息 2. 需要先制作app，然后提交支付宝审核，通过后才能集成 调试的时候估计会真的扣款，请注意
  • 应该在什么时候使用Hadoop datamachine hadoop
    原帖地址：http://blog.chinaunix.net/uid-301743-id-3925358.html 存档，某些观点与我不谋而合，过度技术化不可取，且hadoop并非万能。 --------------------------------------------万能的分割线-------------------------------- 有人问我，“你在大数据和Hado
  • 在GridView中对于有外键的字段使用关联模型进行搜索和排序 dcj3sjt126com yii
    在GridView中使用关联模型进行搜索和排序 首先我们有两个模型它们直接有关联: class Author extends CActiveRecord { ... } class Post extends CActiveRecord { ... function relations() { return array( '
  • 使用NSString 的格式化大全 dcj3sjt126com Objective-C
    格式定义The format specifiers supported by the NSString formatting methods and CFString formatting functions follow the IEEE printf specification; the specifiers are summarized in Table 1. Note that you c
  • 使用activeX插件对象object滚动有重影 蕃薯耀 activeX插件滚动有重影
      使用activeX插件对象object滚动有重影   <object style="width:0;" id="abc" classid="CLSID:D3E3970F-2927-9680-BBB4-5D0889909DF6" codebase="activex/OAX339.CAB#
  • SpringMVC4零配置 hanqunfeng springmvc4
    基于Servlet3.0规范和SpringMVC4注解式配置方式，实现零xml配置，弄了个小demo，供交流讨论。     项目说明如下： 1.db.sql是项目中用到的表，数据库使用的是oracle11g 2.该项目使用mvn进行管理，私服为自搭建nexus,项目只用到一个第三方 jar，就是oracle的驱动； 3.默认项目为零配置启动，如果需要更改启动方式，请
  • 《开源框架那点事儿16》：缓存相关代码的演变 j2eetop 开源框架
    问题引入 上次我参与某个大型项目的优化工作，由于系统要求有比较高的TPS，因此就免不了要使用缓冲。 该项目中用的缓冲比较多，有MemCache，有Redis，有的还需要提供二级缓冲，也就是说应用服务器这层也可以设置一些缓冲。 当然去看相关实现代代码的时候，大致是下面的样子。 [java] view plain copy print ? public vo
  • AngularJS浅析 kvhur JavaScript
    概念 AngularJS is a structural framework for dynamic web apps. 了解更多详情请见原文链接：http://www.gbtags.com/gb/share/5726.htm Directive 扩展html，给html添加声明语句，以便实现自己的需求。对于页面中html元素以ng为前缀的属性名称，ng是angular的命名空间
  • 架构师之jdk的bug排查(一)---------------split的点号陷阱 nannan408 split
    1.前言.    jdk1.6的lang包的split方法是有bug的,它不能有效识别A.b.c这种类型,导致截取长度始终是0.而对于其他字符,则无此问题.不知道官方有没有修复这个bug. 2.代码 String[] paths = "object.object2.prop11".split("'"); System.ou
  • 如何对10亿数据量级的mongoDB作高效的全表扫描 quentinXXZ mongodb
      本文链接:  http://quentinXXZ.iteye.com/blog/2149440 一、正常情况下，不应该有这种需求 首先，大家应该有个概念，标题中的这个问题，在大多情况下是一个伪命题，不应该被提出来。要知道，对于一般较大数据量的数据库，全表查询，这种操作一般情况下是不应该出现的，在做正常查询的时候，如果是范围查询，你至少应该要加上limit。 说一下，
  • C语言算法之水仙花数 qiufeihu c算法
    /** * 水仙花数 */ #include <stdio.h> #define N 10 int main() { int x,y,z; for(x=1;x<=N;x++) for(y=0;y<=N;y++) for(z=0;z<=N;z++) if(x*100+y*10+z == x*x*x
  • JSP指令 wyzuomumu jsp
    jsp指令的一般语法格式： <%@ 指令名 属性 =”值 ” %> 常用的三种指令： page,include,taglib page指令语法形式： <%@ page 属性 1=”值 1” 属性 2=”值 2”%> include指令语法形式： <%@include file=”relative url”%> (jsp可以通过 include
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他