数据一致性
- 数据库事务：使用数据库的事务机制，确保一组数据的相关操作要么全部成功，要么全部失败，从而保证数据的一致性。
- 例如，在转账操作中，涉及到转出账户扣款和转入账户加款两个操作，这两个操作必须在一个事务中执行，以防止出现转出成功但转入失败的情况。
- 锁机制
- 悲观锁：在操作数据之前，先对数据进行加锁，防止其他事务同时修改该数据。
- 例如，在更新一条订单记录时，先对该订单记录加锁，直到更新完成后才释放锁，这样可以确保在更新过程中不会有其他事务对该订单进行修改。
- 乐观锁：乐观锁是数据在并发操作时很少会发生冲突，它通过在数据中添加一个版本号或时间戳来实现。在更新数据时，先检查版本号或时间戳是否与之前读取时一致，如果一致则进行更新，并更新版本号或时间戳；如果不一致，则说明数据已被其他事务修改，需要进行相应的处理，如重试或回滚。
- 分布式事务：如果系统涉及多个分布式节点或微服务，需要使用分布式事务来保证数据在多个节点之间的一致性。例如，使用 TCC（Try - Confirm - Cancel）模式或基于消息队列的最终一致性方案。以基于消息队列的方案为例，当一个事务涉及多个服务时，先将事务操作记录到消息队列中，各个服务从消息队列中获取消息并执行相应的操作，通过消息的可靠传递和处理来保证数据的最终一致性。
- 数据校验和补偿机制：在数据处理的各个环节进行严格的数据校验，确保数据的合法性和完整性。同时，建立补偿机制，当出现数据不一致的情况时，能够通过补偿操作来修复数据。例如，在电商系统中，当订单状态更新失败时，可以通过定时任务或人工触发的方式进行订单状态的检查和修复。
系统稳定性
- 服务器集群和负载均衡：通过构建服务器集群，将请求分发到多个服务器上进行处理，实现负载均衡。这样可以避免单个服务器因负载过高而出现性能瓶颈甚至崩溃的情况。
- 例如，使用 Nginx 作为负载均衡器，根据不同的负载均衡算法将请求分配到后端的多个 Web 服务器上。
- 缓存机制：合理使用缓存可以减轻数据库的压力，提高系统的响应速度和稳定性。
- 例如，将经常访问的数据缓存到内存中，如使用 Redis 作为缓存服务器。当有请求到来时，先从缓存中获取数据，如果缓存中不存在，则再从数据库中查询并将结果缓存起来，下次请求时就可以直接从缓存中获取，减少数据库的访问次数。
- 限流与熔断
- 限流：通过限制单位时间内的请求数量，防止系统因请求过多而过载。
- 例如，可以使用令牌桶算法或漏桶算法来实现限流。以令牌桶算法为例，系统会以一定的速率向令牌桶中放入令牌，每个请求在处理前需要从令牌桶中获取一个令牌，如果令牌桶中没有令牌，则拒绝该请求，从而限制了请求的并发量。
- 熔断：当系统的某个部分出现故障或响应时间过长时，自动切断对该部分的请求，避免故障扩散导致整个系统崩溃。
- 例如，在微服务架构中，当某个微服务出现故障时，熔断器会自动熔断，后续的请求将不再转发到该微服务，而是直接返回错误信息或调用备用的服务，直到该微服务恢复正常。
- 监控与日志
- 监控：建立完善的监控系统，实时监测系统的各项性能指标，如 CPU 使用率、内存使用率、数据库连接数、请求响应时间等。通过监控数据及时发现系统的异常情况，并进行预警。例如，使用 Prometheus 和 Grafana 搭建监控系统，对服务器和应用程序的各项指标进行实时监控和可视化展示。
- 日志：记录系统的操作日志和错误日志，以便在出现问题时能够快速定位和排查故障。日志中应包含详细的信息，如请求时间、请求路径、操作内容、错误信息等。例如，使用 Log4j 或 Logback 等日志框架来记录日志，并将日志存储到专门的日志服务器中，方便进行查询和分析。
- 代码优化和测试：对系统的代码进行优化，提高代码的质量和性能。
- 例如，优化数据库查询语句，避免复杂的嵌套查询和全表扫描；合理使用多线程和异步处理，提高系统的并发处理能力。同时，进行充分的测试，包括单元测试、集成测试、性能测试和压力测试等，确保系统在高并发场景下的稳定性和可靠性。通过性能测试和压力测试，可以发现系统在高并发情况下的性能瓶颈，并针对性地进行优化。
TCC
TCC 模式的核心思想是将一个分布式事务拆分成三个阶段，即尝试阶段（Try）、确认阶段（Confirm）和取消阶段（Cancel），每个阶段都由业务代码来实现，以此保证事务的最终一致性。
三个阶段的具体解释
- 尝试阶段（Try）
- 操作内容：在这个阶段，系统会尝试执行所有业务逻辑的预处理操作。该操作会对业务资源进行预留，但不会真正地提交业务事务。例如，在一个电商系统的分布式事务里，涉及到库存服务和账户服务。当用户下单时，库存服务会在 Try 阶段尝试冻结相应数量的商品库存，账户服务会尝试冻结用户账户中的相应金额。
- 作用：此阶段的主要作用是检查业务操作的可行性，并且对资源进行初步锁定，为后续的确认或取消操作做好准备。
- 确认阶段（Confirm）
- 操作内容：若所有参与事务的服务的 Try 阶段都成功完成，那么就会进入 Confirm 阶段。在这个阶段，系统会对 Try 阶段预留的资源进行真正的业务操作提交。比如，在上述电商系统的例子中，库存服务会正式扣除冻结的商品库存，账户服务会正式扣除用户账户中的冻结金额。
- 特点：Confirm 操作必须是幂等的。这是因为在分布式环境中，可能会出现网络异常等情况，导致 Confirm 操作重复执行。幂等性保证了多次执行相同的 Confirm 操作，其结果与执行一次的结果是相同的。
- 取消阶段（Cancel）
- 操作内容：若在 Try 阶段有任何一个服务执行失败，系统就会进入 Cancel 阶段。在这个阶段，系统会对 Try 阶段预留的资源进行释放。例如，在电商系统中，如果库存服务在 Try 阶段成功冻结了库存，但账户服务在 Try 阶段失败，那么库存服务就需要在 Cancel 阶段释放之前冻结的商品库存。
- 特点：Cancel 操作同样必须是幂等的。原因和 Confirm 操作一样，在分布式环境中，可能会因为网络问题等导致 Cancel 操作重复执行，幂等性确保多次执行 Cancel 操作不会对系统造成额外的影响。
执行流程
- 开启事务：业务系统发起一个分布式事务请求。
- Try 阶段：依次调用各个参与服务的 Try 方法，若所有 Try 方法都成功执行，则进入 Confirm 阶段；若有任何一个 Try 方法执行失败，则进入 Cancel 阶段。
- Confirm 阶段：依次调用各个参与服务的 Confirm 方法，完成业务操作的提交。
- Cancel 阶段：依次调用各个参与服务的 Cancel 方法，释放之前预留的资源。
优缺点
- 优点
- 业务侵入性相对较低：与一些其他的分布式事务解决方案相比，TCC 模式不需要依赖数据库的事务机制，而是由业务代码来实现事务的控制，因此对业务的侵入性相对较小。
- 性能较高：由于 Try 阶段只是对资源进行预留，而不是真正的提交，所以可以在一定程度上提高系统的并发性能。
- 缺点
- 开发成本高：需要开发人员手动实现 Try、Confirm 和 Cancel 三个阶段的业务逻辑，并且要保证 Confirm 和 Cancel 操作的幂等性，这增加了开发的复杂度和成本。
- 一致性问题：虽然 TCC 模式可以保证事务的最终一致性，但在某些极端情况下，如 Confirm 或 Cancel 操作多次失败，可能会导致数据不一致的问题，需要额外的补偿机制来处理。