這是關于k-db鎖技術的最後一部分，此前，陸續介紹了k-db的演進、基本架構、鎖目錄的存儲以及同資料塊映射關系的建立等。本文将介紹k-db鎖包含的資訊和運作機制，也就是每條鎖到底包含哪些資訊，以及每一條鎖是如何建立、執行和取消的。
k-db鎖包含的資訊
不同資料庫産品的鎖記錄的資訊差異不大，通用資料庫在叢集架構下通常需要的鎖資訊如下。鎖資訊的複雜性更多與技術架構相關。叢集架構的資料庫鎖，需要記錄的資訊遠遠超過了active-standby架構的資料庫産品，k-db鎖紀錄的資訊主要包含以下幾點：
datablock address。鎖是針對資料塊的，是以鎖中的資訊需要記錄資料塊的實體位址。
instance id。在叢集環境下，會存在多個執行個體，需要記錄下具體的執行個體id，才能知道該資料塊正在被哪個節點通路。
lock mode。節點在通路資料塊時，需要根據讀寫需求，申請不同的鎖模式。如果是讀的話，一般是申請s鎖（共享鎖），如果是寫入的話，需要申請x鎖（獨占鎖）。
block state，也就是資料塊的狀态。在鎖申請之後，資料塊的狀态也需要進行變化。在常用的資料塊中，包括scur,xur。在這裡重點給大家介紹一個狀态叫做past image 。因為這個狀态在單節點中是沒有的。如果一個資料塊在某一個節點中被修改後，然後被傳輸到了其他節點，那麼本節點存儲的資料塊狀态為pi（past image）block。pi block 在本節點中保留了一份最新更新的資料塊的内容。當某一個節點down機後，利用pi能夠提升資料庫的恢複速度，k-db正是利用了這項技術使得故障恢複速度明顯快于業界其他産品。
role，是關于全局資料的一緻性的資訊。 一個資料塊可以同時在多個節點的緩存中存在，而且可以不一緻。當資料庫的緩存中，一個資料塊最多隻有一個節點與磁盤中的資料不一緻時。這個的角色就是local。當2個或2個以上的節點與磁盤資料不一緻時，這個資料塊的角色更新為global。對比global角色，local角色的資料塊的回寫會更簡單，按照單節點的處理方式即可。而global 方式的話，處理的更加的複雜，需要在多個節點中進行确認。
k-db鎖的運作及測試資料
資料庫鎖的運作可分為申請、使用和取消三個環節，其中申請環節最為複雜，其他環節較為簡單。
cwls——鎖管理的核心
cwls（cluster wait-lock service）子產品負責系統鎖的準許、生成和執行，是系統鎖管理的核心子產品。當一個instacne 向資料塊的master 節點申請鎖時，master 節點通過cluster wait-lock service檢視目前鎖的使用情況。申請程序主要一共有2個隊列，一個是已經配置設定的隊列，一個是等待轉換隊列。配置設定成功的隊列上的鎖模式的相容性，必然是相容的，與之相反的是，等待轉換隊列的鎖模式是不相容的，需要等待。例如，2個節點同時申請對用一個資料塊進行讀取操作。那麼它們需要申請的是讀共享鎖。這2個鎖是相容的，可以同時放在配置設定清單中。gld 中會記錄下這兩個節點的鎖資訊——共享鎖。之後第三個節點想要修改這個資料塊，它需要申請的獨占鎖。master節點的cws發現該模式與目前配置設定連結清單中的鎖資訊不相容，此時它需要等待。先把它放在conver queue中等待。向grant queen中的正在持有鎖的執行個體發送請求，要求它們将目前的鎖進行降級為與他相容的模式。
原文釋出時間為：2016-08-03
本文來自雲栖社群合作夥伴至頂網，了解相關資訊可以關注至頂網。