資訊專欄INFORMATION COLUMN
摘要：?jiǎn)栴}問(wèn)題簡(jiǎn)述如下圖后端寫入的日志丟失并且無(wú)報(bào)錯(cuò)因?yàn)椴恢С謺r(shí)序圖把時(shí)序圖代碼嵌入在代碼里問(wèn)題定位過(guò)程為什么卡在看狀態(tài)轉(zhuǎn)換圖可以看到收到了一直沒(méi)有一直卡在和實(shí)際的代碼是吻合的那么為什么在引發(fā)后發(fā)消息仍然不報(bào)錯(cuò)呢因?yàn)閰f(xié)議允許在收到后繼續(xù)
問(wèn)題 問(wèn)題簡(jiǎn)述
如下圖. server docker restart后, client端寫入的日志丟失, 并且無(wú)報(bào)錯(cuò).
因?yàn)椴恢С謺r(shí)序圖, 把時(shí)序圖代碼嵌入在代碼里.
?```sequence client->server: log_data client->server: log_data server->server: docker restart server->client: fin client->server: log_data loss without error ?```tcp state diagram 問(wèn)題定位過(guò)程 為什么卡在CLOSE_WAIT.
看tcp狀態(tài)轉(zhuǎn)換圖, 可以看到client收到了fin, 一直沒(méi)有recv, 一直卡在CLOSE_WAIT. 和實(shí)際的代碼是吻合的.
那么, 為什么在server docker restart 引發(fā)CLOSE_WAIT后, client發(fā)消息仍然不報(bào)錯(cuò)呢?
因?yàn)?
tcp協(xié)議允許client在收到fin后, 繼續(xù)發(fā)送消息.
server 在docker restart后 ip 改變, client還是往原來(lái)的ip發(fā)送消息, 沒(méi)有主機(jī)通知client rst, 導(dǎo)致消息在系統(tǒng)buffer里積壓.
積壓信息如下:
root@9eeaefa7fe57:/# netstat -nap | grep 27017 | grep 10.0.0 tcp 1 402 10.0.0.186:62281 10.0.0.16:27017 CLOSE_WAIT 4308/server root@9eeaefa7fe57:/# netstat -nap | grep 27017 | grep 10.0.0 tcp 1 70125 10.0.0.186:62281 10.0.0.16:27017 CLOSE_WAIT 4308/server
此時(shí), 在elixir socket接口層面來(lái)看, 不管socket的狀態(tài), 還是發(fā)送, 都是ok的.
iex(client@client.)25> socket |> :inet.port
{:ok, 57395}
iex(client@client.)26> socket |> :gen_tcp.send("aaa")
:ok
如果主動(dòng)close, 則會(huì)進(jìn)入LAST_ACK狀態(tài)
iex(client@client.)27> socket |> :gen_tcp.close() :ok
root@9eeaefa7fe57:/# netstat -nap | grep 27017 | grep 10.0.0 tcp 1 70126 10.0.0.186:62281 10.0.0.16:27017 LAST_ACK -CLOSE_WAIT的恢復(fù)
如果代碼還是只發(fā)不收. 是檢測(cè)不到CLOSE_WAIT的. 顯然, 應(yīng)用層心跳是一個(gè)解決方案. 那么, 不使用心跳, 只發(fā)不收的情況下, 什么時(shí)候才能檢測(cè)到錯(cuò)誤呢?
send buffer 滿
tcp keepalive, 默認(rèn)情況下需要2小時(shí)才能檢測(cè)到連接錯(cuò)誤. 見(jiàn)linux keepalive探測(cè)對(duì)應(yīng)用層socket api的影響
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/27697.html
摘要：由于沒(méi)有了中心化的負(fù)載均衡器，集群不會(huì)因某臺(tái)機(jī)器異常而導(dǎo)致整個(gè)服務(wù)對(duì)外不可用，很好的避免了單點(diǎn)問(wèn)題，同時(shí)也帶了可擴(kuò)展性。 Mesos/Marathon 折騰久了，我們一直希望有機(jī)會(huì)深入到 Swarm 內(nèi)部一探究竟。 另外， Mesos 這一套東西雖然是久經(jīng)企業(yè)級(jí)考驗(yàn)的， 但是安裝、部署和使用相對(duì)復(fù)雜，上手有門檻。同時(shí)，在今年的 DockerCon 上，內(nèi)置了Swarm 功能的 Dock...
摘要：在之前公眾號(hào)的數(shù)人云工程師手記基于的集群管理開(kāi)發(fā)實(shí)踐對(duì)的服務(wù)發(fā)現(xiàn)及負(fù)載均衡有詳細(xì)的介紹。服務(wù)名稱為服務(wù)命名，必須為英文或數(shù)字。 本文是數(shù)人云9月22日線上微信群分享的文章實(shí)錄。數(shù)人云容器管理面板Crane開(kāi)源以來(lái)，很多小伙伴對(duì)它還不是非常了解，數(shù)人云工程師金鑫從Crane技術(shù)背景、環(huán)境準(zhǔn)備和使用步驟等方面為大家做了詳細(xì)的介紹，并整理大家常見(jiàn)的問(wèn)題逐一進(jìn)行了解答。 引言 Docker1....
摘要：應(yīng)該如何解決本文將給出若干提示，如何在生產(chǎn)環(huán)境中使用。路由匹配服務(wù)發(fā)現(xiàn)負(fù)載均衡跨容器通訊非?？煽?。在單個(gè)端口上運(yùn)行一個(gè)服務(wù)，節(jié)點(diǎn)的任意主機(jī)都可以訪問(wèn)，負(fù)載均衡完全在后臺(tái)實(shí)現(xiàn)。 上周數(shù)人云給大家分享了——《你可能需要的關(guān)于Docker Swarm的經(jīng)驗(yàn)分享》今天給大家?guī)?lái)這位作者大大的后續(xù)文章——《Docker Swarm在生產(chǎn)環(huán)境中的進(jìn)階指南》 當(dāng)在本地開(kāi)發(fā)環(huán)境中使用Docker，或者...
摘要：一個(gè)容器起來(lái)，能夠?qū)ν夥?wù)，這時(shí)就看下一步的負(fù)載均衡服務(wù)發(fā)現(xiàn)以及編排。它們有不同的應(yīng)用場(chǎng)景，比如傾向于四層的負(fù)載均衡。不單是負(fù)載均衡，它同時(shí)解決了服務(wù)發(fā)現(xiàn)和負(fù)載均衡兩個(gè)點(diǎn)。 今天是數(shù)人云容器三國(guó)演義Meetup嘉賓演講實(shí)錄第二彈。數(shù)人云工程師春明為大家奉送了一盤干貨的大餐，讓我們讀讀源碼，深入了解一下SwarmKit的世界吧！ 小數(shù)前方預(yù)警：有大量代碼出現(xiàn)！ showImg(htt...
摘要：當(dāng)然此時(shí)的局限性較大，比如沒(méi)有副本和負(fù)載均衡的概念，這導(dǎo)致服務(wù)無(wú)法高可用當(dāng)然也更不存在什么服務(wù)網(wǎng)絡(luò)管理和跨節(jié)點(diǎn)數(shù)據(jù)存儲(chǔ)這些東西沒(méi)有服務(wù)模型集群中服務(wù)間關(guān)系和啟動(dòng)順序編排也很復(fù)雜于是就有了下面的的誕生。 showImg(https://segmentfault.com/img/remote/1460000015317037?w=1885&h=1153); 概述 在我的《Docker S...
閱讀 2531·2021-09-24 10:29
閱讀 3813·2021-09-22 15:46
閱讀 2581·2021-09-04 16:41
閱讀 2986·2019-08-30 15:53
閱讀 1267·2019-08-30 14:24
閱讀 3061·2019-08-30 13:19
閱讀 2177·2019-08-29 14:17
閱讀 3527·2019-08-29 12:55
