分布式环境的特性
1.分布性
2.并发性
程序运行过程中,并发性操作是很常见的比如一个分布式系统中的多个节点同时访问一个共享资源,数据库,分布式存储
3.无序性
进程之间的通信会出现顺序不一致问题
分布式环境面临的问题
网络问题
网络本身的不可靠性,因此会涉及到一些网络通信问题
网络分区(脑裂)
当网络发生异常导致分布式系统中部分节点之间的通信延迟不断增大,最终导致分布式架构中的所有节点只有部分节点可用
三态
成功,失败,超时
分布式事务
ACID(原子性,一致性,隔离性,持久性)
中心化和去中心化
冷备和热备
分布式架构里,很多架构思想是:当集群发生故障时集群中会自动“选举”出一个新的leader
最经典的是:zookeeper/etcd
经典的CAP/BASE理论
CAP
C(Consistency):所有节点上的数据时刻保持一致
A(Availability):每个请求都能收到一个响应无论成功或者失败
P(Partion-tolerance):表示系统出现脑裂以后,可能导致某些server与集群中的其他机器失去联系
实际上只可能是AP或者AP
CAP理论仅适用于原子读写的Nosql场景,不适用于数据库系统
基于CAP理论,CAP理论并不适用于数据库事务(因为更新一些错误的数据而导致数据出现紊乱,无论什么样的数据库高可用方案都是
徒劳) ,虽然XA事务可以保证数据库在分布式系统下的ACID特性,但是会带来性能方面的影响;
eBay尝试了一种完全不同的套路,放宽了对事务ACID的要求。提出了BASE理论
Basically available :数据库采用分片模式,把100W的用户数据分布在5个实例上。如果破坏了其中一个实例,仍然可以保证
80%的用户可用
soft-state: 在基于client-server模式的系统中,server端是否有状态,决定了系统是否具备良好的水平扩展、负载均衡、故障恢复等特性。
Server端承诺会维护client端状态数据,这个状态仅仅维持一小段时间, 这段时间以后,server端就会丢弃这个状态,恢复正常状态
Eventually consistent:数据的最终一致性
初识zookeeper
zookeeper是一个开源的分布式协调服务,是由雅虎创建,基于Google chubby。
zookeeper是什么?
分布式数据一致性的解决方案
zookeeper能做什么?
数据发布/订阅(配置中心:disconf),负债均衡(dubbo利用zookeeper实现负债均衡),命名服务,master选举(kafka,hadoop,hbase),分布式队列,分布式锁。
zookeeper特性
顺序一致性
从同一个客户端发起的事物请求,最终会严格按照顺序被应用到zookeeper中
原子性
所有的事物请求的处理结果在整个集群中的所有机器上的应用情况是一致的,也就是说要么所有机器都应用了某一事物,要么全都不应用
可靠性
一旦服务器成功应用了某个事务数据,并且对客户端做了响应,那么这个数据在整个集群中一定是同步并且保留下来的
实时性
一旦一个事务被成功应用,客户端就能够立即从服务端读取到事务变更后的最新数据状态(zookeeper仅仅保证在一定时间内,近实时)