分布式架构入门：一文轻松搞懂晦涩的CAP理论！( 四 ) _可用性

现在，假设在这个事务中，提取操作已经完成，但是在更新余额时，系统突然崩溃了。在这种情况下，系统应该能够恢复并且完成余额更新，或者它应该完全忽略这个事务，就好像它从未发生过一样。在任何情况下，客户的账户余额都不应该被错误地减少，因为那将违反业务规则。
所以，ACID的一致性是关于在事务开始和结束时满足特定业务规则和约束的，无论事务过程中是否发生了错误或者系统崩溃，数据库都应始终保持一致性状态。
六、CAP的应用案例
1、

文章插图
（ZK）是一个分布式的、开放源码的分布式应用程序协调服务，由雅虎公司开发，并是项目的一部分。是一种典型的CP（/一致性,/分区容错性）系统。
的设计就是这样的。当网络发生分裂，只有数量大于半数的节点（称为“过半机制”）可以继续提供服务，能够保证数据的一致性。数量少于半数的节点会拒绝服务，以此来保证整个系统的一致性。这意味着在部分节点不可用或者网络分区的情况下，可能无法保证所有客户端的可用性。
主要被用于管理和协调分布式系统中的状态信息，如配置信息，状态同步，命名服务和分布式锁等。数据的一致性在这些用途中是非常关键的，因此选择了牺牲一部分可用性以保证一致性。
2、Kafka
CAP定理告诉我们，在网络分区的情况下，不可能同时保证一致性（）和可用（）。但这并不意味着我们不能在一致性和可用性之间找到适合自己的平衡点。
在Kafka中，例如，我们可以通过设置不同的"acks"（）和"min.."参数来权衡一致性和可用性。如果我们设置"acks"为"all"或者"-1"，并且将"min.."设置为一个大于1的数，那么我们就可以提高数据的一致性，但可能会降低系统的可用性，因为每次写操作都需要等待所有的副本都确认。
反之，如果我们设置"acks"为"1"，那么写操作只需要等待一个副本的确认，这就提高了系统的可用性，但可能降低数据的一致性，因为其他的副本可能还没有完成数据的更新。
3、HBase
HBase的设计目标是提供高速的读写访问大量数据，并保证强一致性。在HBase中，数据是自动分片的，每个分片（称为）由一个来服务，每个行键只由一个来服务，所以对单个行的读写都是强一致的。
当网络分区发生时，HBase通常会选择牺牲部分可用性以保持一致性和分区容错性。比如说，如果一个出现问题，HBase的主节点（）会将它上面的重新分配给其他健康的，这个过程中涉及的会在短时间内不可用，因此，HBASE属于CP系统。
4、Redis
Redis是一个开源的键值存储系统，它通常用于作为数据库、缓存和消息代理。Redis单实例是一个基于内存的数据结构存储，并提供持久化机制。对于单实例的Redis，CAP理论并不适用，因为它并不是一个分布式系统。
在Redis的主从复制模式中，如果主节点故障，系统需要手动干预才能恢复写服务（即升级一个从节点为新的主节点）。这意味着它不能自动处理网络分区，因此在严格意义上，它也不能被归类为CAP理论中的任何一类。
对于Redis ，它是一个分布式的Redis解决方案，能够在一定程度上处理网络分区的问题。在出现网络分区时，Redis 会停止对分区节点的操作以保持数据的一致性，所以它更倾向于CP系统。
5、
是一个开源的分布式NoSQL数据库，它是为了满足高可用性和扩展性的需求而设计的。
使用了一种名为最终一致性（）的模型。在这个模型中，系统不保证在任何时刻所有的副本都是一致的，但保证在没有新的更新操作的情况下，所有的副本最终会达到一致的状态。