Apache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款相互独立，却又能够混合部署配合使用的产品组成。 它们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。
Apache ShardingSphere 定位为关系型数据库中间件，旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。 它通过关注不变，进而抓住事物本质。关系型数据库当今依然占有巨大市场，是各个公司核心业务的基石，未来也难于撼动，我们目前阶段更加关注在原有基础上的增量，而非颠覆。
Apache ShardingSphere 5.x 版本开始致力于可插拔架构，项目的功能组件能够灵活的以可插拔的方式进行扩展。 目前，数据分片、读写分离、多数据副本、数据加密、影子库压测等功能，以及对 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 与协议的支持，均通过插件的方式织入项目。 开发者能够像使用积木一样定制属于自己的独特系统。Apache ShardingSphere 目前已提供数十个 SPI 作为系统的扩展点，而且仍在不断增加中。
ShardingSphere 已于2020年4月16日成为 Apache 软件基金会的顶级项目。 欢迎通过邮件列表参与讨论。
ShardingSphere-JDBC
定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
- 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。
- 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。
- 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 标准的数据库。
ShardingSphere-Proxy
定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端(如：MySQL Command Client, MySQL Workbench, Navicat 等)操作数据，对 DBA 更加友好。
- 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 服务端使用。
- 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。
ShardingSphere-Sidecar（TODO）
定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问。 通过无中心、零侵入的方案提供与数据库交互的的啮合层，即 Database Mesh，又可称数据库网格。
Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互进行有效地梳理。 使用 Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。
| ShardingSphere-JDBC | ShardingSphere-Proxy | ShardingSphere-Sidecar | |
|---|---|---|---|
| 数据库 | 任意 | MySQL/PostgreSQL | MySQL/PostgreSQL |
| 连接消耗数 | 高 | 低 | 高 |
| 异构语言 | 仅 Java | 任意 | 任意 |
| 性能 | 损耗低 | 损耗略高 | 损耗低 |
| 无中心化 | 是 | 否 | 是 |
| 静态入口 | 无 | 有 | 无 |
混合架构
ShardingSphere-JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；ShardingSphere-Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。
Apache ShardingSphere 是多接入端共同组成的生态圈。 通过混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场景的应用系统，使得架构师更加自由地调整适合与当前业务的最佳系统架构。
功能列表
数据分片
- 分库 & 分表
- 读写分离
- 分片策略定制化
- 无中心化分布式主键
分布式事务
- 标准化事务接口
- XA 强一致事务
- 柔性事务
数据库治理
- 分布式治理
- 弹性伸缩
- 可观测性（分布式跟踪、指标度量）
- 数据加解密
- 影子表压测
-
元数据介绍 Apache ShardingSphere 的元数据主要包括规则、数据源、表结构等信息。规则信息包含分片、加密、读写分离、事务、高可用等。数据源信息存储的是需要通过 ShardingSphere 来进行管理的底层数据库资源。表结构信息为底层数据源的表结构，包括表的 column 信息、索引信息等。 Apache ShardingSphere 通过这些元数据信息配合治理中心的能力，例如
-
pom.xml: <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.29</version> </dependency> <dependency> <g
-
分布式支持 数据访问层支持分布式数据库，包括读写分离，要启用分布式数据库，需要开启数据库配置文件中的deploy参数： return [ // 启用分布式数据库 'deploy' => 1, // 数据库类型 'type' => 'mysql', // 服务器地址 'hostname' => '192.168.1.1,19
-
5.2 ABP表现层 - 动态WebApi层 5.2.1 建立动态WebApi控制器 这是一篇关于ASP.NET Web API的文档。如果你对ASP.NET感兴趣，请阅读ASP.NET Core文档。 Abp框架能够通过应用层自动生成web api： public interface ITaskAppService : IApplicationService {
-
链接 Web API Controllers 动态WebApi层 集成OData 集成Swagger UI ASPNET Core 集成OData
-
这里我的疑问是，如果我使用多个分布式数据库，cam如何在配置（application.properties）中提到不同的DB源URL？目前我正在使用以下结构来使用一个数据库, 就像上面那样。 所以，如果我使用多个DB用于多个区域，我如何在这里给出有条件的配置？我是微服务世界和分布式数据库设计模式的新手。
-
开发手册的这一部分关注于中间层开发，并明确描述了这一层的数据访问职责。 先是，详细阐述了Spring全面的事务管理支持，随后，详细说明了Spring Framework如何支持多种中间层数据访问的框架和技术。 第 10 章 事务管理 第 11 章 DAO支持 第 12 章 使用JDBC进行数据访问 第 13 章 使用ORM工具进行数据访问 目录 10. 事务管理 10.1. 简介 10.2. 动机
-
每当我读到有关NoSQL分布式数据库的内容时，他们都会提到CAP定理，这意味着在分区系统中，您可以具有完全一致性，完全可用性或两者兼而有之，但不能完全两者兼而有之。 我不太清楚他们在谈论什么类型的一致性： 是数据新鲜度的一致性，其中一些客户端可能会获得比其他客户端更旧的数据吗？ 或者是一致性，即事务可能仅部分完成，这可能会使数据处于不一致的状态？ 第二种解释对我来说听起来很危险，不能真正接受。第一
-
请问 nodejs 中有 类似mycat 或 sharingjdbc的分布式数据库中间件么
-
本文向大家介绍NoSQL数据库的分布式算法详解，包括了NoSQL数据库的分布式算法详解的使用技巧和注意事项，需要的朋友参考一下 今天，我们将研究一些分布式策略，比如故障检测中的复制，这些策略用黑体字标出，被分为三段： 数据一致性。NoSQL需要在分布式系统的一致性，容错性和性能，低延迟及高可用之间作出权衡，一般来说，数据一致性是一个必选项，所以这一节主要是关于 数据复制 和 数据恢复 。 数据放置