1、概述：分布式系统基础原则
分布式架构
集群，系统多节点
痛点：网络不可靠
维护各个节点的状态，保障各个节点之间数据的同步
- 布鲁尔定理
- 对于一个分布式系统而言，不能同时满足以下三点：
- 一致性(consisteny)
- 可用性(Availability)
- 分区容错性(Partition tolerance)
- 最多只能同时满足以上两点，其中P是必须要保留的
- 一致性：系统中的所有数据备份，在同一时刻是否同样的值，所有节点在同一时间的数据完全一致，越多节点，数据同步越耗时
- 可用性：每个请求都能在合理的时间内获得符合预期的响应（不保证获取的结果是最新的数据）。
- 分区容错性：当节点之间的网络出现问题之后，系统依然能正常提供服务。单节点故障
- 选择CA，放弃p分区容错性，假设有两个节点互相通信，当发生网络故障时，为了保证 C（一致性），那么就必须将系统锁住，不允许任何写入操作，否则就会出现节点之间数据不一致了，此时如果有其他请求，系统是不可用的，违背了可用性A
- 在网络正常情况下，CA是可以实现的
- 当有客户端向节点A进行写入请求时（准备写入Message 2），节点A会不接收写入操作，导致写入失败，这样就保证了节点A和节点B的数据一致性，即保证了Consisteny（一致性）。
- 如果有另一个客户端向B节点进行读请求的时候，B请求返回的是网络故障之前所保存的信息（Message 1），并且这个信息是与节点A一致的，是整个系统最后一次成功写入的信息，是能正常提供服务的，即保证了Partition tolerance（分区容错性）。
- zookeeper
- 由于网络问题，节点A和节点B之前不能互相通讯。
- 当有客户端（向节点A进行写入请求时（准备写入Message 2），节点A允许写入，请求操作成功。但此时，由于A和B节点之前无法通讯，所以B节点的数据还是旧的（Message 1）同步失败。
- 当有客户端向B节点发起读请求时候，读到的数据是旧数据，与在A节点读到的数据不一致。但由于系统能照常提供服务，所以满足了Availability（可用性）要求。
- EUREKA，REDIS
- Zookeeper：CP设计，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则无法提供服务，因此可用性没法满足—金融行业
- Eureka：AP原则，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化–
Redis分布式锁和Java锁的区别
- 分布式部署的话，Java锁是锁当前机器上的请求，无法对其他机器的请求进行加锁，因为Java锁用的是jvm的机制，只在本机生效
- 即使项目就是单机部署的，那么在加锁的时候，Java锁的粒度会更大，Java锁会对接口的其他请求全部阻塞，但是分布式锁，只会对接口的某一个key进行请求的时候，加锁；
- Redis分布式锁有key的入参，如果同时key1和key2都来请求接口，那么Redis分布式锁可以同时执行，但是Java锁，不行，会阻塞key2的请求
Redis分布式锁和zk分布式锁怎么选择：
- Redis采用的是AP模式，zk采用的是CP模式
- Redis分布式锁简单粗暴，获取不到锁，就直接不断的重试，比较消费资源、性能
- Redis本身的设计就不是强一致性的，所以，在一些极端的场景下，会出现问题，但是大部分情况下，是不会遇到所谓的极端复杂场景，所以，使用Redis锁也是一个选择
- zk的设计就是强一致性，如果获取不到锁，就添加一个监听，不用一直轮询，但是zk也有其缺点，如果有较多的客户端频繁的申请加锁解锁，对zk集群的压力比较大
https://www.csdn.net/tags/MtTaMg0sNDc4OTcxLWJsb2cO0O0O.html
