如何进行分布式系统架构以及CAP原理的分析

如何进行分布式系统架构以及CAP原理的分析，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

一、什么是分布式系统？

关于分布式系统的定义，《分布式系统原理和范型》一书中是这样定义分布式系统的：“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像是单个系统”。

(图片选自《分布式系统常用技术及案例分析》)

设计一个分布式系统，需要考虑很多方面。比如系统如何拆分子系统？如何规划子系统中的通信？通信是否安全？系统是否具有扩展性？子系统如何让实现可靠性？数据的一致性如何保证？等等，都不是很好解决。

但是对于我们一般的用户来说，开源世界已经有完善的解决方案和工具了，比如，我们在设计通信时，我们可以采用面向消息的中间件，比如Apache ActiveMQ、RabbitMQ、Apache RocketMQ、Apache Kafka等，也有类似与 Google Protocol Buffer、Thrift等 RPC框架。在设计分布式计算时，我们分布式计算可以采用 MapReduce、Apache Hadoop、Apache Spark 、Apache Flink 等。在大数据分布式存储方面，我们可以选择 HDFS、Apache HBase、Apache Cassandra、Memcached、Redis、MongoDB等。在分布式监控方面，常用的技术包括Nagios、Zabbix、Consul、ZooKeeper等。

二、对 CAP 的一点理解

2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP理论正式成为分布式计算领域的公认定理。

首先我们先来看看 CAP 分别代表什么？

一致性：更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致。（注意：这里说的是强一致性。）

可用性:  读和写操作都能成功。无论何时，都可以在有效时间内返回用户的请求。

分区容错性：再出现网络故障导致分布式节点间不能通信时，系统能否继续服务

需要注意的是：在分布式系统中，没有一种设计可以同时满足一致性、可用性、分区容错性  3 个特性。CAP 三者不是对等的，其中 P 是基础，CA 之前需要权衡。

如果说Spanner真有什么特别之处，那就是谷歌的广域网。Google通过建立私有网络以及强大的网络工程能力来保证P，在多年运营改进的基础上，在生产环境中可以最大程度的减少分区发生，从而实现高可用性。

CAP之父在《Spanner，真时，CAP理论》一文中写到  

在全球广域地理分布环境下（全球规模的分布式系统），网络分区是一个自然的事实，甚至有人认为是必然的。（用来解释为什么 P 是基础。）

上面提到的一致性可以分为几类：强一致性、单调一致性、弱一致性、会话一致性、最终一致性。

三、总结

文章开头部分也提到了，现在的开源世界已有完善的分布式系统解决方案了，我们没有必要重复造轮子，难度也可想而知。我们可以在使用的过程中倒推这个系统满足了 CAP 的哪两个特性。比如：Zookpper 是 CP，P 是基础的，所有分布系统需要优先考虑这个，Zookeeper 从顺序一致性、原子性、单一镜像、持久性、实时性保证了数据的一致性。但是它在某些情况（重启或网络节点故障）下会重新选举 Leader，此时整个集群是不可用的。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性。所以 Zookepper 保证了 CP，而不是 AP。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注亿速云行业资讯频道，感谢您对亿速云的支持。