眾所周知, 在多執行緒中,因為共享全域性變數,會導致資源修改結果不一致,所以需要加鎖來解決這個問題,保證同一時間只有一個執行緒對資源進行操作
但是在分散式架構中,我們的服務可能會有n個例項,但執行緒鎖只對同一個例項有效,就需要用到分散式鎖----redis setnx
原理:
修改某個資源時, 在redis中設定一個key,value根據實際情況自行決定如何表示
我們既然要通過檢查key是否存在(存在表示有執行緒在修改資源,資源上鎖,其他執行緒不可同時操作,若key不存在,表示資源未被執行緒佔用,允許執行緒搶佔,然後將通過setnx設定vlaue,表示資源上鎖,其他執行緒不可同時操作)
圖示:
分析:
我們的服務處於一個叢集中,如果只是簡單的的使用執行緒鎖來解決以上問題,是存在問題的:因為執行緒是基於程式的,兩個web server處於不同的程式空間
也就是說,user1的請求發往web server1,那隻能與web server1的其他請求進行鎖的操作,而不能對web server2的請求產生影響
上面的圖中,user1發往web server1的請求負責處理的執行緒為Thread1,同理負責處理user2發往web server2的請求的執行緒thread2
在同一時刻1,兩個執行緒都讀取了mysql中residue_ticket的值為100,對應上圖 (1)(2), 各自對100進行-1操作,更新到資料庫,對應(3)(4)
我們預期的情況是residue_ticket值被減少了兩次,應該為98,但是實際情況下,兩個執行緒都做了100-1=99的操作,並都將mysql中的值改為了99, 的這就會導致最終資料不一致,所以就要用到分散式鎖。
為什麼用redis?
因為redis是單執行緒的,不存在多執行緒資源競爭,並且它真的很快
為什麼用setnx 而不是set?
setnx表示只有在key不存在時才能設定成功,但是set會在key存在的情況下修改value
利用setnx的特性,我們可以這樣這樣設計:
虛擬碼:
# 設定redis鎖的 redis key = 'residue_ticket_lock' # get_ticket是處理購票的邏輯 def get_ticket(): time_out = 5 # 為了防止執行緒過多,當前執行緒獲取不到鎖,長時間處於迴圈中而導致的效能影響,我們設定一個超時時間,如果當前執行緒在超時時間內還沒有搶佔到分散式鎖,就返回失敗的結果 while True: if redis.setnx('residue_ticket_lock','lock',5): # 如果setnx返回True, 表示此刻沒有其他執行緒在運算元據庫,當前執行緒可以上鎖成功,注意不僅設定了value=lock,還設定了過期時間,這是必要的,為了防止上鎖的執行緒異常崩掉導致不能釋放(刪除key)而導致其他所有執行緒永遠拿不到操作權 residue_ticket = mysql.get('residue_ticket') # 從mysql中獲取當前剩餘票數 mysql.update('residue_ticket',residue_ticket-1) # 訂購成功,將票數-1,更新資料到mysql # 刪除key,釋放鎖 redis.del('residue_ticket') return True else: # 如果setnx返回False,表示有其他執行緒對在操作,當前執行緒等待0.01s,並繼續迴圈 time.sleep(0.01) time_out -= 0.01 continue return False