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