java課程設(shè)計日歷記事本代碼已開源

1、java課程設(shè)計歷記事本代碼，已開源1.為什么要使分布式鎖使分布式鎖的的，外乎就是保證同時間只有個客戶端可以對共享資源進操作。舉個很長的例系統(tǒng) A 是個電商系統(tǒng)，前是臺機器部署，系統(tǒng)中有個戶下訂單的接，但是戶下訂單之前定要去檢查下庫存，確保庫存夠了才會給戶下單。由于系統(tǒng)有定的并發(fā)，所以會預(yù)先將商品的庫存保存在 Redis 中，戶下單的時候會更新 Redis 的庫存。此時系統(tǒng)架構(gòu)如下：但是這樣來會產(chǎn)個問題：假如某個時刻，Redis 的某個商品庫存為 1。此時兩個請求同時到來，其中個請求執(zhí)到上圖的第 3 步，更新數(shù)據(jù)庫的庫存為 0，但是第 4 步還沒有執(zhí)。另外個請求執(zhí)到了第 2 步，發(fā)現(xiàn)庫存還是

2、1，就繼續(xù)執(zhí)第 3 步。這樣的結(jié)果，是導(dǎo)致賣出了 2 個商品，然其實庫存只有 1 個。很明顯不對啊！這就是典型的庫存超賣問題。此時，我們很容易想到解決案：鎖把 2、3、4 步鎖住，讓他們執(zhí)完之后，另個線程才能進來執(zhí)第 2 步。按照上的圖，在執(zhí)第 2 步時，使 Java 提供的 Synchronized 或者 ReentrantLock 來鎖住，然后在第 4 步執(zhí)完之后才釋放鎖。這樣來，2、3、4 這 3 個步驟就被“鎖”住了，多個線程之間只能串化執(zhí)。當(dāng)整個系統(tǒng)的并發(fā)飆升，臺機器扛不住了?，F(xiàn)在要增加臺機器，如下圖：增加機器之后，系統(tǒng)變成上圖所，假設(shè)此時兩個戶的請求同時到來，但是落在了不同的機器上

3、，那么這兩個請求是可以同時執(zhí)了，還是會出現(xiàn)庫存超賣的問題。因為上圖中的兩個 A 系統(tǒng)，運在兩個不同的 JVM ，他們加的鎖只對屬于 JVM 的線程有效，對于其他 JVM 的線程是效的。因此，這的問題是：Java 提供的原鎖機制在多機部署場景下失效了，這是因為兩臺機器加的鎖不是同個鎖（兩個鎖在不同的 JVM）。那么，我們只要保證兩臺機器加的鎖是同個鎖，問題不就解決了嗎？此時，就該分布式鎖隆重登場了。分布式鎖的思路是：在整個系統(tǒng)提供個全局、唯的獲取鎖的“東西”，然后每個系統(tǒng)在需要加鎖時，都去問這個“東西”拿到把鎖，這樣不同的系統(tǒng)拿到的就可以認(rèn)為是同把鎖。于這個“東西”，可以是 Redis、Zook

4、eeper，也可以是數(shù)據(jù)庫。此時的架構(gòu)如圖：通過上的分析，我們知道了庫存超賣場景在分布式部署系統(tǒng)的情況下使 Java 原的鎖機制法保證線程安全，所以我們需要到分布式鎖的案。2.效的分布式鎖在設(shè)計分布式鎖的時候，應(yīng)該考慮分布式鎖少要滿的些條件，同時考慮如何效的設(shè)計分布式鎖，以下點是必須要考慮的：(1) 互斥在分布式并發(fā)的條件下，最需要保證在同時刻只能有個線程獲得鎖，這是最基本的點。(2) 防死鎖在分布式并發(fā)的條件下，如有個線程獲得鎖的同時，還沒有來得及去釋放鎖，就因為系統(tǒng)故障或者其它原因使它法執(zhí)釋放鎖的命令,導(dǎo)致其它線程都法獲得鎖，造成死鎖。所以分布式常有必要設(shè)置鎖的有效時間，確保系統(tǒng)出現(xiàn)故障后

5、，在定時間內(nèi)能夠主動去釋放鎖，避免造成死鎖的情況。(3) 性能對于訪問量的共享資源，需要考慮減少鎖等待的時間，避免導(dǎo)致量線程阻塞。所以在鎖的設(shè)計時，需要考慮兩點。1、 鎖的顆粒度要盡量。如你要通過鎖來減庫存，那這個鎖的名稱你可以設(shè)置成是商品的ID,不是任取名稱。這樣這個鎖只對當(dāng)前商品有效,鎖的顆粒度。2、 鎖的范圍盡量要。如只要鎖2代碼就可以解決問題的，那就不要去鎖10代碼了。(4) 重我們知道ReentrantLock是可重鎖，那它的特點就是：同個線程可以重復(fù)拿到同個資源的鎖。重鎖常有利于資源的效利。關(guān)于這點之后會做演。3.基于Redis實現(xiàn)分布式鎖3.1 使Redis命令實現(xiàn)分布式鎖加鎖加

6、鎖實際上就是在redis中，給Key鍵設(shè)置個值，為避免死鎖，并給定個過期時間。使的命令*：SET lock_key random_value NX PX 5000*值得注意的是：random_value 是客戶端成的唯的字符串。NX 代表只在鍵不存在時，才對鍵進設(shè)置操作。PX 5000 設(shè)置鍵的過期時間為5000毫秒。也可以使另外條命令:SETNX key value只不過過期時間法設(shè)置。這樣，如果上的命令執(zhí)成功，則證明客戶端獲取到了鎖。解鎖解鎖的過程就是將Key鍵刪除，但要保證安全性，舉個例：客戶端1的請求不能將客戶端2的鎖給刪除掉。釋放鎖涉及到兩條指令，這兩條指令不是原性的,需要到redi

7、s的lua腳本持特性，redis執(zhí)lua腳本是原性的。腳本如下：這種式較簡單，但是也有個最重要的問題：鎖不具有可重性。使Redisson實現(xiàn)分布式鎖3.2.1Redisson介紹Redisson是架設(shè)在Redis基礎(chǔ)上的個Java駐內(nèi)存數(shù)據(jù)格（In-Memory Data Grid）。充分的利了Redis鍵值數(shù)據(jù)庫提供的系列優(yōu)勢，基于Java實具包中常接，為使者提供了系列具有分布式特性的常具類。使得原本作為協(xié)調(diào)單機多線程并發(fā)程序的具包獲得了協(xié)調(diào)分布式多機多線程并發(fā)系統(tǒng)的能，降低了設(shè)計和研發(fā)規(guī)模分布式系統(tǒng)的難度。同時結(jié)合各富特的分布式服務(wù)，更進步簡化了分布式環(huán)境中程序相互之間的協(xié)作。3.2.2R

8、edisson簡單使Config config = new Config();config.useClusterServers()lock.unlock();只需要通過它的 API中的 Lock 和 Unlock 即可完成分布式鎖，且考慮了很多細節(jié)：l Redisson 所有指令都通過 Lua 腳本執(zhí)，Redis 持 Lua 腳本原性執(zhí)。l Redisson 設(shè)置個 Key 的默認(rèn)過期時間為 30s，但是如果獲取鎖之后，會有個WatchDog每隔10s將key的超時時間設(shè)置為30s。另外，Redisson 還提供了對 Redlock 算法的持，它的法也很簡單：multiLock.unlock(

9、);3.2.3Redisson原理分析(1) 線程去獲取鎖，獲取成功:執(zhí)lua腳本，保存數(shù)據(jù)到redis數(shù)據(jù)庫。線程去獲取鎖，獲取失敗:直通過while循環(huán)嘗試獲取鎖，獲取成功后，執(zhí)lua腳本，保存數(shù)據(jù)到redis數(shù)據(jù)庫。(2) 在個分布式環(huán)境下，假如個線程獲得鎖后，突然服務(wù)器宕機了，那么這個時候在定時間后這個鎖會動釋放，也可以設(shè)置鎖的有效時間(不設(shè)置默認(rèn)30秒），這樣的的主要是防死鎖的發(fā)。但是在實際情況中會有種情況，業(yè)務(wù)處理的時間可能會于鎖過期的時間，這樣就可能*導(dǎo)致解鎖和加鎖不是同個線程。*所以WatchDog作就是Redisson實例關(guān)閉前，不斷延長鎖的有效期。如果程序調(diào)加鎖法顯式地給了

10、有效期，是不會開啟后臺線程(也就是watch dog)進延期的，如果沒有給有效期或者給的是-1，redisson會默認(rèn)設(shè)置30s有效期并且會開啟后臺線程(watch dog)進延期多久進次延期：（默認(rèn)有效期/3），默認(rèn)有效期可以設(shè)置修改的，即默認(rèn)情況下每隔10s設(shè)置有效期為30s(3) Redisson可以實現(xiàn)可重加鎖機制的原因：l Redis存儲鎖的數(shù)據(jù)類型是Hash類型l Hash數(shù)據(jù)類型的key值包含了當(dāng)前線程的信息下是redis存儲的數(shù)據(jù)這表數(shù)據(jù)類型是Hash類型,Hash類型相當(dāng)于我們java的 key, 類型,這key是指 redisson它的有效期還有9秒，我們再來看們的key1

11、值為078e44a3-5f95-4e24-b6aa-80684655a15a:45它的組成是:guid + 當(dāng)前線程的ID。后的value是就和可重加鎖有關(guān)。value代表同客戶端調(diào)lock法的次數(shù)，即可重計數(shù)統(tǒng)計。舉圖說明上這圖的意思就是可重鎖的機制，它最的優(yōu)點就是相同線程不需要在等待鎖，是可以直接進相應(yīng)操作。3.2.4獲取鎖的流程其中的指定字段也就是hash結(jié)構(gòu)中的field值（構(gòu)成是uuid+線程id），即判斷鎖是否是當(dāng)前線程3.2.5加鎖的流程4. 使Redis做分布式鎖的缺點Redis有三種部署式l 單機模式l Master-Slave+Sentienl選舉模式l Redis Clu

12、ster模式如果采單機部署模式，會存在單點問題，只要 Redis 故障了。加鎖就不了采 Master-Slave 模式，加鎖的時候只對個節(jié)點加鎖，即便通過 Sentinel 做了可，但是如果 Master 節(jié)點故障了，發(fā)主從切換，此時就會有可能出現(xiàn)鎖丟失的問題?；谝陨系目紤]，Redis 的作者也考慮到這個問題，他提出了個 RedLock 的算法。這個算法的意思概是這樣的：假設(shè) Redis 的部署模式是 Redis Cluster，總共有 5 個 Master 節(jié)點。通過以下步驟獲取把鎖：獲取當(dāng)前時間戳，單位是毫秒。輪流嘗試在每個 Master 節(jié)點上創(chuàng)建鎖，過期時間設(shè)置較短，般就毫秒。嘗試在

13、多數(shù)節(jié)點上建個鎖，如 5 個節(jié)點就要求是 3 個節(jié)點（n / 2 +1）?？蛻舳擞嬎憬ê面i的時間，如果建鎖的時間于超時時間，就算建成功了。要是鎖建失敗了，那么就依次刪除這個鎖。只要別建了把分布式鎖，你就得不斷輪詢?nèi)L試獲取鎖。但是這樣的這種算法，可能會出現(xiàn)節(jié)點崩潰重啟，多個客戶端持有鎖等其他問題，法保證加鎖的過程定正確。例如：假設(shè)共有5個Redis節(jié)點：A,B,C,D,E。設(shè)想發(fā)了如下的事件序列：(1)客戶端1成功鎖住了A,B,C，獲取鎖成功（但D和E沒有鎖住）。(2)節(jié)點C崩潰重啟了，但客戶端1在C上加的鎖沒有持久化下來，丟失了。(3)節(jié)點C重啟后，客戶端2鎖住了C,D,E，獲取鎖成功。這樣，客戶端1和客戶端2同時獲得了鎖（針對同資源）。最后由于細節(jié)內(nèi)容實在太多了，為了不影響章的觀賞性，只截出了部分知識點致的介紹下，每個節(jié)點都有更細化的內(nèi)容！需要這份檔的朋友可以幫忙點個贊