业界主流的互联网架构中，分布式服务框架、分布式数据访问服务、消息队列服务、服务网关(API)、分布式事务等都是核心的组件和框架。 当我们的系统规模越来越大，从几台服务器扩展到几十台、几百台、上千台，传统的烟囱式的、大集中式系统架构，逐步演进为服务化SOA、分布式的系统架构： 在数据层面，应用层面，访问层面和查询方面，全都以分布式的结构来搭建，使整个系统不存在性能和横向扩展的瓶颈，实现系统的弹性伸缩和横向扩展， 以支撑我们超大规模的系统。 最近研究了业界主流的分布式数据访问服务，做了一次横向对比和分析。基于对比做技术选型、验证，目的就是要设计一套.Net版本的分布式数据访问组件。 搞了这么多年.Net，ORMapping（EF、Hibernate、MyBatis），有必要搞一个“分布式数据访问服务”的技术专题，作为总结和技术分享。 这个系列的第一篇以"华山论剑" 开始吧，细数各门各派的看家本领（分布式数据访问服务框架），一较高低！ 一、微软Azure SQL 使用 Azure SQL 数据库的可缩放工具和功能，可以轻松地横向扩展数据库。特别是可以使用弹性数据库客户端库来创建和管理扩大的数据库。 此功能支持使用成百上千个 AzureSQL 数据库，轻松地开发数据分区应用程序。然后，可以使用弹性作业帮助简化这些数据库的管理。 它包含了三个核心组件：分片映射管理、数据路由、多分片查询 1.分片映射管理器：分片映射管理器是一个特殊的数据库，它维护一个分片集中有关所有分片 （数据库）的全局映射信息。 2.数据路由：使用查询中的数据将请求路由到相应数据库的功能 假设将一个请求传入应用程序。基于请求的分区键值，应用程序必须根据该键值判断正确的数据库。接着，它会与数据库建立连接来处理请求。借助数据依赖路由， 能够通过对应用程序的分片映射的单个简单调用打开连接，进行数据操作： 3.多分片查询：多分片查询用于诸如数据收集/报告等需要跨多个分片运行查询的任务。（相比之下，数据相关的路由会在单个分片上执行所有操作。） 当一个请求涉及多个（或所有）分片时，多分片查询将生效。多分片查询在所有分片或一组分片上执行相同的 T-SQL 代码。使用 UNION ALL 语义， 将参与分片中的结果合并到一个总结果集中。该功能是通过该客户端库处理多个任务公开的，其中包括连接管理、线程管理、故障处理和中间结果处理。 最多可以查询数百个分片 总结：微软的Azure SQL是一个PaaS层的数据访问服务，需要将本地数据库迁移到Azure SQL，即云端SQLServer中， 整个Azure SQL支持对SQLServer的横向扩展，在SDK层面简化屏蔽了分库分表带来的一些编程问题，如果采用Azure SQL的话， 分库分表的部署、管理、集成的确非常方便，原生支持。但是本地化私有云环境下，SQLServer的分库分表就需要自己搞了。 二、阿里分布式关系型数据库服务DRDS云端数据库PaaS服务 DRDS 目前定位成一个中间件（前身是TDDL），在业务应用和RDS（关系型数据库服务器）之间，本身不承担数据存储， 只负责解决分布式情况下数据操作路由、执行、数据处理等功能。主要支持的数据库是MySQL。 DRDS的使用与MySQL非常接近，建实例、建库、建表、SQL操作，唯一比较大的区别在于水平拆分模式下，DRDS对于建表需要指定拆分字段(类似索引)， 只要带上这个拆分字段，SQL只会在部分数据分片上执行，从而加速SQL执行速度。 DRDS有着比较完整的MySQL SQL兼容性 DRDS 对于单机事务完整支持，也就是业务中一个事务中的各个SQL最终都落到同一个数据库即可保障强一致， 对于跨数据库的分布式事务，DRDS提供最终一致分布式事务给业务使用，目前处于内测阶段。 1. DRDS基本原理-读写分离： 对于sql进行类型判定，如果判定为读取操作，则按照用户设置的读权重进行sql路由，到主实例或者到只读上进行sql操作。 2. DRDS基本原理-水平拆分 对于sql进行类型判定，如果判定为读取操作，则按照用户设置的读权重进行sql路由，到主实例或者到只读上进行sql操作。 DRDS中的数据是按照拆分字段值，加上特定的算法进行计算，根据结果存储数据到对应分片。 3. DRDS基本原理-SQL路由 当用户SQL到DRDS时，DRDS会解析整个SQL含义，然后按照拆分字段的值和执行策略将SQL路由到对应分区进行执行。 4. DRDS基本原理-数据合并： 如果一个SQL对应多个分片数据执行，DRDS会将各个分片返回的数据按照原始SQL语义进行合并。 5. DRDS支持的SQL语法 6. DRDS不支持的SQL语法： 受限于分布式事务
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
