摘要：除了 Sharding，ShardingSphere 还具有哪些能力？
从 5.x 开始，Apache ShardingSphere 已从数据库中间件工具演进为分布式数据库生态。在功能方面，也积累了众多实用的能力，本文将为大家带来 Apache ShardingSphere 核心功能的解读。
数据分片
适用场景：海量数据+高并发，如金融场景
数据分片也称为 Sharding，它解决了海量数据高并发场景下，「单体数据库」性能瓶颈和存储上限的问题，它通过多表和多库的方式对数据集合进行拆分，分而治之。
Sharding 是 ShardingSphere 的看家本领，可以说 ShardingSphere 所有的能力都可追溯到 Sharding，从 ShardingSphere 的名字也可以看出这一点。
Sharding 功能可以让用户基于当前技术栈，构建起一套分布式数据库解决方案，如 MySQL、PG 及 openGauss 等数据库，这个过程对应用程序尽量透明，可以少改应用甚至不改应用（具体取决于 SQL 情况），以较少的代价和较低的成本完成分布式数据库改造，提升系统效率及存储上限。
- 分片算法
ShardingSphere 为用户提供了几乎所有常见的分片算法，可以满足不同的业务场景：
- 分片时机
不得不说的是，Sharding 不是一颗银弹，由于底层数据库被拆分，我们需要选择性地放弃一些数据库特性。对于 Sharding 的态度是，能不拆则不拆。但是当你尝试过 Sharding 之外的各种方式，都不能解决性能和存储问题的时候，Sharding 的能力一定会惊艳到你。
业内有流传的单表需要限制在 1000w 记录内的说法，单表在百万级必然没有大问题，但是部分系统支持千万级的记录也是没有问题的，需要结合业务情况、字段特点以及服务器配置而定。
关于 Sharding，能不分则部分，既选择了分，就要分得彻底。
- 分片策略
分片策略直接决定着分片的效率，分片键和分片算法的选择至关重要。我们需要 选择具有共性的字段是最基本的要求，也是就尽量能覆盖绝大多数查询场景 。同时分片键也应具有足够庞大的基数以及唯一性，从而使分片可灵活规划 ，具备较好的扩展性。
ShardingSphere 基于分片场景，给分片设计提供了更多的可能。为了尽量在本地完成响应及减少网络开销，建议将小表配置为广播表（克隆），比如量级在数万及以下记录数的表，都可以配置为广播表。具有相同分片键的两张表需要配置为绑定表，避免 join 产生笛卡尔积，提升查询效率。
关于分片策略的探讨，此前我整理过一篇文章Sharding | 数据分片策略：分片键和分片算法的选择，欢迎交流指点。
- 选择具有共性的字段作为分片键，即查询中高频出现的条件字段；
- 分片字段应具有高度离散的特点，分片键的内容不能被更新；
- 可均匀各分片的数据存储和读写压力，避免片内出现热点数据；
- 尽量减少单次查询所涉及的分片数量，降低数据库压力；
- 最后，不要更换分片键，更换分片键需重分布数据，代价较大。
- 分库还是分表
“我该分库还是分表？”这样的问题有很多，分库和分表发力的方向不同，对于超大规模的场景，当然是建议分库+分表，简单总结如下。
- 数据量大，选分表；
- 并发高，选分库；
- 海量存储+高并发，分库+分表。
Sharding 所覆盖的点还有很多，限于篇幅，这里将不再展开。关于 Sharding 能力的进一步介绍，以及对应的操作演示，请观看如下视频（时长 3’43’’）。
读写分离
适用场景：读请求明显高于写的业务场景，如电商等场景
在读请求压力较大的系统中，配置数据库读写分离的策略能够明显提升系统的吞吐能力。ShardingSphere 提供了读写分离能力，可以与分片联合使用，当然也可以单独使用该项能力。
ShardingSphere 有动态读写分离和静态读写分离供用户选择。动态读写分离可自动识别底层数据节点的角色，当发生主从切换时，ShardingSphere 读写分离会自适应集群的变化，无需维护人员干预。对于使用了域名或 VIP 情况的架构，可将固定的地址配置到 ShardingSphere 中，相比动态读写分离，静态读写关系读写地址是固定的。
- 负载均衡
为了尽可能的提升系统整体吞吐量，ShardingSphere 支持从节点配置负载均衡，如权重和随机等负载均衡算法。对于事物中对延迟比较敏感的查询语句，也可配置为指定主节点进行查询，确保所数据的一致性。
关于读写分离能力的进一步介绍，以及对应的操作演示，请观看如下视频（时长 2’56’’）。
数据加密
适用场景：数据加密存储的数据安全场景，如等保合规等场景
数字化时代，数据安全威胁问题愈发凸显，数据安全在国家安全体系中的重要地位到倒进一步明确。数据加密存储的两个驱动力分别是合规和规避安全事件。对于出海欧洲的业务，则需要关注 GDPR，可通过一文初步了解。
对于数据加密存储的方案，常见的大概有六种，分别是应用加密方案、数据库加密网关方案、后置代理加密方案、数据库 TDE 加密方案、文件加密方案和磁盘加密方案。从实施成本方面来看，越往后的方案实施成本越低，从安全级别来看，越往后的方案安全级别越低。六种数据存储加密方案的详细说明可参考之前整理的文章最后的防线：数据存储加密方案。
ShardingSphere 提供了数据库加密网关方案，即在应用程序和数据库之间对数据进行加解密处理，数据库中存放密文数据，可有效防止组织内部违规检索及外部“脱库”安全事件。由于加密过程完全交给了 ShardingSphere，对于应用程序几乎是透明的，可最大化使用原有的 SQL。
- 加密算法
ShardingSphere 内置了五种加密算法，包括 MD5、AES、RC4、SM3 和 SM4，当然也可使用用户自定义的加密算法，自定义算法可通过 SPI 实现，也可对接加密机使用。
关于数据加密能力的进一步介绍，以及对应的操作演示，请观看如下视频（时长 3’14’’）。
影子库
适用场景：在线环境全链路压测的场景
为了提升系统压力测试的准确性和降低测试成本，部分企业会选择在指定时间对生产环境进行压力测试，通过 ShardingSphere 影子库的能力，可以获取系统真实的吞吐能力，同时可避免数据污染，满足复杂业务场景的在线压力测试需求。
影子库实现的原理是通过影子算法来决定流量具体的路由方向，它由影子算法所决定。影子算法包括基于列的影子算法和基于 Hint 的影子算法。
基于列的影子算法可设置数据特征，当复合指定特征的数据将会自动路由到影子库当中。对于带有 Hint 标识的数据，也可指定路由至影子库中。
关于影子库能力的进一步介绍，以及对应的操作演示，请观看如下视频（时长 3’17’’）。
联邦查询
适用场景：跨库表关联查询的实时分析场景
ShardingSphere 可对跨库的表进行关联查询处理，如不同业务模块下的两张用户表进行关联处理。相比以往的 ETL 处理方式，联邦查询是一个实时性相对较强，并且实施成本较低的方案。
操作流程相对简单，当部署好 ShardingSphere 之后，将两个数据源注册到 ShardingSphere 中即可，对于应用程序或者用户而言，两个数据源就是一套完整的数据库，SQL 语句按照正常的关联方式使用即可。
关于联邦查询能力的进一步介绍，以及对应的操作演示，请观看如下视频（时长 2’34’’）。
高可用
适用场景：ShardingSphere 感知存储节点可用性场景
以上介绍了 ShardingSphere 的一些核心能力，如数据分片和数据加密等，ShardingSphere 在提供数据增强能力的同时，在高可用方面也做足了功课。
ShardingSphere 本身不提供数据库高可用能力，需要数据库层高可用方案来实现，ShardingSphere 提供的是发现存储节点状态并切换的能力，当数据库节点出现故障时，ShardingSphere 会与新主节点建立连接，对上层业务无感。目前 ShardingSphere 高可用能力所支持的数据库架构如下。
- MySQL MGR 单主模式。
- MySQL 主从复制模式。
- openGauss 主从复制模式。
关于高可用能力的进一步介绍，以及对应的操作演示，请观看如下视频（时长 3’54’’）。
数据迁移
适用场景：单体数据库向 ShardingSphere 拆分迁移的场景
对于已经上线的业务，我们应该如何把数据迁移到 ShardingSphere 分布式集群中来？ShardingSphere 数据迁移的能力可以很好地解决这个问题。ShardingSphere 数据迁移能力为用户提供了单机到分布式的数据拆分和迁入能力，无需依赖第三方组件，即可在线完成数据迁移。
迁移过程主要分为两个阶段，存量数据迁移和增量数据同步，当开启迁移任务后，ShardingSphere 首先会对存量数据进行迁移，然后再根据 binlog 信息追增量数据。当数据追平之后，可在窗口时间（建议）或业务低峰期，通过内置校验功能进行源端和目标端数据一致性校验，刷新元数据后，即可上线分布式环境支撑业务。相关操作可参考数据迁移使用手册。
关于数据迁移能力的进一步介绍，以及对应的操作演示，请观看如下视频（时长 3’19’’）。
总结
以上是部分核心能力的解读，微内核 + 可插拔架构决定了 ShardingSphere 不存在功能的边界，因此 ShardingSphere 可以为用户提供很大的功能池，不同功能之间的组合可面对更多细分的业务场景。
