分库分表Sharding-JDBC最佳实践专题

一 Mysql数据库架构演变历史

• 单机

  • 请求量大查询慢
  • 单机故障导致业务不可用

• 主从

  • 数据库主从同步，从库可以水平扩展，满足更大读需求
  • 但单服务器TPS，内存，IO都是有限的

• 双主

  • 用户量级上来后，写请求越来越多

  • 一个Master是不能解决问题的，添加多了个主节点进行写入，

  • 多个主节点数据要保存一致性，写操作需要2个master之间同步更加复杂

• 分库和分表
   

二 业务增长-数据库性能优化思路讲解

2.1 这边有个数据库-单表1千万数据，未来1年还会增长多500万，性能比较慢，说下你的优化思路

• 思路

  • 千万不要一上来就说分库分表，这个是最忌讳的事项

  • 一定要根据实际情况分析，两个角度思考

    • 不分库分表

      • 软优化

        • 数据库参数调优
        • 分析慢查询SQL语句，分析执行计划，进行sql改写和程序改写
        • 优化数据库索引结构
        • 优化数据表结构优化
        • 引入NOSQL和程序架构调整

      • 硬优化

        • 提升系统硬件（更快的IO、更多的内存）：带宽、CPU、硬盘

    • 分库分表

      • 根据业务情况而定，选择合适的分库分表策略（没有通用的策略）

        • 外卖、物流、电商领域

      • 先看只分表是否满足业务的需求和未来增长

        • 数据库分表能够解决单表数据量很大的时,数据查询的效率问题，
        • 无法给数据库的并发操作带来效率上的提高，分表的实质还是在一个数据库上进行的操作，受数据库IO性能的限制

      • 如果单分表满足不了需求，再分库分表一起

• 结论

  • 在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案
  • 如果数据量极大，且业务持续增长快，再考虑分库分表方案

三 Mysql数据库分库分表后带来的优点

3.1 分库分表解决的现状问题

• 解决数据库本身瓶颈

  • 连接数： 连接数过多时，就会出现‘too many connections’的错误，访问量太大或者数据库设置的最大连接数太小的原因

  • Mysql默认的最大连接数为100.可以修改，而mysql服务允许的最大连接数为16384

  • 数据库分表可以解决单表海量数据的查询性能问题

  • 数据库分库可以解决单台数据库的并发访问压力问题

• 解决系统本身IO、CPU瓶颈

  • 磁盘读写IO瓶颈，热点数据太多，尽管使用了数据库本身缓存，但是依旧有大量IO,导致sql执行速度慢

  • 网络IO瓶颈，请求的数据太多，数据传输大，网络带宽不够，链路响应时间变长

  • CPU瓶颈，尤其在基础数据量大单机复杂SQL计算，SQL语句执行占用CPU使用率高，也有扫描行数大、锁冲突、锁等待等原因

    • 可以通过 show processlist; 、show full processlist，发现 CPU 使用率比较高的SQL
    • 常见的对于查询时间长，State 列值是 Sending data，Copying to tmp table，Copying to tmp table on disk，Sorting result，Using filesort 等都是可能有性能问题SQL，清楚相关影响问题的情况可以kill掉
    • 也存在执行时间短，但是CPU占用率高的SQL，通过上面命令查询不到，这个时候最好通过执行计划分析explain进行分析

四 Mysql数据库分库分表后的六大问题你是否知道怎么解决

• 问题一：跨节点数据库Join关联查询

  • 数据库切分前，多表关联查询，可以通过sql join进行实现
  • 分库分表后，数据可能分布在不同的节点上，sql join带来的问题就比较麻烦

• 问题二：分库操作带来的分布式事务问题

  • 操作内容同时分布在不同库中，不可避免会带来跨库事务问题，即分布式事务

• 问题三：执行的SQL排序、翻页、函数计算问题

  • 分库后，数据分布再不同的节点上， 跨节点多库进行查询时，会出现limit分页、order by排序等问题
  • 而且当排序字段非分片字段时，更加复杂了，要在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序（也会带来更多的CPU/IO资源损耗）

• 问题四：数据库全局主键重复问题

  • 常规表的id是使用自增id进行实现，分库分表后，由于表中数据同时存在不同数据库中，如果用自增id，则会出现冲突问题

• 问题五：容量规划,分库分表后二次扩容问题

  • 业务发展快，初次分库分表后，满足不了数据存储，导致需要多次扩容

• 问题六：分库分表技术选型问题

  • 市场分库分表中间件相对较多，框架各有各的优势与短板，应该如何选择

五 海量数据处理之Mysql数据库【垂直分表】讲解

• 需求：商品表字段太多，每个字段访问频次不一样，浪费了IO资源，需要进行优化

• 垂直分表介绍

  • 也就是“大表拆小表”，基于列字段进行的

  • 拆分原则一般是表中的字段较多，将不常用的或者数据较大，长度较长的拆分到“扩展表 如text类型字段

  • 访问频次低、字段大的商品描述信息单独存放在一张表中，访问频次较高的商品基本信息单独放在一张表中

  • 垂直拆分原则

    • 把不常用的字段单独放在一张表;
    • 把text，blob等大字段拆分出来放在附表中;
    • 业务经常组合查询的列放在一张表中

  • 例子：商品详情一般是拆分主表和附表

//拆分前
CREATE TABLE `product` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `title` varchar(524) DEFAULT NULL COMMENT '视频标题',
  `cover_img` varchar(524) DEFAULT NULL COMMENT '封面图',
  `price` int(11) DEFAULT NULL COMMENT '价格,分',
  `total` int(10) DEFAULT '0' COMMENT '总库存',
  `left_num` int(10) DEFAULT '0' COMMENT '剩余',
  
  `learn_base` text COMMENT '课前须知，学习基础',
  `learn_result` text COMMENT '达到水平',
  `summary` varchar(1026) DEFAULT NULL COMMENT '概述',  
  `detail` text COMMENT '视频商品详情',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;


//拆分后
CREATE TABLE `product` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `title` varchar(524) DEFAULT NULL COMMENT '视频标题',
  `cover_img` varchar(524) DEFAULT NULL COMMENT '封面图',
  `price` int(11) DEFAULT NULL COMMENT '价格,分',
  `total` int(10) DEFAULT '0' COMMENT '总库存',
  `left_num` int(10) DEFAULT '0' COMMENT '剩余',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

CREATE TABLE `product_detail` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `product_id` int(11) DEFAULT NULL COMMENT '产品主键',
  `learn_base` text COMMENT '课前须知，学习基础',
  `learn_result` text COMMENT '达到水平',
  `summary` varchar(1026) DEFAULT NULL COMMENT '概述',  
  `detail` text COMMENT '视频商品详情',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

六 海量数据处理之Mysql数据库【垂直分库】讲解

• 需求：C端项目里面，单个数据库的CPU、内存长期处于90%+的利用率，数据库连接经常不够，需要进行优化

• 垂直分库讲解

  • 垂直分库针对的是一个系统中的不同业务进行拆分， 数据库的连接资源比较宝贵且单机处理能力也有限

  • 没拆分之前全部都是落到单一的库上的，单库处理能力成为瓶颈，还有磁盘空间，内存，tps等限制

  • 拆分之后，避免不同库竞争同一个物理机的CPU、内存、网络IO、磁盘，所以在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈

  • 垂直分库可以更好解决业务层面的耦合，业务清晰，且方便管理和维护

  • 一般从单体项目升级改造为微服务项目，就是垂直分库

  • 问题：垂直分库分表可以提高并发，但是依然没有解决单表数据量过大的问题

七 海量数据处理之Mysql数据库【水平分表】讲解

• 需求：当一张表的数据达到几千万时，查询一次所花的时间长，需要进行优化，缩短查询时间

• 都是大表拆小表

  • 垂直分表：表结构拆分
  • 水平分表：数据拆分

• 水平分表

  • 把一个表的数据分到一个数据库的多张表中，每个表只有这个表的部分数据

  • 核心是把一个大表，分割N个小表，每个表的结构是一样的，数据不一样，全部表的数据合起来就是全部数据

  • 针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去

  • 但是这些表还是在同一个库中，所以单数据库操作还是有IO瓶颈，主要是解决单表数据量过大的问题

  • 减少锁表时间，没分表前，如果是DDL(create/alter/add等)语句，当需要添加一列的时候mysql会锁表，期间所有的读写操作只能等待

八 海量数据处理之Mysql数据库【水平分库】讲解

• 需求：高并发的项目中，水平分表后依旧在单个库上面，1个数据库资源瓶颈 CPU/内存/带宽等限制导致响应慢，需要进行优化

• 水平分库

  • 把同个表的数据按照一定规则分到不同的数据库中，数据库在不同的服务器上
  • 水平分库是把不同表拆到不同数据库中，它是对数据行的拆分，不影响表结构
  • 每个库的结构都一样,但每个库的数据都不一样，没有交集，所有库的并集就是全量数据
  • 水平分库的粒度，比水平分表更大

九 Mysql数据库水平分库分表常见策略介绍-range

方案一：自增id，根据ID范围进行分表（左闭右开）

• 规则案例

  • 1~1,000,000 是 table_1
  • 1,000,000 ~2,000,000 是 table_2
  • 2,000,000~3,000,000 是 table_3
  • ...更多

• 优点

  • id是自增长，可以无限增长
  • 扩容不用迁移数据，容易理解和维护

• 缺点

  • 大部分读和写都访会问新的数据，有IO瓶颈，整体资源利用率低

  • 数据倾斜严重，热点数据过于集中，部分节点有瓶颈

• 范围角度思考问题 (范围的话更多是水平分表)

  • 数字

    • 自增id范围

  • 时间

    • 年、月、日范围
    • 比如按照月份生成 库或表 pay_log_2022_01、pay_log_2022_02

  • 空间

    • 地理位置：省份、区域（华东、华北、华南）
    • 比如按照 省份 生成 库或表

• 基于Range范围分库分表业务场景

  • 微博发送记录、微信消息记录、日志记录，id增长/时间分区都行

    • 水平分表为主，水平分库则容易造成资源的浪费

  • 网站签到等活动流水数据时间分区最好

    • 水平分表为主，水平分库则容易造成资源的浪费

  • 大区划分（一二线城市和五六线城市活跃度不一样，如果能避免热点问题，即可选择）

    • saas业务水平分库（华东、华南、华北等）

十 Mysql数据库水平分库分表策略介绍-Hash取模

方案二：hash取模（Hash分库分表是最普遍的方案）

• 为啥不之间取模，如果取模的字段不是整数型要先hash，统一规则就行

• 案例规则

  • 用户ID是整数型的，要分2库，每个库表数量4表，一共8张表
  • 用户ID取模后，值是0到7的要平均分配到每张表

A库ID = userId % 库数量 2 
表ID = userId / 库数量 2 % 表数量4

• 例子

userId	id % 2 (库-取余)	id /2 % 4 (表)
1	1	0
2	0	1
3	1	1
4	0	2
5	1	2
6	0	3
7	1	3
8	0	0
9	1	0

• 优点

  • 保证数据较均匀的分散落在不同的库、表中，可以有效的避免热点数据集中问题，

• 缺点

  • 扩容不是很方便，需要数据迁移

十一 分库分表常见中间件介绍和ShardingSphere极速认知

11.1 业界常见分库分表中间件

• Cobar（已经被淘汰没使用了）

• TDDL

  • 淘宝根据自己的业务特点开发了 TDDL （Taobao Distributed Data Layer）
  • 基于JDBC规范，没有server，以client-jar的形式存在，引入项目即可使用
  • 开源功能比较少，阿里内部使用为主

• Mycat

  • 地址 MyCat2
  • Java语言编写的MySQL数据库网络协议的开源中间件，前身 Cobar
  • 遵守Mysql原生协议，跨语言，跨平台，跨数据库的通用中间件代理
  • 是基于 Proxy，它复写了 MySQL 协议，将 Mycat Server 伪装成一个 MySQL 数据库
  • 和ShardingShere下的Sharding-Proxy作用类似，需要单独部署

• ShardingSphere 下的Sharding-JDBC

  • 地址：https://shardingsphere.apache.org/

  • Apache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈

    它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar 3个独立产品组合

  • Sharding-JDBC

    • 基于jdbc驱动，不用额外的proxy，支持任意实现 JDBC 规范的数据库
    • 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖
    • 可理解为加强版的 JDBC 驱动，兼容 JDBC 和各类 ORM 框架

• 最感兴趣的是Mycat和ShardingJdbc区别，也是被面试官问比较多的

  • 两者设计理念相同，主流程都是SQL解析-->SQL路由-->SQL改写-->结果归并

  • sharding-jdbc

    • 基于jdbc驱动，不用额外的proxy，在本地应用层重写Jdbc原生的方法，实现数据库分片形式
    • 是基于 JDBC 接口的扩展，是以 jar 包的形式提供轻量级服务的，性能高
    • 代码有侵入性

  • Mycat

    • 是基于 Proxy，它复写了 MySQL 协议，将 Mycat Server 伪装成一个 MySQL 数据库
    • 客户端所有的jdbc请求都必须要先交给MyCat，再有MyCat转发到具体的真实服务器
    • 缺点是效率偏低，中间包装了一层
    • 代码无侵入性

  • 什么是ShardingSphere

    • 已于2020年4月16日成为 Apache 软件基金会的顶级项目，懂的都懂
    • 是一套开源的分布式数据库解决方案组成的生态圈，定位为 Database Plus
    • 它由 JDBC、Proxy 和 Sidecar这 3 款既能够独立部署，又支持混合部署配合使用的产品组成

11.2 三大构成（下面图片素材来源 sharding-sphere官网）

• ShardingSphere-Sidecar(规划中，简单知道就行)

  • 定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问
  • 通过无中心、零侵入的方案提供与数据库交互的啮合层，即 Database Mesh，又可称数据库网格

• ShardingSphere-JDBC

  • 它使用客户端直连数据库，以 jar 包形式提供服务

  • 无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架

  • 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis,或直接使用 JDBC

  • 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, HikariCP 等；

  • 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，PostgreSQL，Oracle，SQLServer 以及任何可使用 JDBC 访问的数据库

  • 采用无中心化架构，与应用程序共享资源，适用于 Java 开发的高性能的轻量级 OLTP 应用

• ShardingSphere-Proxy

  • 数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持
  • 向应用程序完全透明，可直接当做 MySQL/PostgreSQL
  • 它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端（如：MySQL Command Client, MySQL Workbench, Navicat 等）操作数据

• 三大组件对比

 11.3 分库分表和Sharding-Jdbc常见概念术语讲解

• 数据节点Node

  • 数据分片的最小单元，由数据源名称和数据表组成
  • 比如：ds_0.product_order_0

• 真实表

  • 在分片的数据库中真实存在的物理表
  • 比如订单表 product_order_0、product_order_1、product_order_2

• 逻辑表

  • 水平拆分的数据库（表）的相同逻辑和数据结构表的总称
  • 比如订单表 product_order_0、product_order_1、product_order_2，逻辑表就是product_order

• 绑定表

  • 指分片规则一致的主表和子表
  • 比如product_order表和product_order_item表，均按照order_id分片，则此两张表互为绑定表关系
  • 绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升

• 广播表

  • 指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致
  • 适用于数据量不大且需要与海量数据的表进行关联查询的场景
  • 例如：字典表、配置表

11.4 分库分表和Sharding-Jdbc常见分片算法讲解

• 数据库表分片（水平库、表）

  • 包含分片键和分片策略

• 分片键 (PartitionKey)

  • 用于分片的数据库字段，是将数据库(表)水平拆分的关键字段
  • 比如prouduct_order订单表，根据订单号 out_trade_no做哈希取模，则out_trade_no是分片键
  • 除了对单分片字段的支持，ShardingSphere也支持根据多个字段进行分片

• 分片策略（先了解，后面有案例实战）
  

• 行表达式分片策略 InlineShardingStrategy（必备）

  • 只支持【单分片键】使用Groovy的表达式，提供对SQL语句中的 =和IN 的分片操作支持

  • 可以通过简单的配置使用，无需自定义分片算法，从而避免繁琐的Java代码开发

prouduct_order_$->{user_id % 8}` 表示订单表根据user_id模8，而分成8张表，表名称为`prouduct_order_0`到`prouduct_order_7

• 标准分片策略StandardShardingStrategy（需了解）

  • 只支持【单分片键】，提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法
  • PreciseShardingAlgorithm 精准分片 是必选的，用于处理=和IN的分片
  • RangeShardingAlgorithm 范围分配 是可选的，用于处理BETWEEN AND分片
  • 如果不配置RangeShardingAlgorithm，如果SQL中用了BETWEEN AND语法，则将按照全库路由处理，性能下降

• 复合分片策略ComplexShardingStrategy（需了解）

  • 支持【多分片键】，多分片键之间的关系复杂，由开发者自己实现，提供最大的灵活度
  • 提供对SQL语句中的=, IN和BETWEEN AND的分片操作支持

• Hint分片策略HintShardingStrategy（需了解）

  • 这种分片策略无需配置分片健，分片健值也不再从 SQL中解析，外部手动指定分片健或分片库，让 SQL在指定的分库、分表中执行

  • 用于处理使用Hint行分片的场景，通过Hint而非SQL解析的方式分片的策略

  • Hint策略会绕过SQL解析的，对于这些比较复杂的需要分片的查询，Hint分片策略性能可能会更好

• 不分片策略 NoneShardingStrategy（需了解）

  • 不分片的策略。

十二 SpringBoot2.5+MybatisPlus整合Sharding-Jdbc实战

 
        
        11
        11
        11
        2.5.5
        3.4.0
        1.18.16
        4.1.1
        4.12
        1.1.16
        
        true
    

• maven pom文件配置

        
            org.springframework.boot
            spring-boot-starter-web
            ${spring.boot.version}
        

        
            
            
        

        
            org.springframework.boot
            spring-boot-starter-test
            ${spring.boot.version}
            test
        


        
        
            com.baomidou
            mybatis-plus-boot-starter
            ${mybatisplus.boot.starter.version}
        

        
            mysql
            mysql-connector-java
            8.0.27
        

        
            org.projectlombok
            lombok
            ${lombok.version}
            
        

        
            org.apache.shardingsphere
            sharding-jdbc-spring-boot-starter
            ${sharding-jdbc.version}
        

        
            junit
            junit
            ${junit.version}
        
    

    
        
            
                org.springframework.boot
                spring-boot-maven-plugin
                ${spring.boot.version}
                
                    true
                    true
                
            

        
    

12.1 订单数据库讲解和分库分表SQL脚本创建说明

• 分库分表需求

  • 2库2表

• 数据库

  • xdclass_shop_order_0

    • product_order_0

    • product_order_1

  • xdclass_shop_order_1

    • product_order_0

    • product_order_1

  • 脚本

    CREATE TABLE `product_order_0` (
      `id` bigint NOT NULL AUTO_INCREMENT,
      `out_trade_no` varchar(64) DEFAULT NULL COMMENT '订单唯一标识',
      `state` varchar(11) DEFAULT NULL COMMENT 'NEW 未支付订单,PAY已经支付订单,CANCEL超时取消订单',
      `create_time` datetime DEFAULT NULL COMMENT '订单生成时间',
      `pay_amount` decimal(16,2) DEFAULT NULL COMMENT '订单实际支付价格',
      `nickname` varchar(64) DEFAULT NULL COMMENT '昵称',
      `user_id` bigint DEFAULT NULL COMMENT '用户id',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
    

  • 实体类

@Data
@EqualsAndHashCode(callSuper = false)
@TableName("product_order")
public class ProductOrderDO {

    @TableId(value = "id", type = IdType.AUTO)
    private Long id;

    private String outTradeNo;

    private String state;

    private Date createTime;

    private Double payAmount;

    private String nickname;

    private Long userId;

}

//数据库实体类
public interface ProductOrderMapper extends BaseMapper {

}

 12.2 Sharding-Jdbc常规数据源配置和水平分表实战

server.port=8080
spring.application.name=xdclass-jdbc

logging.level.root=INFO
# 打印执行的数据库以及语句
spring.shardingsphere.props.sql.show=true

# 数据源 db0
spring.shardingsphere.datasource.names=ds0
# 第一个数据库
spring.shardingsphere.datasource.ds0.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.ds0.jdbc-url=jdbc:mysql://165.25.317.15:3306/shop_order_0?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
spring.shardingsphere.datasource.ds0.username=root
spring.shardingsphere.datasource.ds0.password=root



# 指定product_order表的数据分布情况，配置数据节点,行表达式标识符使用 ${...} 或 $->{...}，但前者与 Spring 本身的文件占位符冲突，所以在 Spring 环境中建议使用 $->{...}
spring.shardingsphere.sharding.tables.product_order.actual-data-nodes=ds0.product_order_$->{0..1}
# 指定product_order表的分片策略，分片策略包括【分片键和分片算法】 
spring.shardingsphere.sharding.tables.product_order.table-strategy.inline.sharding-column=user_id
spring.shardingsphere.sharding.tables.product_order.table-strategy.inline.algorithm-expression=product_order_$->{user_id % 2}

 12.3 SpringBoot+Sharding-Jdbc单元测试和问题点引出

@RunWith(SpringRunner.class)  //底层用junit  SpringJUnit4ClassRunner
@SpringBootTest(classes = DemoApplication.class)
@Slf4j
public class DbTest {

    @Autowired
    private ProductOrderMapper productOrderMapper;

    @Test
    public void testSaveProductOrder(){

        for(int i=0;i<10;i++){
            ProductOrder productOrder = new ProductOrder();
            productOrder.setCreateTime(new Date());
            productOrder.setNickname("i="+i);
            productOrder.setOutTradeNo(UUID.randomUUID().toString().substring(0,32));
            productOrder.setPayAmount(100.00);
            productOrder.setState("PAY");
            productOrder.setUserId(Long.valueOf(i+""));
            productOrderMapper.insert(productOrder);
        }
    }
}

• 控制台SQL

  • Logic SQL : 逻辑SQL，没具体到哪个数据节点
  • Actual SQL：真实SQL, 具体到每个数据节点的SQL

12.4 分库分表下常见主键id生产策略讲解 

• 单库下一般使用Mysql自增ID, 但是分库分表后，会造成不同分片上的数据表主键会重复。

• 需求

  • 性能强劲
  • 全局唯一
  • 防止恶意用户规矩id的规则来获取数据

• 业界常用ID解决方案

• 数据库自增ID

  • 利用自增id, 设置不同的自增步长，auto_increment_offset、auto-increment-increment

DB1: 单数
//从1开始、每次加2

DB2: 偶数
//从2开始，每次加2

• 缺点

  • 依靠数据库系统的功能实现，但是未来扩容麻烦
  • 主从切换时的不一致可能会导致重复发号
  • 性能瓶颈存在单台sql上

• UUID

  • 性能非常高，没有网络消耗

  • 缺点

    • 无序的字符串，不具备趋势自增特性
    • UUID太长，不易于存储，浪费存储空间，很多场景不适用

• Redis发号器

  • 利用Redis的INCR和INCRBY来实现，原子操作，线程安全，性能比Mysql强劲

  • 缺点

    • 需要占用网络资源，增加系统复杂度

• Snowflake雪花算法

  • twitter 开源的分布式 ID 生成算法，代码实现简单、不占用宽带、数据迁移不受影响

  • 生成的 id 中包含有时间戳，所以生成的 id 按照时间递增

  • 部署了多台服务器，需要保证系统时间一样，机器编号不一样

  • 缺点

    • 依赖系统时钟（多台服务器时间一定要一样）