微服务架构中的数据一致性 挑战 在传统的单体应用程序架构中，一个共享的关系型数据库负责维护数据一致性。在微服务架构中，每个微服务通常有自己的数据存储，这导致数据库分布在应用程序之间。不同的微服务可能采用不同的技术管理其数据，例如非关系型数据库。 这种分布式架构虽然在可伸缩性、高可用性和灵活性方面提供了好处，但它也带来了关键的数据一致性/完整性和事务管理问题。 ACID 特性和单体应用程序 在单体应用程序中，通过 ACID 事务，一个共享的关系型数据库保持数据一致性。ACID 是一个缩写，代表： 原子性 (Atomicity)：事务中的所有操作要么全部成功，要么全部失败。 一致性 (Consistency)：事务将数据库从一种有效状态转换为另一种有效状态。 隔离性 (Isolation)：一个事务对数据库所做的更改对于其他同时运行的事务是不可见的。 耐久性 (Durability)：一旦事务提交，对其所做的更改将永久存储，即使发生系统故障。 关系型数据库管理系统通过支持 ACID 特性来维护强数据一致性。 微服务架构中的 ACID 挑战 在微服务架构中，每个微服务都有自己的数据存储，并且使用不同的技术。因此，没有中央数据库或单一的事务工作单元。业务逻辑跨多个本地事务进行，这意味着您无法跨微服务架构中的数据库使用单一的事务工作单元。 但是，您仍然需要在应用程序中使用 ACID 特性。为了说明这一点，让我们考虑一个简单的示例场景： 订单管理系统示例 在一个订单管理系统中，可能存在库存管理、支付和订单管理等服务。假设这些服务都按照微服务架构设计，并应用了 "每个服务一个数据库" 的模式。 为了完成订单流程，订单服务首先调用库存管理服务进行库存控制和预留。订单中的相关产品被预留，以防止卖给其他客户。第二步是支付步骤。支付服务负责支付业务。订单服务调用支付服务，从客户的信用卡中完成支付。 由于每个服务都是独立的，对分离的数据库的更新在服务范围内被提交。最后一步是创建订单记录。在这一步中，假设发生了技术错误，订单记录无法创建，订单号无法发送给客户，但已从客户那里收到了付款。 这里出现了数据一致性问题。在客户的信用卡被收取费用但订单未创建的情况下，系统处于不一致的状态。 可能的解决方案 解决微服务架构中的数据一致性问题没有一刀切的解决方案。根据具体情况，可以采用不同的方法。有两种主要方法： 分布式事务 在分布式事务中，事务跨两个或多个资源（例如数据库、消息队列）执行。通过分布式事务管理器或协调器，跨多个数据库保证数据的完整性。 分布式事务是一个复杂的过程，因为涉及多个资源。两阶段提交 (2PC) 是一种阻塞协议，用于确保在分布式事务中所有事务要么全部成功，要么全部失败。XA 标准是 2PC 分布式事务的规范。JTA 包括 Xtandard API。符合 JTA 标准的应用程序服务器支持 Xtandard API。 分布式事务的优点： 提供强数据一致性 适合依赖 ACID 事务的应用程序 分布式事务的缺点： 复杂且难以实现 性能开销高 阻塞性，限制了应用程序的并发性 最终一致性 最终一致性是一种用于在分布式系统中实现高可用性的模型。在一个最终一致性的系统中，允许一段时间的不一致，直到解决分布式数据的问题。此模型不适用于跨多个微服务的分布式 ACID 事务。 最终一致性使用 BASE 数据库模型。虽然 ACID 模型提供了一个一致的系统，但 BASE 模型提供了高可用性。BASE 是一个缩写，代表： 基本可用性 (Basic Availability)：即使发生系统故障，系统也可以继续运行。 软状态 (Soft State)：系统中的状态可能在一段时间内不一致。 最终一致性 (Eventual Consistency)：经过一段时间后，系统中的所有副本都将最终收敛到一致的状态。 SAGA 模式 SAGA（事务应用程序协作的简单准则）是一种常见的模式，用于实现最终一致性模型。在 SAGA 中，事务通过一系列局部事务执行，称为子事务。这些子事务按照特定顺序执行，并且在发生故障时可以补偿。 SAGA 的优点： 提供最终一致性 高性能和高并发性 易于实现 SAGA 的缺点： 只能用于无状态应用程序 需要仔细设计和编排，避免死锁和异常情况 选择适当的方法 选择解决微服务架构中数据一致性问题的最佳方法取决于应用程序的特定要求。一般来说，如果应用程序需要强数据一致性，则分布式事务是更合适的选择。但是，如果应用程序重视高可用性和性能，最终一致性可能是一个更好的选择。 结论 在微服务架构中维护分布式数据存储之间的数据一致性可能非常具有挑战性。通过仔细考虑应用程序的特定需求和可用的解决方案，组织可以实现数据一致性，同时受益于微服务架构所提供的优势。

---

数据库系统中 数据的一致性指的是什么？

同步更新。

简单说来就是一条column的数据在多个表中保持同步更新， 一般用foreign key实现mapping

比如两张表table1,table2

其中table1的uid column是primary key，table2的uid column是foreign key,

则当修改table1的uid column的一row时，table2的对应row也会自动更新。

扩展资料：

常用的一致性模型有：

1、严格一致性（linearizability, strict/atomic Consistency）：读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能，在分布式网络环境不可能实现。

2、顺序一致性（sequential consistency）：所有使用者以同样的顺序看到对同一数据的操作，但是该顺序不一定是实时的，等。

Java互联网架构-微服务架构如何解决跨库问题的思路与方案？

我们公司使用的就是微服务加分库分表，一般来说如果应用系统出现性能瓶颈或者业务代码耦合过重，可考虑使用微服务架构，而后端的数据库通常使用读写分离，双主互备或者是分库分表来实现性能的提升和数据服务的高可用。

在数据分布在不同的数据库服务器的带来良好性能的同时，新的问题也随之而来，比如说数据一致性的保证，性能监控，数据存取复杂等，而较为突出的就是数据跨库问题！数据分布在不同的节点上，导致原来的连接查询需要跨库，字段的主键难以保证唯一，跨库的事务处理复杂，下面逐一解决:

1，连接查询(join)问题:因为库表分布在不同的机器上，连接查询失效。

解决办法:

①，代码解决:根据某个字段进行hash的方式进行分库分表，保证落在一个库中的类似表中(比如aa_00.t_user_0000和aa_00.t_member_0000)，然后基于这样的规则在代码中进行连接查询语句书写！

②，同步:将常用的，需要的字段同步到一个库中进行联合查询！

③，冗余:在一个库中冗余更多的连接查询需要的字段，保证全部数据都能查询到！

2，唯一主键:如果使用传统的自增等方式，多库中的主键id势必重复，所以需要对唯一性加以控制！

解决方法:UUID(根据机器ID，时间等)，redis(单线程保证不重复)，snowflake算法！

3，分布式事务:

1，TCC:try控制业务代码流程，Confirm确认事务的正确性，cancel取消失败的事务！

2，基于消息系统的一致性方案:单节点事务完成后，通过发送消息保证事务提交，如果失败可通过重试，任务补偿等方式保证数据一致性！

总的来说，分布式系统有着很多以往不存在的问题，还需要具体问题具体分析，可一起交流，更多的技术分享，敬请关注。。。