虚拟电商-数据库分库分表

一、数据库分库分表介绍

1.1为什么要分库分表

一般mysql单表存储数据量小于1千万左右的时候，它的读写性能是最好的。但是当业务发展到一定程度，数据增长到一定程度的时候，我们就会发现为什么查询速度越来越慢了，甚至还会出现数据库挂了等其他一系列问题。那么此时我们就需要采取一些方案来解决这些问题，一般如下：

1：分库分表

2：读写分离

3：利用NoSql

我们重点讲解数据库分库分表，也叫数据库分片。
单一数据节点的弊端：性能上的瓶颈。不具备高可用性，无法随意扩容。运维成本高。

对于数据库来说：进行分片的话对于延迟任务来说会有三个数据库：chongba_schedule0、chongba_schedule1、chongba_schedule2。对于数据库表来说可能有taskinfo0、taskinfo1、taskinfo2，对于日志表来说也是同样的有taskinfo_logs0、taskinfo_logs1、taskinfo_logs2。这样的话我们要存储一条数据的话，我们就可以首先选择一个数据，如选择chongba_schedule0数据库或者chongba_schedule1数据库，选择到chongba_schedule1这个数据库后继续选择任务表taskinfo0、taskinfo1。这样的话我们的访问压力就降低，存储能力是会提高的，也会提升系统的访问性能。支持一些高并发的访问场景。

在这里插入图片描述

二、分片方案：

2.1垂直分片

按照业务拆分的方式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。

在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库。下图展示了根据业务需要，将用户表和订单表垂直分片到不同的数据库的方案。

在这里插入图片描述

2.2水平分片

水平分片又称为横向拆分。相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。

例如：根据主键分片，偶数主键的记录放入0库（或表），奇数主键的记录放入1库（或表）

在这里插入图片描述

三、分库分表技术模式

3.1 中间件Proxy模式

Proxy属于中间层方案，在应用程序和MySQL之间搭建一层Proxy。中间层介于应用程序与数据库间，需要做一次转发，基于JDBC协议转发，例如Mycat07
在这里插入图片描述

代理探讨举例：

首先代理(Proxy)是什么，在日常生活中我们有很多这种的例子，比如你买火车票可以直接去火车站，也可以去代理网点，代理网点再和火车站建立关系，这就相当于一个第三方关系的存在。

3.2 Client客户端模式

Client模式属于客户端直连方案。此方案的优势在于轻便，兼容JDBC以及ORM框架，对兼容性、性能以及DBA影响小。例如ShardingSphere，阿里的TDDL

在这里插入图片描述

四、ShardingSphere介绍

ShardingSphere介绍
官网：https://shardingsphere.apache.org/index_zh.html

Sharding-JDBC在3.0后改名为ShardingSphere, Sharding-JDBC 最早由当当网架构师张亮主导开发，如果看到 com.dangdang 的包路径，基本是1.* 版本,后来作者去了京东，有团队支持开发，包名也发生了变化。目前交给Apache官方孵化，从4.0.0版本开始, 包名和3.0 又大有变化。

ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

ShardingSphere定位为关系型数据库中间件，旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。它与NoSQL和NewSQL是并存而非互斥的关系。NoSQL和NewSQL作为新技术探索的前沿，放眼未来，拥抱变化，是非常值得推荐的。反之，也可以用另一种思路看待问题，放眼未来，关注不变的东西，进而抓住事物本质。关系型数据库当今依然占有巨大市场，是各个公司核心业务的基石，未来也难于撼动，我们目前阶段更加关注在原有基础上的增量，而非颠覆

在这里插入图片描述