这个AI能帮女朋友自拍
|
如果任何一个 XA Client 否决了此次提交，所有数据库都要求 XA Manager 回滚它们在事务中的信息，优点是可以最大程度保证了数据的强一致，适合对数据强一致要求很高的业务场景;缺点就是实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。 本地消息表
本地消息表实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。 通过数据同步工具将 user 库的 users 表实时同步到trade库中，这样就可以直接在 trade 库做 Join 操作，比较依赖于同步工具的稳定性，如果同步有延迟，就会导致数据不一致，产生脏数据，需要做好风险评估和兜底方案。 分布式事务问题 拆分之后，数据分布在不同的 RDS 实例上，对表的 DML 操作就变成了多个子表的 DML 操作，就涉及到分布式事务，也要遵循事务 ACID 特性，同时也会提到两个重要的理论：CAP(Consistency一致性，Availability可用性，Partition tolerance分区容忍性Partitiontolerance)和BASE(Basically Available基本可用， Soft state软状态，Eventually consistent最终一致性)，进而产生了解决分布式事务问题不同的方案。 MySQL XA事务
MySQL支持分布式事务(XA 事务或者 2PC 两阶段提交)，分为两个阶段：Prepare 和 Commit，事务处理过程如下 这样解决了订单表 orders 太大的问题，查询的时候要先通过分区键 user_id 定位是哪个 RDS 实例，再定位到具体的子表，然后做 DML操作，问题是代码改造的工作量大，而且服务调用链路变长了，对系统的稳定性有一定的影响。其实已经有些数据库中间件实现了分库分表的功能，例如常见的 mycat，阿里云的 DRDS 等。 分布式数据库 通过上面的分表和分库方案的介绍，主要会遇到下面三类问题：
拆分后的问题 垂直拆分 跨库Join问题 在垂直拆分之前，系统中所需的数据是可以通过表 Join 来完成的，而拆分之后，数据库可能分布式在不同 RDS 实例，Join 处理起来比较麻烦，根据 MySQL 开发规范，一般是禁止跨库 Join 的，那该怎么处理呢? 首先要考虑这种垂直拆分的合理性，如果可以调整，那就优先调整，如果无法调整，根据以往的实际经验，总结几种常见的解决思路。 全局表 用过 mycat 做分库分表的朋友都清楚，有个全局表的概念，也就是每个 DataNode 上都有一份全量数据，例如一些数据字典表，数据很少修改，可以避免跨库 Join 的性能问题。 数据同步
对于分布式系统，不同的服务的数据库是分布在不同的 RDS 实例上的，在禁止跨库 Join 的情况下，数据同步是一种解决方案。 （编辑：孝感站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
