1.分布式事務(wù)

創(chuàng)新互聯(lián)公司主打移動網(wǎng)站、成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站改版、網(wǎng)絡(luò)推廣、網(wǎng)站維護(hù)、域名申請、等互聯(lián)網(wǎng)信息服務(wù)，為各行業(yè)提供服務(wù)。在技術(shù)實力的保障下，我們?yōu)榭蛻舫兄Z穩(wěn)定，放心的服務(wù)，根據(jù)網(wǎng)站的內(nèi)容與功能再決定采用什么樣的設(shè)計。最后，要實現(xiàn)符合網(wǎng)站需求的內(nèi)容、功能與設(shè)計，我們還會規(guī)劃穩(wěn)定安全的技術(shù)方案做保障。

2. 分布式鎖

Java 原生 API 雖然有并發(fā)鎖，但并沒有提供分布式鎖的能力，所以針對分布式場景中的鎖需要解決的方案。

分布式鎖的解決方案大致有以下幾種：

• 基于數(shù)據(jù)庫實現(xiàn)
• 基于緩存（redis，memcached 等）實現(xiàn)
• 基于 Zookeeper 實現(xiàn)

2.1. 基于數(shù)據(jù)庫實現(xiàn)分布式鎖

實現(xiàn)

1. 創(chuàng)建表

CREATE TABLE `methodLock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
  `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '鎖定的方法名',
  `desc` varchar(1024) NOT NULL DEFAULT '備注信息',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存數(shù)據(jù)時間，自動生成',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='鎖定中的方法';

2. 獲取鎖

想要鎖住某個方法時，執(zhí)行以下 SQL：

insert into methodLock(method_name,desc) values (‘method_name’,‘desc’)

因為我們對  method_name  做了唯一性約束，這里如果有多個請求同時提交到數(shù)據(jù)庫的話，數(shù)據(jù)庫會保證只有一個操作可以成功，那么我們就可以認(rèn)為操作成功的那個線程獲得了該方法的鎖，可以執(zhí)行方法體內(nèi)容。

成功插入則獲取鎖。

3. 釋放鎖

當(dāng)方法執(zhí)行完畢之后，想要釋放鎖的話，需要執(zhí)行以下 Sql:

delete from methodLock where method_name ='method_name'

問題

1. 這把鎖強(qiáng)依賴數(shù)據(jù)庫的可用性。如果數(shù)據(jù)庫是一個單點，一旦數(shù)據(jù)庫掛掉，會導(dǎo)致業(yè)務(wù)系統(tǒng)不可用。
2. 這把鎖沒有失效時間，一旦解鎖操作失敗，就會導(dǎo)致鎖記錄一直在數(shù)據(jù)庫中，其他線程無法再獲得到鎖。
3. 這把鎖只能是非阻塞的，因為數(shù)據(jù)的 insert 操作，一旦插入失敗就會直接報錯。沒有獲得鎖的線程并不會進(jìn)入排隊隊列，要想再次獲得鎖就要再次觸發(fā)獲得鎖操作。
4. 這把鎖是非重入的，同一個線程在沒有釋放鎖之前無法再次獲得該鎖。因為數(shù)據(jù)中數(shù)據(jù)已經(jīng)存在了。

解決辦法

1. 單點問題可以用多數(shù)據(jù)庫實例，同時塞 N 個表，N/2+1 個成功就任務(wù)鎖定成功
2. 寫一個定時任務(wù)，隔一段時間清除一次過期的數(shù)據(jù)。
3. 寫一個 while 循環(huán)，不斷的重試插入，直到成功。
4. 在數(shù)據(jù)庫表中加個字段，記錄當(dāng)前獲得鎖的機(jī)器的主機(jī)信息和線程信息，那么下次再獲取鎖的時候先查詢數(shù)據(jù)庫，如果當(dāng)前機(jī)器的主機(jī)信息和線程信息在數(shù)據(jù)庫可以查到的話，直接把鎖分配給他就可以了。

小結(jié)

• 優(yōu)點: 直接借助數(shù)據(jù)庫，容易理解。
• 缺點: 會有各種各樣的問題，在解決問題的過程中會使整個方案變得越來越復(fù)雜。操作數(shù)據(jù)庫需要一定的開銷，性能問題需要考慮。

2.2. 基于 Redis 實現(xiàn)分布式鎖

相比于用數(shù)據(jù)庫來實現(xiàn)分布式鎖，基于緩存實現(xiàn)的分布式鎖的性能會更好一些。目前有很多成熟的分布式產(chǎn)品，包括 Redis、memcache、Tair 等。這里以 Redis 舉例。

Redis 命令

• setnx - setnx key val：當(dāng)且僅當(dāng) key 不存在時，set 一個 key 為 val 的字符串，返回 1；若 key 存在，則什么都不做，返回 0。
• expire - expire key timeout：為 key 設(shè)置一個超時時間，單位為 second，超過這個時間鎖會自動釋放，避免死鎖。
• delete - delete key：刪除 key

實現(xiàn)

單點實現(xiàn)步驟：

1. 獲取鎖的使用，使用 setnx 加鎖，鎖的 value 值為一個隨機(jī)生成的 UUID，再使用 expire 設(shè)置一個過期值。
2. 獲取鎖的時候還設(shè)置一個獲取的超時時間，若超過這個時間則放棄獲取鎖。
3. 釋放鎖的時候，通過 UUID 判斷是不是該鎖，若是該鎖，則執(zhí)行 delete 進(jìn)行鎖釋放。

問題

• 單點問題。如果單機(jī) redis 掛掉了，那么程序會跟著出錯。
• 如果轉(zhuǎn)移使用 slave 節(jié)點，復(fù)制不是同步復(fù)制，會出現(xiàn)多個程序獲取鎖的情況

小結(jié)

可以考慮使用 redisson 的解決方案。

2.3. 基于 ZooKeeper 實現(xiàn)分布式鎖

實現(xiàn)

這也是 ZooKeeper 客戶端 curator 的分布式鎖實現(xiàn)。

1. 創(chuàng)建一個目錄 mylock；
2. 線程 A 想獲取鎖就在 mylock 目錄下創(chuàng)建臨時順序節(jié)點；
3. 獲取 mylock 目錄下所有的子節(jié)點，然后獲取比自己小的兄弟節(jié)點，如果不存在，則說明當(dāng)前線程順序號最小，獲得鎖；
4. 線程 B 獲取所有節(jié)點，判斷自己不是最小節(jié)點，設(shè)置監(jiān)聽比自己次小的節(jié)點；
5. 線程 A 處理完，刪除自己的節(jié)點，線程 B 監(jiān)聽到變更事件，判斷自己是不是最小的節(jié)點，如果是則獲得鎖。

小結(jié)

ZooKeeper 版本的分布式鎖問題相對比較來說少。

• 鎖的占用時間限制：redis 就有占用時間限制，而 ZooKeeper 則沒有，最主要的原因是 redis 目前沒有辦法知道已經(jīng)獲取鎖的客戶端的狀態(tài)，是已經(jīng)掛了呢還是正在執(zhí)行耗時較長的業(yè)務(wù)邏輯。而 ZooKeeper 通過臨時節(jié)點就能清晰知道，如果臨時節(jié)點存在說明還在執(zhí)行業(yè)務(wù)邏輯，如果臨時節(jié)點不存在說明已經(jīng)執(zhí)行完畢釋放鎖或者是掛了。由此看來 redis 如果能像 ZooKeeper 一樣添加一些與客戶端綁定的臨時鍵，也是一大好事。
• 是否單點故障：redis 本身有很多中玩法，如客戶端一致性 hash，服務(wù)器端 sentinel 方案或者 cluster 方案，很難做到一種分布式鎖方式能應(yīng)對所有這些方案。而 ZooKeeper 只有一種玩法，多臺機(jī)器的節(jié)點數(shù)據(jù)是一致的，沒有 redis 的那么多的麻煩因素要考慮。

總體上來說 ZooKeeper 實現(xiàn)分布式鎖更加的簡單，可靠性更高。但 ZooKeeper 因為需要頻繁的創(chuàng)建和刪除節(jié)點，性能上不如 Redis 方式。

3. 分布式 Session

在分布式場景下，一個用戶的 Session 如果只存儲在一個服務(wù)器上，那么當(dāng)負(fù)載均衡器把用戶的下一個請求轉(zhuǎn)發(fā)到另一個服務(wù)器上，該服務(wù)器沒有用戶的 Session，就可能導(dǎo)致用戶需要重新進(jìn)行登錄等操作。

分布式 Session 的幾種實現(xiàn)策略：

1. 粘性 session
2. 應(yīng)用服務(wù)器間的 session 復(fù)制共享
3. 基于 cache DB 緩存的 session 共享

3.1. Sticky Sessions

需要配置負(fù)載均衡器，使得一個用戶的所有請求都路由到一個服務(wù)器節(jié)點上，這樣就可以把用戶的 Session 存放在該服務(wù)器節(jié)點中。

缺點：當(dāng)服務(wù)器節(jié)點宕機(jī)時，將丟失該服務(wù)器節(jié)點上的所有 Session。

3.2. Session Replication

在服務(wù)器節(jié)點之間進(jìn)行 Session 同步操作，這樣的話用戶可以訪問任何一個服務(wù)器節(jié)點。

缺點：占用過多內(nèi)存；同步過程占用網(wǎng)絡(luò)帶寬以及服務(wù)器處理器時間。

3.3. Session Server

使用一個單獨的服務(wù)器存儲 Session 數(shù)據(jù)，可以存在 MySQL 數(shù)據(jù)庫上，也可以存在 Redis 或者 Memcached 這種內(nèi)存型數(shù)據(jù)庫。

缺點：需要去實現(xiàn)存取 Session 的代碼。

4. 分布式存儲

通常有兩種解決方案：

1. 數(shù)據(jù)分布：就是把數(shù)據(jù)分塊存在不同的服務(wù)器上（分庫分表）。
2. 數(shù)據(jù)復(fù)制：讓所有的服務(wù)器都有相同的數(shù)據(jù)，提供相當(dāng)?shù)姆?wù)。

5. 分布式緩存

使用緩存的好處：

• 提升數(shù)據(jù)讀取速度
• 提升系統(tǒng)擴(kuò)展能力，通過擴(kuò)展緩存，提升系統(tǒng)承載能力
• 降低存儲成本，Cache+DB 的方式可以承擔(dān)原有需要多臺 DB 才能承擔(dān)的請求量，節(jié)省機(jī)器成本

根據(jù)業(yè)務(wù)場景，通常緩存有以下幾種使用方式

• 懶漢式(讀時觸發(fā))：寫入 DB 后, 然后把相關(guān)的數(shù)據(jù)也寫入 Cache
• 饑餓式(寫時觸發(fā))：先查詢 DB 里的數(shù)據(jù), 然后把相關(guān)的數(shù)據(jù)寫入 Cache
• 定期刷新：適合周期性的跑數(shù)據(jù)的任務(wù)，或者列表型的數(shù)據(jù)，而且不要求絕對實時性

緩存分類：

• 應(yīng)用內(nèi)緩存：如：EHCache
• 分布式緩存：如：Memached、Redis

6. 分布式計算

7. 負(fù)載均衡

7.1. 算法

輪詢（Round Robin）

輪詢算法把每個請求輪流發(fā)送到每個服務(wù)器上。下圖中，一共有 6 個客戶端產(chǎn)生了 6 個請求，這 6 個請求按 (1, 2, 3, 4, 5, 6) 的順序發(fā)送。最后，(1, 3, 5) 的請求會被發(fā)送到服務(wù)器 1，(2, 4, 6) 的請求會被發(fā)送到服務(wù)器 2。

該算法比較適合每個服務(wù)器的性能差不多的場景，如果有性能存在差異的情況下，那么性能較差的服務(wù)器可能無法承擔(dān)過大的負(fù)載（下圖的 Server 2）。

加權(quán)輪詢（Weighted Round Robbin）

加權(quán)輪詢是在輪詢的基礎(chǔ)上，根據(jù)服務(wù)器的性能差異，為服務(wù)器賦予一定的權(quán)值。例如下圖中，服務(wù)器 1 被賦予的權(quán)值為 5，服務(wù)器 2 被賦予的權(quán)值為 1，那么 (1, 2, 3, 4, 5) 請求會被發(fā)送到服務(wù)器 1，(6) 請求會被發(fā)送到服務(wù)器 2。

最少連接（least Connections）

由于每個請求的連接時間不一樣，使用輪詢或者加權(quán)輪詢算法的話，可能會讓一臺服務(wù)器當(dāng)前連接數(shù)過大，而另一臺服務(wù)器的連接過小，造成負(fù)載不均衡。例如下圖中，(1, 3, 5) 請求會被發(fā)送到服務(wù)器 1，但是 (1, 3) 很快就斷開連接，此時只有 (5) 請求連接服務(wù)器 1；(2, 4, 6) 請求被發(fā)送到服務(wù)器 2，只有 (2) 的連接斷開。該系統(tǒng)繼續(xù)運行時，服務(wù)器 2 會承擔(dān)過大的負(fù)載。

最少連接算法就是將請求發(fā)送給當(dāng)前最少連接數(shù)的服務(wù)器上。例如下圖中，服務(wù)器 1 當(dāng)前連接數(shù)最小，那么新到來的請求 6 就會被發(fā)送到服務(wù)器 1 上。

加權(quán)最少連接（Weighted Least Connection）

在最少連接的基礎(chǔ)上，根據(jù)服務(wù)器的性能為每臺服務(wù)器分配權(quán)重，再根據(jù)權(quán)重計算出每臺服務(wù)器能處理的連接數(shù)。

隨機(jī)算法（Random）

把請求隨機(jī)發(fā)送到服務(wù)器上。和輪詢算法類似，該算法比較適合服務(wù)器性能差不多的場景。

源地址哈希法 (IP Hash)

源地址哈希通過對客戶端 IP 哈希計算得到的一個數(shù)值，用該數(shù)值對服務(wù)器數(shù)量進(jìn)行取模運算，取模結(jié)果便是目標(biāo)服務(wù)器的序號。

• 優(yōu)點：保證同一 IP 的客戶端都會被 hash 到同一臺服務(wù)器上。
• 缺點：不利于集群擴(kuò)展，后臺服務(wù)器數(shù)量變更都會影響 hash 結(jié)果。可以采用一致性 Hash 改進(jìn)。

7.2. 實現(xiàn)

HTTP 重定向

HTTP 重定向負(fù)載均衡服務(wù)器收到 HTTP 請求之后會返回服務(wù)器的地址，并將該地址寫入 HTTP 重定向響應(yīng)中返回給瀏覽器，瀏覽器收到后需要再次發(fā)送請求。

缺點：

• 用戶訪問的延遲會增加；
• 如果負(fù)載均衡器宕機(jī)，就無法訪問該站點。

DNS 重定向

使用 DNS 作為負(fù)載均衡器，根據(jù)負(fù)載情況返回不同服務(wù)器的 IP 地址。大型網(wǎng)站基本使用了這種方式做為第一級負(fù)載均衡手段，然后在內(nèi)部使用其它方式做第二級負(fù)載均衡。

缺點：

• DNS 查找表可能會被客戶端緩存起來，那么之后的所有請求都會被重定向到同一個服務(wù)器。

修改 MAC 地址

使用 LVS（Linux Virtual Server）這種鏈路層負(fù)載均衡器，根據(jù)負(fù)載情況修改請求的 MAC 地址。

修改 IP 地址

在網(wǎng)絡(luò)層修改請求的目的 IP 地址。

代理自動配置

正向代理與反向代理的區(qū)別：

• 正向代理：發(fā)生在客戶端，是由用戶主動發(fā)起的。比如外網(wǎng)，客戶端通過主動訪問代理服務(wù)器，讓代理服務(wù)器獲得需要的外網(wǎng)數(shù)據(jù)，然后轉(zhuǎn)發(fā)回客戶端。
• 反向代理：發(fā)生在服務(wù)器端，用戶不知道代理的存在。

PAC 服務(wù)器是用來判斷一個請求是否要經(jīng)過代理。

分享標(biāo)題：T5大牛帶你解析：如何實現(xiàn)分布式技術(shù)
本文網(wǎng)址：http://www.chinadenli.net/article34/pecepe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、關(guān)鍵詞優(yōu)化、靜態(tài)網(wǎng)站、標(biāo)簽優(yōu)化、響應(yīng)式網(wǎng)站、Google

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)