使用EF时，涉及到数据库分库，分表该怎么处理

Posted 2023-04-12

参考技术A 您好，很高兴为您解答。

如果数据库是自动分的，那么任何客户端驱动都没有必要去管它。如果手工分，那就是访问不同的库、不同的表。

如若满意，请点击右侧【采纳答案】，如若还有问题，请点击【追问】

希望我的回答对您有所帮助，望采纳！

~ O(∩_∩)O~本回答被提问者和网友采纳

什么是分库分表？

重中之重，什么是分库分表？什么情况下用到分库分表？其次为分库分表的方式？怎么用？

什么是？

顾名思义，将一个库的数据分散到多个库中，把一个表的数据分到多个表中存储。

什么情况下用到？

当一个库被创建后，随着时间和业务量的增加，或者业务流量本来就很多的情况下，数据库中的数据会越来越多，弊端就开始显现：并发量变大，吞吐量变大，处理数据的能力下降，对数据的操作开销也越大，这是就必须用到分库分表了。

分库分表的方式

分库：主从数据库扩容、双写数据库扩容

分表：垂直分表、水平分表

一、数据分表：

如果单表数据量过大，例如千万级别甚至更多，每次查询会消耗数据库大量资源，如果联表更明显。如MySQL在插入数据的时候，会对表进行加锁（表锁或行锁），当并发高时，都会影响数据库的效率。

这个时候将表进行分散可以一定程度上提高效率。一般来说MySQL数据库单表最好控制在一千万条数据以内。

1、垂直分表：

概念：根据业务把一个表中的字段分到不同的表中，每个表的字段至少有一列交集，一般是主键。 这些被分出去的数据通常根据业务需要，例如分出去一些不常用的字段，长度较长的字段。

场景：字段很多，并且热点数据和非热点数据在一起，单行所需存储空间大，以至数据库缓存的数据行减少，迫使查询时回去读磁盘数据产生大量随机读IO，造成IO瓶颈。

2、水平分表

以某字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。

分析：每个表的结构都一样，但是每个表的数据不一样，没有交集，所有的表数据合起来为一个整体。

场景：并发量不高，但是单表的数据量很多，加重了CPU负担，可以考虑分表。

二、数据分库：

每个物理数据库支持数据都有限的，每一次的数据库请求都会产生一次数据库连接，当一个库无法支持更多访问的时候，一般会把原本单个数据库分成多个，分担压力。

这里有几类分库原则，具体视场景选择：1、根据业务不同分库，这种情况都会把主营业务和其他功能分开。例如订单数据库、核算数据库、评论数据库。

2、根据冷热数据进行分库，用数据访问频率划分。

3、根据访问数据的地域、时间范围进行分库。

1、垂直分库

概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。 如原本库中存放A\B两表，垂直分库后，一库存A表，二库存B表。

分析：每个库的结构都不一样，每个库的数据也不一样，没有交集。

2、水平分库

*概念：*同水平分表，以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。

场景：系统绝对并发量上来了。分表难以解决根本问题，并且没有明显的业务归属来垂直分库的情况下。

三、注意点

分库分表能缓解单库或单表带来的性能瓶颈，但同时也带来了一些问题。

1、分库分表带来的问题及考虑

1.1 分布式事务

当更新内容同时存在于不同库中时，这就带来了跨库的事务问题。跨分片事务也是分布式事务，一般使用“XA协议”和“两阶段提交”处理。分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，延长了事务的执行时间，导致事务在访问共享资源时发生冲突或死锁的概率增高。

1.2 最终一致性

对于那些性能要求很高，但对一致性要求不高的系统，往往不苛求系统的实时一致性，只要在允许的时间段内达到最终一致性即可，可采用事务补偿的方式。与事务在执行中发生错误立刻回滚的方式不同，事务补偿是一种事后检查补救的措施，一些常见的实现方法有：对数据进行对账检查，基于日志进行对比，定期同标准数据来源进行同步等。

1.3 全局表

全局表，也可看做“数据字典表”，就是系统中所有模块都可能依赖的一些表，为了避免库join查询，可以将这类表在每个数据库中都保存一份。这些数据通常很少修改，所以不必担心一致性的问题。

1.4 字段冗余

利用空间换时间，合理冗余部分字段，为了性能而避免join查询。不过需要注意冗余的字段，它的一致性是否对业务产生影响。

1.5 全局主键问题

在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据库自生成ID无法保证全局唯一。因此需要单独设计全局主键，避免跨库主键重复问题。

UUID：UUID标准形式是32个16进制数字，分为5段，形式是8-4-4-4-12的36个字符。这是最简单的方案，但缺点也明显，uuid的无序性会导致索引位置频繁变动，另外占用储存空间多。

*Snowflake（雪花算法）：*Twitter的snowfalke算法解决了分布式系统生成全局ID的需求，生成64位Long型数字。

从网络上摘录一个雪花算法demo：

 
public class IdWorker {
 
	//因为二进制里第一个 bit 为如果是 1，那么都是负数，但是我们生成的 id 都是正数，所以第一个 bit 统一都是 0。
 
	//机器ID 2进制5位 32位减掉1位 31个
	private long workerId;
	//机房ID 2进制5位 32位减掉1位 31个
	private long datacenterId;
	//代表一毫秒内生成的多个id的最新序号 12位 4096 -1 = 4095 个
	private long sequence;
	//设置一个时间初始值 2^41 - 1 差不多可以用69年
	private long twepoch = 1585644268888L;
	//5位的机器id
	private long workerIdBits = 5L;
	//5位的机房id
	private long datacenterIdBits = 5L;
	//每毫秒内产生的id数 2 的 12次方
	private long sequenceBits = 12L;
	// 这个是二进制运算，就是5 bit最多只能有31个数字，也就是说机器id最多只能是32以内
	private long maxWorkerId = -1L ^ (-1L << workerIdBits);
	// 这个是一个意思，就是5 bit最多只能有31个数字，机房id最多只能是32以内
	private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
 
	private long workerIdShift = sequenceBits;
	private long datacenterIdShift = sequenceBits + workerIdBits;
	private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
	private long sequenceMask = -1L ^ (-1L << sequenceBits);
	//记录产生时间毫秒数，判断是否是同1毫秒
	private long lastTimestamp = -1L;
	public long getWorkerId(){
		return workerId;
	}
	public long getDatacenterId() {
		return datacenterId;
	}
	public long getTimestamp() {
		return System.currentTimeMillis();
	}
 
 
 
	public IdWorker(long workerId, long datacenterId, long sequence) {
 
		// 检查机房id和机器id是否超过31 不能小于0
		if (workerId > maxWorkerId || workerId < 0) {
			throw new IllegalArgumentException(
					String.format("worker Id can't be greater than %d or less than 0",maxWorkerId));
		}
 
		if (datacenterId > maxDatacenterId || datacenterId < 0) {
 
			throw new IllegalArgumentException(
					String.format("datacenter Id can't be greater than %d or less than 0",maxDatacenterId));
		}
		this.workerId = workerId;
		this.datacenterId = datacenterId;
		this.sequence = sequence;
	}
 
	// 这个是核心方法，通过调用nextId()方法，让当前这台机器上的snowflake算法程序生成一个全局唯一的id
	public synchronized long nextId() {
		// 这儿就是获取当前时间戳，单位是毫秒
		long timestamp = timeGen();
		if (timestamp < lastTimestamp) {
 
			System.err.printf(
					"clock is moving backwards. Rejecting requests until %d.", lastTimestamp);
			throw new RuntimeException(
					String.format("Clock moved backwards. Refusing to generate id for %d milliseconds",
							lastTimestamp - timestamp));
		}
 
		// 下面是说假设在同一个毫秒内，又发送了一个请求生成一个id
		// 这个时候就得把seqence序号给递增1，最多就是4096
		if (lastTimestamp == timestamp) {
 
			// 这个意思是说一个毫秒内最多只能有4096个数字，无论你传递多少进来，
			//这个位运算保证始终就是在4096这个范围内，避免你自己传递个sequence超过了4096这个范围
			sequence = (sequence + 1) & sequenceMask;
			//当某一毫秒的时间，产生的id数 超过4095，系统会进入等待，直到下一毫秒，系统继续产生ID
			if (sequence == 0) {
				timestamp = tilNextMillis(lastTimestamp);
			}
 
		} else {
			sequence = 0;
		}
		// 这儿记录一下最近一次生成id的时间戳，单位是毫秒
		lastTimestamp = timestamp;
		// 这儿就是最核心的二进制位运算操作，生成一个64bit的id
		// 先将当前时间戳左移，放到41 bit那儿；将机房id左移放到5 bit那儿；将机器id左移放到5 bit那儿；将序号放最后12 bit
		// 最后拼接起来成一个64 bit的二进制数字，转换成10进制就是个long型
		return ((timestamp - twepoch) << timestampLeftShift) |
				(datacenterId << datacenterIdShift) |
				(workerId << workerIdShift) | sequence;
	}
 
	/**
 * 当某一毫秒的时间，产生的id数 超过4095，系统会进入等待，直到下一毫秒，系统继续产生ID
 * @param lastTimestamp
 * @return
 */
	private long tilNextMillis(long lastTimestamp) {
 
		long timestamp = timeGen();
 
		while (timestamp <= lastTimestamp) {
			timestamp = timeGen();
		}
		return timestamp;
	}
	//获取当前时间戳
	private long timeGen(){
		return System.currentTimeMillis();
	}
 
	/**
 * main 测试类
 * @param args
 */
	public static void main(String[] args) {
		System.out.println(1&4596);
		System.out.println(2&4596);
		System.out.println(6&4596);
		System.out.println(6&4596);
		System.out.println(6&4596);
		System.out.println(6&4596);
// IdWorker worker = new IdWorker(1,1,1);
// for (int i = 0; i < 22; i++) {
// System.out.println(worker.nextId());
// }
	}
}

1.6 扩容问题

知识盲区，谢谢。。。。。。。