分布式之BASE理论分析

写在前面

在这篇文章 我们分析了分布式系统中的CAP理论，但是CAP理论其实并不是完全适用于现代的互联网系统的，当我们将系统设计为CP时，此时假设我们的系统有3个节点，如果每个节点的可用性是99.9%，则整个集群的可用性就是99.7%，则每个月集群不可用的时间是(30*24*60)*0.003=129.6分钟，一个月就有超过两个小时的时间集群不可用，简直就是灾难级了，这还只是3个节点，节点越多会越严重，这么看来CP显然是有很大问题的。接着再来看AP，AP的问题是过分要求可用，现在我们考虑流量突增的场景，为了满足A，我们可能需要额外的机器来stand by，但是这些stand by的机器虽然在平时用不到，但也是需要额外的成本的，即要多花钱，这有时候可能都是得不偿失的，为了解决这个问题，当大规模分布式系统在实践中不断的被应用后，一个对于AP升级后的全新理论就被被提出来了，这既是BASE，也是我们本文的绝对主角，下面我们就一起看下吧！

1：BASE

1.1：理论分析

BASE理论的核心思想是基本可用和最终一致性，这里的基本可用就是basically available，也就是BASE中的BA,最终一致性就是eventually consistency，也就是BASE中的E,注意这里的最终一致性中的最终，说明这个一致是有一个过程的，而这个过程叫做是Soft State，也就是BASE中的S，因此BASE的组成如下：

BA:basically available
S:soft state
E:eventually consistency

我们可以看到以上的带有妥协性的词汇，基本，最终这其实都是一种对于设计的妥协，对于AC结合现代互联网实际情况的一种升级。

1.2：理论实现

1.2.1：基本可用

包括但不限于如下4中方式

流量削峰（业务无损）:在可预料的场景中，通过程序控制来分散流量到不同的时间点，如12306春运购票，在不同的时间点发放不同热点城市的车票，如8点发放北京的，9点发放上海的
延迟响应（业务无损吧我认为，毕竟只是慢了点）：基于任务队列延迟处理，保证核心业务正常
体验降级（业务无损）：如因为流量激增，导致商品图片无法显示，此时就可以考虑返回较低清晰度图片，降低服务器压力，这就是体验降级，视频等也是同样的道理，用户依然在使用，但体验不那么好了。
过载保护（业务有损）：超过一定量后，直接拒绝请求。

不同的方式要根据自己具体的业务场景来做出最优选择，不可一概而论。

1.2.2：最终一致性

最终一致性描述的是，所有的数据副本并非立即达到数据的一致性状态，而是经过一段时间之后，才达到一致性的状态，一般有如下几种方式实现最终一致性：

1:读时检测，在读数据时检测是否为最新数据，不是则修改为最新数据
2：写时检测，在写数据时检测是否为最新数据，不是则修改为最新数据
3：异步检测，通过异步的方式来定时检测数据是否为最新数据，不是则修改为最新数据

写在后面

小结

本文先分析了CAP理论对于现代互联网系统的不足，并分析了其问题，从而引出了BASE理论，然后分析了BASE理论的基本可用，最终一致性，最后给出了实现基本可用和最终一致性的常用方案。希望本文能够帮助到你。

参考文章列表

分布式事务（一）、CAP，BASE理论 。