基于ShardingSphere分库分表

liang_336

已于 2022-04-07 15:13:39 修改

阅读量2.6k

点赞数

分类专栏： java ShardingSphere Sharding-JDBC 文章标签： java 数据库

于 2022-03-24 20:45:37 首次发布

本文链接：https://blog.csdn.net/liang_336/article/details/123720281

版权

java 同时被 3 个专栏收录

9 篇文章 0 订阅

订阅专栏

ShardingSphere

1 篇文章 0 订阅

订阅专栏

Sharding-JDBC

1 篇文章 0 订阅

订阅专栏

背景：

无论是数据库还是应用从最原始的单机架构开始，随着用户的增多，考虑到系统的高可用和越来越多的用户请求，我们开始使用主从架构，用户量和业务量进一步上升之后，微服务集群和数据库集群也就出现了，就应用而言，随着服务器的增加可以将请求量分摊到出去，而数据库是不是也可以采用类似的思想进行分而治之呢，分库分表就出现了。

遇见的问题：

1、单库数据量太大，单个数据库处理能力有限，单库所在的服务器磁盘空间有限，磁盘IO也一直是现在大部分应用场景的瓶颈。

2、单表数据量太大，查询，插入，更新操作都会变慢，在加字段，加索引，机器迁移都会产生高负载，影响服务正常使用。

如何解决：

垂直拆分：表结构不一样，但至少有一列一样，每个库/表的数据都是全量数据

库：电商库 –> 订单库商品库会员库

表：用户表 –> user_base user_info

优点：拆分业务清晰，数据维护简单，不同业务在不同服务器

缺点：单库/单表数据量大，读写压力大；受某种业务场景的影响（例如：双十一订单库的压力会非常大，但是用户和商品的写压力几乎没有）出现性能问题；部分业务无法关联，只能通过java接口调用。

水平拆分：同一库/表按照范围（分段分片）或者hash取模（取模分片）

库：电商库 –> 表结构一样，数据不一样

表：用户表 –> 根据id分段或者id取模

优点：单库/表的数据保持为一定的量，有助于提高性能；同时提高了系统的稳定性（一个库挂了只影响部分用户）；拆分表结构未变，代码改动点较少

缺点：数据的扩容有很大的维护量（这边之前看了一篇关于扩容的文章，觉得讲的有些道理，这边也贴出来引用下：ShardingJDBC分库分表完美扩容 - 掘金）；拆分规则很难抽象出来；分片事务的一致性问题，部分业务无法关联起来，只能通过java接口调用。

带来的问题：

（1）、分布式事务（ShardingSphere提供了解决）

（2）、跨库的join查询（ShardingSphere提供了优化）

（3）、分布式全局唯一ID（ShardingSphere提供了解决）

· （4）、开发成本提高（对程序员的要求，多花钱找厉害的开发，或者看我这文章不就解决了麽）

ShardingSphere实战

ShardingSphere定位为关系型数据库中间件，旨在充分合理地在分布式场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。

Sharding-JDBC：被定位为轻量级Java框架，在Java的JDBC层提供的额外服务，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

适用于任何基于Java的ORM框架，如:JPA，Hibernate，Mybatis，Spring JDBC Template或直接使用JDBC;
基于任何第三方的数据库连接池，如：DBCP，C3P0，BoneCP，Druid，HikariCP等
支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer和PostgreSQL。

主要功能：

数据分片
读写分离
分布式主键
分布式事务
数据库治理
配置动态化
数据脱敏

Sharding-JDBC内部结构：

图中黄色部分表示的是Sharding-JDBC的入口API，采用工厂方法的形式提供。目前有ShardingDataSourceFactory和MasterSlaveDataSourceFactory两个工厂类。ShardingDataSourceFactory用于创建分库分表或分库分表+读写分离的JDBC驱动，MasterSlaveDataSourceFactory用于创建独立使用读写分离的JDBC驱动。

图中蓝色部分表示的是Sharding-JDBC的配置对象，提供灵活多变的配置方式。 ShardingRuleConfiguration是分库分表配置的核心和入口，它可以包含多个TableRuleConfiguration和MasterSlaveRuleConfiguration。每一组相同规则分片的表配置一个TableRuleConfiguration。如果需要分库分表和读写分离共同使用，每一个读写分离的逻辑库配置一个MasterSlaveRuleConfiguration。每个TableRuleConfiguration对应一个ShardingStrategyConfiguration，它有5中实现类可供选择。

仅读写分离使用MasterSlaveRuleConfiguration即可。

图中红色部分表示的是内部对象，由Sharding-JDBC内部使用，应用开发者无需关注。Sharding-JDBC通过ShardingRuleConfiguration和MasterSlaveRuleConfiguration生成真正供ShardingDataSource和MasterSlaveDataSource使用的规则对象。ShardingDataSource和MasterSlaveDataSource实现了DataSource接口，是JDBC的完整实现方案。

初始化流程

配置Configuration对象。
通过Factory对象将Configuration对象转化为Rule对象。
通过Factory对象将Rule对象与DataSource对象装配。
Sharding-JDBC使用DataSource对象进行分库。

使用过程：

引入maven依赖：

<groupId>org.apache.shardingsphere</groupId>

<artifactId>sharding-jdbc-core</artifactId>

<version>${latest.release.version}</version>

</dependency>

规则配置：Sharding-JDBC可以通过Java，YAML，Spring命名空间和Spring Boot Starter四种方式配置，开发者可根据场景选择合适的配置方式。

创建DataSource：通过ShardingDataSourceFactory工厂和规则配置对象获取ShardingDataSource，然后即可通过DataSource选择使用原生JDBC开发，或者使用JPA，Mybatis等ORM工具。

DataSource dataSource = ShardingDataSourceFactory.createDataSource(dataSourceMap, shardingRuleConfig, props);

核心概念：

真实表：数据库中真实存在的物理表。例如：t_order0，t_order1

逻辑表：在分片之后同一类表结构的名称。例如：t_order

数据节点：在分片之后，由数据源和数据表组成。例如：ds0.t_order1，ds1.t_order1

绑定表：值的是分片规则一致的关系表（主表，子表），例如：t_order和t_order_item，均按照order_id分片，则此两个表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，可以提升查询效率。

t_order：t_order0、t_order1

t_order_item：t_order_item0、t_order_item1

select * from t_order o left join t_order_item oi on o.order_id = oi.order_id where o.order_id in (1, 2);

如果不配置绑定表关系，采用笛卡尔积关联，会生成4个SQL

select * from t_order0 o left join t_order_item0 oi on o.order_id = oi.order_id where o.order_id in (1, 2);

select * from t_order1 o left join t_order_item0 oi on o.order_id = oi.order_id where o.order_id in (1, 2);

select * from t_order0 o left join t_order_item1 oi on o.order_id = oi.order_id where o.order_id in (1, 2);

select * from t_order1 o left join t_order_item1 oi on o.order_id = oi.order_id where o.order_id in (1, 2);

如果配置绑定表关系，生成两个SQL

select * from t_order0 o left join t_order_item0 oi on o.order_id = oi.order_id where o.order_id in (1, 2);

select * from t_order1 o left join t_order_item1 oi on o.order_id = oi.order_id where o.order_id in (1, 2);

广播表：在使用中有些表没必要做分片，例如字典表，省份表等，因为它们数据量不大，但是他们有可能要和海量数据进行关联，可以在多个库中冗余，避免跨库查询问题

分片策略：针对数据源和数据表两个维度，Sharding-JDBC提供了多种分片策略；而分片策略主要包含了分片键和分片算法。

分片键：用于分片的数据库字段，是将数据库（表）水平拆分的关键字段。例：将订单表中的订单主键取模分片，则订单主键为分片字段，将执行全路由，性能较差。除了对单分片字段的支持，ShardingSphere也支持根据多个字段进行分片。
分片算法：就是来实现分片的计算规则。

Sharding-JDBC提供内置了多种分片算法，包含四种类型，同时也支持自定义：

自动分片算法

自动分片算法，就是根据我们配置的算法表达式完成数据的自动分发功能，在Sharding-JDBC中又提供了五种自动分片算法。

取模分片算法：最基础的取模算法，会根据分片字段和分片大小进行取模运算得到一个结果。
哈希取模分片算法：和取模算法相同，唯一的区别是针对分片键得到哈希之后再取模
分片容量范围：简单解释就是按照某个字段的数值范围进行分片。
基于分片边界的范围分片算法：前面的分片容量范围分片是一个均衡的分片方法，如果存在不均衡的场景，例如：[0,100]保存到表0，(100,1000]保存到表1，(1000,10000]保存到表2等；我们就可以基于分片边界范围分片算法来完成
自动时间段分片算法：根据时间段进行分片；例如：按照每一年划分一个表

标准分片算法

准备分片算法，它只支持对单个分片键（字段）为依据的分库分表，Sharding-JDBC提供了两种算法实现。

行表达式分片算法：使用Groovy的表达式，提供对SQL语句中=和IN的分片操作支持，只支持单片分键，可以通过简单的配置使用，从而避免繁琐的Java代码开发；如：t_order_$->{order_id % 8}表示t_order表根据order_id模8分成8张表，表名称为t_order_0到t_order_7。
时间范围分片算法：和前面自动分片算法的自动时间段分片算法类似

复合分片算法

复合分片算法，SQL语句中有>,>=,<,<=,=,IN和BETWEEN AND等操作符，不同的是复合分片策略支持对多个分片键操作。

复合行表达式分片算法：用于处理使用多键进行分片的场景，多个分片键的逻辑较为复杂，需要应用开发者自行处理其中的复杂度

Hint分片算法

Hint分片算法，用于处理使用Hint行分片的场景。对于分片字段非SQL决定，而有其他外置条件决定的场景，可使用SQL Hint灵活的注入分片字段；

Hint行表达式分片算法：SQL Hint支持通过JavaAPI和SQL注释两种方式去实现，指定了强制路由的SQL将会无视原有的分片逻辑，直接路由至指定的真实数据节点

流程剖析：

ShardingSphere3个产品的数据分片功能主要流程是完全一致的，如下图所示：

SQL解析：SQL解析分为词法解析和语法解析。先通过词法解析将SQL拆分成一个个不可在分的单词。再使用语法解析器对SQL进行理解，并最终提炼解析上下文。

Sharding-JDBC采用不同的解析器对SQL进行解析，解析器类型如下：

MYSQL解析器
Oracle解析器
SQLServer解析器
PostgresqlSQL解析器
默认SQL解析器

查询优化：负责合并和优化分片条件，如OR等

SQL路由：根据解析上下文匹配用户配置的分片策略，并生成路由路径。目前支持分片路由和广播路由。

SQL改写：将SQL改写为真实数据库中可以正确执行的语句。SQL改写分为正确性改写和优化改写。

SQL执行：通过多线程执行器异步执行SQL。

结果归并：将多个执行结果集中归并以便于通过统一的JDBC接口输出。结果归并包括流式归并，内存归并和使用装饰者模式的追加归并这几种方式。

SQL使用规范：

支持项：路由至单数据节点时，目前MySQL数据库100%兼容，其他数据库完善中

路由至多数据节点时，全面支持DQL,DML,DDL,DCL,TCL。支持分页，去重，排序，分组，聚合，关联查询（不支持跨库关联）。以下用最复杂的查询为例：

SELECT select_expr [, select_expr ...] FROM table_reference [, table_reference ...] [WHERE predicates] [GROUP BY {col_name | position} [ASC | DESC], ...] [ORDER BY {col_name | position} [ASC | DESC], ...] [LIMIT {[offset,] row_count | row_count OFFSET offset}]

不支持项：路由至多数据节点时，不支持CASE WHEN、HAVING、UNION(ALL)

支持分页子查询，但其他子查询有限支持，无论嵌套多少层，只解析至第一个包含数据表的子查询，一旦在下层嵌套中再次找到包含数据表的子查询将直接抛出解析异常。

例如，以下查询可以支持：

SELECT COUNT(*) FROM (SELECT * FROM t_order o)

以下查询不支持：

SELECT COUNT(*) FROM (SELECT * FROM t_order o WHERE o.id IN (SELECT id FROM t_order WHERE status = ?))

简单来说，通过子查询进行非功能需求，在大部分情况下是可以支持的。比如分页、统计总数等；而通过子查询实现业务查询当前并不能支持。

由于归并的限制，子查询中包含聚合函数目前无法支持。
不支持包含schema的SQL。因为ShardingSphere的理念是像使用一个数据源一样使用多个数据源，因此对SQL的访问都是在同一逻辑schema之上。
当分片键处于运算表达式或函数中的SQL时，将采用全路由的形式获取结果。

例如下面的SQL，create_time为分片键：

SELECT * FROM t_order WHERE to_date(create_time, 'yyyy-mm-dd') = '2020- 05-05';

由于ShardingSphere只能通过SQL字面提取分片的值，因此当分片键处于运算表达式或者函数中时，ShardingSphere无法提前获取分片键位于数据库中的值，从而无法计算出真正的分片值。

不支持的SQL示例：

INSERT INTO tbl_name (col1, col2, …) VALUES(1+2, ?, …) //VALUES语句不支持运算

表达式

INSERT INTO tbl_name (col1, col2, …) SELECT col1, col2, … FROM tbl_name WHERE col3 = ? //INSERT .. SELECT

SELECT COUNT(col1) as count_alias FROM tbl_name GROUP BY col1 HAVING count_alias > ? //HAVING

SELECT * FROM tbl_name1 UNION SELECT * FROM tbl_name2 //UNION

SELECT * FROM tbl_name1 UNION ALL SELECT * FROM tbl_name2 //UNION ALL

SELECT * FROM ds.tbl_name1 //包含schema

SELECT SUM(DISTINCT col1), SUM(col1) FROM tbl_name //同时使用普通聚合函数和DISTINCT

SELECT * FROM tbl_name WHERE to_date(create_time, ‘yyyy-mm-dd’) = ? //会导致全路由

分页查询：完全支持MySQL和Oracle的分页查询，SQLServer由于分页查询较为复杂，仅部分支持
性能瓶颈：查询偏移量过大的分页会导致数据库获取数据性能低下，以MySQL为例：

SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10;

这句SQL在分库分表的情况下，无法像单表时一样利用索引跳过1000000条记录后，再获取10条记录，其性能可想而知。在分库分表的情况下（假设分为两个库），为了保证数据的准正确性，SQL会改写为：

SELECT * FROM t_order ORDER BY id LIMIT 0, 1000010;

即将偏移量前的记录全部取出，并仅获取排序后的最后10条记录。这会在数据库本身就执行很慢的情况下，进一步加剧性能瓶颈。因为原SQL仅需要传输10条记录至客户端，而改写之后的SQL则会传输1000010 * 2的记录至客户端。

ShardingSphere优化：ShardingSphere进行了以下2个方面的优化

首先，采用流式处理 + 归并排序的方式来避免内存的过量占用

其次，ShardingSphere对仅落至单节点的查询进行进一步的优化

分页方案优化：

由于分库分表情况下Limit不能通过索引查询数据，因此如果可以保证ID的连续性，通过ID进行分页是比较好的解决方案：

SELECT * FROM t_order WHERE id > 1000000 AND id <= 1000010 ORDER BY id;

或者通过记录上次查询结果的最后一条记录的ID进行下一页的查询：

SELECT * FROM t_order WHERE id > 1000000 LIMIE 10;

分布式主键：

ShardingSphere不仅提供了内置的分布式主键生成器，例如：UUID，SNOWFLAKE，还抽离出分布式主键生成器的接口，方便用户自行实现自定义的自增主键生成器。

UUID：采用UUID.randomUUID()的方式产生分部署主键

SNOWFLAKE：在分片规则模块可配置每个表的主键生成策略，默认使用雪花算法，生成64bit的长整型数据

自定义：自定义主键类，实现ShardingKeyGenerator接口

分布式事务：

分布式事务理论：

CAP定理：又被叫做布鲁尔定理。对于共享数据系统，最多只能同时拥有CAP其中的两个，任意两个都有其使用的场景。

BASE理论：是指基本可用（Basically Available）支持分区失败、软状态（ Soft State）允许短时间内不同步、最终一致性（ Eventual Consistency）数据最终是一致的，但是实时是不一致的。它的核心思想是即使无法做到强一致性（CAP 中的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。

分布式事务模式：了解了分布式事务中强一致性和最终一致性理论，下面介绍集中常见的分布式事务的解决方案。

2PC模式（强一致性）：是Two-Phase Commit的缩写，即两阶段提交，就是将事务的提交过程分为两个阶段进行处理。事务的发起者称为协调者，事务的执行者称为参与者。协调者统一协调参与者执行。

阶段1：准备阶段

协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者的答复。

各参与者执行事务操作，但不提交事务，将undo和redo信息记入到事务日志中。

如参与者执行成功，给协调者返回yes；如果执行失败，给协调者返回no。

阶段2：提交阶段

如果协调者收到参与者的失败消息或者超时，直接给每个参与者发送回滚（rollback）消息；否则，发送提交（commit）消息

该模式实现简单，但是实际项目中使用较少，主要原因：

性能问题：所有参与者在事务提交阶段处于同步阻塞状态，暂用系统资源，容易导致性能瓶颈

可靠性问题：如果协调者存在单点故障问题，协调者故障，参与者将一直处于锁定状态

数据一致性问题：在阶段2中，如果发生局部网络问题，一部分事务参与者收到提交消息，另一部分事务参与者没有收到，那么会导致节点之间数据不一致。

3PC模式（强一致性）：三阶段提交是基于两阶段提交的改进版本，与两阶段提交不同的是，引入了超时机制。这边同时在协调者和参与者都引入了超时机制同时将两阶段提交的准备阶段（第一步）拆分成2个阶段，插入了一个preCommit阶段，解决了原先的两阶段提交中，参与者在准备之后，由于协调者或参与者发生崩溃或错误，而导致参与者无法知晓处于长时间等待的问题。如果在指定的时间内协调者没有收到参与者的消息则默认失败。

阶段1：canCommit阶段

协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者的答复。

如参与者执行成功，给协调者返回yes；如果执行失败，给协调者返回no。

阶段2：preCommit阶段

协调者根据阶段1中参与者的反应情况执行预提交事务或者中断事务操作

如果参与者均返回yes，协调者向所有的参与者发送preCommit请求，参与者收到preCommit请求之后，执行事务操作，但是不提交；将undo日志和redo日志信息记录事务日志；各参与者向协调者反馈ask响应或no响应，并等待最终指令。

如果任何一个参与者返回no或者等待超时：协调者向所有参与者发出abort请求，参与者收到协调者发送的abort请求或者在等待中出现超时，参与者均会中断事务

阶段3：do Commit阶段

该阶段进行真正的事务提交，根据阶段二返回的结果完成事务的提交或中断操作

相较于2PC模式，3PC模式降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题（比如网络中断等），参与者会在等待超时之后继续提交事务。

XA（强一致性）：XA是由X/Open组织提出的分布式事务规范，是基于两阶段提交协议。XA规范主要定义了全局事务管理器（TM）和局部资源管理器（RM）之间的接口，目前主流的关系型数据库产品都是实现了XA接口。 XA之所以需要引入事务管理器，是因为在分布式系统中，从理论上讲两台机器理论上无法达到一致性状态，需要引入一个单点进行协调，由全局事务管理器管理和协调事务，可以跨越多个资源（数据库）和进程。事务管理器用来保证所有的事务参与者都完成了准备工作（第一阶段）。如果事务管理器收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。MySQL在这个XA事务中扮演的是参与者的角色，而不是事务管理器。

TCC模式（最终一致性）：TCC(Try-Confirm-Cancel)的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。TCC 是服务化的两阶段编程模型，其 Try、Confirm、Cancel 3 个方法均由业务编码实现：

Try操作：作为第一阶段，负责资源的检查和预留

Confirm操作：作为二阶段提交操作，执行真正的业务

Cancel操作：是预留资源的取消

TCC模式相较于XA的传统模型图如下：

TCC相较于XA，解决了如下几个缺点：

解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器可以变成多点，引入集群

同步阻塞：引入超时机制，超时后补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小

数据一致性：有了补偿机制后，由业务活动管理器控制一致性

Saga模式（最终一致性）：Saga这个概念源于1987 年普林斯顿大学的 Hecto 和 Kenneth 发表的一篇数据库论文Sagas ，一个Saga事务是一个有多个短时事务组成的长时的事务。在分布式事务场景下，我们把一个Saga分布式事务看做是一个由多个本地事务组成的事务，每个本地事务都有一个与之对应的补偿事务。在Saga事务的执行过程中，如果某一步执行出现异常，Saga事务会被终止，同时会调用对应的补偿事务完成相关的恢复操作，这样保证Saga相关的本地事务要么都是执行成功，要么通过补偿恢复
成为事务执行之前的状态。（自动反向补偿机制）。

Saga事务基本协议如下：

每个Saga事务由一系列幂等的有序子事务（sub-transaction）Ti组成。

每个Ti都有对应的幂等补偿操作Ci，补偿动作用于撤销Ti造成的结果。

Saga的执行顺序由两种：

事务正常执行完成：T1，T2，T3，…Tn；例如：减库存（T1），创建订单（T2），支付（T3）…依次有序完成；

事务回滚：T1，T2，…Ti，Tj，…C2，C1，其中0<j<n,例如：减库存（T1），创建订单（T2），支付（T3），支付失败，支付回滚（C3），订单回滚（C2），恢复库存（C1）。

Saga是一种补偿模式，它定义了两种补偿策略：

向前恢复：对应上面第一种执行顺序，发生失败进行重试，适用于必须要成功的场景。

向后恢复：对应于上面提到的第二种执行顺序，发生错误之后撤销掉之前所有成功的子事务，使得整个Saga的执行结果撤销。

Seata框架：Seata（Simple Extensible Autonomous Transaction Architecture）是一套一站式分布式事务解
决方案，是阿里集团和蚂蚁金服联合打造的分布式事务框架。Seata目前的事务模式有AT、TCC、
Saga和XA，默认是AT模式，AT本质上是2PC协议的一种实现。

Sharding-Sphere整合了XA、Saga和Seata模式后，为分布式事务提供了极大的便利，我们可以在应用程序编程时，采用统一模式进行使用。

基于ACID的强一致性事务和基于BASE的最终一致性事务都不是银弹，只有在最适合的场景中才能发挥它们最大的长处。可通过下表详细对比它们之间的关系，并帮助开发者进行技术选型。

	*本地事务*	*两（三）阶段事务*	*柔性事务*
业务改造	无	无	实现相关接口
一致性	不支持	支持	最终一致
隔离性	不支持	支持	业务方保证
并发性能	无影响	严重衰退	略微衰退
适合场景	业务方处理不一致	短事务 & 低并发	长事务 & 高并发

Sharding-Proxy：被定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务器端版本，用于完成对异构语言的支持。

Jdbc层(性能高,不支持跨语言，主要产品 Proxy层(性能低,支持跨语言,主要产品有

Sharding-JDBC，tddl等） Mycat，Mysql-Proxy，Sharding-Proxy等）

Sharding-Proxy的优势在于对异构语言的支持，向应用完全透明，可以直接当MySQL和PostgreSQL使用，并且适用于任何兼容MySQL和PostgreSQL的客户端。

注意事项：

Sharding-Proxy默认不支持hint，如需支持，请在conf/server.yaml中，将props的属性proxy.hint.enabled设置为true。在Sharding-Proxy中HintShardingAlgorithm的泛型只能是String类型
Sharding-Proxy支持多逻辑数据源，每个以“config-“做前缀命名yaml配置文件，即作为一个逻辑数据源
Sharding-Proxy默认提供Zookeeper的注册中心解决方案，如果你想使用Sharding-Proxy的数据库治理功能，则需要使用注册中心实现熔断和从库禁用功能。

Sharding-Sidecar（规划中）：被定位为Kubernetes或Mesos的云原生数据库代理，以DaemonSet的形式代理所有对数据库的访问。

对比：

	*ShardingSphere-JDBC*	*ShardingSphere-Proxy*	*ShardingSphere-Sidecar*
数据库	任意	MySQL/PostgreSQL	MySQL/PostgreSQL
连接消耗数	高	低	高
异构语言	仅Java	任意	任意
性能	损耗低	损耗略高	损耗低
无中心化	是	否	是
静态入口	无	有	无

liang_336

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
基于ShardingSphere分库分表

背景：无论是数据库还是应用从最原始的单机架构开始，随着用户的增多，考虑到系统的高可用和越来越多的用户请求，我们开始使用主从架构，用户量和业务量进一步上升之后，微服务集群和数据库集群也就出现了，就应用而言，随着服务器的增加可以将请求量分摊到出去，而数据库是不是也可以采用类似的思想进行分而治之呢，分库分表就出现了。遇见的问题：1、单库数据量太大，单个数据库处理能力有限，单库所在的服务器磁盘空间有限，磁盘IO也一直是现在大部分应用场景的瓶颈。2、单表数据量太大，查询，插入，更新操作...
复制链接

扫一扫