[TOC]

1.1. 第一章 sharding-jdbc概述

image-20201213161858364

  • 磁盘IO的开销问题,单库情况下无法承载过多的访问
  • 所有的用户数据都存放在同一个表中,【1000万】,查询的时候效率比较低
  • 业务的边界不清晰,专库专用

虽然我们对应用系统做了大量的微服务处理,提升了系统在应用体系上的吞吐量,但是随着业务的越来越多,我们的数据库势必有不堪重负的一天,那么我们是怎么处理数据层的问题呢?这里就需要采用分库分表的策略来处理:

​ Sharding-jdbc是ShardingSphere的其中一个模块,定位为轻量级Java框架,在Java的JDBC层提供的额外服务。 它使用客户端直连数据库,以jar包形式提供服务,无需额外部署和依赖,可理解为增强版的JDBC驱动,完全兼容JDBC和各种ORM框架。

  • 适用于任何基于Java的ORM框架,如:JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
  • 基于任何第三方的数据库连接池,如:DBCP, C3P0, BoneCP, Druid, HikariCP等。
  • 支持任意实现JDBC规范的数据库。目前支持MySQL,Oracle,SQLServer和PostgreSQL。

1.2. 第二章 分库分表基础概念

1.2.1. 1、垂直分库

名词解释:垂直分库是指按照业务将表进行分类,分布到不同的数据库上面,每个库可以放在不同的服务器上,它的核心理念是专库专用。

它带来的提升是:

  • 解决业务层面的耦合,业务清晰

  • 能对不同业务的数据进行分级管理、维护、监控、扩展等

  • 高并发场景下,垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈

    垂直分库通过将表按业务分类,然后分布在不同数据库,并且可以将这些数据库部署在不同服务器上,从而达到多个服务器共同分摊压力的效果,==但是依然没有解决单表数据量过大的问题。==

image-20201216171224789

1.2.2. 2、水平分库

名词解释:是把同一个表的数据按一定规则拆到不同的数据库中,每个库可以放在不同的服务器上。

水平分库是把不同表拆到不同数据库中,它是对数据行的拆分,不影响表结构

它带来的提升是:

  • 解决了单库大数据,高并发的性能瓶颈。
  • 提高了系统的稳定性及可用性

image-20201216171942624

1.2.3. 3、垂直分表

名词解释:将一个表按照字段分成多表,每个表存储其中一部分字段 它带来的提升是:

1.为了避免IO争抢并减少锁表的几率,查看详情的用户与商品信息浏览互不影响

2.充分发挥热门数据的操作效率,商品信息的操作的高效率不会被商品描述的低效率所拖累。

通常我们按以下原则进行垂直拆分:

  1. 把不常用的字段单独放在一张表;
  2. 把text,blob等大字段拆分出来放在附表中;
  3. 经常组合查询的列放在一张表中;

image-20201216212743505

1.2.4. 4、水平分表

水平分表是在同一个数据库内,把同一个表的数据按一定规则拆到多个表中。

它带来的提升是:

  • 优化单一表数据量过大而产生的性能问题

  • 避免IO争抢并减少锁表的几率

    库内的水平分表,解决了单一表数据量过大的问题,分出来的小表中只包含一部分数据,从而使得单个表的数据量变小,提高检索性能。

image-20201218153359933

1.2.5. 5、分库分表总结

垂直分表:可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表,这样既能使业务清晰,还能提升部分性能。拆分后,尽量从业务角度避免联查,否则性能方面将得不偿失。

垂直分库:可以把多个表按业务耦合松紧归类,分别存放在不同的库,这些库可以分布在不同服务器,从而使访问压力被多服务器负载,大大提升性能,同时能提高整体架构的业务清晰度,不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。

水平分库:可以把一个表的数据(按数据行)分到多个不同的库,每个库只有这个表的部分数据,这些库可以分布在不同服务器,从而使访问压力被多服务器负载,大大提升性能。它不仅需要解决跨库带来的所有复杂问题,还要解决数据路由的问题(数据路由问题后边介绍)。

水平分表:可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中,每个表只有这个表的部分数据,这样做能小幅提升性能,它仅仅作为水平分库的一个补充优化。

一般来说,在系统设计阶段就应该根据业务耦合松紧来确定垂直分库,垂直分表方案,在数据量及访问压力不是特别大的情况,首先考虑缓存、读写分离、索引技术等方案。若数据量极大,且持续增长,再考虑水平分库水平分表方案

1.3. 第三章 sharding-jdbc架构

1.3.1. 1、名称解释

  • 逻辑表(LogicTable):进行水平拆分的时候同一类型(逻辑、数据结构相同)的表的总称。例:用户数据根据主键尾数拆分为2张表,分别是tab_user_0到tab_user_1,他们的逻辑表名为tab_user。

  • 真实表(ActualTable):在分片的数据库中真实存在的物理表。即上个示例中的tab_user_0到tab_user_1。

  • 数据节点(DataNode):数据分片的最小单元。由数据源名称和数据表组成,例:spring-boot_0.tab_user_0,spring-boot_0.tab_user_1,spring-boot_1.tab_user_0,spring-boot_1.tab_user_1。

  • 动态表(DynamicTable):逻辑表和物理表不一定需要在配置规则中静态配置。如,按照日期分片的场景,物理表的名称随着时间的推移会产生变化。

  • 绑定表(BindingTable):指分片规则一致的主表和子表。例如:t_order表和t_order_item表,均按照order_id分片,则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联,关联查询效率将大大提升。举例说明,如果SQL为:

    SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
    

    ==让order的数据落库位置,与order_item落库的位置在同一个数据节点==

    在不配置绑定表关系时,假设分片键order_id将数值10路由至第0片,将数值11路由至第1片,那么路由后的SQL应该为4条,它们呈现为笛卡尔积:

    SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
    
    SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
    
    SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
    
    SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
    

    在配置绑定表关系后,路由的SQL应该为2条:

    SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
    
    SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
    

    其中t_order在FROM的最左侧,ShardingSphere将会以它作为整个绑定表的主表。 所有路由计算将会只使用主表的策略,那么t_order_item表的分片计算将会使用t_order`的条件。故绑定表之间的分区键要完全相同。

  • 分片键(ShardingColumn):分片字段用于将数据库(表)水平拆分的字段,支持单字段及多字段分片。例如上例中的order_id。

  • 分片算法(ShardingAlgorithm):进行水平拆分时采用的算法,分片算法需要应用方开发者自行实现,可实现的灵活度非常高。目前提供4种分片算法。由于分片算法和业务实现紧密相关,因此并未提供内置分片算法,而是通过分片策略将各种场景提炼出来,提供更高层级的抽象,并提供接口让应用开发者自行实现分片算法

1、精确分片算法
对应PreciseShardingAlgorithm,必选,用于处理使用单一键作为分片键的=与IN进行分片的场景。需要配合StandardShardingStrategy使用。

2、范围分片算法
对应RangeShardingAlgorithm,可选,用于处理使用单一键作为分片键的BETWEEN AND进行分片的场景。如果不配置RangeShardingAlgorithm,SQL中的BETWEEN AND将按照全库路由处理。需要配合StandardShardingStrategy使用。

3、复合分片算法
对应ComplexKeysShardingAlgorithm,用于处理使用多键作为分片键进行分片的场景,包含多个分片键的逻辑较复杂,需要应用开发者自行处理其中的复杂度。需要配合ComplexShardingStrategy使用。

4、Hint分片算法
对应HintShardingAlgorithm,用于处理使用Hint行分片的场景。需要配合HintShardingStrategy使用。
  • 分片策略(ShardingStrategy):包含分片键和分片算法,由于分片算法的独立性,将其独立抽离。真正可用于分片操作的是分片键 + 分片算法,也就是分片策略。目前提供5种分片策略。
1、标准分片策略
对应StandardShardingStrategy。提供对SQL语句中的=, IN和BETWEEN AND的分片操作支持。StandardShardingStrategy只支持单分片键,提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法。PreciseShardingAlgorithm是必选的,用于处理=和IN的分片。RangeShardingAlgorithm是可选的,用于处理BETWEEN AND分片,如果不配置RangeShardingAlgorithm,SQL中的BETWEEN AND将按照全库路由处理。

2、复合分片策略
对应ComplexShardingStrategy。复合分片策略。提供对SQL语句中的=, IN和BETWEEN AND的分片操作支持。ComplexShardingStrategy支持多分片键,由于多分片键之间的关系复杂,因此并未进行过多的封装,而是直接将分片键值组合以及分片操作符透传至分片算法,完全由应用开发者实现,提供最大的灵活度。

3、行表达式分片策略
对应InlineShardingStrategy。使用Groovy的表达式,提供对SQL语句中的=和IN的分片操作支持,只支持单分片键。对于简单的分片算法,可以通过简单的配置使用,从而避免繁琐的Java代码开发,如: t_user_$->{u_id % 8} 表示t_user表根据u_id模8,而分成8张表,表名称为t_user_0到t_user_7。

4、Hint分片策略
对应HintShardingStrategy。通过Hint而非SQL解析的方式分片的策略。

5、不分片策略
对应NoneShardingStrategy。不分片的策略。

1.3.2. 2、架构图

img

由图可知,在sql执行过程中需要经过几个过程:

例如现在有一条查询语句:

select * from t_user where id=10;==》10s从1000W

进行了分库分表操作,2个库ds0,ds1,采用的分片键为id,逻辑表为t_user,真实表为t_user_0、t_user_1两张表,分库、分表算法为均为取余(%2)。

  • sql解析:通过解析sql语句提取分片键列与值进行分片,例如比较符 =、in 、between and,及查询的表等。
  • sql改写:根据解析结果,及采用的分片逻辑改写sql,上例经过sql改写后,真实语句为:
select * from ds0.t_user_0 where id=10;==>ds0.t_user_0 2S
select * from ds0.t_user_1 where id=10;==>ds0.t_user_1 2S
select * from ds1.t_user_0 where id=10;==>ds1.t_user_0 2S
select * from ds1.t_user_1 where id=10;==>ds1.t_user_1 2S
  • sql路由:找到sql需要去哪个库、哪个表执行语句,上例sql根据采用的策略可以得到将在ds0库,t_user_0表执行语句。
  • sql执行:执行改写后的sql。
  • 结果归并:当我们执行某些复杂语句时,sql可能会在多个库、多个表中执行,sql分别对应执行后会对结果集进行归并操作,得到最终的结果

1.4. 第四章 sharding-jdbc实战

1.4.1. 1、pom依赖

在module-user-service和module-business-service中添加

<!-- 分布式事务atomikos -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jta-atomikos</artifactId>
</dependency>
<!-- sharding-jdbc -->
<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
</dependency>

1.4.2. 2、分库键回填机制

在BasicPojo中添加分片字段shardingId

package com.itheima.springcloud.basic;

import com.baomidou.mybatisplus.annotation.FieldFill;
import com.baomidou.mybatisplus.annotation.TableField;
import com.fasterxml.jackson.annotation.JsonFormat;
import com.itheima.springcloud.utils.ToString;
import lombok.AllArgsConstructor;
import org.apache.commons.lang3.builder.ToStringBuilder;
import org.apache.commons.lang3.builder.ToStringStyle;
import org.springframework.format.annotation.DateTimeFormat;

import java.util.Date;

/**
 * @Description:基础类
 */
@AllArgsConstructor
public class BasicPojo extends ToString {

    public BasicPojo() {
    }

    public BasicPojo(Long id) {
        this.id = id;
    }

    /**
     * @Description 主键
     */
    @JsonFormat(shape = JsonFormat.Shape.STRING)
    private Long id;

    /**
     * @Description 数据源分片Id
     */
    @TableField(fill = FieldFill.INSERT)
    protected Long shardingId;

    @TableField(fill = FieldFill.INSERT)//INSERT代表只在插入时填充
    @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")//set
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")//get
    protected Date createdTime;

    @TableField(fill = FieldFill.INSERT_UPDATE)// INSERT_UPDATE 首次插入、其次更新时填充(或修改)
    @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")//set
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")//get
    protected Date updatedTime;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public Date getCreatedTime() {
        return createdTime;
    }

    public void setCreatedTime(Date createdTime) {
        this.createdTime = createdTime;
    }

    public Date getUpdatedTime() {
        return updatedTime;
    }

    public void setUpdatedTime(Date updatedTime) {
        this.updatedTime = updatedTime;
    }

    public String toString() {
        return ToStringBuilder.reflectionToString(this, ToStringStyle.SHORT_PREFIX_STYLE);
    }
}

MyBatisMetaObjectHandler中添加shardingId回填

package com.itheima.springcloud.handler;

import com.baomidou.mybatisplus.core.handlers.MetaObjectHandler;
import com.itheima.springcloud.utils.SnowflakeIdWorker;
import lombok.extern.slf4j.Slf4j;
import org.apache.ibatis.reflection.MetaObject;
import org.springframework.beans.factory.annotation.Autowired;

import java.util.Date;

/**
 * @Description:自动填充
 */
@Slf4j
public class MyBatisMetaObjectHandler implements MetaObjectHandler {

    @Autowired
    SnowflakeIdWorker snowflakeIdWorker;

    @Override
    public void insertFill(MetaObject metaObject) {
        log.info("开始插入填充.....");
        Object shardingId = getFieldValByName("shardingId", metaObject);
        if (metaObject.hasSetter("shardingId")&&shardingId==null) {
            this.strictInsertFill(metaObject, "shardingId", Long.class,snowflakeIdWorker.nextId() );
        }
        if (metaObject.hasSetter("createdTime")) {
            this.strictInsertFill(metaObject, "createdTime", Date.class, new Date());
        }
        if (metaObject.hasSetter("updatedTime")) {
            this.strictInsertFill(metaObject, "updatedTime", Date.class, new Date());
        }
    }

    @Override
    public void updateFill(MetaObject metaObject) {
        log.info("开始更新填充.....");
        if (metaObject.hasSetter("updatedTime")) {
            this.strictUpdateFill(metaObject, "updatedTime", Date.class, new Date());
        }
    }
}

1.4.3. 3、yml文件

在module-user-servic修改

itheima:
  framework:
    jwt:
      base64-encoded-secret-key: 20201010
      ttl-millis: 3600
    swagger:
      swagger-path: com.itheima.springcloud.web
#服务配置
server:
  #端口
  port: 8083
  #服务编码
  tomcat:
    uri-encoding: UTF-8
#spring相关配置
spring:
  #应用配置
  application:
    #应用名称
    name: module-user-service
  main:
    allow-bean-definition-overriding: true
  jta:
    atomikos:
      properties:
        log-base-dir: D:/home/module-user-service-atomikos
        log-base-name: module-user-service
  #数据源配置
  shardingsphere:
    datasource:
      names: ds0,ds1
      ds0:
        type: com.alibaba.druid.pool.DruidDataSource
        driverClassName: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost:3306/spring-boot_0?useAffectedRows=true&serverTimezone=UTC
        username: root
        password: root
      ds1:
        type: com.alibaba.druid.pool.DruidDataSource
        driverClassName: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost:3306/spring-boot_1?useAffectedRows=true&serverTimezone=UTC
        username: root
        password: root
    #分库分表
    sharding:
      tables:
        tab_user:
          actualDataNodes: ds${0..1}.tab_user_${0..1} #数据节点
          databaseStrategy: #水平分库
            inline:
              shardingColumn: sharding_id
              algorithmExpression: ds${sharding_id % 2} #水平分库策略表达式
          tableStrategy: #水平分表
            inline:
              shardingColumn: id
              algorithmExpression: tab_user_${id % 2} #水平分表表达式
          keyGenerator:
            type: SNOWFLAKE #主键策略
            column: id #主键ID
      binding-tables: #绑定表
        - tab_user
      broadcast-tables: #广播表
        - tab_role
        - tab_role_resource
        - tab_seller
        - tab_user_role
      default-key-generator: #默认主键
        type: SNOWFLAKE
        column: id
    props:
      sql.show: true #打印sql
  redis:
    host: 127.0.0.1 #Redis服务器地址
    port: 7379 #Redis服务器连接端口
    timeout: 2000 #请求redis服务的超时时间,这里注意设置成0时取默认时间2000
    lettuce:
      pool:
        #连接池最大连接数(使用负值表示没有限制)
        #建议为业务期望QPS/一个连接的QPS,例如50000/1000=50
        #一次命令时间(borrow|return resource+Jedis执行命令+网络延迟)的平均耗时约为1ms,一个连接的QPS大约是1000
        max-active: 50
        #连接池中的最大空闲连接
        #建议和最大连接数一致,这样做的好处是连接数从不减少,从而避免了连接池伸缩产生的性能开销。
        max-idle: 10
        #连接池中的最小空闲连接
        #建议为0,在无请求的状况下从不创建链接
        min-idle: 0
        #连接池最大阻塞等待时间 毫秒(-1表示没有限制)
        #建议不要为-1,连接池占满后无法获取连接时将在该时间内阻塞等待,超时后将抛出异常。
        max-wait: 10000
#mubatis配置
mybatis-plus:
  # MyBaits 别名包扫描路径,通过该属性可以给包中的类注册别名
  type-aliases-package: com.itheima.springcloud.pojo
  # 该配置请和 typeAliasesPackage 一起使用,如果配置了该属性,则仅仅会扫描路径下以该类作为父类的域对象 。
  type-aliases-super-type: com.itheima.springcloud.basic.BasicPojo
  configuration:
    # 这个配置会将执行的sql打印出来,在开发或测试的时候可以用
    log-impl: org.apache.ibatis.logging.slf4j.Slf4jImpl
    # 驼峰下划线转换
    map-underscore-to-camel-case: true
    use-generated-keys: true
    default-statement-timeout: 60
    default-fetch-size: 100
  global-config:
    db-config:
      #主键类型(雪花ID)
      id-type: assign_id
    #机器 ID 部分(影响雪花ID)
    worker-id: 1
    #数据标识 ID 部分(影响雪花ID)
    datacenter-id: 1
logging:
  config: classpath:logback-8083.xml
#注册中心
eureka:
  client:
    service-url:
      defaultZone: http://eureka2:8082/eureka/,http://eureka1:8081/eureka/
    #表示eureka client间隔多久去拉取服务注册信息,默认为30秒,
    #对于api-gateway,如果要迅速获取服务注册状态,可以缩小该值,比如5秒
#    registry-fetch-interval-seconds: 15

在module-business-service修改

itheima:
  framework:
    oss:
      bucket-name: itheima-sh-oss
      access-key-id: LTAI4G2g6WqYBZyZMovev1pd
      access-key-secret: 2Q4x5TpgHRP8Eo3ehQzCJxPteBl4R4
      endpoint: oss-cn-shanghai.aliyuncs.com
      web-site: https://itheima-sh-oss.oss-cn-shanghai.aliyuncs.com/
      proxy-username: aliyun-sdk-java
      socket-timeout: 10000
      idle-connection-time: 10000
      connection-request-timeout: 4000
      max-connections: 2048
      max-error-retry: 5
      white-list: 127.0.0.1
      connection-timeout: 10000
    swagger:
      swagger-path: com.itheima.springcloud.web
#服务配置
server:
  #端口
  port: 8089
  #服务编码
  tomcat:
    uri-encoding: UTF-8
#spring相关配置
spring:
  #应用配置
  application:
    #应用名称
    name: module-business-service
  main:
    allow-bean-definition-overriding: true
  jta:
    atomikos:
      properties:
        log-base-dir: D:/home/module-business-service-atomikos
        log-base-name: module-business-service
  shardingsphere:
    datasource:
      names: ds0,ds1
      ds0:
        type: com.alibaba.druid.pool.DruidDataSource
        driverClassName: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost:3306/spring-boot_0?useAffectedRows=true&serverTimezone=UTC
        username: root
        password: root
      ds1:
        type: com.alibaba.druid.pool.DruidDataSource
        driverClassName: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost:3306/spring-boot_1?useAffectedRows=true&serverTimezone=UTC
        username: root
        password: root
    #分库分表
    sharding:
      tables:
        tab_route:
          actualDataNodes: ds${0..1}.tab_route_${0..1}
          databaseStrategy:
            inline:
              shardingColumn: sharding_id
              algorithmExpression: ds${sharding_id % 2}
          tableStrategy:
            inline:
              shardingColumn: id
              algorithmExpression: tab_route_${id % 2}
          keyGenerator:
            type: SNOWFLAKE
            column: id
      binding-tables:
        - tab_route
      broadcast-tables:
        - tab_affix
        - tab_category
        - tab_favorite
      default-key-generator:
        type: SNOWFLAKE
        column: id
    props:
      sql.show: true
  redis:
    host: 127.0.0.1 #Redis服务器地址
    port: 7379 #Redis服务器连接端口
    timeout: 2000 #请求redis服务的超时时间,这里注意设置成0时取默认时间2000
    lettuce:
      pool:
        #连接池最大连接数(使用负值表示没有限制)
        #建议为业务期望QPS/一个连接的QPS,例如50000/1000=50
        #一次命令时间(borrow|return resource+Jedis执行命令+网络延迟)的平均耗时约为1ms,一个连接的QPS大约是1000
        max-active: 50
        #连接池中的最大空闲连接
        #建议和最大连接数一致,这样做的好处是连接数从不减少,从而避免了连接池伸缩产生的性能开销。
        max-idle: 10
        #连接池中的最小空闲连接
        #建议为0,在无请求的状况下从不创建链接
        min-idle: 0
        #连接池最大阻塞等待时间 毫秒(-1表示没有限制)
        #建议不要为-1,连接池占满后无法获取连接时将在该时间内阻塞等待,超时后将抛出异常。
        max-wait: 10000
#mubatis配置
mybatis-plus:
  # MyBaits 别名包扫描路径,通过该属性可以给包中的类注册别名
  type-aliases-package: com.itheima.springcloud.pojo
  # 该配置请和 typeAliasesPackage 一起使用,如果配置了该属性,则仅仅会扫描路径下以该类作为父类的域对象 。
  type-aliases-super-type: com.itheima.springcloud.basic.BasicPojo
  configuration:
    # 这个配置会将执行的sql打印出来,在开发或测试的时候可以用
    log-impl: org.apache.ibatis.logging.slf4j.Slf4jImpl
    # 驼峰下划线转换
    map-underscore-to-camel-case: true
    use-generated-keys: true
    default-statement-timeout: 60
    default-fetch-size: 100
  global-config:
    db-config:
      #主键类型(雪花ID)
      id-type: assign_id
    #机器 ID 部分(影响雪花ID)
    worker-id: 1
    #数据标识 ID 部分(影响雪花ID)
    datacenter-id: 1
#注册中心
eureka:
  client:
    service-url:
      defaultZone: http://eureka2:8082/eureka/,http://eureka1:8081/eureka/
    #表示eureka client间隔多久去拉取服务注册信息,默认为30秒,
    #对于api-gateway,如果要迅速获取服务注册状态,可以缩小该值,比如5秒
#    registry-fetch-interval-seconds: 15
logging:
  config: classpath:logback.xml

results matching ""

    No results matching ""