腳本加鎖
『壹』 怎麼給批處理腳本上個密碼鎖
@echo off
:menu
echo.
set /p password=請輸入密碼:
echo.
if /i "%password%"=="A" (goto next) else (echo; 密碼錯誤,請重新輸入&&goto menu)
:next
echo Yes
echo.寫下你的代碼
pause
『貳』 C語言和shell語言給文件加鎖
一般情況下是做不到的！
從文件本身角度是無法實現加鎖的！
只能從應用程序角度去加鎖，如：在C程序中進行加鎖和鎖檢查，當然，可以不是真正意義上的鎖（否則shell無法識別）。 同時，在shell進程中進行加鎖的鎖檢查！
『叄』 怎麼樣才能用腳本文件來對注冊表進行解鎖腳本文件是在哪裡編寫的
解鎖注冊表四招
相信有不少朋友遇到過注冊表被鎖而不能進入注冊表的情況。有時候他人的機器被鎖，而有的是上一次自己故意加鎖，而解鎖方法又忘記了。這里教你幾招，徹底打開這把鎖。
第一招 如果你有備份，比如你以前曾將system.dat和user.dat分別備份為backsys.bak和backusr.bak，則只需用它們將現存的兩文件覆蓋即可：
c:\windows>attrib -h -s -r system.dat
c:\windows>attrib -h -s -r user.dat
c:\windows> backsys.bat system.dat
c:\windows> backusr.bak user.dat
c:\windows>attrib +h +s +r system.dat
c:\windows>attrib +h +s +r user.dat
容笑註：如果以前您曾經用regedit.exe（注冊表編輯器）導出過注冊表，只要雙擊導出的這個文件即可導入注冊表解鎖。
第二招 寫注冊表腳本文件
REGEDIT4
[HKEY_CURRENT_USER\Software\Wicrosoft\Windows\currentversion\Policies\System]
"DisableRegistryTools"=dword:00000000
REGEDIT4必須大寫且頂格，其下面要空一行再寫路徑。用記事本或其他編輯軟體寫好後保存為以.reg為擴展名的文件，雙擊執行。不過在鎖注冊表時，高明的人早就將注冊表中.reg文件與regedit的文件關聯給刪了，這時可以考慮用下面的招式。
第三招 用regedit命令
在純DOS下，regedit也可用命令行的形式使用，例如：
REGEDIT/D HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools
如果regedit也被刪除了，仍然不用怕！我們有必殺技。
第四招 用vba寫wsh（Windows s cripting Host）
DIM WSH
SET WSH=Ws cript.CREATEOBJECT("Ws cript.SHELL")
WSH.POPUP("將為您解開注冊表！")
WSH.REGWRIT"HKCU\SOFTWARE\MICROSOFT\WINDOWS\CURRENTBERSION\POLICIES\SYSTEM\DISABLEREGISTRYTOOLS",0,"REG_DWORD"
WSH.POPUP("SUCCESSFULLY!")
用記事本寫完後存為以.vbs為擴展名的文件後雙擊執行即可。
『肆』 linux 定時任務，如何加鎖
好像沒有加鎖的功能，但是你可以在你的腳本中寫一個判斷，如果有相同進程，就不執行
『伍』 按鍵精靈腳本如何鎖定程序執行，或者怎麼綁定yy
在腳本重復執行的最開始運行，這樣的話每次刷完一次圖，就檢測一次yy是否打開。也可以使用多線程，至始至終的檢測。使用多線程時，只要他一關，腳本就停止，不管有沒有刷完。
（BeginThread 多線程檢測yy是否開啟中）
（sub 多線程檢測yy是否開啟中）
dim hwnd //如果前邊已經使用著這個hwnd，可以加後綴數字10000.200000都可以
hwnd = //你的yy句柄
Window = Plugin.Window.IsWindow(Hwnd)
If Window < > 1 Then //< > 這個是不等號 不知道有沒有輸錯
i=1
while i = 0
MsgBox "又不要你錢，就開個yy還ggyy的，你去死吧。"
delay 10
MsgBox "弄個對話框彈死你！"
delay 10
Wend
EndScript //結束腳本
elseif window = 1 then
MsgBox "關閉腳本時候，請先停止腳本，後關閉yy，謝謝"
End If
（delay 1000 //多線程，一秒鍾檢測一次，否則的話機器可能會卡）
（End Sub）
其實就是一個窗口打開的判定。當然也有其他方式。帶括弧的就是多線程檢測。使用的時候把括弧去掉
看了有用的 不贊是豬！
『陸』 Redisson實現分布式鎖原理
如圖所示啊，石杉大佬畫的redisson分布式鎖原理。
大概總結下，保證我們的key落到一個集群里，並且加鎖操作是基於lua腳本的原子性操作，對於鎖延遲由watch dog控制。
具體可以看 https://www.cnblogs.com/AnXinliang/p/10019389.html
如果你對某個redis master實例，寫入了myLock這種鎖key的value，此時會非同步復制給對應的master slave實例。但是這個過程中一旦發生redis master宕機，主備切換，redis slave變為了redis master。
接著就會導致，客戶端2來嘗試加鎖的時候，在新的redis master上完成了加鎖，而客戶端1也以為自己成功加了鎖。
此時就會 導致多個客戶端對一個分布式鎖完成了加鎖。
這時系統在業務語義上一定會出現問題，導致各種臟數據的產生。
所以這個就是redis cluster，或者是redis master-slave架構的主從非同步復制導致的redis分布式鎖的最大缺陷：在redis master實例宕機的時候，可能導致多個客戶端同時完成加鎖。
如果主動結構redis架構模式下，我們想保證完全一致，必須重寫加鎖的邏輯了， 保證必須mater和slave同時加鎖成功，我們整個加鎖才是成功的 。
上面的2是對於單個主從結構我們可以這樣干，如果假設我們有多個相對獨立的master，無slave呢？我們在其中一個master上加了🔐，然後它掛了豈不是我們的數據會在剩下的結點會重新加鎖成功？
redis引入了 紅鎖 的概念：用Redis中的多個master實例，來獲取鎖，只有 大多數 實例獲取到了鎖，才算是獲取成功 。
具體的紅鎖演算法分為以下五步：
以上步驟來自redis 分布式鎖的解釋,如下
」相同的key和隨機值（隨機值用於唯一關系客戶端和key）在N個節點上請求鎖「
這里的隨機數是什麼？
這對於 避免刪除由另一個客戶端創建的鎖 很重要。例如，客戶端可能會獲取鎖，執行某些操作時被阻塞的時間超過鎖的有效時間（密鑰將過期的時間），然後移除已被其他客戶端獲取的鎖。使用 just DEL 是不安全的，因為客戶端可能會刪除另一個客戶端的鎖。使用上面的腳本，每個鎖都用一個隨機字元串「簽名」，所以只有當它仍然是客戶端試圖移除它時設置的鎖才會被移除。
這個隨機字元串應該是什麼？我們假設它是 20 個位元組 /dev/urandom ，但您可以找到更便宜的方法使其對您的任務足夠獨特。例如，一個安全的選擇是用 RC4 播種 /dev/urandom ，並從中生成一個偽隨機流。一個更簡單的解決方案是使用具有微秒精度的 UNIX 時間戳，將 時間戳與客戶端 ID 連接起來。它並不安全，但對於大多數環境來說可能就足夠了。
假設一共有5個Redis節點：A, B, C, D, E。設想發生了如下的事件序列：
為了應對這一問題，提出了 延遲重啟 (delayed restarts)的概念。
就是,一個節點崩潰後，先不立即重啟它，而是等待一段時間再重啟，這段時間應該大於鎖的有效時間(lock validity time)。
這樣的話，這個節點在重啟前所參與的鎖都會過期，它在重啟後就不會對現有的鎖造成影響。
客戶端1在獲得鎖之後發生了很長時間的GC pause，在此期間，它獲得的鎖過期了，而客戶端2獲得了鎖。
當客戶端1從GC pause中恢復過來的時候，它不知道自己持有的鎖已經過期了，它依然向共享資源（ 比如 一個存儲服務）發起了寫數據請求，
而這時鎖實際上被客戶端2持有，因此兩個客戶端的寫請求就有可能沖突（鎖的互斥作用失效了）。
如何解決這個問題呢?引入了 fencing token 的概念：
首先：RedLock根據隨機字元串來作為單次鎖服務的token，這就意味著對於資源而言，無法根據鎖token來區分client持有的鎖所獲取的先後順序。
fencing token可以理解成採用全局遞增的序列替代隨機字元串,即 有序token ，作為鎖token來使用
流程：
假設有5個Redis節點A, B, C, D, E。
這個問題用Redis實現分布式鎖暫時無解。而生產環境這種情況是存在的。
時鍾跳躍是可以避免的，取決於基礎設施和運維； 時鍾跳躍是可以避免的，取決於基礎設施和運維；
redis是保持的AP而非CP，如果要追求強一致性可以使用zookeeper分布式鎖，但是zookeeper也不是完全沒問題，在出現網路顏值，客戶端與服務端失聯情況的時候也依然可能會出現分布式的問題。