2.数据复制与一致性.pptxVIP

2 数据复制与一致性2.2 一致性模型分类 2.3副本更新策略 2.4一致性协议2.2 一致性模型分类1.一致性模型关系图2.定义以下场景及术语来说明各种一致性的具体含义：A,B,C：代表3个独立的进程，这些进程会对NoSQL数据库里的数据进行读/写操作。x：NoSQL数据库中的某条数据。v1,v2,v3：数据x的不同取值。Write(Item,Value):代表某进程的一次写操作，将Item的值更新为Value。Read(Item,Value):代表某进程的一次读操作，即读出Item的值为Value。Notify(p1,p2,Item,Value):代表进程p1通知进程p2将Item的值更新为Value。2.2.1 强一致性在数据库的所有进程中，当更新完成，后续所有访问都将获得更新值。弱一致性：即系统不能保证后续访问都将获得更新值。2.2.2 最终一致性在对x做出操作后，与最终看到新数值之前，存在一个时间片段，在这个时间片段内，数据也许是不一致的，即“不一致窗口”。2.2.3 因果一致性因果一致性发生在进程之间有因果依赖关系的情形下。进程A与进程C没有因果依赖关系，则遵循最终一致性。2.2.4 “读你所写”一致性“读你所写”一致性是因果一致性的特例。更新操作后，进程A后续访问到的都是新数值，其他进程并未受影响。2.2.5 会话一致性“会话一致性”是“读你所写”一致性的变体。当进程A通过会话与数据库系统连接，同一个会话内，可以保证“读你所写”一致性，若会话终止，进程A的数值则会不一定。2.2.6 单调读一致性最终一致性的另一种变体。如果某个进程读取到数据x的一个数值，那么后续所有访问将不会返回任何之前的值。2.2.7 单调写一致性另外一种最终一致性的变体。对于某个进程来说，单调写一致性可以保证其多次写操作的序列化，同时也保证了应用开发者的顺利开发。在实际的存储系统中，可以综合使用以上的一致性模型。2.3 副本更新策略类型AB有无一致性协议没有任何，直接更新有是否有执行顺序无，多个节点交叉有，唯一确定数据是否一致不一致一致2.3.1 同时更新2.3.2 主从式更新类型A：同步方式B：异步方式C：混合方式含义主副本等待所有从副本更新完成后才确认更新操作完成主副本在通知从副本更新之前即可确认更新操作主副本首先同步更新从副本数据，然后确认更新操作完成，其他副本通过异步方式获得更新异步方式根据读操作的响应方式，可分为两种情形根据读操作的响应方式，可分为两种情形任意一个副本接收到读请求后，将其转发给主副本任意一个副本都可响应读请求同时更新了好多节点，至少要读出一个新数值对读出的数值没有要求优点强一致性保证了强一致性请求延时大大降低强一致性-缺点请求延时较大请求延时增加结果不一致问题请求延时增大读不一致问题2.3.3 任意节点更新类型A：同步通知其他副本B：异步通知其他副本特点与“主从式更新”类型A类似存在和“同时更新”及“主从式更新”策略类型B类似的问题数据更新请求可能发给多副本中的任意一个节点，然后由这个节点来负责通知其他副本进行数据更新。请求延时和一致性权衡有以下两种情形：2.4 一致性协议2.4.1 两阶段提交协议（Two-Phrase Commit,2PC）含义：在大数据环境下，代表要么所有备份数据同时更改某个数值，要么都不更改。两类实体：唯一的协调者，众多的参与者。两阶段提交过程：协调者的有限状态机：参与者的有限状态机： 从刚才的状态机中可以看出，协调者的等待状态，参与者的初始状态和准备状态都需要等待对方的反馈信息，进入了阻塞状态，而且很可能因有进程陷入崩溃而导致处于阻塞态的对象进入长时间的等待。为了解决这种情况，引入：超时判断机制和参与者互询机制。进程Q状态处于困境的参与者P的动作COMMITCOMMITABORTABORTINITABORTREADY与其他参与者联系为了解决长时阻塞，提出了三阶段提交协议（3PC）：2.4.2 向量时钟（Vector Clock）向量时钟的作用Alice、Ben、Cathy和Dave四人约定下周一起聚餐，四个人通过邮件商量聚餐的时间。Alice首先建议周三聚餐。之后Dave和Catby商量觉得周四更合适。后来Dave又和Ben商量之后觉得周二也行。最后Alice要汇总大家的意见，得到的反馈如下：Cathy说，他和Dave商量的时间是周四Ben说，他和Dave商量的时间是周三此时恰好联系不上Dave，而且不知道Cathy和Ben分别与Dave确定时间的先后顺序，Alice就不能确定到底该定在哪天了。简单地说，就是为每个商议结果加上一个时间戳，当结果改变时，更新时间戳向量时钟的更新规则1.每次修改数据，本节点的版本号加1;2.当进程发送消息时，会将自己的向量时钟和消息m同时发送出;3. 每次同步数