Go預言實現的后段狀態推送設計與實踐
【導讀】本文是一篇Go預言實現的后段狀態推送設計與實踐，寫的非常詳細，一起來學習吧！
狀態推送
前言：掃碼登錄功能自微信提出后，越來越多的被應用于各個web與app。這兩天公司要做一個掃碼登錄功能，在leader的技術支持幫助下（基本都靠leader排坑），終于將服務搭建起來，并且支持上萬并發。
長連接選擇
決定做掃碼登錄功能之后，在網上查看了很多的相關資料。對于掃碼登錄的實現方式有很多，淘寶用的是輪詢，微信用長連接，QQ用輪詢……。方式雖多，但目前看來大體分為兩種，1：輪詢，2：長連接。（兩種方式各有利弊吧，我研究不深，優缺點就不贅述了）
在和leader討論之后選擇了用長連接的方式。所以對長連接的實現方式調研了很多：
1.微信長連接：通過動態加載script的方式實現。
這種方式好在沒有跨域問題。
2.websocket長連接：在PC端與服務端搭起一條長連接后，服務端主動不斷地向PC端推送狀態。這應該是最完美的做法了。
3.我使用的長連接：PC端向服務端發送請求，服務端并不立即響應，而是hold住，等到用戶掃碼之后再響應這個請求，響應后連接斷開。
為什么不采用websocket呢？因為當時比較急、而對于websocket的使用比較陌生，所以沒有使用。不過我現在這種做法在資源使用上比websocket低很多。
接口設計
（本來想把leader畫的一副架構圖放上來，但涉及到公司，不敢）
自己畫的一副流程圖
稍微解釋一下：
第一條連接：打開PC界面的時候向服務端發送請求并建立長連接（1）。當APP成功掃碼后（2），響應這次請求（3）。
第二條連接類似。
分析得出我們的服務只需要兩個接口即可
1.與PC建立長連接的接口
2.接收APP端數據并將數據發送給前端的接口
再細想可將這兩個接口抽象為：
1.PC獲取狀態接口：get
2.APP設置狀態接口：set
具體實現
用GO寫的（不多嗶嗶）
長連接的根本原理：連接請求后，服務端利用channel阻塞住。等到channel中有value后，將value響應
Router
func Router（）{
http.HandleFunc（“/status/get”， Get）
http.HandleFunc（“/status/set”， Set）
}
GET
每一條連接需要有一個KEY作標識，不然APP設置的狀態不知道該發給那臺PC。每一條連接即一個channel
var Status map［string］（chan string） = make（map［string］（chan string））
func Get（w http.ResponseWriter， r *http.Request）{
//接收key的操作
key = //PC在請求接口時帶著的key
Status［key］ = make（chan string） //不需要緩沖區
value ：= 《-Status［key］
ResponseJson（w， 0， “success”， value） //自己封的響應JSON方法
}
SET
APP掃碼后可以得到二維碼中的KEY，同時將想給PC發送的VALUE一起發送給服務端
func Set（w http.ResponseWriter， r *http.Request）{
key =
value = //向PC傳遞的值
Status［key］ 《- value
}
這就是實現的最基本原理。
接下來我們一點點實現其他的功能。
1.超時
從網上找了很多資料，大部分都說這種方式
srv ：= &http.Server{
ReadTimeout： 5 * time.Second，
WriteTimeout： 10 * time.Second，
}
log.Println（srv.ListenAndServe（））
這種方式確實是設置讀超時與寫超時。但（親測）這種超時方式并不友善，假如現在WriteTimeout是10s，PC端請求過來之后，長連接建立。PC處于pending狀態，并且服務端被channel阻塞住。10s之后，由于超時連接失效（并沒有斷，我也不了解其中原理）。PC并不知道連接斷了，依然處于pending狀態，服務端的這個goroutine依然被阻塞在這里。這個時候我調用set接口，第一次調用沒用反應，但第二次調用PC端就能成功接收value。
從圖可以看出，我設置的WriteTimeout為10s，但這條長連接即使15s依然能收到成功響應。（ps：我調用了兩次set接口，第一次沒有反應）
研究后決定不使用這種方式設置超時，采用接口內部定時的方式實現超時返回
select {
case 《-`Timer`：
utils.ResponseJson（w， -1， “timeout”， nil）
case value ：= 《-statusChan：
utils.ResponseJson（w， 0， “success”， value）
}
Timer即為定時器。剛開始Timer是這樣定義的
Timer ：= time.After（60 * time.Second）
60s后Timer會自動返回一個值，這時上面的通道就開了，響應timeout
但這樣做有一個弊端，這個定時器一旦創建就必須等待60s，并且我沒想到辦法提前將定時器關了。如果這個長連接剛建立后5s就被響應，那么這個定時器就要多存在55s。這樣對資源是一種浪費，并不合理。
這里選用了context作為定時器
ctx， cancel ：= context.WithTimeout（context.Background（）， time.Duration（Timeout）*time.Second）
defer cancel（）
select {
case 《-ctx.Done（）：
utils.ResponseJson（w， -1， “timeout”， nil）
case result ：= 《-Status［key］：
utils.ResponseJson（w， 0， “success”， result）
}
ctx在初始化的時候就設置了超時時間time.Duration（Timeout）*time.Second
超時之后ctx.Done（）返回完成，起到定時作用。如果沒有cancel（）則會有一樣的問題。原因如下
context對比time包。提供了手動關閉定時器的方法cancel（）
只要get請求結束，都會去關閉定時器，這樣可以避免資源浪費（一定程度避免內存泄漏）。
注即使golang官方文檔中，也推薦defer cancel（）這樣寫
官方文檔也寫到：即使ctx會在到期時關閉，但在任何場景手動調用cancel都是很好的做法。
2.多機支持
服務如果只部署在一臺機器上，萬一機器跪了，那就全跪了。
所以我們的服務必須同時部署在多個機器上工作。即使其中一臺掛了，也不影響服務使用。
這個圖不會畫，只能用leader的圖了
在項目初期討論的時候leader給出了兩種方案。1.如圖使用redis做多機調度。2.使用zookeeper將消息發送給多機
因為現在是用redis做的，只講述下redis的實現。（但依賴redis并不是很好，多機的負載均衡還要依賴其他工具。zookeeper能夠解決這個問題，之后會將redis換成zookeeper）
首先我們要明確多機的難點在哪？
我們有兩個接口，get、set。get是給前端建立長連接用的。set是后端設置狀態用的。
假設有兩臺機器A、B。若前端的請求發送到A機器上，即A機器與前端連接，此時后端調用set接口，如果調用的是A機器的set接口，那是最好，長連接就能成功響應。但如果調用了B機器的set接口，B機器上又沒有這條連接，那么這條連接就無法響應。
所以難點在于如何將同一個key的get、set分配到一臺機器。
有人給我提過一個意見：在做負載均衡的時候，就將連接分配到指定機器。剛開始我覺的很有道理，但細細想，如果這樣做，在以后如果要加機器或減機器的時候會很麻煩。對橫向的增減機器不友善。
最后我還是采用了leader給出的方案：用redis綁定key與機器的關系
即前端請求到一臺機器上，以key做鍵，以機器IP做值放在redis里面。后端請求set接口時先用key去redis里面拿到機器IP，再將value發送到這臺機器上。
此時就多了一個接口，用于機器內部相互調用
ChanSet
func Router（）{
http.HandleFunc（“/status/get”， Get）
http.HandleFunc（“/status/set”， Set）
http.HandleFunc（“/channel/set”， ChanSet）
}
func ChanSet（w http.ResponseWriter， r *http.Request）{
key =
value =
Status［key］ 《- value
}
GET
func Get（w http.ResponseWriter， r *http.Request）{
IP = getLocalIp（） //得到本機IP
RedisSet（key， IP） //以key做鍵，IP做值放入redis
Status［key］ 《- value
}
SET
func Set（w http.ResponseWriter， r *http.Request）{
IP = RedisGet（key） //用key去取對應機器的IP
Post（IP， key， value） //將key與value都發送給這臺機器
}
注這里相當于用redis sentinel做多臺機器的通信。哨兵會幫我們將數據同步到所有機器上
這樣即可實現多機支持
3.跨域
剛部署到線上的時候，第一次嘗試就跪了。查看錯誤（Access-Control-Allow-Origin）
因為前端是通過AJAX請求的長連接服務，所以存在跨域問題。
在服務端設置允許跨域
func Get（w http.ResponseWriter， r *http.Request）{
w.Header（）.Set（“Access-Control-Allow-Origin”， “*”）
w.Header（）.Add（“Access-Control-Allow-Headers”， “Content-Type”）
}
若是像微信的做法，動態的加載script方式，則沒有跨域問題。
服務端直接允許跨域，可能會有安全問題，但我不是很了解，這里為了使用，就允許跨域了。
4.Map并發讀寫問題
跨域問題解決之后，線上可以正常使用了。緊接著請測試同學壓測了一下。
預期單機并發10000以上，測試同學直接壓了10000，服務掛了。
可能預期有點高，5000吧，于是壓了5000，服務掛了。
1000呢，服務掛了。
100，服務掛了。
……
這下豁然開朗，不可能是機器問題，絕對是有BUG
看了下報錯
去看了下官方文檔
Map是不能并發的寫操作，但可以并發的讀。
原來對Map操作是這樣寫的
func Get（w http.ResponseWriter， r *http.Request）{
`Status［key］ = make（chan string）`
`defer close（Status［key］）`
select {
case 《-ctx.Done（）：
utils.ResponseJson（w， -1， “timeout”， nil）
case `result ：= 《-Status［key］`：
utils.ResponseJson（w， 0， “success”， result）
}
}
func ChanSet（w http.ResponseWriter， r *http.Request）{
`Status［key］ 《- value`
}
Status［key］ = make（chan string）在Status（map）里面初始化一個通道，是map的寫操作
result ：= 《-Status［key］從Status［key］通道中讀取一個值，由于是通道，這個值取出來后，通道內就沒有了，所以這一步也是對map的寫操作
Status［key］ 《- value向Status［key］內放入一個值，map的寫操作
由于這三處操作的是一個map，所以要加同一把鎖
var Mutex sync.Mutex
func Get（w http.ResponseWriter， r *http.Request）{
//這里是同組大佬教我的寫法，通道之間的拷貝傳遞的是指針，即statusChan與Status［key］指向的是同一個通道
statusChan ：= make（chan string）
Mutex.Lock（）
Status［key］ = statusChan
Mutex.Unlock（）
//在連接結束后將這些資源都釋放
defer func（）{
Mutex.Lock（）
delete（Status， key）
Mutex.Unlock（）
close（statusChan）
RedisDel（key）
}（）
select {
case 《-ctx.Done（）：
utils.ResponseJson（w， -1， “timeout”， nil）
case result ：= 《-statusChan：
utils.ResponseJson（w， 0， “success”， result）
}
}
func ChanSet（w http.ResponseWriter， r *http.Request）{
Mutex.Lock（）
Status［key］ 《- value
Mutex.Unlock（）
}
到現在，服務就可以正常使用了，并且支持上萬并發。
5.Redis過期時間
服務正常使用之后，leader review代碼，提出redis的數據為什么不設置過期時間，反而要自己手動刪除。我一想，對啊。
于是設置了過期時間并且將RedisDel（key）刪了。
設置完之后不出意外的服務跪了。
究其原因
我用一個key=1請求get，會在redis內存儲一條數據記錄（1 =》 Ip）。如果我set了這條連接，按之前的邏輯會將redis里的這條數據刪掉，而現在是等待它過期。若是在過期時間內，再次以這個key=1，調用set接口。set接口依然會從redis中拿到IP，Post數據到ChanSet接口。而ChanSet中Status［key］ 《- value由于Status［key］是關閉的，會阻塞在這里，阻塞不要緊，但之前這里加了鎖，導致整個程序都阻塞在這里。
這里和leader討論過，仍使用redis過期時間但需要修復這個Bug
func ChanSet（w http.ResponseWriter， r *http.Request）{
Mutex.Lock（）
ch ：= Status［key］
Mutex.Unlock（）
if ch ！= nil {
ch 《- value
}
}
不過這樣有一個問題，就是同一個key，在過期時間內是無法多次使用的。不過這與業務要求并不沖突。
6.Linux文件最大句柄數
在給測試同學測試之前，自己也壓測了一下。不過剛上來就瘋狂報錯，“%￥#@￥……%……%%..too many fail open.。.”
搜索結果是linux默認最大句柄數1024.
開了下自己的機器 ulimit -a 果然1024。修改（修改方法不多BB）
7.同時監聽兩個端口
服務有兩個API，get是給前端使用的，對外開放。set是給后端使用的，內部接口。所以這兩個接口需要放在兩個端口上。
由于http.ListenAndServe（）本身有阻塞，故第一個監聽需要一個goroutine
go http.ListenAndServe（“：11000”， FrontendMux） //對外開放的端口
http.ListenAndServe（“：11001”， BackendMux） //內部使用的端口
原文標題：Golang-長連接-狀態推送
文章出處：【微信公眾號：Linux愛好者】歡迎添加關注！文章轉載請注明出處。
責任編輯：haq
-
PC
+關注
關注
9文章
2167瀏覽量
159339 -
連接
+關注
關注
2文章
101瀏覽量
21824
原文標題：Golang-長連接-狀態推送
文章出處：【微信號：LinuxHub，微信公眾號：Linux愛好者】歡迎添加關注！文章轉載請注明出處。
發布評論請先 登錄
Go 語言高并發服務設計與性能調優實戰：從萬級到百萬級并發的演進之路
蔚來世界模型NWM全新版本正式推送
低成本TLI4971/TLE4971電流傳感器評估套件——MS2Go與S2Go
探索TLE493D-P3XX-MS2GO 3D 2Go套件：開啟3D磁傳感器評估之旅
深度解析 | 低抖動高精度EtherCAT多軸控制的實現與實踐案例
電能質量在線監測裝置支持的數據推送頻率是多少？
房產數據平臺安家go獲取地區列表數據的API接口
電能質量在線監測裝置的數據推送頻率調整會影響數據的準確性嗎？
設備的狀態監測可以通過哪些方式實現？
資源狀態感知是如何實現對網絡鏈路狀態的實時感知的？
訂單實時狀態查詢接口技術實現
淘寶/天貓：使用訂單查詢API實時追蹤包裹狀態，自動推送物流通知至用戶
鋰電池制造：電芯后段處理中的除氣工藝
工商網監
評論