|
【IT168 资讯】这是关于K-DB锁技术的最后一部分，此前，陆续介绍了K-DB的演进、基本架构、锁目录的存储以及同数据块映射关系的建立等。本文将介绍K-DB锁包含的信息和运行机制，也就是每条锁到底包含哪些信息，以及每一条锁是如何建立、执行和取消的。 K-DB锁包含的信息 不同数据库产品的锁记录的信息差异不大，通用数据库在集群架构下通常需要的锁信息如下。锁信息的复杂性更多与技术架构相关。集群架构的数据库锁，需要记录的信息远远超过了Active-Standby架构的数据库产品，K-DB锁纪录的信息主要包含以下几点： 1、DataBlock address。锁是针对数据块的，所以锁中的信息需要记录数据块的物理地址。 2、Instance id。在集群环境下，会存在多个实例，需要记录下具体的实例id，才能知道该数据块正在被哪个节点访问。 3、Lock mode。节点在访问数据块时，需要根据读写需求，申请不同的锁模式。如果是读的话，一般是申请S锁(共享锁)，如果是写入的话，需要申请X锁(独占锁)。 4、Block state，也就是数据块的状态。在锁申请之后，数据块的状态也需要进行变化。在常用的数据块中，包括SCUR,XUR。在这里重点给大家介绍一个状态叫做PAST IMAGE 。因为这个状态在单节点中是没有的。如果一个数据块在某一个节点中被修改后，然后被传输到了其开奖直播节点，那么本节点存储的数据块状态为PI(Past Image)block。PI block 在本节点中保留了一份最新更新的数据块的内容。当某一个节点down机后，利用PI能够提升数据库的恢复速度，K-DB正是利用了这项技术使得故障恢复速度明显快于业界其开奖直播产品。 5、Role，是关于全局数据的一致性的信息。 一个数据块可以同时在多个节点的缓存中存在，而且可以不一致。当数据库的缓存中，一个数据块最多只有一个节点与磁盘中的数据不一致时。这个的角色就是local。当2个或2个以上的节点与磁盘数据不一致时，这个数据块的角色升级为global。对比global角色，local角色的数据块的回写会更简单，按照单节点的处理方式即可。而global 方式的话，处理的更加的复杂，需要在多个节点中进行确认。
|
