分布式服务基础理论知识—一些设计原则

我之前对分布式的理解（只是缘在此山中的浅显认识）：

分布式=远程调用+多机服务，通过增加机器形成集群可支撑更多的并发访问量。实现多机服务就需要进行ha和loadbalance策略，等等。表现在web环境就是apache或者Nginx配置tomcat集群，或者基于某个开源rpc框架配置了一番，能够多机共同对外提供服务就是分布式系统了。

殊不知，这只是先入为主的主观感受，就是把问题想当然了，因为我们都在随波逐流的用所谓的“分布式”，所以觉得分布式就应该这样。

而现在随着知识的沉淀，对计算机底层知识的深入理解，才知道，通过增加机器形成集群虽然能支撑更多的并发访问量（以前并未考虑是为什么，现在知道是受单机硬件和操作系统的限制，解决了C10K问题），但是也会带来其它问题，用CAP（这个理论也有一些人质疑是伪命题）的理论来讲就是，当多机中有机器发生故障时，也就是P（分区容忍性(Partition tolerance)）必然存在的情况下，如何进行失效转移，从而保证C（强一致性(Consistency)）、A（可用性(Availability)）呢？

按照CAP理论，在分区网络环境和操作系统一定会存在问题的情况下，上面问题的答案是无解的。就是说P一定存在的情况下就是只能保证CA的其中一个。（否则的话问题退化为保证ACID(其中的C不同于CAP中的C），目前主要有两种方式实现ACID：第一种是Write ahead logging，也就是日志式的方式(现代数据库均基于这种方式)。第二种是Shadow paging。）

而我们为什么还要继续使用这种架构呢？

其实对于大多数WEB应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是多数分布式架构产品的方向。当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求像关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

这就引发了目前的一个设计思想：

BASE思想

说起来很有趣，BASE的英文意义是碱，而ACID是酸。真的是水火不容啊。

Basically Availble --基本可用

Soft-state --软状态/柔性事务

"Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的

Eventual Consistency --最终一致性

最终一致性， 也是 ACID 的最终目的。

BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性： Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库) Soft state软状态 状态可以有一段时间不同步，异步。 Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时一致。

BASE思想的主要实现有

1.按功能划分数据库

2.sharding碎片

BASE思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。

参考：分布式基础（1）:CAP原理、BASE思想和最终一致性

CAP理论十二年回顾："规则"变了

不懂点CAP理论，你好意思说你是做分布式的吗？

分布式系统架构的基本原则和实践