1、分布式性环境特点
1) 分布性, 服务器的位置
2) 并发性, 程序运行过程中,不同进程的并发操作的很常见的(比如同一个分布式系统中的多个节点同时访问共享资源)
3) 无序性 进程之间的消息通信,可能会出现顺序不一致的情况
2、分布式环境面临的问题
1) 网络通信 网络本性的不可靠性, 比如不可控的断电,电缆线的端口
2) 网络分区(在elasticsearch等集群中也叫脑裂) 当网络发生异常导致分布式系统中部分节点的网络延迟不断加大,导致不能正常通信
3) 三态 成功。失败和超时三种状态
4) 分布式事务 在不同的服务器上也需要保证ACID(原子性、一致性、隔离性、和持久性) ,之前是所有的事务范围都在同一个jvm环境中
3、中心化和去中心化(分户式环境中常用思想就是,当集群中故障发生的时候,集群中马上进行自动选举,比如zookeeper和etcd )
1) 中心化:主备思想(冷备和热备:热备就是两个master或leader但是只有一个在工作的状态,冷备就是主挂掉后马上进行选举)
2) 去中心化:没有主备之分,好处就是至少保证只是一部分不能正常工作
4、CAP和BASE理论
1) CAP:三者不能同时成立,最多只能保证两者成立(即:CA、CP、AP),由于分区容错是我们不可控的,所以我们一般选择CA,
并且CAP理论仅使用于Nosql场景,不使用于数据库的系统
C:(一致性Consistency)所有节点上的数据原子时刻保持一致
A:(可用性Availability) 每个情况都能收到一个相应,不论是三态中的哪个状态
P:(分区容错 Partition-tolerance)
2) BASE
基于CAP理论并且不适用于数据库(因为更新一些错误的数据而导致的数据紊乱,无论什么样的数据库高可用都是徒劳),
XA事务虽然可以保证数据库在分布式环境下的ACID特性,但是会带来性能方面的应用。
eBay尝试了一种完全不同的思想就是将ACID的事务要求进行放宽,于是提出了BASE理论(柔性事务):
Basically available : 数据库采用分片模式,比如将100w用户数据分布在多个实例上,若有一个或多个实例不可用,至少保证大部分用户可用
Soft-state(软状态):在基于client-server模式的系统中,server端是否有状态决定了系统是否具备良好的水平扩展、负载均衡故障恢复等特性。
Server端承诺会维护进行一小段时间内的client端的数据状态,过后server端将会丢弃这个状态恢复正常状态。
比如:用户系统调用订单系统生成订单,这时订单服务状态为处理中,并调用支付系统中的支付功能。当支付完成后将返回状态
给订单系统,此时才将订单处理中的状态修改为支付成功,而不是直接使用强一致性事务。
Eventually consistent:数据的最终一致性