分布式架构应用的可用性和一致性问题

最新推荐文章于 2025-06-05 09:04:42 发布

原创最新推荐文章于 2025-06-05 09:04:42 发布 · 1.1k 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

收录于

IT技术

本文探讨了分布式系统中的CAP原则，指出在高可用性和一致性之间必须做出权衡。在互联网应用的新特点要求下，BASE原则成为解决这一问题的指导思想，它强调基本可用、弱状态和最终一致性。微服务架构与分布式系统紧密相关，必须考虑这些一致性与可用性的问题。通过微服务的设计和实施，可以实现高性能、高可用的分布式互联网应用。

前言

对于互联网架构该怎么做，存在着一定的误区，所以写此文章，抛砖引玉。

1. 传统应用的可用性和一致性问题

传统的单体应用架构，其高可用和一致性问题是两个独立的问题，两者并没有关联关系比如，传统的SQL数据库的事务通常都是支持ACID的强事务机制，所以单数据库的模式使得事务强一致性得到满足。

A代表原子性，即在事务中执行多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行;

C代表一致性，即保证进行事务的过程中整个数据库的状态是一致的，不会出现数据花掉的情况;

I代表隔离性，即两个事务不会相互影响，覆盖彼此数据等;

D表示持久化，即事务一旦完成，那么数据应该是被写到安全的，持久化存储的设备上（比如磁盘）。在可用性方面，传统单体应用并不一定要求7x24小时高可用，所以其高可用的架构设计依赖于业务需求。如果业务需要7x24小时不间断服务，那么完全可以通过存储冗余（如mirror,raid等），instance冗余（如oracle RAC，J2EE应用多节点部署，多个Http Server,F5 load balance）等方法提高系统可用性。

2. 分布式系统的cap原则

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

分区容错性（P）：

通俗地讲，什么是分布式，分布式就是把一个东西拆分开来放在不同地方（跑）。如图是最简单的分布式系统。

对于分布式系统而言，由于网络硬件肯定会出现延迟、丢包、网络不通等问题，必然会存在网络分区。所以在面对网络故障情况下，在一定的时限内，在不同地方依旧能得到（可用性）东西，且东西是一致的（一致性），这就是分区容错性。分区容错性往往是分布式系统必须达到的。

而在传统集中的单体系统是不会发生这种事情的。

3. 互联网应用的新特点和要求

高可用特性，高性能，可伸缩

目标：
互联网架构目标

如图为互联网应用架构的分布式服务的较高境界
互联网架构

由此可知，新的互联网应用采用的是分布式架构，那么天然的它的架构就是分区架构，P必须满足，同时，网站的可用率往往是要求7*24小时服务的。那么，根据CAP原则，可以推导出这样一个结论，为了高可用性，就得牺牲强一致性。为了一致性，就得牺牲高可用性。这个结论实际上很容易想通，设想一个事务操作，需要修改两个不同地方的数据库的内容，很不幸的是有一个数据库可能因为网络问题不能马上提交修改。那么，如果要保证强一致性，那么，事务操作就得等待网络故障恢复，高可用性就得不到满足。如果要高可用，那么，有一个数据库就没有被立即提交修改，一致性就得不到保证。

如何在C和A中进行选择，这个问题可以用base原则来解决。

4. 分布式应用解决可用性和一致性的BASE原则

BASE是下面三个术语的缩写：

基本可用（Basically Available） 基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子。

   响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

   功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态（Soft state） 弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。**最终一致（Eventually consistent）**最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

5. 与微服务的关系

再来看看微服务，微服务应用的特点或者目的：

1. 开发时： 持续快速交付高质量的服务（共享服务、快速开发、技术多样等）

2. 运行时： 高可用高性能可伸缩的分布式的互联网应用架构。

如果只用单库、不同时使用多库技术，如果不用分布式应用架构，不考虑服务共享服务熔断和服务治理，如果不考虑持续交付。那么，用微服务架构还不如用分包技术，拆分几个包，单独运行，达到提高性能的目的，同时又不会大幅增加系统的复杂度。

所以，一切不以分布式为架构的微服务，都是耍流氓！要用微服务，就得采用分布式架构，就得面对C和A的抉择问题，而微服务框架springcloud以及微服务领域设计思想和分库设计，正好贯彻了BASE原则，而Devops管理工具和方法、灰度发布、容器技术等则构成了帮助微服务实现分布式架构高可用性和最终一致性的生态环境。

参考：

一致性，可用性,分区容错性

互联网架构的演变

标签

#微服务