mysql分库分表方案（第十四/十五章/十六章/十七章/十八章）海量数据处理-商用短链

第十四章初恋的感觉-海量数据下的分库分表知识阶段一

第1集账号微服务里面的流量包业务模型梳理和需求讲解

简介：账号微服务里面的流量包业务模型梳理和需求讲解

流量包业务模型梳理

数据量预估（尽量一次性扩容预估好，数据迁移成本大）
- 未来2年，短链平台累计5百万用户
  - 一个用户10条记录/年，总量就是5千万条
  - 单表不超过1千万数据，需要分5张表
  - 进一步延伸，进行水平分表，比如 2张表、4张表、8张表、16张表
- 因为业务逻辑复杂，我们就不分那么多表，分2表操作即可
问题
- 分库分表怎么分？有哪些形式呢? 还会带来哪些问题？
- 比如 2张表、4张表、8张表、16张表这样的思路？
- …更多问题

第2集【面试题】业务增长-数据库性能优化思路讲解

简介：【面试题】业务增长-数据库性能优化思路讲解

面试官：这边有个数据库-单表1千万数据，未来1年还会增长多500万，性能比较慢，说下你的优化思路
思路
- 千万不要一上来就说分库分表，这个是最忌讳的事项
- 一定要根据实际情况分析，两个角度思考
  - 不分库分表
    - 软优化
      - 数据库参数调优
      - 分析慢查询SQL语句，分析执行计划，进行sql改写和程序改写
      - 优化数据库索引结构
      - 优化数据表结构优化
      - 引入NOSQL和程序架构调整
    - 硬优化
      - 提升系统硬件（更快的IO、更多的内存）：带宽、CPU、硬盘
  - 分库分表
    - 根据业务情况而定，选择合适的分库分表策略（没有通用的策略）
      - 外卖、物流、电商领域
    - 先看只分表是否满足业务的需求和未来增长
      - 数据库分表能够解决单表数据量很大的时,数据查询的效率问题，
      - 无法给数据库的并发操作带来效率上的提高，分表的实质还是在一个数据库上进行的操作，受数据库IO性能的限制
    - 如果单分表满足不了需求，再分库分表一起
结论
- 在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案
- 如果数据量极大，且业务持续增长快，再考虑分库分表方案

第3集走进Mysql数据库分库分表后带来的优点和缺点《上》

简介：走进Mysql数据库分库分表后带来的优点和缺点《上》

分库分表解决的现状问题
- 解决数据库本身瓶颈
  - 连接数：连接数过多时，就会出现‘too many connections’的错误，访问量太大或者数据库设置的最大连接数太小的原因
    - 大家学第一个大课，或者微服务的时候没物理分库，多数都出现上述问题，
  - Mysql默认的最大连接数为100.可以修改，而mysql服务允许的最大连接数为16384
  - 数据库分表可以解决单表海量数据的查询性能问题
  - 数据库分库可以解决单台数据库的并发访问压力问题
- 解决系统本身IO、CPU瓶颈
  - 磁盘读写IO瓶颈，热点数据太多，尽管使用了数据库本身缓存，但是依旧有大量IO,导致sql执行速度慢
  - 网络IO瓶颈，请求的数据太多，数据传输大，网络带宽不够，链路响应时间变长
  - CPU瓶颈，尤其在基础数据量大单机复杂SQL计算，SQL语句执行占用CPU使用率高，也有扫描行数大、锁冲突、锁等待等原因

第4集走进Mysql数据库分库分表后带来的优点和缺点《下》

简介：走进Mysql数据库分库分表后带来的优点和缺点《下》

带来新的问题
- 问题一：跨节点数据库Join关联查询和多维度查询
  - 数据库切分前，多表关联查询，可以通过sql join进行实现
  - 分库分表后，数据可能分布在不同的节点上，sql join带来的问题就比较麻烦
不同维度查看数据，利用的partitionKey是不一样的
- 例如
  - 订单表的partionKey是user_id，用户查看自己的订单列表方便
  - 但商家查看自己店铺的订单列表就麻烦，分布在不同数据节点

问题二：分库操作带来的分布式事务问题
- 操作内容同时分布在不同库中，不可避免会带来跨库事务问题，即分布式事务
问题三：执行的SQL排序、翻页、函数计算问题
- 分库后，数据分布再不同的节点上，跨节点多库进行查询时，会出现limit分页、order by排序等问题
- 而且当排序字段非分片字段时，更加复杂了，要在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序（也会带来更多的CPU/IO资源损耗）
问题四：数据库全局主键重复问题
- 常规表的id是使用自增id进行实现，分库分表后，由于表中数据同时存在不同数据库中，如果用自增id，则会出现冲突问题
问题五：容量规划,分库分表后二次扩容问题
- 业务发展快，初次分库分表后，满足不了数据存储，导致需要多次扩容
问题六：分库分表技术选型问题
- 市场分库分表中间件相对较多，框架各有各的优势与短板，应该如何选择
  - 更多问题。。。

第5集海量数据处理之Mysql【垂直分表-垂直分库】讲解

简介：海量数据处理之Mysql数据库垂直分表和分库讲解

需求：商品表字段太多，每个字段访问频次不一样，浪费了IO资源，需要进行优化
垂直分表介绍
- 也就是“大表拆小表”，基于列字段进行的
- 拆分原则一般是表中的字段较多，将不常用的或者数据较大，长度较长的拆分到“扩展表如text类型字段
- 访问频次低、字段大的商品描述信息单独存放在一张表中;
- 访问频次较高的商品基本信息单独放在一张表中
- 垂直拆分原则
  - 把不常用的字段单独放在一张表;
  - 把text，blob等大字段拆分出来放在附表中;
  - 业务经常组合查询的列放在一张表中
- 例子：商品详情一般是拆分主表和附表

代码语言：javascript复制

//拆分前
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;

需求：C端项目里面，单个数据库的CPU、内存长期处于90% 的利用率，数据库连接经常不够，需要进行优化
垂直分库讲解
- 垂直分库针对的是一个系统中的不同业务进行拆分，数据库的连接资源比较宝贵且单机处理能力也有限
- 没拆分之前全部都是落到单一的库上的，单库处理能力成为瓶颈，还有磁盘空间，内存，tps等限制
- 拆分之后，避免不同库竞争同一个物理机的CPU、内存、网络IO、磁盘，所以在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈
- 垂直分库可以更好解决业务层面的耦合，业务清晰，且方便管理和维护
- 一般从单体项目升级改造为微服务项目，就是垂直分库

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

第6集海量数据处理之Mysql【水平分表-水平分库】讲解

简介：海量数据处理之Mysql【水平分表-水平分库】讲解

需求：当一张表的数据达到几千万时，查询一次所花的时间长，需要进行优化，缩短查询时间
都是大表拆小表
- 垂直分表：表结构拆分
- 水平分表：数据拆分
水平分表
- 把一个表的数据分到一个数据库的多张表中，每个表只有这个表的部分数据
- 核心是把一个大表，分割N个小表，每个表的结构是一样的，数据不一样，全部表的数据合起来就是全部数据
- 针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去
- 但是这些表还是在同一个库中，所以单数据库操作还是有IO瓶颈，主要是解决单表数据量过大的问题
- 减少锁表时间，没分表前，如果是DDL(create/alter/add等)语句，当需要添加一列的时候mysql会锁表，期间所有的读写操作只能等待
需求：高并发的项目中，水平分表后依旧在单个库上面，1个数据库资源瓶颈 CPU/内存/带宽等限制导致响应慢，需要进行优化
水平分库
- 把同个表的数据按照一定规则分到不同的数据库中，数据库在不同的服务器上
- 水平分库是把不同表拆到不同数据库中，它是对数据行的拆分，不影响表结构
- 每个库的结构都一样,但每个库的数据都不一样，没有交集，所有库的并集就是全量数据
- 水平分库的粒度，比水平分表更大

第十五章如漆似胶-海量数据下的分库分表策略讲解

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

简介： 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瓶颈，整体资源利用率低
  - 数据倾斜严重，热点数据过于集中，部分节点有瓶颈

第2集 Mysql数据库水平分库分表策略介绍-Range延伸进阶

简介： Mysql数据库水平分库分表常见策略介绍-range延伸

Range范围分库分表，有热点问题，所以这个没用？
- 关于怎么选择分库分表策略问题，如果业务适合就行，没有万能策略！！！！
- 基于方案一：自增id，根据ID范围进行分表延伸解决方案，你能想到多少种
范围角度思考问题 (范围的话更多是水平分表)
- 数字
  - 自增id范围
- 时间
  - 年、月、日范围
  - 比如按照月份生成库或表 pay_log_2022_01、pay_log_2022_02
- 空间
  - 地理位置：省份、区域（华东、华北、华南）
  - 比如按照省份生成库或表
基于Range范围分库分表业务场景
- 微博发送记录、微信消息记录、日志记录，id增长/时间分区都行
  - 水平分表为主，水平分库则容易造成资源的浪费
- 网站签到等活动流水数据时间分区最好
  - 水平分表为主，水平分库则容易造成资源的浪费
- 大区划分（一二线城市和五六线城市活跃度不一样，如果能避免热点问题，即可选择）
  - saas业务水平分库（华东、华南、华北等）

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

简介： Mysql数据库水平分库分表常见策略介绍-Hash取模

方案二：hash取模（Hash分库分表是最普遍的方案）
- 为啥不之间取模，如果取模的字段不是整数型要先hash，统一规则就行

案例规则

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

代码语言：javascript复制

库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

优点

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

缺点

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

更多架构课程请访问 xdclass.net

第十六章热恋的感觉-海量数据下的分库分表技术栈讲解

第1集大话业界常见数据库分库分表中间件介绍

简介：大话业界常见分库分表中间件介绍

业界常见分库分表中间件
- Cobar（已经被淘汰没使用了）
- TDDL
  - 淘宝根据自己的业务特点开发了 TDDL （Taobao Distributed Data Layer）
  - 基于JDBC规范，没有server，以client-jar的形式存在，引入项目即可使用
  - 开源功能比较少，阿里内部使用为主
- Mycat
  - 地址 http://www.mycat.org.cn/
  - 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转发到具体的真实服务器
  - 缺点是效率偏低，中间包装了一层
  - 代码无侵入性

第2集分库分表中间件Apache ShardingSphere急速认知

简介：分库分表中间件Apache ShardingSphere急速认知

什么是ShardingSphere
- 已于2020年4月16日成为 Apache 软件基金会的顶级项目，懂的都懂
- 是一套开源的分布式数据库解决方案组成的生态圈，定位为 Database Plus
- 它由 JDBC、Proxy 和 Sidecar这 3 款既能够独立部署，又支持混合部署配合使用的产品组成
三大构成（下面图片素材来源 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 等）操作数据

第3集分库分表和Sharding-Jdbc常见概念术语讲解

简介：分库分表和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分片，则此两张表互为绑定表关系
- 绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升

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

第4集分库分表和Sharding-Jdbc常见分片算法讲解

简介：分库分表和Sharding-Jdbc常见分片算法讲解

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

包含分片键和分片策略

分片键 (PartitionKey)

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

分片策略（如果要看各个策略的实际操作，看ShardingSphere专题视频即可）

行表达式分片策略 InlineShardingStrategy

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

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

代码语言：javascript复制

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的分片操作支持
prouduct_order_0_0、prouduct_order_0_1、prouduct_order_1_0、prouduct_order_1_1
Hint分片策略HintShardingStrategy
- 这种分片策略无需配置分片健，分片健值也不再从 SQL中解析，外部手动指定分片健或分片库，让 SQL在指定的分库、分表中执行
- 用于处理使用Hint行分片的场景，通过Hint而非SQL解析的方式分片的策略
- Hint策略会绕过SQL解析的，对于这些比较复杂的需要分片的查询，Hint分片策略性能可能会更好
不分片策略 NoneShardingStrategy
- 不分片的策略。

自己实现分片策略的优缺点

优点：可以根据分片策略代码里面自己拼装真实的数据库、真实的表，灵活控制分片规则
缺点：增加了编码，不规范的sql容易造成全库表扫描，部分sql语法支持不友好

第十七章流量包模块-海量数据下的分库分表《青铜玩法》

第1集账号微服务-流量包模块水平分表需求讲解和开发

简介：账号微服务-流量包模块水平分表需求讲解和开发

需求

未来2年，短链平台累计5百万用户
- 付费流量包记录：一个用户10条/年，总量就是5千万条
- 单表不超过1千万数据，需要分5张表
- 进一步延伸，进行水平分表，比如 2张表、4张表、8张表、16张表
流量包traffic表数据太多，选取可用流量包会影响性能，需要降低单表数据量，进行水平分表
分表数量：线上分8张表，本地分2张表即可
分片key： account_no，查询维度都是根据account_no进行查询
分片策略：行表达式分片策略 InlineShardingStrategy

新建表

traffic_0
traffic_1

代码语言：javascript复制

CREATE TABLE `traffic_0` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `day_limit` int DEFAULT NULL COMMENT '每天限制多少条，短链',
  `day_used` int DEFAULT NULL COMMENT '当天用了多少条，短链',
  `total_limit` int DEFAULT NULL COMMENT '总次数，活码才用',
  `account_no` bigint DEFAULT NULL COMMENT '账号',
  `out_trade_no` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '订单号',
  `level` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '产品层级：FIRST青铜、SECOND黄金、THIRD钻石',
  `expired_date` date DEFAULT NULL COMMENT '过期日期',
  `plugin_type` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '插件类型',
  `product_id` bigint DEFAULT NULL COMMENT '商品主键',
  `gmt_create` datetime DEFAULT CURRENT_TIMESTAMP,
  `gmt_modified` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_trade_no` (`out_trade_no`,`account_no`) USING BTREE,
  KEY `idx_account_no` (`account_no`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

配置

加入 sharding-jdbc依赖包，account项目注释下面的依赖排查

代码语言：javascript复制

          <exclusions>
                <exclusion>
                    <groupId>org.apache.shardingsphere</groupId>
                    <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
                </exclusion>
            </exclusions>

配置文件 (注释之前jdbc单库配置)

代码语言：javascript复制

# 数据源 ds0 第一个数据库
  shardingsphere:
    datasource:
      ds0:
        connectionTimeoutMilliseconds: 30000
        driver-class-name: com.mysql.cj.jdbc.Driver
        idleTimeoutMilliseconds: 60000
        jdbc-url: jdbc:mysql://120.79.150.146:3306/dcloud_account?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
        maintenanceIntervalMilliseconds: 30000
        maxLifetimeMilliseconds: 1800000
        maxPoolSize: 50
        minPoolSize: 50
        password: xdclass.net168
        type: com.zaxxer.hikari.HikariDataSource
        username: root
      names: ds0
    props:
    # 打印执行的数据库以及语句
      sql:
        show: true

    sharding:
      tables:
        traffic:
# 指定traffic表的数据分布情况，配置数据节点,行表达式标识符使用 ${...} 或 $->{...}，但前者与 Spring 本身的文件占位符冲突，所以在 Spring 环境中建议使用 $->{...}
          actual-data-nodes: ds0.traffic_$->{0..1}

第2集账号微服务-流量包模块水平分表策略配置和测试实战

简介：账号微服务-流量包模块水平分表策略配置和测试实战

水平分表策略配置

代码语言：javascript复制

# 水平分表策略 行表达式分片
          table-strategy:
            inline:
              algorithm-expression: traffic_$->{account_no % 2}
              sharding-column: account_no

单元测试

代码语言：javascript复制

  @Autowired
    private TrafficMapper trafficMapper;

    @Test
    public  void testSaveTraffic(){

        Random random = new Random();
        for(int i=0;i<3;i  ) {
            TrafficDO trafficDO = new TrafficDO();
            trafficDO.setAccountNo(Long.valueOf(random.nextInt(1000)));
            trafficMapper.insert(trafficDO);
        }
    }

问题
- 主键id重复

第3集分库分表暴露的问题-ID冲突和分布式id生成介绍

简介：分库分表暴露的问题-ID冲突和分布式id生成

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

需求

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

业界常用ID解决方案

数据库自增ID

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

代码语言：javascript复制

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

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

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

UUID

性能非常高，没有网络消耗
缺点
- 无序的字符串，不具备趋势自增特性
- UUID太长，不易于存储，浪费存储空间，很多场景不适用

Redis发号器

利用Redis的INCR和INCRBY来实现，原子操作，线程安全，性能比Mysql强劲
缺点
- 需要占用网络资源，增加系统复杂度

Snowflake雪花算法

twitter 开源的分布式 ID 生成算法，代码实现简单、不占用宽带、数据迁移不受影响
生成的 id 中包含有时间戳，所以生成的 id 按照时间递增
部署了多台服务器，需要保证系统时间一样，机器编号不一样
缺点
- 依赖系统时钟（多台服务器时间一定要一样）

第4集小D-带你彻底掌握分布式 ID 生成算法Snowflake原理

简介：小D-带你彻底掌握分布式 ID 生成算法Snowflake原理

什么是雪花算法Snowflake
- twitter用scala语言编写的高效生成唯一ID的算法
- 优点
  - 生成的ID不重复
  - 算法性能高
  - 基于时间戳，基本保证有序递增
计算机的基础知识回顾
- bit与byte
  - bit(位)：电脑中存储的最小单位，可以存储二进制中的0或1
  - byte(字节)：一个byte由8个bit组成
- 常规64位系统里面java数据类型存储字节大小
  - int：4 个字节
  - short：2 个字节
  - long：8 个字节
  - byte：1 个字节
  - float：4 个字节
  - double：8 个字节
  - char：2 个字节
- 科普：数据类型在不同位数机器的平台下长度不同（怼面试官的严谨性）
  - 16位平台 int 2个字节16位
  - 32位平台 int 4个字节32位
  - 64位平台 int 4个字节32位
雪花算法生成的数字，long类，所以就是8个byte，64bit
- 表示的值 -9223372036854775808（-2的63次方） ~ 9223372036854775807（2的63次方-1）
- 生成的唯一值用于数据库主键，不能是负数，所以值为0~9223372036854775807（2的63次方-1）

第5集分布式ID生成器Snowflake里面的坑你是否知道

简介：分布式ID生成器Snowflake里面的坑你是否知道

分布式ID生成器需求

性能强劲
全局唯一不能重复
防止恶意用户根据id的规则来获取数据

全局唯一不能重复-坑

坑一
- 分布式部署就需要分配不同的workId, 如果workId相同，可能会导致生成的id相同
坑二：
- 分布式情况下，需要保证各个系统时间一致，如果服务器的时钟回拨，就会导致生成的 id 重复
  - 啥时候会有系统回拨？？？？
    - 小滴课堂-老王闲着，人工去生产环境做了系统时间调整，应该不会这么傻吧
    - 业务需求，代码里面做了系统时间同步

配置实操

代码语言：javascript复制

spring.shardingsphere.sharding.tables.traffic.key-generator.props.worker.id=1

方式一

订单id使用MybatisPlus的配置,TrafficDO类配置

代码语言：javascript复制

@TableId(value = "id", type = IdType.ASSIGN_ID)
默认实现类为DefaultIdentifierGenerator雪花算法

方式二

使用Sharding-Jdbc配置文件,注释DO类里面的id分配策略

代码语言：javascript复制

#id生成策略
          key-generator:
            column: id
            props:
              worker:
                id: 0
            #id生成策略
            type: SNOWFLAKE

第6集分布式ID生成器Snowflake自定义wrokId实战

简介：分布式ID生成器Snowflake自定义wrokId实战

进阶：动态指定sharding jdbc 的雪花算法中的属性work.id属性
- 使用sharding-jdbc中的使用IP后几位来做workId, 但在某些情况下会出现生成重复ID的情况
  - 解决办法时
    - 在启动时给每个服务分配不同的workId, 引入redis/zk都行，缺点就是多了依赖
    - 启动程序的时候，通过JVM参数去控制，覆盖变量

代码语言：javascript复制

@Configuration
public class SnowFlakeWordIdConfig {

    /**
     * 动态指定sharding jdbc 的雪花算法中的属性work.id属性
     * 通过调用System.setProperty()的方式实现,可用容器的 id 或者机器标识位
     * workId最大值 1L << 100，就是1024，即 0<= workId < 1024
     * {@link SnowflakeShardingKeyGenerator#getWorkerId()}
     *
     */
    static {
        try {
            InetAddress ip4 = Inet4Address.getLocalHost();
            String addressIp = ip4.getHostAddress();
            System.setProperty("workerId", (Math.abs(addressIp.hashCode())24) "");
        } catch (UnknownHostException e) {
            throw new BizException(BizCodeEnum.OPS_NETWORK_ADDRESS_ERROR);
        }
    }
}

配置

代码语言：javascript复制

#id生成策略
          key-generator:
            column: id
            props:
              worker:
                id: ${workerId}
            #id生成策略
            type: SNOWFLAKE

第7集 shardingjdbc-Snowflake时间回拨问题解决和封装ID生成器

简介： shardingjdbc-Snowflake时间回拨问题解决和封装ID生成器

shardingjdbc-Snowflake里面解决时间回拨问题

需求
- 用户注册-生成的account_no需要是long类型，且全局唯一
利用Sharding-Jdbc封装id生成器

代码语言：javascript复制

public class IDUtil {

    private static SnowflakeShardingKeyGenerator shardingKeyGenerator = new SnowflakeShardingKeyGenerator();

    /**
     * 雪花算法生成器,配置workId，避免重复
     *
     * 10进制 654334919987691526
     * 64位 0000100100010100101010100010010010010110000000000000000000000110
     *
     * {@link SnowFlakeWordIdConfig}
     *
     * @return
     */
    public static Comparable<?> geneSnowFlakeID(){
        return shardingKeyGenerator.generateKey();
    }
}

修改注册时账号生成策略

ide jdbc postgresql TDSQLMySQL版分布式

0 人点赞

mysql分库分表方案（第十四/十五章/十六章/十七章/十八章）海量数据处理-商用短链

第十四章 初恋的感觉-海量数据下的分库分表知识阶段一

第1集 账号微服务里面的流量包业务模型梳理和需求讲解

第2集【面试题】业务增长-数据库性能优化思路讲解

第3集 走进Mysql数据库分库分表后带来的优点和缺点《上》

第4集 走进Mysql数据库分库分表后带来的优点和缺点《下》

第5集 海量数据处理之Mysql【垂直分表-垂直分库】讲解

第6集 海量数据处理之Mysql【水平分表-水平分库】讲解

第十五章 如漆似胶-海量数据下的分库分表策略讲解

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

第2集 Mysql数据库水平分库分表策略介绍-Range延伸进阶

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

第十六章 热恋的感觉-海量数据下的分库分表技术栈讲解

第1集 大话业界常见数据库分库分表中间件介绍

第2集 分库分表中间件Apache ShardingSphere急速认知

第3集 分库分表和Sharding-Jdbc常见概念术语讲解

第4集 分库分表和Sharding-Jdbc常见分片算法讲解

第十七章 流量包模块-海量数据下的分库分表《青铜玩法》

第1集 账号微服务-流量包模块水平分表需求讲解和开发

第2集 账号微服务-流量包模块水平分表策略配置和测试实战

第3集 分库分表暴露的问题-ID冲突和分布式id生成介绍

第4集 小D-带你彻底掌握分布式 ID 生成算法Snowflake原理

第5集 分布式ID生成器Snowflake里面的坑你是否知道

第6集 分布式ID生成器Snowflake自定义wrokId实战

第7集 shardingjdbc-Snowflake时间回拨问题解决和封装ID生成器

第十四章初恋的感觉-海量数据下的分库分表知识阶段一

第1集账号微服务里面的流量包业务模型梳理和需求讲解

第3集走进Mysql数据库分库分表后带来的优点和缺点《上》

第4集走进Mysql数据库分库分表后带来的优点和缺点《下》

第5集海量数据处理之Mysql【垂直分表-垂直分库】讲解

第6集海量数据处理之Mysql【水平分表-水平分库】讲解

第十五章如漆似胶-海量数据下的分库分表策略讲解

第十六章热恋的感觉-海量数据下的分库分表技术栈讲解

第1集大话业界常见数据库分库分表中间件介绍

第2集分库分表中间件Apache ShardingSphere急速认知

第3集分库分表和Sharding-Jdbc常见概念术语讲解

第4集分库分表和Sharding-Jdbc常见分片算法讲解

第十七章流量包模块-海量数据下的分库分表《青铜玩法》

第1集账号微服务-流量包模块水平分表需求讲解和开发

第2集账号微服务-流量包模块水平分表策略配置和测试实战

第3集分库分表暴露的问题-ID冲突和分布式id生成介绍

第4集小D-带你彻底掌握分布式 ID 生成算法Snowflake原理

第5集分布式ID生成器Snowflake里面的坑你是否知道

第6集分布式ID生成器Snowflake自定义wrokId实战