分布式环境的特点
分布性
并发性
程序运行过程中,并发性操作是很常见的。比如同一个分布式系统中的多个节点,同时访问一个共享资源。数据库、分布式存储
无序性
进程之间的消息通信,会出现顺序不一致问题
分布式环境下面临的问题
网络通信
网络本身的不可靠性,因此会设计到一些网络通信问题
网络分区(脑裂)
当网络发生异常导致分布式系统中部分节点之间的网络延时不断增加,最终导致组成分布式架构的所有节点中是有部分节点能够正常通信。
一个master,多个slave组成的正常集群,假设其中两台服务器网络通信不正常,可能会重新选举出一个master,导致两个独立的集群,这两个集群本身是完整的。会产生数据重复等问题。
###分布式三态
- 成功
- 失败
- 超时
- 出现网络问题,消息没有发送到客户端,或客户端没有收到
单机环境
- 成功
- 失败
###分布式事务
- 原子性
- 一致性
- 隔离性
- 持久性
###中心化和去中心化
中心化
- 角色
- 领导
- 下属
- 角色
- 解决
- 热备
- 人才储备,领导不行了,直接激活人才
- 冷备
- 两个领导都存活,一个干活,一个就绪
- 热备
- 去中心化
- 所有人都是水平的,没有谁领导谁
- 全国网络节点
- 解决脑裂问题
分布式架构里面,很多的架构思想采用的是:当集群发生故障的时候,集群中的人群会自动选举出一个新的领导。最典型的是:zookeeper/etcd
###经典的CAP/BASE理论
- CAP
- C
- Consistency一致性
- 所有节点上的数据,时刻保持一致
- 同步会有延迟(网络)
- A
- Availability可用性
- 每个请求都能收到一个响应,无论响应成功或者失败
- P
- Partition-tolerance分区容错
- 表示系统出现脑裂以后,可能导致某些server与集群中的其它机器失去联系
- C
一般只能满足两个条件,常见是:CP/AP。
CAP理论仅适用于原子读写的NoSQL场景,不适用于数据库系统。因为数据出现问题是没办法恢复的,更新一些错误的数据而导致数据出现紊乱,无论什么样的数据库高可用方案都是徒劳。虽然XA事务(分布式事务解决方案)可以保证数据库在分布式系统下的ACID特性,但是会带来性能方面的影响。
- BASE
- Basically Available
- 数据库采用分片模式,把100W的用户数据分布在5个实例。如果破坏了其中一个实例,仍然可以保证80%的用户可用
- soft-state
- 在基于client-server模式的系统中,serveer端是否有状态,决定了系统是否具备良好的水平扩展、负载均衡、故障恢复等特性
- server端承诺会维护client端状态数据,这个状态仅仅维持一小段时间,这段时间以后,server端就会丢弃这个状态,恢复正常
- Eventually Consistent
- 数据的最终一致性
- Basically Available