摘要:在用自定義網(wǎng)絡(luò)跑容器的時候發(fā)現(xiàn)一個問題的自定義網(wǎng)絡(luò)啟動會延遲大概秒換句話說就是如果你使用自定義網(wǎng)絡(luò)在一個容器啟動時想訪問另外一個容器會失敗但是如果你先等待秒再訪問的話就一切正常如果你使用自定義網(wǎng)絡(luò)在一個容器啟動時另外一個容器會卡住一段時間。
Docker Issue Network Delay
在用自定義Docker網(wǎng)絡(luò)跑容器的時候發(fā)現(xiàn)一個問題:Docker的自定義網(wǎng)絡(luò)啟動會延遲大概40秒!
換句話說就是:
如果你使用自定義網(wǎng)絡(luò)在一個容器啟動時想訪問另外一個容器會失敗!但是如果你先等待40秒再訪問的話就一切正常!
如果你使用自定義網(wǎng)絡(luò)在一個容器啟動時ping另外一個容器會卡住一段時間。
解決:加上啟動腳本檢測網(wǎng)絡(luò)是否就緒!
可以用類似下面的腳本檢測服務(wù)是否就緒,或者干脆檢查dmesg消息也可以
until nc -z zk 2181; do echo "waiting for zk to be ready"; sleep 0.5; done現(xiàn)象
在用自定義Docker網(wǎng)絡(luò)跑Kafka的時候發(fā)現(xiàn)一個現(xiàn)象:zk服務(wù)正常,但是 Kafka始終報告連接不上zk
$ docker run --net=br --ip=192.168.33.88 --name=zk -h=zk -d wurstmeister/zookeeper $ docker run --net=br --ip=192.168.33.91 --name=kf1 -h=kf1 -e KAFKA_ZOOKEEPER_CONNECT=zk -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kf1:9092 -e KAFKA_BROKER_ID=1 --link zk:zk -it wurstmeister/kafka
運(yùn)行后始終報錯:
java.net.NoRouteToHostException: No route to host at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1141)
而如果你不用自定義網(wǎng)絡(luò)的話則一切正常!
$ docker run --name=zk -h=zk -d wurstmeister/zookeeper $ docker run --name=kf1 -h=kf1 -e KAFKA_ZOOKEEPER_CONNECT=zk -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kf1:9092 -e KAFKA_BROKER_ID=1 --link zk:zk -it wurstmeister/kafka分析
那么問題在哪里呢?經(jīng)過跟蹤后終于發(fā)現(xiàn)問題在于Docker的自定義網(wǎng)絡(luò)啟動會延遲大概40秒!需要等容器實(shí)例dmesg中出現(xiàn)下列消息的時才能正常訪問網(wǎng)絡(luò)中的其他容器實(shí)例,這個等待時間大概是40秒
[ 1077.847733] docker1: topology change detected, propagating解決
問題找到了,搜索了一圈也沒有找到怎么讓這個延遲時間消失的解決方法,好吧,用土辦法:既然是因?yàn)榫W(wǎng)絡(luò)還沒準(zhǔn)備好,那就等它準(zhǔn)備好!
可以用類似下面的腳本檢測服務(wù)是否就緒,或者干脆檢查dmesg消息也可以
until nc -z zk 2181; do echo "waiting for zk to be ready"; sleep 0.5; done
那么只要在Docker容器真正開始運(yùn)行之前先運(yùn)行上面的腳本檢測網(wǎng)絡(luò)是否就緒就可以了,查了一下wurstmeister/zookeeper正好有一個CUSTOM_INIT_SCRIPT參數(shù)可以干這個事,妥了!
$ docker run --net=br --ip=192.168.33.88 --name=zk -h=zk -d wurstmeister/zookeeper $ docker run --net=br --ip=192.168.33.91 --name=kf1 -h=kf1 -e KAFKA_ZOOKEEPER_CONNECT=zk -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kf1:9092 -e KAFKA_BROKER_ID=1 -e CUSTOM_INIT_SCRIPT="until nc -z zk 2181; do echo "waiting for zk to be ready"; sleep 1; done" --link zk:zk -it wurstmeister/kafka
waiting for kafka to be ready waiting for zk service ready ...... [2017-12-11 09:04:51,046] INFO [Partition user_events-0 broker=1] No checkpointed highwatermark is found for partition user_events-0 (kafka.cluster.Partition) [2017-12-11 09:04:51,047] INFO Replica loaded for partition user_events-0 with initial high watermark 0 (kafka.cluster.Replica) [2017-12-11 09:04:51,050] INFO [Partition user_events-0 broker=1] user_events-0 starts at Leader Epoch 0 from offset 0. Previous Leader Epoch was: -1 (kafka.cluster.Partition) [2017-12-11 09:04:51,087] INFO [ReplicaFetcherManager on broker 1] Removed fetcher for partitions user_events-0 (kafka.server.ReplicaFetcherManager) [2017-12-11 09:04:51,087] INFO [Partition user_events-0 broker=1] user_events-0 starts at Leader Epoch 1 from offset 0. Previous Leader Epoch was: 0 (kafka.cluster.Partition)
另外:
這個方法也適用于啟動時需要依賴其他服務(wù)就緒的情況,比如等待數(shù)據(jù)庫就緒等
或者某些容器服務(wù)初始化時間較長,另外的容器需要等它就緒等
https://github.com/SixQuant/e...
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/27164.html
摘要:百度搜索資源平臺有閃電算法的支持,為了能夠保障用戶體驗(yàn),給予優(yōu)秀站點(diǎn)更多面向用戶的機(jī)會,閃電算法在年月初上線。下欄是每一個指標(biāo)的細(xì)化性能評估。最后優(yōu)化之路漫漫,永無止境,天下武功,唯快不破。 showImg(https://segmentfault.com/img/remote/1460000018537491); 首屏作為直面用戶的第一屏,其重要性不言而喻,如何加快加載的速度是非常重...
摘要:然而實(shí)際業(yè)務(wù)中還存在另外一種定時任務(wù),它可能需要一些觸發(fā)條件才開始定時,比如編寫博文時候,設(shè)置小時之后發(fā)送。在消息監(jiān)聽類中,對通道定義了,這里會對延遲消息做具體的邏輯。由于消息的消費(fèi)是延遲的,從而變相實(shí)現(xiàn)了從消息發(fā)送那一刻起開始的定時任務(wù)。 應(yīng)用場景 我們在使用一些開源調(diào)度系統(tǒng)(比如:elastic-job等)的時候,對于任務(wù)的執(zhí)行時間通常都是有規(guī)律性的,可能是每隔半小時執(zhí)行一次,或者...
閱讀 2341·2021-11-22 14:56
閱讀 1482·2021-09-24 09:47
閱讀 915·2019-08-26 18:37
閱讀 2832·2019-08-26 12:10
閱讀 1531·2019-08-26 11:55
閱讀 3151·2019-08-23 18:07
閱讀 2308·2019-08-23 14:08
閱讀 614·2019-08-23 12:12