《五分钟学技术》系列每日更新，关注我带你每天都进步一点！

引子

如果你想学习分布式架构，但是并不了解CAP理论，那是绝对不行的。下面我就来跟大家一起学习一下分布式的基础理论CAP。

CAP概述

CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

下面我们就来解释一下提到的这三个关键词，“一致性”、“可用性”、“分区容错性”

一致性

一致性是指所有节点在同一时间的数据应完全一致，也就是数据一样。

三种一致性策略

强一致性：要求更新过的数据都能被后续的访问所看到

弱一致性：能容忍更新的部分或者全部访问不到

最终一致性：经过一段时间后要求能访问到更新的数据

而CAP中说的这个一致性则强一致性。

可用性

可用性是指服务一直可用，而且是正常响应时间。

对于一个具有可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以，一般我们在衡量一个系统的可用性的时候，都是通过停机时间来计算的，不允许出现用户操作失败或者访问超时等情况。一个分布式系统中任何一部分如负载均衡、应用服务器、应用代码、数据库服务器等，任何一个节点的不稳定都可以影响可用性。

分区容错性

分区容错性是指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

简单说就是在网络中断，信息丢失的情况下，系统如果还能正常工作，就是有比较好的分区容错性。

CAP权衡

通过CAP理论我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要如何取舍呢？

我们分三种情况来阐述一下。

舍弃分区容错性

这种情况在分布式系统中几乎是不存在的。在分布式环境下，网络分区是一个自然的事实。所以分区是必然的，如果舍弃分区容错性，就意味着不是分布式系统。

对于一个分布式系统来说。P是一个基本要求，CAP三者中，只能在CA两者之间做权衡，并且要想尽办法提升P。

舍弃可用性

如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。

一个保证了CP而一个舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有节点数据全部一致之后再让用户访问系统。

设计成CP的系统其实也不少，其中最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况时，优先保证数据的强一致性，代价就是舍弃系统的可用性。如Redis、HBase等，还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。

舍弃一致性

要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

这种舍弃强一致性而保证系统的分区容错性和可用性的场景和案例非常多。对于很多业务系统来说，比如淘宝的购物，12306的买票。都是在可用性和一致性之间舍弃了一致性而选择可用性。

你在12306买票的时候肯定遇到过这种场景，当你购买的时候提示你是有票的（但是可能实际已经没票了），你也正常的去输入验证码，下单了。但是过了一会系统提示你下单失败，余票不足。这其实就是先在可用性方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，但是这种舍弃其实舍弃的只是强一致性。退而求其次保证了最终一致性。也就是说，虽然下单的瞬间，关于车票的库存可能存在数据不一致的情况，但是过一段时间，还是要保证最终一致性。

总结

到底是要舍弃一致性还是可用性，要根据面对的场景而定，要判断当前场景下，数据准确重要还是提供服务重要，所以还需要你灵活运用之。