1、问:why分布式锁,以及how?
曰:比如,我们有如果是单台机器,并发来了怎么搞?我们有很多处理高并发的方法手段,例如synchronized、retrentlock、courrentMap、synchronizeHashMap等等,来防止高并发,这个是合理的。但是这只能针对一台机器,如果有一个方法,每次只允许一个访问,那么synchronized也可以出现两次。所以,单机锁没有用了,需要分布式锁。
如何获得分布式锁呢:1、数据库的方法,获得一个锁就增加一条记录,释放锁就删除记录。2、缓存,redis memercache都可以。3、zk。目前用2比较溜。
借助zk理解分布式系统相关,参考《从paxos到zk分布式一致性原理与实践》
Part I - C1:单机-分布式系统所面临的问题
Part II - C2-C4:分布式一致性协议
Part IV - C7:ZK原理与架构设计
Part I - C1:单机-分布式系统所面临的问题
IBM制造的System/360系列大型机为集中式结构框架起到了很大的推广作用。大型机太贵了,所以阿里08年开始推行的去IOE活动,推动了电商分布式系统的发展。既然是分布式的系统,那么节点之间可没有主从之分,但是有副本的概念,就是一个数据或服务的冗余。
分布式系统缺乏一个全局时钟。网络故障会带来问题。
事务也相应发生了变化:ACID----CAP/BASE
Atomic/Consistency/Isolation/Durability
原子性:事务要么都执行,要么都不执行
一致性:事务如果执行了一部分,另一部分没有写入物理库,就称为破坏了一致性
隔离性:读未提交、读已提交、重复读、串行读
持久性:一旦submit,状态就固定了,就算机器down了,恢复也是submit之后的状态。
Consistency/Avaliable/Partition tolerance(分区容错性)
一致性:分布式环境的一致性指的是“数据在多个副本之间保持一致性”
可用性:系统能在一定的时间能返回结果。
分区容错性:分布式系统存在的核心意义,一个部分down了,其他部分可以顶起来。
Base Avaliable/ Soft status/ Eventually consistency
基本可用:当系统出现了问题的时候,对系统进行降级,允许损失部分可用性(同上,两个方面)。
软状态:副本之间的状态,同步可以不实时,允许存在时延。
最终一致性:经过一段时间之后,达到一致性。(由软状态促进)整个BASE比CAP柔和了许多。
比如数据库的主备同步的时候,就是采取的“最终一致性”,依赖读取Binlog进行同步,而不是主备都写成功了才算Durability成功;所以有时候代码里面,需要强制读取主库才行。
Part II - C2-C4:分布式一致性协议 2PC/3PC/Paxos
分布式系统提交事务的时候,A节点并不知道其他节点提交是否成功了,所以A提交事务的时候就会比较忐忑。因此分布式系统 同步数据的时候需要有个协调者(Coordinator),其他的节点称之为参与者(Participant)。Coordinator负责协调Participant,决定Participant是否要进行事务的提交。
2PC:
1、提交事务请求
Coordinator发放事务请求,Participant判断是否可以进行事务处理、执行事务操作、写入Undo Redo日志、返回给Coordinator Yes or No
2、Coordinator根据Yes or No进行判断,向Participant发送commit or rollback命令。
完成。
优点:简单、容易实现
缺点:1、同步阻塞:所有节点在第一步骤之后,只能等待,不能进行其他处理;2、单点问题:Coordinator在第一步之后挂了,其他节点都会处于阻塞状态;3、数据不一致(脑裂):第二步ing Coordinator挂了,或者第二步之后,某些节点网络挂了,导致节点之间数据不一致。4、太过保守:任意节点失败导致整个系统的事务失败。
3PC:
1、CanCommit:类似于2PC的第一步前面部分,是否可以进行事务处理
2、PreCommit:2PC的第一步后面的部分,通知各节点进行事务执行,写入Undo Redo 日志;Coordinator根据Participant返回的结果通知各节点准备提交或者中断事务。
3、DoCommit:Coordinator向Participant发送cimmit or rollback。
相对于2PC更麻烦一点,也没有解决实际问题。
Paxos协议
核心点是,过半
应用一:Chubyy分布式锁服务,使用Paxos协议确定Master是哪一台机器,其他机器使用Paxos协议从Master同步数据(即:master使用Paxos进行广播)。
应用二:Hypertable类似于HBase的分布式存储
应用三:产品:Zookeeper,协议:ZAB:Zookeeper Atomic Broadcast。zookeeper是一个典型的分布式数据一致性解决方案,应用程序基于其可实现诸如,发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁、分布式队列等功能
zk数据模型类似于一个文件系统,但是数据都存储在内存中,以实现高吞吐、低延迟目的。
角色:Leader提供读写,Follower提供读及参与Leader选举,Observer读。
ZAB是在paxos基础上,为zk专门设计的数据一致性算法,主要是为了支持奔溃恢复和原子广播。奔溃恢复,看起来就是Master挂了之后,Lollowers进行选举,过半同意的那个称为新的Master,剩余的Followers与Master进行数据同步。
PartIII C6:应用场景
1、数据发布与订阅(类似disconf)
在zk中选择一个数据节点,配置上我们需要的数据,客户端在这个数据节点上注册一个watch事件,所有订阅了的客户端都可以收到变更通知,当数据变化了之后,节点会给客户端推送一个通知,客户端再来拉取最新的数据。ZK有API接口!
2、负载均衡
没看懂
3、命名服务
分布式项目中,只需要知道名字就可以对对象进行操作,避免了IP地址等细节处理。客户端根据名字获得实体服务的地址、资源等。与java里面的JNDI(Java Naming and Directory Interface)异曲同工。但是,广义上的命名,并不只是命名而已,比如获得一个全局的唯一id,也是命名。就可以通过zk的znode来获得。在zk中每一个数据节点都会维护一份子节点的顺序序列,客户端每创建一个子节点,都会在这个数据节点后面添加一个序号。
另外,uuid32位乱序字符+4位短横杠,除了唯一性没有任何额外的意义。
4、分布式协调/通知
在zk中创建临时节点等。这里可以用来:节点存在即表示存活(心跳);
5、集群管理
也是通过在zk中注册节点
6、Master选举
6.1利用数据库。各个节点向数据库插入一个unique的唯一值,插入成功了则为Master,失败了则为Slave。但是如果Master挂了,那就是挂了,并不会通知Slave们。
6.2利用zk。而zk,其他点创建Master失败之后,会在zk上注册一个watch,master 挂了之后zk会通知Slave们,进行Master选举来。
7、分布式锁
在zk中注册一个临时节点,成功则为获得锁,失败则为没有获得锁,同时会注册watch事件。但是在获得锁之后要释放锁。zk也会用心跳检测获得锁的节点,如果节点挂了,就释放了临时节点,其他注册了watch事件的应用节点就可以在zk通知后,获得注册临时节点的机会了。
redis好像没有自动释放key的方法?万一节点挂了,岂不是尴尬了?
Part IV - C7:ZK原理与架构设计
额。。。安定下来再细看