京东数据库下载-金刚1024灯库r20灯库下载

本文根据dbaplus社区第183期在线分享整理而成。

面对互联网大数据的快速发展和云服务需求的激增，对于企业来说极其重要的数据又该如何面对这些新的变化？

ShardingSphere作为Apache基金会的分布式数据库中间件项目，针对数据水平垂直拆分、分布式事务、数据服务治理、数据安全等需求，提供一套适用于互联网应用架构和云服务架构的多元解决方案。 生态圈。

本次分享将介绍Apache ShardingSphere的核心功能，在京东的具体实现，以及产品生态的发展。

内容大纲：

1.阿帕奇分片领域

生态系统介绍

Apache ShardingSphere 是一个开源的分布式数据库中间件生态系统。 自2016年开源以来，不断升级开发新特性，重构了稳定的微内核，并于2018年11月进入Apache基金会孵化器。

它由京东牵头，由多家公司和整个ShardingSphere社区共同运营和贡献。 其主要功能模块有：数据分库（分库分表）、分布式事务、数据库治理。

目前已有7000+关注度、70+企业登陆gitHub的成功案例。

参考链接：

对于新朋友，介绍部分主要呈现Apache ShardingSphere生态概况； 对于老朋友来说，它的迭代和发展日新月异，你可以看到它最近的发展状况和方向。 目前整个Apache ShardingSphere生态的架构如下图所示：

整体核心功能将形成一个闭环，不仅为您提供最基础最核心的数据分片和分布式事务功能，还为以ShardingSphere为核心的整个分布式数据库系统提供数据库治理功能，如动态配置信息统一管理、调用链和拓扑图、高可用管理、数据脱敏安全、权限控制等强大的管理功能。

此外，我们提供了MySQL、Oracle、PostgreSQL、SQL Server等不同数据库的多模式连接支持，真正屏蔽了底层数据库选择的影响，让无论使用什么数据库，数据都可以在没有用户感知的情况下进行处理。 数据库治理的分片、分布式事务和功能操作。

管控界面模块旨在为用户提供清晰可见的信息查看、配置更新管理、统计报表等功能。

在接入端部分，为了满足不同用户对不同场景的需求，ShardingSphere提供了多种接入端，包括Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（规划中）：

Apache ShardingSphere是一个生态，它的开源基因注定了它的发展是开放和自由的，社区参与和贡献。 因此，在设计其架构时，会更加注重打造微内核和开发生态。

我们在各个方面都提供了开放的接口，让所有感兴趣的朋友都可以参与其中，贡献代码，成为Apache基金会项目的提交者。

2.阿帕奇分片领域

核心功能&接入终端

一、核心功能介绍

数据分片、分布式事务、数据库治理功能已经成熟，可以提供给用户用于生产； 多模连接和管控接口还在开发中，还需要时间和大家见面。

具体来说，成熟的核心功能主要包括以下内容：

可见Apache ShardingSphere的整个生态圈功能众多且强大。 每个功能点都可以扩展形成系列课程。 限于篇幅，本次分享主要介绍数据分片的内容，并结合京东的实际实现，对数据分片过程中遇到的问题及相应的解决方案进行说明。

在此基础上，很多业务系统出于性能和安全的考虑，会选择这两种方式的混合部署架构，即同时使用读写分离和水平分片策略，如下图所示：

在这种情况下，底层数据的架构网络将显得异常复杂和繁琐。 因为在整个分布式数据库系统中会有：分库1、分库2……，以及对应的从库1、从库2……

对于业务开发的同学来说，自己的精力和注意力不应该仅仅放在与KPI挂钩的业务代码开发上，还需要考虑如何实现和维护这样一个分布式数据库系统。

如何避免重新发明轮子？ 如何只专注于自己的业务发展？

Apache ShardingSphere 充当管理员，为每个人实现和维护分布式数据库系统。 作为一个分布式数据库中间件，它将为大家解决这些场景下的数据库管理和维护工作。

通过引入这一层中间件京东数据库下载，业务开发可以像数据库一样使用整个复杂繁琐的分布式数据库系统，而不必关心底层所有子数据库和读写库的使用和维护，如图下图：

那么，Apache ShardingSphere 是如何做到的呢？

首先，它为用户提供了多种内置的分片策略方式，并开放了自定义分片策略接口，帮助用户完成特殊场景下的分片需求。

数据分片最重要的是：如何拆分数据库表？

这会关系到以后整个数据库系统的性能，以及与业务系统匹配的默契程度。 ShardingSphere提供了哈希取模、范围划分、标签分类、时间范围、复合分片等多种分片策略。

例如，业务方可能根据订单号的后几十位对数据库表进行hash取模； 也可以将日志文件信息划分为日、月、年维度存入数据库； 也可以根据业务类型分库分表。

针对各种业务场景，ShardingSphere 提供了以下分片策略。 虽然这些分配策略基本可以满足80%以上业务方的需求，但是还是会出现一些不正常的业务场景。

为此，我们开放了数据分片策略的接口。 业务方可以根据自己的异常需求选择实现这些数据分片接口，ShardingSphere会通过SPI加载使用。

确定数据分片策略后，ShardingSphere会使用分片策略对某条SQL进行如下操作，完成DDL&DML&DAL&DQL&TCL等操作。

但这个过程对用户是透明的，即在用户无感知的情况下，ShardingSphere解析用户输入的SQL，然后根据用户指定的分片策略重写不带分片信息的SQL。 改写成一条或多条真实的SQL，实际执行在一张或多张数据表上。

另外，还需要找出每条真实的SQL需要在哪个库的哪个子表中执行，最后将改写后的真实SQL发送到对应的子表中进行多线程执行。 而用户将得到最终聚合后的数据结果集。

2. 接入终端介绍

Apache ShardingSphere作为一个生态系统，为用户提供了多种接入终端，以满足用户在不同应用场景下的需求。 他们是：

目前，Sharding-JDBC 和 Sharding-Proxy 已经可以生产，Sharding-Sidecar 还在开发中。

1）Sharding-JDBC

Sharding-JDBC定位为一个轻量级的Java框架，在Java JDBC层提供额外的服务。 它使用客户端直接连接数据库，以jar包的形式提供服务，无需额外部署和依赖。 可以理解为JDBC驱动的增强版，完全兼容JDBC和各种ORM框架。

2）分片代理

Sharding-Proxy定位为透明数据库代理，提供服务器版本封装数据库二进制协议支持异构语言。

目前先提供MySQL版本。 可以使用任何兼容MySQL协议的访问客户端（如：MySQL Command Client、MySQL Workbench等）操作数据，对DBA更友好：

3）Sharding-Sidecar

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

通过非中心化、零侵入的方案提供与数据库交互的网格化层，即Database Mesh，也称为数据网格。

Database Mesh 的重点是如何将分布式数据访问应用程序和数据库有机地连接起来。 它更注重交互，就是有效梳理杂乱的应用程序和数据库之间的交互。

使用Database Mesh，访问数据库的应用程序和数据库最终将形成一个巨大的网格系统。 应用程序和数据库只需要在网格系统中注册。 它们都是由网格化层管理的对象。

3.阿帕奇分片领域

京东实战

目前，ShardingSphere已经在京东落地了很多大大小小的业务。 这里只是几个大型系统。 这些业务系统有的非常重要，有的相对较新。 如下所示：

从这个案例我们可以看出：

每个落地案例都可以独立分享给大家讲解。 本次分享主要介绍落地白条业务的实战情况。

在这次落地过程中，我特意总结了实战中遇到的问题以及相应的解决方案。 相信大家在生产实践中也会遇到类似的问题。 希望这些解决方案能够给大家带来相关的经验和思考，赠人玫瑰，手留余香。

遇到的主要问题和相应的解决方案可以参考下图：

1. SQL 兼容性

通过上面的解释可以看出，使用任何分布式数据库中间件都会面临一个问题：是否完全支持SQL？

因为一条不包含分片信息的SQL需要经过解析、重写、路由、执行、合并等步骤，所以对SQL的处理可能会导致中间件不支持某些SQL。

这个问题在我们真正落地白条业务的时候也出现了。

白条业务的业务逻辑非常复杂庞大，多样的场景需求对SQL的兼容性要求很高。

为了全面支持白条业务，ShardingSphere从两方面进行了优化重构：

SQL解析模块是中间件的基石。 基石不牢，上层建筑就岌岌可危。

从第一代分析引擎使用Druid内置的分析引擎到第二代自研的SQL分析引擎，到现在使用Antlr解析器作为SQL解析器，已经两年了。

耗费了这么多的时间和精力，只是为了真正构建基石京东数据库下载，让分析引擎独立可控，高效全面地支持SQL。 目前，SQL支持状态为：

2.分布式主键

在传统的数据库软件开发中，主键自动生成技术是一项基本要求。 对于这种需求，各个数据库也都提供了相应的支持，比如MySQL的自增key，Oracle的自增序列。

数据分片后，很难为不同的数据节点生成一个全局唯一的主键。 同一个逻辑表中不同实际表之间的自增键会产生重复的主键，因为它们无法相互感知。

虽然可以通过约束自增主键的初始值和步长来避免冲突，但需要引入额外的运维规则，使得方案缺乏完整性和可扩展性。

目前有很多第三方方案可以完美解决这个问题，比如UUID等依靠特定算法生成唯一键，或者通过引入主键生成服务。

为了方便用户使用，满足不同用户在不同使用场景下的需求，ShardingSphere提供了内置的分布式主键生成器，如UUID、SNOWFLAKE等分布式主键生成器，用户可以通过简单的方式使用配置生成一个全局唯一的自增ID。

此外，我们还提取了分布式主键生成器的接口，让用户可以实现自己定制的自增主键生成算法，满足用户在特殊场景下的需求。

3.业务分片的键值注入

通过解析SQL语句提取分片键列和分片值进行分片，是ShardingSphere对SQL的零侵入方式。

如果SQL语句中没有分片条件，则不能分片，需要全路由。 在某些应用场景中，分片条件不存在于SQL中，而是存在于外部业务逻辑中。 因此，有必要提供一种方式来对外指定分片结果，在ShardingSphere中称为Hint。

ShardingSphere 使用 ThreadLocal 来管理分片键值。 分片条件可以通过编程方式添加到HintManager中，分片条件只在当前线程中有效。

除了以编程方式使用强制分片路由，ShardingSphere 还计划通过 SQL 中的特殊注释来引用 Hint，让开发者可以更透明地使用该功能。 指定了强制分片路由的SQL会忽略原来的分片逻辑，直接路由到指定的真实数据节点。

下图将给出该场景的具体实现示例：

ShardingSphere通过在HintManager中注入状态与具体路由表的关系，根据用户指定的规则强制执行SQL到db_0.t_order_1，并将结果返回给用户。

4.性能优化

性能问题是任何在线系统在面临业务高峰时都必须考虑的问题。 面对京东白条的量级应用，ShardingSphere为了满足白条业务对TPS/QPS的强制性要求，做了各种优化，主要有：

限于篇幅，这里主要介绍Bind table和broadcast table的使用。 这两个表的配置和使用，主要是优化表关联问题中分表与分表的笛卡尔积表关联，解决不支持跨库表关联的情况。

绑定表是指分片规则相同的主表和子表。 例如：t_order 表和t_order_item 表都是按照order_id 分片的，那么两个表就绑定了。 绑定表之间的多表关联查询不会有笛卡尔积关联，因此关联查询的效率会大大提高。

因为主表和子表采用相同的分表策略，数据在主表和子表的分布会完全一致，所以在查询表时可以避免笛卡尔积。 例如，如果 SQL 是：

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在没有配置绑定表关系的情况下，假设shard key order_id将value 10路由到slice 0，value 11路由到slice 1，那么路由后的SQL应该是4条，它们以笛卡尔积的形式呈现：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

配置绑定表关系后，路由SQL应该是2：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

其中t_order在FROM的最左边，ShardingSphere会把它作为整个绑定表的主表。

所有路由计算只会使用主表的策略，那么t_order_item表的分片计算会使用t_order的条件。 因此，绑定表之间的分区键必须完全相同。

广播表是指存在于所有底层分片数据源中的表，表中的表结构和数据在各个分片中是完全一致的。

这样，在进行关联查询时，由于广播表存在于所有分库中，避免了笛卡尔积关联查询和跨库关联。 比较适合数据量不大，需要关联海量数据表的场景，比如字典表。

4.阿帕奇分片领域

迭代与计划

Apache ShardingSphere的发展规划如下图所示：

官网和GitHub也欢迎大家访问：

5.写在最后

感谢小伙伴们能够看完文章，当然这里也可能直接跳转。 本文来自网络分享，感兴趣的朋友可以回顾一下网络分享，应该比文字更生动有趣。

从一开始的DBA，到成为分布式数据库中间件JAVA开发程序员，我也开始在开源领域探索和寻找自我的定位和意义。 互联网行业犹如大海航行的时代，波涛汹涌，万变千变。

愿所有的朋友都能当好舵手，悬云直航，助力大海。

现场回放