《ShardingSphere JDBC?Sharding JDBC？》基本小白脱坑问题

        因为在短链接中的很多操作也需要依靠sharding JDBC来完成所以同时也在短链接的文章中。

        在网上看了很多文章，可能是因为技术的迭代等等原因，看的越多蒙的越快。在学习的道路上梳理一下，希望可以帮助到别的小伙伴。

官网地址： 

Apache ShardingSphere

第一问：为啥现在都在说ShardingSphere JDBC？那Sharding JDBC没了？

不是的，ShardingSphere JDBC（前身称为Sharding-JDBC）并不是包含多个独立组件，而是一个统一的数据库访问层解决方案的组成部分。它是一个轻量级的Java框架，通过提供一套完整的JDBC驱动的方式来透明化分库分表操作，使得用户能够像操作单个数据库一样操作分布式的数据库集群。

ShardingSphere JDBC 是 Apache ShardingSphere 项目的一部分，主要聚焦于数据库水平拆分场景，提供了数据分片、读写分离、柔性事务以及分布式治理等功能，且无需额外部署和依赖中间件即可与应用程序一同启动运行。

在架构上看，虽然Apache ShardingSphere作为一个整体的数据平台解决方案包含了多个组件，例如：

• ShardingSphere JDBC：适用于任何兼容JDBC的数据库，将分片、读写分离等功能以jar包的形式内嵌到应用程序中。
• ShardingSphere Proxy：作为独立的数据库代理服务，提供更丰富的数据库路由策略和服务治理能力。
• ShardingSphere Sidecar：在云原生场景下，作为Kubernetes的Sidecar模式部署，为无侵入式数据分片提供支持。

但对于单一的ShardingSphere JDBC而言，并没有多个独立的子组件之说，它是作为一个整体单元工作的。

第二问:ShardingSphere JDBC?那这个和ShardingJDBC有什么区别？

提到的“ShardingSphere JDBC”实际上是对原先“Sharding-JDBC”的更新和升级后的名称。随着项目的演进和发展，原本的“Sharding-JDBC”项目整合进了更为全面的“Apache ShardingSphere”大数据处理生态系统中，并按照功能和形态划分为不同的产品线，其中就包括了“ShardingSphere JDBC”。

因此，“ShardingSphere JDBC”和“Sharding-JDBC”实质上指的是同一事物的不同阶段：

• Sharding-JDBC：最初是指的一个专注于在Java应用中进行数据库分片（sharding）的轻量级框架，通过JDBC驱动扩展的方式实现在应用端的数据库水平扩展能力。

• ShardingSphere JDBC：随着项目发展，该项目被纳入到了更广泛的Apache ShardingSphere项目之下，并正式更名为“ShardingSphere JDBC”，其不仅保留了原有的数据库分片功能，还可能增加了更多如分布式事务、数据治理等企业级特性，成为了Apache ShardingSphere项目中针对Java应用环境下的一个模块。

所以，现在大家所说的“ShardingSphere JDBC”就是以前“Sharding-JDBC”的延续和发展，具备更强大的功能和更完善的设计。

第三问：那如果我项目中本来使用的是ShardingJDBC那我如何升级使用呢？

要从旧版本的Sharding-JDBC升级到ShardingSphere JDBC的较新版本，请遵循以下一般性步骤：

步骤1：确认目标版本

首先，查看ShardingSphere官方发布的升级文档，了解您当前正在使用的Sharding-JDBC版本可以平滑升级到哪个ShardingSphere JDBC的版本，以及各个版本之间的兼容性和重大变更说明。

步骤2：分析现有配置

由于不同版本之间可能会有配置项的变动或移除，你需要对比当前使用的Sharding-JDBC配置与目标版本的ShardingSphere JDBC配置要求：

• application.properties 或 application.yml 中的配置前缀和属性名可能会有所改变，比如前面提到的Sharding-JDBC 3.0升至4.0时的配置项前缀调整。
• 分片规则、读写分离策略等配置也可能发生结构变化，需对照新版本文档进行适配。

步骤3：更新依赖

在构建工具（如Maven或Gradle）的依赖管理中，将Sharding-JDBC的依赖替换为ShardingSphere JDBC相应的新版本依赖。

步骤4：迁移代码

如果您的代码中直接引用了Sharding-JDBC相关的API，检查是否有相应的API接口或类发生了变动，确保更新后的API使用正确。

步骤5：测试验证

完成上述更改后，进行全面的功能和性能测试，确保升级后系统功能正常，性能满足预期，并解决可能出现的任何兼容性问题。

步骤6：阅读官方升级指南

具体升级过程应当参照Apache ShardingSphere官方网站发布的升级指南，因为每个版本间的迁移可能都有特定的注意事项和详细步骤：

• 查阅官方文档：https://shardingsphere.apache.org/document/current/en/upgrade-guide/
• 查看对应版本的Release Notes：https://shardingsphere.apache.org/document/current/en/releases/

请务必仔细阅读对应版本的官方升级指导文档，以获取最准确、最新的升级步骤和建议。

第四问：SHARDINGSPHERE-JDBC和SHARDINGSPHERE-PROXY的区别

Apache ShardingSphere 的 ShardingSphere-JDBC 和 ShardingSphere-Proxy 是两种不同的产品形态，用于解决分布式数据库环境下的数据分片、读写分离、数据治理等场景问题，但它们在架构设计和应用场景上有所区别：

ShardingSphere-JDBC:

• 架构与集成方式：ShardingSphere-JDBC 是一个轻量级的 jar 包，设计为与应用程序进程内嵌合，即通过 jar 化服务的形式无缝集成到业务应用中，通过增强JDBC驱动的方式实现透明化的数据库访问代理。
• 性能与资源消耗：由于直接运行在应用服务器进程中，无网络传输开销，性能损耗相对较小，适合对性能要求较高的场景。
• 适用场景：非常适合于新开发或者存量较少，需要进行分库分表改造的Java应用项目，特别是OLTP（在线事务处理）场景，例如高并发交易系统。

ShardingSphere-Proxy:

• 架构与集成方式：ShardingSphere-Proxy 则是一个独立的服务进程，充当数据库中间件的角色，对外表现为MySQL/PostgreSQL等数据库服务器，客户端无需任何改动，像连接普通数据库一样连接Proxy。
• 性能与资源消耗：虽然增加了网络通信环节，但由于其集中式管理的特点，对于复杂查询优化、多租户场景等有较好的支持，并且能统一管理和运维，资源消耗相对更大，但可以通过横向扩展来提高服务能力。
• 适用场景：适用于不希望侵入业务代码进行改造，或是涉及多种语言混合开发的项目，以及对分析型查询（OLAP）需求较高或对数据库运维友好的场景，因为它可以作为统一的数据入口，简化整体架构。

总结来说：

• 如果正在使用的项目完全基于Java，并且希望保持高度的性能和灵活性，同时能够在代码级别深度整合数据库分片等功能，那么ShardingSphere-JDBC会是一个更好的选择。
• 而如果需要支持多种编程语言的数据库访问，或者期望通过中间件的方式来统一管控复杂的分布式数据库集群，那么ShardingSphere-Proxy的中间件模式则更为合适。