直播源碼開發(fā)使用的分布式架構(gòu)在使用前需要先了解其相關(guān)的服務(wù)業(yè)務(wù)，分布式業(yè)務(wù)的基礎(chǔ)在于原子性、一致性、隔離性、持久性四點(diǎn)，特征的強(qiáng)調(diào)主要是因?yàn)樗鼈冊(cè)谥辈ピ创a開發(fā)處理請(qǐng)求時(shí)發(fā)揮了重要作用，不過(guò)分布式業(yè)務(wù)也有它自己的缺點(diǎn)存在，我們先來(lái)看看分布式業(yè)務(wù)相關(guān)的內(nèi)容，再了解下分布式鎖有何用處。

?

一、分布式業(yè)務(wù)實(shí)際應(yīng)用方案

1、首先是提交階段，從準(zhǔn)備開始，直播源碼開發(fā)先執(zhí)行事務(wù)操作，然后返回執(zhí)行結(jié)果給協(xié)調(diào)者，到提交階段后，協(xié)調(diào)者會(huì)根據(jù)參與者執(zhí)行的結(jié)果通知參與者進(jìn)行提交或回滾

缺點(diǎn)：這種方式的最大缺點(diǎn)在于參與者都處于阻塞狀態(tài)，需要等前面的請(qǐng)求響應(yīng)完才行；由于是單點(diǎn)操作，如果存在某個(gè)環(huán)節(jié)出現(xiàn)故障，那會(huì)阻塞所有請(qǐng)求；一個(gè)節(jié)點(diǎn)失敗整個(gè)事務(wù)都會(huì)失敗，風(fēng)險(xiǎn)大

2、本地消息表階段，直播源碼開發(fā)的節(jié)點(diǎn)完成操作后會(huì)發(fā)送消息到本地消息表，本地消息表將信息轉(zhuǎn)發(fā)到Kafka等消息隊(duì)列中，等待被讀取，還可以直接從其他節(jié)點(diǎn)讀取消息并執(zhí)行操作

優(yōu)點(diǎn)：因?yàn)楸苊饬酥辈ピ创a開發(fā)的分布式事務(wù)，能夠?qū)崿F(xiàn)一致性

缺點(diǎn)：需要異步操作

?

二、分布式鎖

分布式鎖屬于跨進(jìn)程節(jié)點(diǎn)的一種互斥鎖，保護(hù)節(jié)點(diǎn)對(duì)共享資源的使用權(quán)，因?yàn)槭枪蚕碣Y源，每個(gè)節(jié)點(diǎn)都有訪問的權(quán)利，但兩個(gè)節(jié)點(diǎn)同時(shí)訪問會(huì)造成資源不夠的情況，為了避免影響到請(qǐng)求響應(yīng)，直播源碼開發(fā)會(huì)強(qiáng)制一個(gè)節(jié)點(diǎn)使用完資源后，其他節(jié)點(diǎn)才可以再使用。

分布式鎖的特點(diǎn)：

1、排他性，同一時(shí)刻下，直播源碼開發(fā)只能有一個(gè)節(jié)點(diǎn)訪問共享資源

2、可重入性，允許當(dāng)前沒有釋放資源的節(jié)點(diǎn)再次請(qǐng)求連續(xù)使用資源

3、給資源設(shè)置訪問時(shí)間，到時(shí)間沒有再請(qǐng)求自動(dòng)釋放資源，避免直播源碼開發(fā)出現(xiàn)死鎖現(xiàn)象

?

三、分布式鎖的實(shí)現(xiàn)形式

我們說(shuō)個(gè)最常見的，redis。

Redis滿足直播源碼開發(fā)對(duì)分布式鎖的所有要求，但是它容易出現(xiàn)多個(gè)進(jìn)程搶占同一個(gè)鎖資源的情況，所以也不是萬(wàn)能的，需要用官方的解決方案解決。

聲明：以上內(nèi)容為云豹科技作者本人原創(chuàng)，未經(jīng)作者本人同意，禁止轉(zhuǎn)載，否則將追究相關(guān)法律責(zé)任