分布式系统非常关注三个指标:
- 数据一致性
- 系统可用性
- 节点连通性与扩展性
关于一致性
数据“强一致性”,是希望系统只读到最新写入的数据,例如:通过单点串行化的方式,就能够达到这个效果。
关于session一致性,DB主从一致性,DB双主一致性,DB与Cache一致性,数据冗余一致性,消息时序一致性,分布式事务一致性,库存扣减一致性
关于可用性
如果系统每运行100个时间单位,会有1个时间单位无法提供服务,则说系统的可用性是99%。
可用性和可靠性是比较容易搞混的两个指标,以一台取款机为例:
- 正确的输入,能够取到正确的钱,表示系统可靠
- 取款机7*24小时提供服务,表示系统可用
保证系统高可用的方法是
- 冗余
- 故障自动转移
反向代理层,站点层,服务层,缓存层,数据库层各层保证系统高可用的方法,详见文章《究竟啥才是互联网架构“高可用”》。
关于连通性与扩展性
分布式系统,往往有多个节点,每个节点之间,都不是完全独立的,需要相互通信,当发生节点无法联通时,数据是否还能保持一致,系统要如何进行容错处理,是需要考虑的。
同时,连通性和扩展性紧密相关,想要加机器扩展性能,必须有良好的连通性。当一个节点脱离系统,系统就出现问题,往往意味着系统是无法扩展的。
反向代理层,站点层,服务层,缓存层,数据库层各层保证系统扩展性的方法,详见文章《究竟啥才是互联网架构“可扩展”》。
什么是CAP定理?
CAP定理,是对上述分布式系统的三个特性,进行了归纳:
- 一致性(Consistency)
- 可用性(Availability)
- 分区容忍性(Partition Tolerance)
并且,定理指出,在系统实现时,这三者最多兼顾两点。
一致性,可用性,多节点扩展性三者只能取其二,既然加锁已经加上,常见的最佳工程架构实践是什么呢?
互联网,最常见的实践是这样的:
- 节点连通性,多节点扩展性,连通性异常的处理必须保证,满足P
- 一致性C与可用性A一般二选一
- 选择一致性C,举例:传统单库水平切分,就是这类选型的典型
- 选择可用性A,举例:双主库同步高可用,就是这类选型的典型
强一致很难怎么办?
单点串行化,虽然能保证“强一致”,但对系统的并发性能,以及高可用有较大影响,互联网的玩法,更多的是“最终一致性”,短期内未必读到最新的数据,但在一个可接受的时间窗口之后,能够读到最新的数据。
例如:数据库主从同步,从库上的数据,就是一个最终的一致。
总结
- CAP可以理解为一致性,可用性,联通与扩展性
- CAP三者只能取其二
- 最常见的实践是AP+最终一致性
微服务治理
对于微服务的治理而言,核心就是服务的注册和发现。所以选择哪个组件,很大程度上要看它对于服务注册与发现的解决方案。在这个领域,开源架构很多,最常见的是Zookeeper,但这并不是一个最佳选择。
在分布式系统领域有个著名的CAP定理:C——数据一致性,A——服务可用性,P——服务对网络分区故障的容错性。这三个特性在任何分布式系统中不能同时满足,最多同时满足两个。
Zookeeper是著名Hadoop的一个子项目,很多场景下Zookeeper也作为Service发现服务解决方案。Zookeeper保证的是CP,即任何时刻对Zookeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性,但是它不能保证每次服务请求的可用性。从实际情况来分析,在使用Zookeeper获取服务列表时,如果zookeeper正在选主,或者Zookeeper集群中半数以上机器不可用,那么将就无法获得数据了。所以说,Zookeeper不能保证服务可用性。
诚然,对于大多数分布式环境,尤其是涉及到数据存储的场景,数据一致性应该是首先被保证的,这也是zookeeper设计成CP的原因。但是对于服务发现场景来说,情况就不太一样了:针对同一个服务,即使注册中心的不同节点保存的服务提供者信息不尽相同,也并不会造成灾难性的后果。因为对于服务消费者来说,能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下,也好过因为无法获取实例信息而不去消费。所以,对于服务发现而言,可用性比数据一致性更加重要——AP胜过CP。而Spring Cloud Netflix在设计Eureka时遵守的就是AP原则。