BASE 理论

BASE 简介

BASE 其实就是对 C A P 的延伸。

我们在保证 A P 的情况下，我们永远无法做到强一致，就是我们这个业务状态做不了强一致，

但是我们可以让它弱一致，也就是我们说的最终一致，强一致弱一致是对立概念

强一致，就是我们以前用的这种本地系统。我们就一个数据库，一台机器，我们一个代码在这操作好多数据。那操作完了要么都成功，要么都失败。这是一个强一致状态。

但我们在分布式以后呢，我们想要保证强一致可能很难。

但是我们可以保证最终一致，这就是我们说的 BASE，BASE 解释起来就是这个样子。

基本可用（Basically Available）

也就是说我们这个业务系统基本能用就行了，我们可以让它损失部分的可用性。比如说有两三个机器宕机了，我们可以损失一些部分的功能，或者我们也可以让他损失一些响应时间。

本来呢他不宕机，我查他挺快的，他宕机了，我查他不行了，我多查几个其他机器，查询速度慢一点也行，

所以我们最终都是希望一两个节点的不可用，不会导致我们整个系统不可用。

所以我们肯定想要让我们整个系统都是可用的，我们可以让它响应时间上有损失，多试几次，也可以让它功能上有损失。

比如我们这个网站在高峰期的时候，我们为了保护我们系统的稳定性，我们可能将部分的消费者流量直接引导到一个错误页面，就是我们说的这个降级页面。当前服务排队人太多了，请稍后重试等等。所以这就是我们说的基本可用。我们要保证业务的基本能用。

然后再加上我们的软状态。

软状态（ Soft State）

软状态就指的是我们系统存在中间状态，不像我们的强一致，要么成要么败，我们也可以有一个中间状态。类似正在同步中这样。

比如我们保存了一个数据，它要么有，要么没有，但是还有一个正在同步中。我们可以有一个中间状态。

然后我们希望最终一致

最终一致（ Eventual Consistency）

最终一致指的就是我们这个系统里边的这些数据。经过一段时间后，最终达到业务状态是一致的。

比如我们这个下单方法。

我们这个库存扣了，订单回滚了，库存没办法回滚，我们总是有一个东西呢没办法回滚，那没办法回滚怎么办呢？

我们首先不要求强一致了，但是我可以让系统过一段时间对它做一个检查，检查以后发现，刚才扣的这个库存都没人用，那再重新给它加回来，

这样最终导致的就是你如果没有这个订单，我最终就不给你扣这个库存，但是我们不是说立马就不扣的，我们可以让它到达一个最终一致。

我们可以用各种手段来保证最终一致性。

总结

所谓的强一致，就是我们要求这个数据更新以后，立马就能被看到。那我们现在的本地事务，我们现在就是这种强一致状态。

弱一致，就是我现在更新完了，可能有一段时间我还看不到，我能容忍部分的时间、或者部分的节点，我这更新成功了，只有这个数据库。
更成功了。那其他库呢可能还没有成功，还正在同步中。我们就可以忍受这些正在同步中的过程。如果能忍受，我们就说我们这个事务
可以做成一个弱一致性的事务。不是非要那么强的。

最终一致，就是指我们这个弱一致，经过一段时间以后，我们肯定得把它原来的数据同步过来。

或者我们这个下单方法，原来扣了的库存，最终都得加上去。这就是我们说的最终一致性。