golang可重入鎖的實現(xiàn)

如何實現(xiàn)可重入鎖？

成都創(chuàng)新互聯(lián)長期為成百上千家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為興寧企業(yè)提供專業(yè)的網(wǎng)站設計制作、成都網(wǎng)站制作，興寧網(wǎng)站改版等技術服務。擁有10余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

實現(xiàn)一個可重入鎖需要這兩點：

1.記住持有鎖的線程

2.統(tǒng)計重入的次數(shù)

轉自golangroadmap

go語言實現(xiàn)一個簡單的簡單網(wǎng)關

網(wǎng)關=反向代理+負載均衡+各種策略，技術實現(xiàn)也有多種多樣，有基于 nginx 使用 lua 的實現(xiàn)，比如 openresty、kong；也有基于 zuul 的通用網(wǎng)關；還有就是 golang 的網(wǎng)關，比如 tyk。

這篇文章主要是講如何基于 golang 實現(xiàn)一個簡單的網(wǎng)關。

轉自： troy.wang/docs/golang/posts/golang-gateway/

整理：go語言鐘文文檔:

啟動兩個后端 web 服務（代碼）

這里使用命令行工具進行測試

具體代碼

直接使用基礎庫 httputil 提供的NewSingleHostReverseProxy即可，返回的reverseProxy對象實現(xiàn)了serveHttp方法，因此可以直接作為 handler。

具體代碼

director中定義回調(diào)函數(shù)，入?yún)?http.Request，決定如何構造向后端的請求，比如 host 是否向后傳遞，是否進行 url 重寫，對于 header 的處理，后端 target 的選擇等，都可以在這里完成。

director在這里具體做了：

modifyResponse中定義回調(diào)函數(shù)，入?yún)?http.Response，用于修改響應的信息，比如響應的 Body，響應的 Header 等信息。

最終依舊是返回一個ReverseProxy，然后將這個對象作為 handler 傳入即可。

參考 2.2 中的NewSingleHostReverseProxy，只需要實現(xiàn)一個類似的、支持多 targets 的方法即可，具體實現(xiàn)見后面。

作為一個網(wǎng)關服務，在上面 2.3 的基礎上，需要支持必要的負載均衡策略，比如：

隨便 random 一個整數(shù)作為索引，然后取對應的地址即可，實現(xiàn)比較簡單。

具體代碼

使用curIndex進行累加計數(shù)，一旦超過 rss 數(shù)組的長度，則重置。

具體代碼

輪詢帶權重，如果使用計數(shù)遞減的方式，如果權重是5,1,1那么后端 rs 依次為a,a,a,a,a,b,c,a,a,a,a…，其中 a 后端會瞬間壓力過大；參考 nginx 內(nèi)部的加權輪詢，或者應該稱之為平滑加權輪詢，思路是：

后端真實節(jié)點包含三個權重：

操作步驟：

具體代碼

一致性 hash 算法，主要是用于分布式 cache 熱點/命中問題；這里用于基于某 key 的 hash 值，路由到固定后端，但是只能是基本滿足流量綁定，一旦后端目標節(jié)點故障，會自動平移到環(huán)上最近的那么個節(jié)點。

實現(xiàn)：

具體代碼

每一種不同的負載均衡算法，只需要實現(xiàn)添加以及獲取的接口即可。

然后使用工廠方法，根據(jù)傳入的參數(shù)，決定使用哪種負載均衡策略。

具體代碼

作為網(wǎng)關，中間件必不可少，這類包括請求響應的模式，一般稱作洋蔥模式，每一層都是中間件，一層層進去，然后一層層出來。

中間件的實現(xiàn)一般有兩種，一種是使用數(shù)組，然后配合 index 計數(shù)；一種是鏈式調(diào)用。

具體代碼

Go語言設計與實現(xiàn)（上）

基本設計思路：

類型轉換、類型斷言、動態(tài)派發(fā)。iface，eface。

反射對象具有的方法：

編譯優(yōu)化：

內(nèi)部實現(xiàn)：

實現(xiàn) Context 接口有以下幾個類型（空實現(xiàn)就忽略了）：

互斥鎖的控制邏輯：

設計思路：

（以上為寫被讀阻塞，下面是讀被寫阻塞）

總結，讀寫鎖的設計還是非常巧妙的：

設計思路：

WaitGroup 有三個暴露的函數(shù):

部件：

設計思路：

結構：

Once 只暴露了一個方法：

實現(xiàn)：

三個關鍵點：

細節(jié)：

讓多協(xié)程任務的開始執(zhí)行時間可控（按順序或歸一）。（Context 是控制結束時間）

設計思路： 通過一個鎖和內(nèi)置的 notifyList 隊列實現(xiàn)，Wait() 會生成票據(jù)，并將等待協(xié)程信息加入鏈表中，等待控制協(xié)程中發(fā)送信號通知一個（Signal()）或所有（Boardcast()）等待者（內(nèi)部實現(xiàn)是通過票據(jù)通知的）來控制協(xié)程解除阻塞。

暴露四個函數(shù)：

實現(xiàn)細節(jié)：

部件：

包： golang.org/x/sync/errgroup

作用：開啟 func() error 函數(shù)簽名的協(xié)程，在同 Group 下協(xié)程并發(fā)執(zhí)行過程并收集首次 err 錯誤。通過 Context 的傳入，還可以控制在首次 err 出現(xiàn)時就終止組內(nèi)各協(xié)程。

設計思路：

結構：

暴露的方法：

實現(xiàn)細節(jié)：

注意問題：

包： "golang.org/x/sync/semaphore"

作用：排隊借資源（如錢，有借有還）的一種場景。此包相當于對底層信號量的一種暴露。

設計思路：有一定數(shù)量的資源 Weight，每一個 waiter 攜帶一個 channel 和要借的數(shù)量 n。通過隊列排隊執(zhí)行借貸。

結構：

暴露方法：

細節(jié)：

部件：

細節(jié)：

包： "golang.org/x/sync/singleflight"

作用：防擊穿。瞬時的相同請求只調(diào)用一次，response 被所有相同請求共享。

設計思路：按請求的 key 分組（一個 *call 是一個組，用 map 映射存儲組），每個組只進行一次訪問，組內(nèi)每個協(xié)程會獲得對應結果的一個拷貝。

結構：

邏輯：

細節(jié)：

部件：

如有錯誤，請批評指正。

Go語言——sync.Map詳解

sync.Map是1.9才推薦的并發(fā)安全的map，除了互斥量以外，還運用了原子操作，所以在這之前，有必要了解下 Go語言——原子操作

go1.10\src\sync\map.go

entry分為三種情況：

從read中讀取key，如果key存在就tryStore。

注意這里開始需要加鎖，因為需要操作dirty。

條目在read中，首先取消標記，然后將條目保存到dirty里。（因為標記的數(shù)據(jù)不在dirty里）

最后原子保存value到條目里面，這里注意read和dirty都有條目。

總結一下Store：

這里可以看到dirty保存了數(shù)據(jù)的修改，除非可以直接原子更新read，繼續(xù)保持read clean。

有了之前的經(jīng)驗，可以猜測下load流程：

與猜測的 區(qū)別 ：

由于數(shù)據(jù)保存兩份，所以刪除考慮：

先看第二種情況。加鎖直接刪除dirty數(shù)據(jù)。思考下貌似沒什么問題，本身就是臟數(shù)據(jù)。

第一種和第三種情況唯一的區(qū)別就是條目是否被標記。標記代表刪除，所以直接返回。否則CAS操作置為nil。這里總感覺少點什么，因為條目其實還是存在的，雖然指針nil。

看了一圈貌似沒找到標記的邏輯，因為刪除只是將他變成nil。

之前以為這個邏輯就是簡單的將為標記的條目拷貝給dirty，現(xiàn)在看來大有文章。

p == nil，說明條目已經(jīng)被delete了，CAS將他置為標記刪除。然后這個條目就不會保存在dirty里面。

這里其實就跟miss邏輯串起來了，因為miss達到閾值之后，dirty會全量變成read，也就是說標記刪除在這一步最終刪除。這個還是很巧妙的。

真正的刪除邏輯：

很繞。。。。

文章題目：go語言如何實現(xiàn)可重入鎖 go 可重入鎖
瀏覽地址：http://jinyejixie.com/article48/dosgsep.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、品牌網(wǎng)站設計、企業(yè)網(wǎng)站制作、網(wǎng)站導航、企業(yè)建站、手機網(wǎng)站建設

廣告

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