微服务架构下的数据一致性
微服务系统和数据库设计方案
微服务系统和数据库设计方案随着互联网的不断发展和应用的日益普及，传统的单体应用架构已经很难满足需求的快速变化和高并发的要求。
微服务架构作为一种新的应用架构模式，逐渐受到了越来越多的关注和应用。
以下是一个微服务系统和数据库设计方案的详细分析。
1.微服务系统设计方案在设计微服务系统时，需要考虑以下几个方面：1.1服务拆分：根据业务逻辑将应用拆分成多个小服务，每个服务都包含一个或多个特定的业务功能。
1.2 服务通信：由于各个微服务是自治的，所以它们之间需要通过一定的通信机制进行协作。
可以使用RESTful、消息队列等方式进行服务之间的通信。
1.3 服务注册与发现：为了方便管理和访问各个微服务，可以使用服务注册与发现的机制，例如使用Eureka、Consul等工具。
1.4服务容错：针对服务的故障和异常，需要设计容错机制来保证系统的可用性和稳定性。
可以使用断路器、限流、降级等手段。
1.5数据一致性：由于微服务的分布式特性，会面临数据一致性的挑战。
需要设计一套合理的数据同步和一致性保证机制。
在微服务系统的数据库设计时，需要考虑以下几个方面：2.1数据库类型选择：根据业务需求和数据模型的复杂度，选择适合的数据库类型，例如关系型数据库、NoSQL数据库等。
2.2数据库拆分：由于微服务架构的分布式特性，数据库也需要进行拆分，可以根据业务功能、数据关系等进行拆分，以避免单一数据库的性能瓶颈。
2.3数据库复制和同步：为了提高系统的可用性和容错性，可以使用数据库复制和同步机制，例如主从复制、多主复制等。
2.4 数据库缓存：可以使用缓存技术，例如Redis、Memcached等，来提高数据库的读取性能和并发处理能力。
2.5数据库备份和恢复：为了保证数据的安全性，需要定期对数据库进行备份，并设计相应的恢复机制。
综上所述，微服务系统和数据库设计方案需要考虑各个微服务的拆分与通信、服务注册与发现、容错和数据一致性等方面。
数据库设计需要考虑数据库类型选择、拆分、复制与同步、缓存和备份恢复等方面。
微服务架构下的故障排查与问题定位(三)
微服务架构下的故障排查与问题定位引言：随着互联网的高速发展，微服务架构逐渐成为企业构建复杂应用系统的首选。
微服务架构的优势在于提供了高可伸缩性、灵活性和可重用性。
然而，由于微服务架构的复杂性，故障排查和问题定位变得更加困难和挑战性。
本文将探讨微服务架构下的故障排查与问题定位，以帮助开发人员和运维团队更好地解决潜在问题。
第一部分：故障排查方法论在微服务架构下，故障排查应该采用一种系统化的方法论。
以下是一种常用的故障排查方法论：1. 监控与日志分析：监控是首要任务，通过对关键指标和日志的监控与分析，可以预测和发现潜在的故障。
通过集中式的日志平台，可以实现日志的集中存储和分析，帮助快速定位问题。
2. 压力测试和负载均衡：利用压力测试工具对系统进行负载测试，找出系统的瓶颈和性能瓶颈。
通过负载均衡策略，可以分散请求，提高系统的稳定性和可用性。
3. 分布式跟踪和调用链分析：借助分布式跟踪系统，可以对整个微服务架构进行调用链追踪，定位请求在系统中的路径和耗时。
通过调用链分析，可以发现耗时过长的服务或组件，定位潜在的性能问题。
第二部分：常见故障和问题定位在微服务架构中，虽然故障的种类繁多，但有一些常见的故障和问题定位方法可以参考。
1. 服务间通信故障：当服务之间出现通信故障时，可从网络层面着手排查。
检查网络配置、防火墙规则和网络带宽是否满足需求。
同时，还可以使用诸如ping、telnet等工具进行网络连通性测试，以定位具体问题。
2. 数据一致性问题：在微服务架构下，数据一致性是一个重要的问题。
当数据在多个服务之间传递时，可能会出现数据不一致的情况。
此时，可以通过在服务中添加日志、分析数据库操作日志的方式来排查问题，定位数据更新失败或者不一致的原因。
3. 服务性能问题：当某个服务出现性能瓶颈或响应变慢时，可以通过日志分析、代码性能优化以及系统资源利用率监控等方法进行问题定位。
借助性能分析工具，如Java VisualVM、Gatling等，可以定位到性能瓶颈所在的方法和代码段。
《2024年面向微服务重构的关系数据库拆分方法研究》范文
《面向微服务重构的关系数据库拆分方法研究》篇一一、引言随着企业业务规模的不断扩大和系统复杂性的日益增长，微服务架构已成为现代软件开发的重要选择。
在微服务架构中，数据管理和存储成为了一个重要的问题。
其中，关系数据库的拆分与重构，直接影响到系统的性能、扩展性及整体运维效率。
本文将重点探讨面向微服务重构的关系数据库拆分方法，以助力企业构建更高效、可扩展的微服务系统。
二、关系数据库拆分的背景与必要性随着业务的发展，传统单一数据库的架构逐渐难以满足系统的性能需求。
尤其在微服务架构下，服务之间的依赖性和交互性增加，单一的数据库可能导致数据访问冲突、性能瓶颈及维护困难等问题。
因此，对关系数据库进行拆分和重构成为了一个必要的需求。
通过拆分数据库，可以降低系统复杂性，提高数据访问性能和扩展性，同时简化运维工作。
三、关系数据库拆分的方法与策略1. 垂直拆分垂直拆分是指根据业务功能或模块将数据库进行拆分。
在微服务架构中，每个服务负责特定的业务功能，因此垂直拆分可以与微服务的划分相对应。
通过将不同的业务功能或模块的数据存储在不同的数据库中，可以降低数据访问的耦合性，提高系统的可扩展性。
2. 水平拆分水平拆分是指将同一类型的数据按照一定的规则进行拆分，存储在多个数据库中。
这种方法适用于数据量巨大的情况，通过将数据分散到多个数据库中，可以平衡负载，提高系统的并发处理能力。
在微服务架构中，水平拆分可以与服务的横向扩展相结合，实现动态调整数据库资源的需求。
3. 分片与分库策略在关系数据库的拆分过程中，需要制定合理的分片与分库策略。
分片是指将数据按照一定的规则进行切片，每个切片存储在不同的数据库中。
而分库则是指将整个数据库按照业务或功能进行拆分。
在制定策略时，需要考虑数据的关联性、查询性能、事务处理等因素，以确保数据的完整性和一致性。
四、关系数据库拆分的实施步骤1. 需求分析：根据业务需求和系统架构，分析数据库拆分的必要性及可行性。
微服务架构的优劣比较
微服务架构的优劣比较随着互联网行业的不断发展，越来越多的企业开始关注微服务架构。
相比传统的单体架构，微服务架构更加容易扩展和维护，并且能够满足不同的业务需求。
但是微服务架构也有其优劣之处，本文将就微服务架构的优劣进行比较分析。
一、微服务架构的优势1. 可扩展性强微服务架构是基于模块化的设计，每个模块都是独立的服务单元。
这种设计可以更加容易实现水平扩展，即集群化扩展。
只需要增加更多的服务实例即可处理更多的请求，而不需要改变整个系统的结构，这极大地提高了系统的可扩展性。
2. 业务解耦微服务架构中每个服务都可以拥有自己独立的数据存储、业务逻辑和接口。
这种设计可以更好地解耦业务，增加系统的可维护性和可拓展性。
3. 技术栈多样性微服务架构中每个服务都可以使用不同的技术栈，例如Java、PHP、Node.js等。
这使得开发人员可以使用最适合自己的技术栈，进而提高开发效率和服务的稳定性。
4. 高度可用性微服务架构中的服务都是独立的，一个服务的故障并不会影响到整个系统的正常运行。
并且每个服务可以有多个实例，保证了高度的可用性。
5. DevOps和敏捷开发微服务架构可以很好地支持DevOps和敏捷开发，快速地迭代和发布服务，同时也让开发人员能够更加专注于自己的领域。
二、微服务架构的劣势1. 系统复杂度高微服务架构由多个独立的服务组成，每个服务都有独立的数据库、缓存、日志等。
这样就会导致系统的复杂度大大增加，同时也需要更多的专业人员来维护系统。
2. 系统集成难度增加在微服务架构中，不同的服务需要进行相互调用和协作，这就需要将它们进行集成。
这会让系统集成难度增加，同时也增加了系统的风险。
3. 部署和维护成本高微服务架构中有多个独立的服务，需要对每个服务进行部署和维护。
这会增加系统的部署和维护成本。
4. 数据一致性问题微服务架构中每个服务都有独立的数据库，这就会带来数据一致性问题，需要通过事务、事件等手段来保证数据的一致性。
微服务架构的组件挑选与集成(一)
微服务架构的组件挑选与集成引言：随着云计算和物联网的快速发展，微服务架构在许多应用程序中得到了广泛应用。
微服务架构具有良好的可伸缩性和灵活性，可以帮助开发人员更好地管理复杂的应用程序。
在实施微服务架构时，组件的选择和集成是一个关键的决策。
一、微服务架构的概述微服务架构是一种通过将应用程序拆分为更小、更独立的服务来构建应用程序的方法。
每个服务都可以独立部署，横向扩展和更新。
这种架构风格可以提高开发效率和应用程序的可伸缩性。
二、组件挑选与集成的重要性在实施微服务架构时，选择适合的组件和正确地集成它们是至关重要的。
良好的组件选择和集成可以提高应用程序的性能、可靠性和可维护性。
错误的选择或不正确的集成可能导致性能问题、软件故障以及长期的维护困难。
三、组件挑选的考虑因素1. 功能要求：首先，需要明确应用程序的功能需求，以便选择具备必要功能的组件。
例如，如果应用程序需要进行大规模数据处理，那么选择一个高效的分布式计算组件是非常重要的。
2. 开源与商业：目前市场上有许多开源和商业的微服务组件可供选择。
根据项目的需求和预算，权衡开源和商业组件的优缺点，做出明智的选择。
3. 社区支持：选择具有活跃社区支持的组件。
活跃的社区可以提供及时的更新和bug修复，以及对常见问题的技术支持。
4. 可扩展性：组件应该具备良好的可扩展性，以便应对未来的增长和变化。
考虑组件是否可以容易地横向扩展，以应对高并发的需求。
四、组件集成的挑战组件选择后，正确的集成是实现微服务架构成功的关键一步。
以下是一些组件集成中可能面临的挑战：1. 通信协议：不同的服务需要通过合适的通信协议进行通信。
例如，RESTful API和消息队列是常用的通信协议。
在集成组件时，需要确保它们使用相同的通信协议，以便实现有效的通信。
2. 服务发现与负载均衡：微服务架构中的服务数量通常很大，因此需要一种机制来发现和管理服务的位置和状态。
同时，负载均衡是确保请求被均匀分配到不同服务上的关键因素。
mic学架构面试题
mic学架构面试题一、什么是微服务架构？微服务架构是一种软件开发模式，将一个大型的应用程序拆分成多个小型、独立的服务。
每个服务都可以独立运行、独立开发、独立部署，并通过轻量级的通信机制（例如HTTP、消息队列等）来相互协作。
微服务架构通过将应用程序拆分成独立的服务，使得开发人员能够更快速地开发、测试和部署新功能，降低系统的耦合度，提高系统的可伸缩性和可维护性。
二、微服务架构的核心原则有哪些？1. 单一职责原则：每个微服务只负责一个明确的业务功能，服务的职责应该尽量保持单一且清晰。
2. 松耦合原则：各个微服务之间应该尽量避免直接的依赖关系，通过接口进行通信，减少服务之间的耦合度。
3. 独立演化原则：每个微服务都可以独立进行开发、测试和部署，不影响其他服务的正常运行。
4. 自动化部署原则：通过持续集成和自动化部署工具，实现微服务的快速部署和水平扩展，提高开发效率。
5. 去中心化治理原则：不依赖集中的管理平台，而是通过自愿协作和去中心化的方式来实现服务的发现、负载均衡和故障恢复等功能。
三、微服务架构的优势有哪些？1. 弹性伸缩：由于微服务的独立性，可以根据需求对某个具体服务进行个性化的扩展和收缩，提高系统对并发和高负载的处理能力。
2. 独立部署：每个微服务都可以独立进行开发、测试和部署，不影响其他服务的正常运行，进而提高交付速度和可靠性。
3. 技术多样性：不同的微服务可以使用不同的开发语言、框架和数据存储技术，使团队可以根据具体需求选择最适合的技术栈。
4. 故障隔离：由于微服务之间的松耦合，某个服务的故障不会影响整个系统的稳定性，可以进行精细的故障定位和快速的恢复。
5. 持续交付：由于微服务的独立性和自动化部署的支持，可以实现快速迭代和持续交付，减少上线的风险和时间成本。
6. 更好的可维护性：每个微服务都可以单独进行修改和维护，不影响其他服务的正常运行，使得系统更容易进行代码维护和重构。
四、微服务架构的挑战有哪些？1. 分布式系统复杂性：微服务架构面对的是一个分布式系统，需要处理网络通信、服务调用和数据一致性等复杂性问题。
微服务应用案例分析
▪ 数据一致性与分布式事务
1.在微服务架构中，保证数据的一致性和处理分布式事务是挑战之一。 2.可以采用分布式事务框架或者事件驱动架构等方式来解决数据一致性问题。 3.需要根据具体业务场景和数据一致性需求来选择合适的解决方案。
微服务应用案例分析
微服务间的通信与协调
微服务间的通信与协调
▪ 微服务间通信协议选择
1.选择合适的通信协议对于微服务间的通信与协调至关重要， 常见的通信协议包括HTTP/HTTPS、gRPC、AMQP等。 2.在选择通信协议时，需要考虑服务间的通信频率、数据量、 实时性要求等因素。 3.不同的通信协议各有优缺点，需要根据具体业务场景进行选 择和优化。
总结与展望
▪ 微服务应用的发展趋势
1.微服务应用将继续保持高速发展的趋势，成为应用架构的主流方式。 2.未来微服务将更加注重智能化和自动化，通过机器学习和人工智能等技术提高微服务的自治 能力和智能化水平。 3.微服务将与云计算、大数据、物联网等技术更加紧密地结合，发挥更加全面和高效的作用。
▪ 微服务应用的前景展望
1.服务拆分：根据业务领域和功能模块，将电商系统拆分为多个独立的微服务。 2.服务接口设计：定义微服务之间的接口协议和数据格式，保证服务之间的松耦合和可复用性 。
案例一：电商系统微服务化
电商系统微服务化的实施过程
1.服务开发：采用敏捷开发方法，快速迭代和交付微服务。 2.服务测试：确保每个微服务的质量和稳定性，降低集成测试 的难度。
软件架构设计中的微服务拆分原则与实践
软件架构设计中的微服务拆分原则与实践在软件架构设计中，微服务架构已经成为一种流行的设计模式。
微服务架构通过将大型应用程序拆分为一系列小型、自治的服务，以提高系统的可伸缩性、可维护性和灵活性。
微服务架构的核心在于如何进行服务的拆分，即根据什么原则来确定每个服务的边界。
本文将介绍微服务拆分的原则和实践，以帮助软件架构师更好地理解和应用微服务架构。
一、单一责任原则在进行微服务的拆分时，首先要考虑的原则是单一责任原则。
单一责任原则是一种面向对象设计的原则，它要求一个类或者一个模块只负责完成一个明确的职责。
在微服务架构中，同样需要遵守这个原则，即将一个服务设计成只负责一个明确的业务功能。
这样可以降低服务之间的耦合度，使得每个服务可以独立地进行开发、测试和部署。
拆分服务时，可以根据业务功能的不同将服务进行拆分。
例如，一个电子商务系统可以拆分为订单服务、支付服务、用户服务等。
每个服务只专注于自己的业务功能，实现了单一责任原则。
二、高内聚低耦合原则高内聚低耦合是软件设计的另一个重要原则，同样适用于微服务架构的拆分。
高内聚指的是一个模块或者一个服务内部的组件之间关联紧密，共同完成同一个功能。
低耦合则是指两个模块或者服务之间的依赖关系尽量松散，一个模块的变化不会影响到其他模块。
在微服务架构中，高内聚低耦合的原则可以帮助我们确定服务的边界。
一个微服务应该包含着一个业务功能所需的所有组件，这些组件彼此之间关联紧密，共同完成同一个功能。
同时，一个微服务尽量与其他微服务之间的依赖关系较弱，每个服务都可以独立地进行开发和部署。
三、可用性与可伸缩性原则在构建微服务架构时，可用性和可伸缩性是非常重要的考虑因素。
可用性是指系统在运行过程中持续地为用户提供服务的能力，而可伸缩性是指系统能够根据负载的变化来动态地调整资源的能力。
在微服务架构中，服务的拆分应该考虑到可用性和可伸缩性的要求。
一方面，可以将服务按照业务功能的不同进行拆分，这样每个服务可以独立地进行横向扩展，提高服务的可伸缩性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
微服务架构下的数据一致性写在前面随着微服务架构的推广，越来越多的公司采用微服务架构来构建自己的业务平台。
就像前边的文章说的，微服务架构为业务开发带来了诸多好处的同时，例如单一职责、独立开发部署、功能复用和系统容错等等，也带来一些问题。
例如上手难度变大，运维变得更复杂，模块之间的依赖关系更复杂，数据一致性难以保证，等等。
但是办法总是比问题多，本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的。
微服务架构的数据一致性问题以电商平台为例，当用户下单并支付后，系统需要修改订单的状态并且增加用户积分。
由于系统采用的是微服务架构，分离出了支付服务、订单服务和积分服务，每个服务都有独立数据库做数据存储。
当用户支付成功后，无论是修改订单状态失败还是增加积分失败，都会造成数据的不一致。
为了解决例子中的数据一致性问题，一个最直接的办法就是考虑数据的强一致性。
那么如何保证数据的强一致性呢？我们从关系型数据库的ACID 理论说起。
ACID关系型数据库具有解决复杂事务场景的能力，关系型数据库的事务满足ACID 的特性。
•Atomicity：原子性（要么都做，要么都不做）•Consistency：一致性（数据库只有一个状态，不存在未确定状态）•Isolation：隔离性（事务之间互不干扰）•Durability：永久性（事务一旦提交，数据库记录永久不变）具有ACID 特性的数据库支持数据的强一致性，保证了数据本身不会出现不一致。
然而微服务架构下，每个微服务都有自己的数据库，导致微服务架构的系统不能简单地满足ACID，我们就需要寻找微服务架构下的数据一致性解决方案。
微服务架构的系统本身是一种分布式系统，而本文讨论的问题其实也就是分布式事务之数据一致性的问题，我们来聊聊分布式系统的CAP 理论和BASE 理论。
CAPCAP 是指在一个分布式系统下，包含三个要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），并且三者不可得兼。
•C：Consistency，一致性，所有数据变动都是同步的。
•A：Availability，可用性，即在可以接受的时间范围内正确地响应用户请求。
•P：Partition tolerance，分区容错性，即某节点或网络分区故障时，系统仍能够提供满足一致性和可用性的服务。
关系型数据库单节点保证了数据强一致性（C）和可用性（A），但是却无法保证分区容错性（P）。
然而在分布式系统下，为了保证模块的分区容错性（P），只能在数据强一致性（C）和可用性（A）之间做平衡。
具体表现为在一定时间内，可能模块之间数据是不一致的，但是通过自动或手动补偿后能够达到最终的一致。
BASEBASE 理论主要是解决CAP 理论中分布式系统的可用性和一致性不可兼得的问题。
BASE 理论包含以下三个要素：•BA：Basically Available，基本可用。
•S：Soft State，软状态，状态可以有一段时间不同步。
•E：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致。
BASE 模型与ACID 不同，满足CAP 理论，通过牺牲强一致性来保证系统可用性。
由于牺牲了强一致性，系统在处理请求的过程中，数据可以存在短时的不一致。
系统在处理业务时，记录每一步的临时状态。
当出现异常时，根据状态判断是否继续处理请求或者退回原始状态，从而达到数据的最终一致。
例如，在上面的案例中，支付成功，订单也成功，但增加积分失败，此时，不应回滚支付和订单，而应通过一些补偿方法来让积分得以正确地增加。
后面会讲到具体的实现方法。
在分享我们的分布式事务实践方案之前，先看看早期解决分布式事务问题的二阶段提交协议。
二阶段提交协议X/Open DTP（Distributed Transaction Process）是一个分布式事务模型，此模型主要使用二阶段提交（2PC，Two-Phase-Commit）来保证分布式事务的完整性。
在这个模型里面，有三个角色：•AP：Application，应用程序，业务层。
•RM：Resource Manager，资源管理器，关系型数据库或支持XA 接口（XA 规范是X/Open 组织定义的分布式事务规范）的组件。
•TM：Transaction Manager ，事务管理器，负责各个RM 的提交和回滚。
当应用程序（AP）调用了事务管理器（TM）的提交方法时，事务的提交分为两个阶段实行。
第一阶段（准备阶段）TM 通知所有参与事务的各个RM，给每个RM 发送prepare 消息。
RM 接收到消息后进入准备阶段后，要么直接返回失败，要么创建并执行本地事务，写本地事务日志（redo 和undo 日志），但是不提交（此处只保留最后一步耗时最少的提交操作给第二阶段执行）。
第二阶段（提交/ 回滚阶段）TM 收到RM 准备阶段的失败消息或者获取RM 返回消息超时，则直接给RM 发送回滚（rollback）消息，否则发送提交（commit）消息。
RM 根据TM 的指令执行提交或者回滚，执行完成后释放所有事务处理过程中使用的锁（最后阶段释放锁）。
二阶段提交的利弊优点2PC 提供了一套完整的分布式事务的解决方案，遵循事务严格的ACID 特性。
缺点•TM 通过XA 接口与各个RM 之间进行数据交互，从第一阶段的准备阶段，业务所涉及的数据就被锁定，并且锁定跨越整个提交流程。
在高并发和涉及业务模块较多的情况下对数据库的性能影响较大。
•二阶段是反可伸缩模式的，业务规模越大，涉及模块越多，局限性越大，系统可伸缩性越差。
•在技术栈比较杂的分布式应用中，存储组件有很多不支持XA 协议。
二阶段的诸多弊端，导致分布式系统下无法直接使用此方案来解决数据一致性问题，但它提供了解决分布式系统下数据一致性问题的思路。
下面就通过案例来分享我们是如何保证微服务架构的数据一致性的。
可靠消息最终一致性可靠消息最终一致性方案本质上是利用MQ 组件实现的二阶段提交。
此方案涉及3 个模块：•上游应用，执行业务并发送MQ 消息。
•可靠消息服务和MQ 消息组件，协调上下游消息的传递，并确保上下游数据的一致性。
•下游应用，监听MQ 的消息并执行自身业务。
上游应用执行业务并发送MQ 消息（第一阶段）上游应用将本地业务执行和消息发送绑定在同一个本地事务中，保证要么本地操作成功并发送MQ 消息，要么两步操作都失败并回滚。
上游应用和可靠消息之间的业务交互图如下：1.上游应用发送待确认消息到可靠消息系统2.可靠消息系统保存待确认消息并返回3.上游应用执行本地业务4.上游应用通知可靠消息系统确认业务已执行并发送消息。
5.可靠消息系统修改消息状态为发送状态并将消息投递到MQ 中间件。
以上每一步都可能出现失败情况，分析一下这5 步出现异常后上游业务和消息发送是否一致：上游应用执行完成，下游应用尚未执行或执行失败时，此事务即处于BASE 理论的Soft State 状态。
下游应用监听MQ 消息并执行业务（第二阶段）下游应用监听MQ 消息并执行业务，并且将消息的消费结果通知可靠消息服务。
可靠消息的状态需要和下游应用的业务执行保持一致，可靠消息状态不是已完成时，确保下游应用未执行，可靠消息状态是已完成时，确保下游应用已执行。
下游应用和可靠消息服务之间的交互图如下：1.下游应用监听MQ 消息组件并获取消息2.下游应用根据MQ 消息体信息处理本地业务3.下游应用向MQ 组件自动发送ACK 确认消息被消费4.下游应用通知可靠消息系统消息被成功消费，可靠消息将该消息状态更改为已完成。
以上每一步都可能出现失败情况，分析一下这4 步出现异常后下游业务和消息状态是否一致：通过分析以上两个阶段可能失败的情况，为了确保上下游数据的最终一致性，在可靠消息系统中，需要开发消息状态确认和消息重发两个功能以实现BASE 理论的Eventually Consistent 特性。
消息状态确认可靠消息服务定时监听消息的状态，如果存在状态为待确认并且超时的消息，则表示上游应用和可靠消息交互中的步骤4 或者5 出现异常。
可靠消息则携带消息体内的信息向上游应用发起请求查询该业务是否已执行。
上游应用提供一个可查询接口供可靠消息追溯业务执行状态，如果业务执行成功则更改消息状态为已发送，否则删除此消息确保数据一致。
具体流程如下：1.可靠消息查询超时的待确认状态的消息2.向上游应用查询业务执行的情况3.业务未执行，则删除该消息，保证业务和可靠消息服务的一致性。
业务已执行，则修改消息状态为已发送，并发送消息到MQ 组件。
消息重发消息已发送则表示上游应用已经执行，接下来则确保下游应用也能正常执行。
可靠消息服务发现可靠消息服务中存在消息状态为已发送并且超时的消息，则表示可靠消息服务和下游应用中存在异常的步骤，无论哪个步骤出现异常，可靠消息服务都将此消息重新投递到MQ 组件中供下游应用监听。
下游应用监听到此消息后，在保证幂等性的情况下重新执行业务并通知可靠消息服务此消息已经成功消费，最终确保上游应用、下游应用的数据最终一致性。
具体流程如下：1.可靠消息服务定时查询状态为已发送并超时的消息2.可靠消息将消息重新投递到MQ 组件中3.下游应用监听消息，在满足幂等性的条件下，重新执行业务。
4.下游应用通知可靠消息服务该消息已经成功消费。
通过消息状态确认和消息重发两个功能，可以确保上游应用、可靠消息服务和下游应用数据的最终一致性。
当然在实际接入过程中，需要引入人工干预功能。
比如引入重发次数限制，超过重发次数限制的将消息修改为死亡消息，等待人工干预。
代入开篇案例，通过可靠消息最终一致性方案，第一阶段，订单状态更改之前，订单服务向可靠消息服务请求保存待确认消息。
可靠消息服务保存消息并返回。
订单服务接收到返回信息后执行本地业务并通知可靠消息服务业务已执行。
消息服务更改消息状态并将消息投递到MQ 中间件。
第二阶段，积分系统监听到MQ 消息，查看积分是否已增加，如果没有增加则修改积分，然后请求可靠消息服务。
可靠消息服务接收到积分系统的请求，将消息状态更改为已完成。
到这里，已经介绍完如何通过可靠消息服务来保证数据的一致性。
但由于引入了可靠消息服务和消息队列，带来了一定的复杂性，所以，它更适用于跨平台技术栈不统一的场景。
下面再来介绍在技术栈统一的情况下，如何通过TCC 来解决数据一致的方法。
TCC（Try-Confirm-Cancel）TCC 方案是二阶段提交的另一种实现方式，它涉及3 个模块，主业务、从业务和活动管理器（协作者）。
下面这张图是互联网上关于TCC 比较经典的图示：第一阶段：主业务服务分别调用所有从业务服务的try 操作，并在活动管理器中记录所有从业务服务。