网站开发背景论文,网站如何做触屏滑动,租空间网站,百度售后服务电话人工#x1f680; 优质资源分享 #x1f680;
学习路线指引#xff08;点击解锁#xff09;知识定位人群定位#x1f9e1; Python实战微信订餐小程序 #x1f9e1;进阶级本课程是python flask微信小程序的完美结合#xff0c;从项目搭建到腾讯云部署上线#xff0c;打造一… 优质资源分享
学习路线指引点击解锁知识定位人群定位 Python实战微信订餐小程序 进阶级本课程是python flask微信小程序的完美结合从项目搭建到腾讯云部署上线打造一个全栈订餐系统。Python量化交易实战入门级手把手带你打造一个易扩展、更安全、效率更高的量化交易系统
作者刘晓敏
2022 年 4 月中国电子云开源了其云原生数据库 Mesh 项目 DBPack。该项目的诞生旨在解决用户上云过程中面临的一些技术难点诸如分布式事务、分库分表等。由于它数据库 Mesh 的定位意味着它可以支持任意微服务编程语言。
分布式事务
DBPack 的分布式事务致力于实现对用户的业务无入侵它对 HTTP 流量和 MYSQL 流量做了拦截代理支持 AT 模式自动补偿 SQL和 TCC 模式自动补偿 HTTP 请求。
DBPack 从 Kubernetes control loop 思想中获得灵感采用 ETCD Watch 机制来驱动分布式事务提交回滚。在采用代理使连接增加一跳的情况下它的性能相比采用 MYSQL 存储的分布式事务解决方案 seata-golang 性能提高了百分之 50。 AT 模式
AT 模式的性能取决于全局锁的释放速度哪个事务竞争到了全局锁就能对业务数据做修改在单位时间内全局锁的释放速度越快竞争到锁的事务越多性能越高。从 ETCD 官方 Bench 测试数据中可以看到ETCD 在高并发下读写延迟很低不同并发压力下写延迟 2 毫秒到 20 毫秒不等读延迟基本在 10 毫秒以内。采用 ETCD 来存储全局锁是 DBPack 分布式事务性能提升的关键。 上图展示了 seata-golang 协调一个分布式事务的交互逻辑。从图上我们可以看出事务发起者TM和事务协调者TC间存在创建开始全局事务、提交回滚全局事务 RPC 交互。事务参与者RM和事务协调者TC间存在注册分支事务、报告分支事务执行状态 RPC 交互。事务协调者TC和 MYSQL 交互保存状态数据。
而 DBPack 创建全局事务、注册分支事务只是在 ETCD 插入两条 KV 数据事务提交回滚时修改对应数据的状态DBPack Sidecar 通过 ETCD Watch 机制感知到数据的变化就能立即处理数据的提交回滚从而在交互上减少了很多 RPC 请求。 各 Sidecar Watch 应用产生的数据各自处理实际上已经没有中心化的事务协调者架构也变得简单了。核心的事务协调逻辑代码包括配置代码都比 Seata-golang 大幅减少。所以 DBPack 以全新的云原生的思路带了更简洁的架构和更高的性能。
seata-golang 事务协调核心代码
dbpack 事务协调核心代码
DBPack 支持所有微服务编程语言samples 中已提供了 Go 语言和 Java 语言的例子PHP 和 Python 的例子也在开发中。
TCC 模式
提到 TCC 模式大家可能第一时间想到 TCC 模式可能存在的问题幂等性、防悬挂等。事务悬挂产生的原因是什么其实这是一个很伪的问题 APP1 在调用 APP2 的 Prepare 方法之前事务框架根据上下文信息自动把 Commit、Cancel 需要执行的方法名以及 Prepare 方法执行的上下文告诉事务协调者注册分支事务再执行 Prepare 方法。如果执行 APP1 调用 APP2 的 Prepare 方法的时候发生网络问题导致 APP2 迟迟没有收到 Prepare 请求事务协调者经过一定时间后认为全局事务超时则 TC 根据注册上来的事务分支信息发起全局回滚此时APP1 向 APP2 发起一个 Cancel 请求很巧的是APP2 端 Cancel 请求比 Prepare 请求先到达事务空回滚后再收到 Prepare 请求Prepare 如果正常执行了那就完了全局事务已经回滚了这个 Prepare 操作永远也不会提交、回滚事务挂起了数据不一致了。
首先这种概率很小其次为什么一定要在 Prepare 网络请求之前注册分支事务可不可以在 APP2 收到 Prepare 请求执行业务代码之前注册这时候一定能确定 Prepare 请求已经到了Cancel 请求确定能在 Prepare 请求之后发生是不是就不存在悬挂问题了。
实际上 seata-golang 诞生之时就支持在分支业务执行端注册 TCC 事务分支但大家可能没有深入思考这个问题机械地认为事务悬挂必然会发生。
DBPack 也是在请求到达 sidecar 后再注册 TCC 事务分支确保 Prepare 先于 Cancel 执行。有人说因为 CPU 调度的原因还是可能出现 Cancel 先于 Prepare 执行的情况但这种概率非常非常低。具体到操作的业务数据建议使用 XID 和 BranchID 加锁。
读写分离
DBPack 当前支持对 SQL 请求自动路由写请求路由到写库读请求路由到读库。在开启事务的情况下请求自动路由到写库。同时也可以通过 SQL Hint 自动路由读请求到用户指定的数据库。
分库分表
分库分表的功能目前还在开发中当前已经支持跨分片、跨 DB 的查询请求支持 Order By 和 Limit。
结语
更多特性我们也在积极开发中DBPack 社区非常 Open进入到社区我们都是平等的开源爱好者在这里你也可以成长为大佬欢迎感兴趣的同学与我们一起建设 DBPack 社区。进群或参与社区建设请添加微信scottlewis。
链接
DBPack 项目地址https://github.com/cectc/dbpack
DBPack 文档https://cectc.github.io/dbpack-doc/#/