中间件
常用中间件
MyCat
- 是基于 Proxy，它复写了 MySQL 协议，将 Mycat Server 伪装成⼀个 MySQL 数据库
- 客户端所有的jdbc请求都必须要先交给MyCat，再有 MyCat转发到具体的真实服务器
- 缺点是效率偏低，中间包装了⼀层
- 代码⽆侵⼊性
ShardingSphere下的Sharding-JDBC
- 基于jdbc驱动，不⽤额外的proxy，在本地应⽤层重写Jdbc 原⽣的⽅法，实现数据库分⽚形式
- 是基于 JDBC 接⼝的扩展，是以 jar 包的形式提供轻量级服务的，性能⾼
- 代码有侵⼊性
两者的区别和相同点
相同点：
流程都是SQL解析–>SQL路由–>SQL改
写–>结果归并
区别：
ShardingSphere
简介
- 是⼀套开源的分布式数据库解决⽅案组成的⽣态圈，定位为 Database Plus
- 它由 JDBC、Proxy 和 Sidecar这 3款既能够独⽴部署，⼜⽀持混合部署配合使⽤的产品组成
三大构成
ShardingSphere-Sidecar
ShardingSphere-JDBC
ShardingSphere-Proxy
水平分表常见分片策略
- ⾏表达式分⽚策略 InlineShardingStrategy
只⽀持【单分⽚键】使⽤Groovy的表达式，提供对SQL语
句中的 =和IN 的分⽚操作⽀持 - 标准分⽚策略StandardShardingStrategy
只⽀持【单分⽚键】- PreciseShardingAlgorithm 精准分⽚ 是必选的，⽤于处理
=和IN的分⽚ - RangeShardingAlgorithm 范围分配 是可选的，⽤于处理
BETWEEN AND分⽚
- PreciseShardingAlgorithm 精准分⽚ 是必选的，⽤于处理
- 复合分⽚策略ComplexShardingStrategy
⽀持【多分⽚键】，提供对SQL语句中的=, IN和BETWEEN AND的分⽚操作⽀
持 - Hint分⽚策略HintShardingStrategy
springboot整合sharding-jdbc
添加依赖
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-jdbc-spring-boot-starter</artifactId>
</dependency>
配置文件
# 数据源 ds0 第一个数据库
shardingsphere:
datasource:
#数据源名称
names: ds0
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: 123
type: com.zaxxer.hikari.HikariDataSource
username: root
props:
# 打印执行的数据库以及语句
sql:
show: true
sharding:
tables:
traffic:
# 指定traffic表的数据分布情况，配置数据节点,行表达式标识符使用 ${...} 或 $->{...}，但前者与 Spring 本身的文件占位符冲突，所以在 Spring 环境中建议使用 $->{...}
actual-data-nodes: ds0.traffic_$->{0..1}
#水平分表策略+行表达式分片
table-strategy:
inline:
algorithm-expression: traffic_$->{ account_no % 2 }
sharding-column: account_no
#id生成策略
key-generator:
column: id
props:
worker:
id: ${workId}
#id生成策略
type: SNOWFLAKE
分库分表暴露的问题-ID冲突
常见解决方案
数据库自增ID
设置不同的自增步长
auto_increment_offset、auto-increment-increment
缺点
依靠数据库系统的功能实现，但是未来扩容麻烦
主从切换时的不⼀致可能会导致重复发号
性能瓶颈存在单台sql上
UUID
性能⾮常⾼，没有⽹络消耗
缺点
⽆序的字符串，不具备趋势⾃增特性
UUID太⻓，不易于存储，浪费存储空间，很多场景不适⽤
Redis 发号器
利⽤Redis的INCR和INCRBY来实现，原⼦操作，线程安全，性能⽐Mysql强劲
缺点
需要占⽤⽹络资源，增加系统复杂度
SnowFlake雪花算法
twitter 开源的分布式 ID ⽣成算法，代码实现简单、不占⽤宽带、数据迁移不受影响
⽣成的 id 中包含有时间戳，所以⽣成的 id 按照时间递增
部署了多台服务器，需要保证系统时间⼀样，机器编号不⼀样
缺点
依赖系统时钟（多台服务器时间⼀定要⼀样）
SnowFlake雪花算法
简介
twitter⽤scala语⾔编写的⾼效⽣成唯⼀ID的算法
优点
⽣成的ID不重复
算法性能⾼
基于时间戳，基本保证有序递增
雪花算法⽣成的数字
- long类，所以就是8个byte，64bit
- ⽣成的唯⼀值⽤于数据库主键，不能是负数，所以值为
0~9223372036854775807（2的63次⽅-1）
两个重要的点
保证workId不能重复
解决方法：
自定义workId
import lombok.extern.slf4j.Slf4j;
import org.springframework.context.annotation.Configuration;
import java.net.Inet4Address;
import java.net.InetAddress;
import java.net.UnknownHostException;
@Configuration
@Slf4j
public class SnowFlakeWordIdConfig {
/**
* 动态指定sharding jdbc 的雪花算法中的属性work.id属性
* 通过调用System.setProperty()的方式实现,可用容器的 id 或者机器标识位
* workId最大值 1L << 100，就是1024，即 0<= workId < 1024
* {@link SnowflakeShardingKeyGenerator#getWorkerId()}
*
*/
static {
try {
InetAddress inetAddress = Inet4Address.getLocalHost();
String hostAddressIp = inetAddress.getHostAddress();
String workId = Math.abs(hostAddressIp.hashCode()) % 1024+"";
System.setProperty("workId",workId);
log.info("workId:{}",workId);
} catch (UnknownHostException e) {
e.printStackTrace();
}
}
}
配置文件中
#id生成策略
key-generator:
column: id
props:
worker:
id: ${workId}
#id生成策略
type: SNOWFLAKE
时钟回拨
org.apache.shardingsphere.core.strategy.keygen.SnowflakeShardingKeyGenerator 已经解决了时钟回拨问题，看下源码
核心流程：
最后一次生成主键的时间 lastTime，和当前系统时间比较 currTime ，如果 lastTime < currTime ,则正常，如果lastTime > currTIme ,如果时间差在容忍范围内，则线程休眠时间差值，如果时间差大于容忍范围，则直接报异常。
public synchronized Comparable<?> generateKey() {
long currentMilliseconds = timeService.getCurrentMillis();
// 判断是否需要等待容忍时间差，如果需要，则等待时间差过去，再获取当前系统时间
if (this.waitTolerateTimeDifferenceIfNeed(currentMilliseconds)) {
currentMilliseconds = timeService.getCurrentMillis();
}
// 如果最后一次毫秒与当前系统时间毫秒相同,即还在同一毫秒内
if (this.lastMilliseconds == currentMilliseconds) {
/**
&位与运算符:两个数都转为二进制,如果相对应位都是1,则结果为1,否则为0
当序列为4095时,4095+1后的新序列与掩码进行位与运算结果是
当序列为其他值时,位与运算结果都不会是0
即本毫秒的序列已经用到最大值4096,此时要取下一个毫秒时间值*/
if (0L == (this.sequence = this.sequence + 1L & 4095L)) {
currentMilliseconds = this.waitUntilNextTime(currentMilliseconds);
}
} else {
// 上一毫秒已经过去,把序列值重置为1
this.vibrateSequenceOffset();
this.sequence = (long)this.sequenceOffset;
}
// 记录最新的时间戳
this.lastMilliseconds = currentMilliseconds;
/**
XX......xxx000000000000000000000000时间差XX
XXXXXXXXXX0000000000000 机器ID XX
XXXXXXXXXX序列号×序列号 xx
三部分进行|位或运算:如果相对应位都是0,则结果为0,否则为1
*/
return currentMilliseconds - EPOCH << 22 | this.getWorkerId() << 12 | this.sequence;
}
private boolean waitTolerateTimeDifferenceIfNeed(long currentMilliseconds) {
try {
// 如果获取ID时的最后一次时间毫秒数小于等于当前系统时间毫秒数,属于正常情况,则不需要等待
if (this.lastMilliseconds <= currentMilliseconds) {
return false;
} else {
// 时钟回拨的情况(生成序列的时间大于当前系统的时间),需要等等待时间差
long timeDifferenceMilliseconds = this.lastMilliseconds - currentMilliseconds;
// 获取ID时的最后一次毫秒数减去当前系统时间毫秒数的时间差
// 时间差小于最大容忍时间差,即当前还在时钟回拨的时间差之内
Preconditions.checkState(timeDifferenceMilliseconds < (long)this.getMaxTolerateTimeDifferenceMilliseconds(), "Clock is moving backwards, last time is %d milliseconds, current time is %d milliseconds", new Object[]{this.lastMilliseconds, currentMilliseconds});
// 线程休眠时间差
Thread.sleep(timeDifferenceMilliseconds);
return true;
}
} catch (Throwable var5) {
throw var5;
}
}
具体业务中，使用该方法生成唯一账号
import org.apache.shardingsphere.core.strategy.keygen.SnowflakeShardingKeyGenerator;
public class IDUtil {
private static SnowflakeShardingKeyGenerator shardingKeyGenerator = new SnowflakeShardingKeyGenerator();
/**
* 雪花算法生成器
* @return
*/
public static Comparable<?> geneSnowFlakeID(){
return shardingKeyGenerator.generateKey();
}
}
//生成唯一的账号
accountDO.setAccountNo(Long.valueOf(IDUtil.geneSnowFlakeID().toString()));
![[Linux] Linux操作系统 进程的状态](https://i-blog.csdnimg.cn/direct/6608759bac0541288895c80446ad41ef.png)
