第十四章 初恋的感觉-海量数据下的分库分表知识阶段一
第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等大字段拆分出来放在附表中; 业务经常组合查询的列放在一张表中 例子:商品详情一般是拆分主表和附表 //拆分前
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范围进行分表延伸解决方案,你能想到多少种
范围角度思考问题 (范围的话更多是水平分表)
数字 时间 年、月、日范围 比如按照月份生成 库或表 pay_log_2022_01、pay_log_2022_02 空间 地理位置:省份、区域(华东、华北、华南) 比如按照 省份 生成 库或表
基于Range范围分库分表业务场景
微博发送记录、微信消息记录、日志记录,id增长/时间分区都行 网站签到等活动流水数据时间分区最好 大区划分(一二线城市和五六线城市活跃度不一样,如果能避免热点问题,即可选择) 第3集 Mysql数据库水平分库分表策略介绍-Hash取模 简介: Mysql数据库水平分库分表常见策略介绍-Hash取模
方案二:hash取模(Hash分库分表是最普遍的方案)
为啥不之间取模,如果取模的字段不是整数型要先hash,统一规则就行 案例规则
用户ID是整数型的,要分2库,每个库表数量4表,一共8张表 用户ID取模后,值是0到7的要平均分配到每张表 库ID = userId % 库数量 2
表ID = userId / 库数量 2 % 表数量4
优点
保证数据较均匀的分散落在不同的库、表中,可以有效的避免热点数据集中问题, 缺点
更多架构课程请访问 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代码开发
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 新建表
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项目注释下面的依赖排查 <exclusions>
<exclusion>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-jdbc-spring-boot-starter</artifactId>
</exclusion>
</exclusions>
# 数据源 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集 账号微服务-流量包模块水平分表策略配置和测试实战 简介: 账号微服务-流量包模块水平分表策略配置和测试实战
# 水平分表策略+行表达式分片
table-strategy:
inline:
algorithm-expression: traffic_$->{account_no % 2}
sharding-column: account_no
@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);
}
}
第3集 分库分表暴露的问题-ID冲突和分布式id生成介绍 简介: 分库分表暴露的问题-ID冲突和分布式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 按照时间递增 部署了多台服务器,需要保证系统时间一样,机器编号不一样 缺点 第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 重复 啥时候会有系统回拨???? 小滴课堂-老王闲着,人工去生产环境做了系统时间调整,应该不会这么傻吧 业务需求,代码里面做了系统时间同步 配置实操
spring.shardingsphere.sharding.tables.traffic.key-generator.props.worker.id=1
方式一
订单id使用MybatisPlus的配置,TrafficDO类配置
@TableId(value = "id", type = IdType.ASSIGN_ID)
默认实现类为DefaultIdentifierGenerator雪花算法
方式二
使用Sharding-Jdbc配置文件,注释DO类里面的id分配策略 #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参数去控制,覆盖变量 @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())%1024)+"");
} catch (UnknownHostException e) {
throw new BizException(BizCodeEnum.OPS_NETWORK_ADDRESS_ERROR);
}
}
}
#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生成器
public class IDUtil {
private static SnowflakeShardingKeyGenerator shardingKeyGenerator = new SnowflakeShardingKeyGenerator();
/**
* 雪花算法生成器,配置workId,避免重复
*
* 10进制 654334919987691526
* 64位 0000100100010100101010100010010010010110000000000000000000000110
*
* {@link SnowFlakeWordIdConfig}
*
* @return
*/
public static Comparable<?> geneSnowFlakeID(){
return shardingKeyGenerator.generateKey();
}
}