架构师：每天千万级订单的生成，数据库系统如何设计？订单系统架构如何设计？

别说我不爱运动

于 2024-07-25 10:26:17 发布

阅读量969

点赞数 21

文章标签：数据库系统架构

本文链接：https://blog.csdn.net/maizixuetang/article/details/140682312

版权

1. 架构体系深入剖析

1.1 演进与背景

随着数据量的增长，一般db的架构，经历如下演进：

1）单库主从

业务请求并发量大到一定量级后，单一主库无法承受，将读写剥离，从库诞生。
挑战：开发层框架支持，多数据源，数据读从延迟问题。

2）单库双主多从架构

实战较少，多为灾备而生，双主单写，灾备切换

3）分区表

数据库层面做数据分区策略，对开发层透明。

适用场景：

适合订单场景，最后部分有热点数据，其他都是历史订单（不活跃）
分区表的数据更容易维护，可以直接针对分区做删除、优化、检查、修复、备份等操作
支持多硬件设备，不同分区分散到不同设备，如硬盘
优化查询，只使用必要的分区来提高查询效率，涉及sum()和count()聚合查询时，也可以实现分区并发再汇总。

局限性：

数量上限，一个表最多只能有1024个分区（mysql5.6之后支持8192个分区）
分区表达式类型受限，多为整数或日期。
如果表中有主键或唯一索引，那么分区键必须是主键或唯一索引
分区表中无法使用外键约束

4）横向分表

mysql单表性能超过千万级别会导致性能严重下降，横向，切成多张表。
挑战：分表策略，量级估算，分多少表？查询问题，扩容问题

5）多库

超大量级的单库，备份，主从同步臃肿不堪，
即使拆了表，单服务器依然扛不住，io成为瓶颈。扩充物理节点，就必须分库
挑战：多数据源写，开发框架支持。数据分发难度进一步上升。

1.2 痛点

主流架构一般分库分表都会涉及，追求性能的同时，带来各种痛点
分库分表并不是一门创新技术，它只是由于数据体系结构的限制而做的无奈之举
机器配置无法无限上升，成本飙升，迫不得已衍生的方案

1.2.1 连接

1）jdbc直连

开发层面维护，最原始的，sql拼接

简单粗暴，sql代码写死，扩容会变得极其糟糕。

String year = getYear();


String sql = "select * from order_"+year+" where xxxx";

2）中间件：一般来讲，两种手段

DBproxy，对DB层面，针对机器做代理，一般需要 LVS/F5 等手段来实现流量的负载均衡，跨机房可能需要DNS分发，常见组件：

组件	公司	功能
Atlas	360	读写分离、静态分表
Meituan Atlas	美团	读写分离、单库分表，目前已经在原厂逐步下架。
Cobar	阿里（B2B）	Proxy 的形式位于前台应用和实际数据库之间，开放MySQL 通信协议，开源版中只支持 MySQL，不支持读写分离。
MyCAT	阿里	基于 Cobar ，是一个实现了 MySQL 协议的服务器，可以把它看作是一个数据库代理
Heisenberg	百度	热重启配置、可水平扩容、遵守 MySQL 原生协议、无语言限制。
Kingshard	Kingshard	由 Go 开发高性能 MySQL Proxy 项目，在满足基本的读写分离的功能上，Kingshard 的性能是直连 MySQL 性能的80%以上。
Vitess	谷歌、Youtube	Rpc方式，集群基于ZooKeeper管理
DRDS	阿里	专注于解决单机关系型数据库扩展性问题。

JDBC Proxy，从jdbc连接层面下手，需要对不同的语言编写 Driver

组件	公司	功能
TDDL	阿里淘宝	动态数据源、读写分离、分库分表，很久没更新了
Zebra	美团点评	动态数据源、读写分离、分库分表、CAT监控，接入复杂、限制多。
MTDDL	美团点评	动态数据源、读写分离、分布式主键生成、分库分表、连接池、SQL监控

3）sharding-jdbc：

file

轻量级Java框架，在Java的JDBC层提供的额外服务。以jar包形式使用客户端直连数据库，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

ORM框架，JPA, Hibernate, Mybatis, Spring JDBC，甚至直接使用JDBC。
连接池，DBCP, C3P0, BoneCP, Druid, HikariCP。
数据库，MySQL，Oracle，SQLServer和PostgreSQL。

1.2.2 数据

1）分库分表课题：

分表维度矛盾（用户，时间）
查询复杂度上升（买家，卖家）
数据聚合运算难度增加（数据统计）

2）亿级数据扩容课题：

扩容变得复杂（影响数据分片）

3）本课题：

多库多表怎么保证生成的订单号唯一

2. 分布式订单生成策略

springboot下，基于sharding-jdbc的框架简介。
分表下的订单表案例介绍，userid维度（分库雷同）
启动与调试，按userid验证数据落库，再查询
重点：分布式id的生成策略

2.1 自增

2.1.1 问题背景

1）业务代码

@GetMapping("/incadd")
public Incorder add(int userid){
Incorder incorder = new Incorder();
incorder.setUserid(userid);
mapper.insert(incorder);
return incorder;
}

2）运行结果

file

3）分析

单表下自增功能不会造成数据错乱，数据库自身特性保障了主键的安全
会泄露id规律，数据隔离做不好的话，不法分子可能会循环撞库窃取订单数据
自增是表维度，一旦拆表，多个自增，有序性被打破

2.1.2 起始点分段

1）方案

设置表2的起始点，再来跑试试……

#用以下sql，或者客户端工具设置：


ALTER TABLE incorder_1 AUTO_INCREMENT=10;

2）优缺点

简单容易，数据库层面设置，代码是不需要动的
边界的切分人为维护，操作复杂，触发器自动维护可以实现但在高并发下不推荐

2.1.3 分段步长自增

1）方案

--查看
show session variables like 'auto_inc%';
show global variables like 'auto_inc%';


--设定自增步长
set session auto_increment_increment=2;
--设置起始值
set session auto_increment_offset=1;


--全局的
set global auto_increment_increment=2;
set global auto_increment_offset=1;

3）问题

影响范围不可控，要么session每次设置，忘记会出乱子。要么全局设置，影响全库所有表
结论：不可取！！！

2.1.4 Sequence特性

仅限于oracle和sqlserver，主流mysql不支持

-- 创建一个sequence：


create sequence sequence_name as int minvalue 1 maxvalue 1000000000 start with 1 increment by 1 no cache;


-- sequence的使用：


sequence_name.nextval 


sequence_name.currval


-- 在表中使用sequence：


insert into incorder_0 values(sequence_name.nextval,userid);

2.2 业务规则

2.2.1 方案思想

不用自增，自定义id，加上业务属性，从业务细分角度对并发性降维。例如淘宝，在订单号中加入用户id。

加上用户id后，并发性维度降低到单个用户，每个用户的下单速度变的可控。

时间戳+userid，业务角度，一个正常用户不可能1毫秒内下两个单子，即便有说明是刻意刷单，应该被前端限流。

2.2.2.实现

@GetMapping("/busiadd")
public Strorder busiadd(int userid){
Strorder order = new Strorder();
order.setId(System.currentTimeMillis()+"-"+userid);
order.setUserid(userid);
strorderMapper.save(order);
return order;
}

2.3 集中式分配

2.3.1 MaxId表

1）通过一张max表集中分配

CREATE TABLE `maxid` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(50) DEFAULT NULL,
`nextid` bigint(20) DEFAULT NULL,
PRIMARY KEY (`id`)
);


insert into maxid(name,nextid) values ('orders',1000);

2）创建函数

DROP FUNCTION getid;


-- 创建函数
CREATE FUNCTION getid(table_name VARCHAR(50))
RETURNS BIGINT(20)
BEGIN
-- 定义变量
DECLARE id BIGINT(20);
-- 给定义的变量赋值 
update maxid set nextid=nextid+1 where name = table_name;
SELECT nextid INTO id FROM maxid WHERE name = table_name;
-- 返回函数处理结果
RETURN id;
END

3）StrorderMapper调整id策略，借助mybatis的SelectKey生成id，注意Before=true

@Insert({
"insert into strorder (id,userid)",
"values (#{id},#{userid,jdbcType=INTEGER})"
})
@SelectKey(statement="SELECT getid('orders') from dual", 
keyProperty="id", before=true, resultType=String.class)
int getIdSave(Strorder record);

/**
* maxid表验证
*/
@GetMapping("/maxId")
public Strorder maxId(int userid){
Strorder order = new Strorder();
order.setUserid(userid);
strorderMapper.getIdSave(order);
return order;
}

4）启动验证分表的id情况，maxid表的记录情况。

5）优缺点

不需要借助任何中间件，数据库内部解决
表性能问题感人，下单业务如果事务过长，会造成锁等待

2.3.2 分布式缓存

通过redis的inc原子属性来实现

1）配置redis服务器

# Redis服务器地址
spring.redis.host=127.0.0.1
# Redis服务器连接端口
spring.redis.port=6379

2）使用redis主键

@GetMapping("/redisId")
public Strorder redisId(int userid){
Strorder order = new Strorder();
order.setId(template.opsForValue().increment("next_order_id").toString());
order.setUserid(userid);
strorderMapper.save(order);
return order;
}

3）优缺点

需要额外的中间件redis
与db相比不够直观，不方便查看当前增长的id值，需要额外连接redis服务器读取
性能不是问题，redis得到业界验证和认可
对redis集群的可靠性要求很高，禁止出现故障，否则全部入库被阻断
数据一致性需要注意，尽管redis有持久策略，down机恢复时需要确认和当前库中最大id的一致性

2.4 uuid

2.4.1 代码生成

1）业务代码

@GetMapping("/uuid")
public Strorder uuid(int userid){
Strorder order = new Strorder();
order.setId(UUID.randomUUID().toString());
order.setUserid(userid);
strorderMapper.save(order);
return order;
}

2）启动，数据库验证save结果

2.4.2 优缺点

最简单的方案，数据迁移方便
缺点也是非常明显的，太过冗长，非常的不友好，可读性极差
需要使用字符串存储，占用大量存储空间
在建立索引和基于索引进行查询时性能不如数字

2.5 雪花算法

2.5.1 概论

file

UUID 能保证保证时空唯一，但是过长且是字符，雪花算法由Twitter发明，是一串数字。

Snowflake是一种约定，它把时间戳、工作组 ID、工作机器 ID、自增序列号组合在一起，生成一个 64bits 的整数 ID，能够使用 (2^41)/(1000606024365) = 69.7 年，每台机器每毫秒理论最多生成 2^12 个 ID

1 bit：固定为0

二进制里第一个bit如果是 1，表示负数，但是我们生成的 id都是正数，所以第一个 bit 统一都是 0。

41 bit：时间戳，单位毫秒

41 bit 可以表示的数字多达 2^41 - 1，也就是可以标识 2 ^ 41 - 1 个毫秒值。

注意！这个时间不是绝对时间戳，而是相对值，所以需要定义一个系统开始上线的起始时间

10 bit：哪台机器产生的

代表的是这个服务最多可以部署在 2^10 台机器上，也就是 1024 台机器。

官方定义，前5 个 bit 代表机房 id，后5 个 bit 代表机器 id。

这10位是机器维度，可以根据公司的实际情况自由定制。

12 bit：自增序列

同1毫秒内，同一机器，可以产生2 ^ 12 - 1 = 4096个不同的 id。

优缺点：

不依赖第三方介质例如 Redis、数据库，本地程序生成分布式自增 ID
只能保证在工作组中的机器生成的 ID 唯一，不同组下可能会重复
时间回拨后，生成的 ID 就会重复，所以需要保持时间是网络同步的。

2.5.2 实现

1）自己用java代码实现

工具类：

package com.itheima.sharding.config;


import org.apache.commons.lang3.StringUtils;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;


@Component
public class Snowflake {


/** 序列的掩码，12个1，也就是(0B111111111111=0xFFF=4095) */
private static final long SEQUENCE_MASK = 0xFFF;


/**系统起始时间，这里取2020-01-01 **/
private long startTimeStamp = 1577836800000L;


/** 上次生成 ID 的时间截 */
private long lastTimestamp = -1L;


/** 工作机器 ID(0~31) */
private long workerId;


/** 数据中心 ID(0~31) */
private long datacenterId;


/** 毫秒内序列(0~4095) */
private long sequence = 0L;




/**
* @param datacenterId 数据中心 ID (0~31)
* @param workerId 工作机器 ID (0~31)
*/
public Snowflake(@Value("${snowflake.datacenterId}") long datacenterId, @Value("${snowflake.workerId}") long workerId) {
if (workerId > 31 || workerId < 0) {
throw new IllegalArgumentException("workId必须在0-31之间，当前="+workerId);
}
if (datacenterId > 31 || datacenterId < 0) {
throw new IllegalArgumentException("datacenterId必须在0-31之间，当前="+datacenterId);
}


this.workerId = workerId;
this.datacenterId = datacenterId;
}


/**
* 加锁，线程安全
* @return long 类型的 ID
*/
public synchronized long nextId() {
long timestamp = currentTime();


// 如果当前时间小于上一次 ID 生成的时间戳，说明系统时钟回退过这个时候应当抛出异常
if (timestamp < lastTimestamp) {
throw new RuntimeException("时钟回退！时间差="+(lastTimestamp - timestamp));
}


// 同一毫秒内，序列增加
if (lastTimestamp == timestamp) {
//超出阈值。思考下为什么这么运算？
sequence = (sequence + 1) & SEQUENCE_MASK;
// 毫秒内序列溢出
if (sequence == 0) {
//自旋等待下一毫秒
while ((timestamp= currentTime()) <= lastTimestamp);
}
} else {
//已经进入下一毫秒，从0开始计数
sequence = 0L;
}


//赋值为新的时间戳
lastTimestamp = timestamp;


//移位拼接
long id = ((timestamp - startTimeStamp) << 22)
| (datacenterId << 17)
| (workerId << 12)
| sequence;


System.out.println("new id = "+id);
System.out.println("bit id = "+toBit(id));


return id;
}




/**
* 返回当前时间，以毫秒为单位
*/
protected long currentTime() {
return System.currentTimeMillis();
}


/**
* 转成二进制展示
*/
public static String toBit(long id){
String bit = StringUtils.leftPad(Long.toBinaryString(id), 64, "0");
return bit.substring(0,1) +
" - " +
bit.substring(1,42) +
" - " +
bit.substring(42,52)+
" - " +
bit.substring(52,64);
}


public static void main(String[] args) {
Snowflake idWorker = new Snowflake(1, 1);


for (int i = 0; i < 10; i++) {
long id = idWorker.nextId();
System.out.println(id);
System.out.println(toBit(id));
}


}




}

springboot启动参数，指定机器编号：

snowflake.datacenterId=1
snowflake.workerId=1

业务部分：

/**
* 自定义雪花算法
*/
@GetMapping("/myflake")
public Strorder myflake(int userid){
Strorder order = new Strorder();
order.setId(String.valueOf(snowflake.nextId()));
order.setUserid(userid);
strorderMapper.save(order);
return order;
}

代码启动生成，分析位数
更改机器id，分析位数

2）借助sharding配置

配置信息，非常简单

spring.shardingsphere.sharding.tables.strorder.key-generator.column=id
spring.shardingsphere.sharding.tables.strorder.key-generator.type=SNOWFLAKE
spring.shardingsphere.sharding.tables.strorder.key-generator.props.worker.id=3

Mapper代码

@Insert({
"insert into strorder (userid)",
"values (#{userid,jdbcType=INTEGER})"
})
@SelectKey(statement="SELECT max(id) from strorder where userid=#{userid,jdbcType=INTEGER}", keyProperty="id", before=false, resultType=String.class)
int shardingIdSave(Strorder record);

业务代码

/**
* sharding的雪花算法
*/
@GetMapping("/shardingFlake")
public Strorder shardingFlake(int userid){
Strorder order = new Strorder();
order.setUserid(userid);
strorderMapper.shardingIdSave(order);
System.out.println(Snowflake.toBit(Long.valueOf(order.getId())));
return order;
}

结果分析

生成的id号由sharding-jdbc自动添加到maper的sql中
机器编号为3，所以打印的bit中机器为 00011，修改为其他机器，测试结果

sharding源码分析：

package org.apache.shardingsphere.core.strategy.keygen;


import com.google.common.base.Preconditions;
import java.util.Calendar;
import java.util.Properties;
import lombok.Generated;
import org.apache.shardingsphere.spi.keygen.ShardingKeyGenerator;


public final class SnowflakeShardingKeyGenerator implements ShardingKeyGenerator {
public static final long EPOCH;
private static final long SEQUENCE_BITS = 12L;
private static final long WORKER_ID_BITS = 10L;
private static final long SEQUENCE_MASK = 4095L;
private static final long WORKER_ID_LEFT_SHIFT_BITS = 12L;
private static final long TIMESTAMP_LEFT_SHIFT_BITS = 22L;
private static final long WORKER_ID_MAX_VALUE = 1024L;
private static final long WORKER_ID = 0L;
private static final int DEFAULT_VIBRATION_VALUE = 1;
private static final int MAX_TOLERATE_TIME_DIFFERENCE_MILLISECONDS = 10;
private static TimeService timeService = new TimeService();
private Properties properties = new Properties();
private int sequenceOffset = -1;
private long sequence;
private long lastMilliseconds;


public SnowflakeShardingKeyGenerator() {
}


public String getType() {
return "SNOWFLAKE";
}


public synchronized Comparable<?> generateKey() {
long currentMilliseconds = timeService.getCurrentMillis();
if (this.waitTolerateTimeDifferenceIfNeed(currentMilliseconds)) {
currentMilliseconds = timeService.getCurrentMillis();
}


if (this.lastMilliseconds == currentMilliseconds) {
if (0L == (this.sequence = this.sequence + 1L & 4095L)) {
currentMilliseconds = this.waitUntilNextTime(currentMilliseconds);
}
} else {
this.vibrateSequenceOffset();
this.sequence = (long)this.sequenceOffset;
}


this.lastMilliseconds = currentMilliseconds;
return currentMilliseconds - EPOCH << 22 | this.getWorkerId() << 12 | this.sequence;
}


//...


//获取机器编号
private long getWorkerId() {
long result = Long.valueOf(this.properties.getProperty("worker.id", String.valueOf(0L)));
Preconditions.checkArgument(result >= 0L && result < 1024L);
return result;
}






//...




//序列上限，等候下一毫秒
private long waitUntilNextTime(long lastTime) {
long result;
for(result = timeService.getCurrentMillis(); 
result <= lastTime; 
result = timeService.getCurrentMillis()) {
;
}


return result;
}






static {
Calendar calendar = Calendar.getInstance();
calendar.set(2016, 10, 1);
calendar.set(11, 0);
calendar.set(12, 0);
calendar.set(13, 0);
calendar.set(14, 0);
EPOCH = calendar.getTimeInMillis();
}
}

3）时钟回退问题

关于snowflake算法的缺陷（时钟回拨问题），sharding-jdbc没有给出解决方案