在建設資料庫高可用的時候，採用了consul的機制實現，在開發相關元件的時候，使用了consul的鎖機制。但是由於使用的不正確，帶來了一些問題，下面主要介紹我的使用場景及使用方式，出現的問題，以及正確的使用方法。
在進行資料庫高可用的選舉元件設計時，考慮使用consul的鎖來進行consul-server的選舉，誰先獲取到鎖，誰就成為consul-server的leader，由leader實施資料庫選主。
元件開發選用python進行開發，consul驅動使用的是python的consul驅動：【
驅動對於consul的相關操作基本與consul提供的api功能保持一致。
設計中每一套高可用服務都有乙個鎖k-v，選舉動作觸發的時候，所有consul-server都會嘗試對這個鎖k-v加鎖，繫結自己的session id，完成選主動作後，再釋放鎖，即：
import consul
lock_key =
consul_cli = consul.consul(
)sid = consul_cli.session.create(
)lock_flag = consul_cli.kv.put(lock_key,
"test1-acquire"
, acquire=sid)
"""選舉...
"""consul_cli.session.destroy(sid)
a：主b：從1
c：從2
連續兩個節點a、b故障，此時應該由a切換到b，然後由b切換到c。
但是實際發生的時候，由a切換到b，但是b無法切換到c。
根據分析和測試，發現consul的鎖有兩個點沒注意到：
1、consul的鎖在非正常釋放的時候，會根據session的lock_delay引數進行解鎖延遲，這個lock_delay預設是15s。
2、通過destroy session的方式釋放鎖是非正常的鎖釋放，需要通過release操作才是正確的鎖釋放。
根據這兩個點，基本上能確定，為什麼a切換到b後，無法切換到c。
主要是a、b連續故障，選舉間隔在15s內，而程式是通過destroy session來釋放鎖，會有15s的鎖釋放延遲，導致b故障的時候consul-server無法獲取到鎖，從而無法進行選主，也就無法切換到c節點了。
根據以上兩點，做了兩點調整
1、通過release方式釋放鎖，使得鎖能夠正確釋放；
2、將lock_delay調成2s，避免非正常釋放鎖的情況下其他consul-server無法獲取到鎖，從而無法選舉出正確的主節點；
demo
import consul
lock_key =
consul_cli = consul.consul(
)sid = consul_cli.session.create(lock_delay=2)
lock_flag = consul_cli.kv.put(lock_key,
"test1-acquire"
, acquire=sid)
"""選舉...
"""lock_flag = consul_cli.kv.put(lock_key,
"test1-release"
, release=sid)
consul_cli.session.destroy(sid)
MySQL行鎖 表鎖 悲觀鎖 樂觀鎖的特點與應用
轉至 我們在運算元據庫的時候，可能會由於併發問題而引起的資料的不一致性 資料衝突 如何保證資料併發訪問的一致性 有效性，是所有資料庫必須解決的乙個問題，鎖的衝突也是影響資料庫併發訪問效能的乙個重要因素，從這一角度來說，鎖對於資料庫而言就顯得尤為重要。mysql鎖概述 相對其他資料庫而言，mysql的...
飛天軟體鎖Rockey1在軟體產品中的應用
飛天rockey1是免驅的，插上usb口就能用，非常方便，一般情況下免驅的鎖容易被破解，若真的到了別人破解自己軟體鎖的那一天，也就很成功了，所以rockey1對於一般軟體產品應用已經足夠了。1 rockey1的預設產品pid為8個f，使用者密碼userpin為16個f，開發商密碼sopin為16個f...
鎖 mysql Mysql的鎖（S鎖和X鎖的區別）
共享鎖和排它鎖 mysql的鎖系統 shared lock 和 exclusive lock 共享鎖和排它鎖，也叫讀鎖和寫鎖，即read lock和write lock 讀鎖是共享的，或者說是相互不阻塞的 寫鎖是排他的，乙個寫鎖會阻塞其他的寫鎖和讀鎖 在實際的資料庫系統中，每時每刻都發生鎖定，當某個...