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

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

政和网站制作公司哪家好,找成都创新互联公司!从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设公司等网站项目制作,到程序开发,运营维护。成都创新互联公司成立与2013年到现在10年的时间,我们拥有了丰富的建站经验和运维经验,来保证我们的工作的顺利进行。专注于网站建设就选成都创新互联公司

一、什么是分布式系统?

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

如何进行分布式系统架构以及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 分别代表什么?

如何进行分布式系统架构以及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。

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


新闻标题:如何进行分布式系统架构以及CAP原理的分析
标题路径:http://hbruida.cn/article/jjsssh.html