12.软件架构设计：大型网站技术架构与业务架构融合之道 --- CAP理论

第12章 CAP理论 
12.1 CAP理论的误解 
	C：一致性。如事务一致性，多副本一致性。
	A：可达性。客户端超时，也是不可达。
	P：网络分区。系统一旦变成分布式，有多个节点，就可能存在超时或者网络中断。

	在大规模分布式系统场景下，P(网络分区)往往是一个必然的存在，只能在C和A之间权衡。在实际中，大部分都是AP或CP的系统，而很少有CA的系统。
CP的系统追求强一致性，比如zookeeper，但牺牲了一定的性能；AP的系统追求高可用，牺牲了一定的一致性，比如数据库的主从复制，kafka的主从复制。

	为什么很少有CA的系统？因为要实现A(高可用)，必然需要冗余，有了冗余就可能存在网络分区(P)。比如传统的关系型数据库实现了事务ACID，也就是强
一致性(C)，但是单机版没有A，也没有P。要实现A，需要加从库，但也只能解决A的问题，却无法保证强一致性，转而寻求最终一致性。
	
	通过分析可以看出，P并不是通过牺牲A或者C换取的，而是需要通过网络基础设施的稳定性来保证。

12.2 现实世界不存在“强一致性”（PACELC理论） 
	正因为 "延迟" 的必然存在，CAP的扩展理论 PACELC 应用而生。其中的P,A,C 没有变化，只是引入了 Latency(延迟)因素，E指的是 Else。

	当P出现的时候，只能在A和C之间做权衡，牺牲A换取C 或者 牺牲C换取A(也就是CAP理论)。否则，当P没有出现(网络正常)，需要在L和C之间做权衡。

12.3 典型案例：分布式锁 
	举例说明分布式锁有多难：

	方案1：基于Zookeeper实现
		最常见的分布式锁是基于zookeeper来实现的，利用zookeeper的"瞬时节点"的特性。每次加锁都是创建一个瞬时节点，释放锁则删除瞬时节点。因为
	zookeeper和客户端之间通过心跳检测客户端是否宕机，如果宕机，则zookeeper检测到后自动删除瞬时节点，从而释放锁。

		zookeeper自身用zab协议保证高可用和强一致性，但该方案有2个问题：
			1.性能问题。在高并发下qps不够。
			2.因为用心跳检测客户端是否宕机，当网络超时或客户端发生full GC的时候会产生误判。本来客户端没有宕机，却误判为宕机了，锁被释放，然后被
			另外一个进程拿到了，从而导致两个进程拿到同一把锁。这也就是通常说的"脑裂"。

	方案2：基于Redis实现
		redis的性能比zookeeper好，所以通常用来实现分布式锁，但问题也很明显。

		问题1：redis没有zookeeper强一致性的zab协议，redis主从之间采用的是异步复制，如果主宕机，则切换到从，会导致部分锁的数据丢失，
		也就是多个进程会拿到同一把锁。

		问题2：客户端和redis之间没有心跳，如果客户端在拿到锁之后，释放锁之前宕机，锁将永远不能释放。要解决这个问题，是给锁加一个超时时间，过了一段
		时间后，锁将无条件释放。但这又带来了第三个问题。

		问题3：如果客户端不是真的宕机，而只是因为full GC发生了阻塞，或业务逻辑的执行时间超出了锁的超时时间，则锁被无条件释放，也会导致两个进程拿到
		同一把锁。

	可见，要实现一个高可用，通用的，强一致，高并发的分布式锁很难。也正是因为如此，在实际业务场景中，应尽量避免用分布式锁，或用串行化，弱一致性
等策略。即使要用分布式锁，往往也是针对特定的业务场景，对问题有兜底方案。