當項目使用分散式架構時,就會有可能出現客戶端數據重覆提交的情況 比如,當你向伺服器發起一個借貸命令時,如果手速夠快,可能會向後臺的兩個撥款伺服器發起同一個請求 此時, 如果不進行處理, 後臺可能會向用戶撥款兩次, 但是用戶只有一次的借錢記錄. 這時, 也是用到了常用sso登錄時的技術Redis, 前 ...
當項目使用分散式架構時,就會有可能出現客戶端數據重覆提交的情況
比如,當你向伺服器發起一個借貸命令時,如果手速夠快,可能會向後臺的兩個撥款伺服器發起同一個請求
此時, 如果不進行處理, 後臺可能會向用戶撥款兩次, 但是用戶只有一次的借錢記錄.
這時, 也是用到了常用sso登錄時的技術Redis, 前臺向後端發起某個請求時, 拿到請求的這台伺服器會去訪問Redis 使用Redis的setnx方法
如:
setnx user1 lock
這樣如果該user1是第一次存入redis ,會返回1 相當於拿到這個請求處理的鎖,可以繼續執行, 如果不是第一次,則會返回0,說明沒有拿到處理的鎖
這個時候,此台伺服器就沒有必要繼續執行. 這就起到了分散式鎖的作用
而且,本身redis是單線程的,在一個客戶端登錄之後,其他客戶端無法登陸和操作.這就有了安全保證
同時, 如果項目在拿到這個分佈試鎖的時候,伺服器宕機了, 但是redis中已經存在了相應的key, 那麼程式就會出現思索的情況,因此,在創建這個鎖的時候
最好給他設定一個超時時間, 如多這段時間內,這個鎖沒有被銷毀,則會自動銷毀.
