Apache ShardingSphere 团队先前应邀到海科融通北京总部,PMC Chair 张亮与海科融通的技术同学在异构数据库关联查询、分布式事务、两地三中心、系统高可用等方面展开了交流。
作为一家专业面向中小微商户、为行业提供完整支付解决方案及综合金融服务的高新技术企业,海科融通通过深耕支付行业与自我创新的紧密结合,目前已经打造出了符合行业需求的“支付+互联网”金融生态圈,用现代支付赋能传统商业。海科融通深耕金融领域二十多年,频繁交易产生的巨量数据以及多元数据库并存的状态,使得后台架构面临的挑战愈发严峻。因此海科融通选择 Apache ShardingSphere,为未来在处理支付生态里海量的多元化数据方面引进新思路。
在执行了数据库分片操作后,由于事务不在同一个实例下,许多用户会关注跨节点状态下数据查询的能力。作为 Apache ShardingSphere 的功能特性之一,联邦查询能够解决跨节点查询的问题。但与此同时,跨节点查询会带来非常高的性能损耗,这对于性能、反应要求较高的场景下是不可接受的。
为此,Apache ShardingSphere 在联邦查询体系中引入了查询优化模块。通过优化模型, Proxy 能够计算出相对高效的执行方案,将数据分为必要与不必要两类,在各自的分片中对必要的数据进行跨节点计算,不必要的数据即留在本地处理,进而减少因跨节点查询所带来的性能浪费。
ShardingSphere 可以承载一部分实际业务的聚合查询工作,不过面对复杂业务或数据体量较大的情况下,一般选择将分析的工作下推。因为 ShardingSphere 本身在实现查询时也需要下推之后再做聚合。如果要实现 AP 计算,ShardingSphere 最后对接的一定是像 Hbase、ClickHouse 等此类数据库,而并非 MySQL 此类数据库。
两地三中心,本质上是技术+管理的综合性方案。目前 ShardingSphere 的两地三中心策略分为三个层面:
目前 ShardingSphere 的治理节点是通过 ZooKeeper 或 ETCD 实现的。如果要部署五个治理节点,将三个 ZooKeeper 部署在同一节点下,将另外的两个 ZooKeeper 分别部署在另外两个节点中。如果其中一个机房出现问题,ZooKeeper 依然可以正常运作。
至于网络消耗问题,ShardingSphere 的线上流量分为两部分,只有管理流量才会走 ZooKeeper,真正的线上流量是不会经过 ZooKeeper 的。因此即使是 ZooKeeper 挂掉了,ShardingSphere 也不会受影响,只是不能去改变 ZooKeeper 的配置。ShardingSphere 的大部分流量是不用经过治理中心的,只有管理流量才会经过治理中心。同时 ShardingSphere 本地也缓存一份治理中心的源数据,因此即便外部出现不可用的问题,ShardingSphere 本身也不会受到影响。
是没有额外成本的。目前 Apache ShardingSphere 提供 XA 及柔性事务集成方案。在 ACID 事务中对隔离性的要求很高,在事务执行过程中,必须将所有的资源锁定。柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面,通过放宽对强一致性要求,来换取系统吞吐量的提升。不过在使用过程中,由于性能没有 XA 高,使用柔性事务的感受不如使用 XA 的感受好,因此用户大多比较熟悉 XA。
这里以 XA 为例。作为 ShardingSphere 分布式事务管理中的一部分,XA 本身分为 AP、TM 以及 RM 三部分。其中 AP 即应用程序,TM 为事务管理器,RM 为资源管理器。ShardingSphere 是将 AP 和 TM 融合在了一起,通过将本地事务转换成为 AP 和 TM,然后再和 RM 进行交互,进而完全屏蔽用户使用 XA 的感知。
欢迎点击链接,了解更多内容:
Apache ShardingSphere 官网: https://shardingsphere.apache.org/
Apache ShardingSphere GitHub 地址: https://github.com/apache/shardingsphere
SphereEx 官网: https://www.sphere-ex.com
欢迎添加社区经理微信(ss_assistant_1)加入交流群,与众多 ShardingSphere 爱好者一同交流。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70001955/viewspace-2896957/ ,如需转载,请注明出处,否则将追究法律责任。