雖然出現報錯資訊,但是,整個程式並沒有出錯。至於原因,上的文字已經很好的解釋了。
在此,再簡單的說一下。
出現這種情況的原因是,我們的程式已經啟動(已經出現紅框中此條日誌,代表程式已經啟動,所以程式本身沒有問題。),為什麼會出現錯誤呢?
是因為在此系統中,我們要搭建的是集群環境, 每一台伺服器在自己啟動之後,都要去連線集群中的其他伺服器,以便於相互之間通訊傳遞資訊。
但是,我們肯定是按照次序啟動伺服器,我們不管先啟動哪一台伺服器,其他的伺服器都還沒有準備就緒,所以肯定會出現找不到要連線的伺服器,所以會報錯。
這個錯誤根本不需要解決, 把所有的伺服器全部啟動,整個集群就可以正常執行(因為出現的是連線錯誤,現在所有的伺服器已經準備就緒,所以不會再一次出現連線錯誤,除非某台伺服器down掉。)
ps:這裡有必要提醒一下,在微服務一書中使用的properties檔案配置,而啟動的是把服務都打包成jar來啟動的,不是用idea,請讀者留意
127.0
.
0.1
peer1
127.0
.
0.1
peer2
ps:官方文件中說到這個配置在生產環境當中(線上伺服器開發)沒有太大作用,這裡僅供本地使用
至此,在本機配置的eureka的集群完成
二、實現eureka高可用集群的優缺點
優點:也即是我們實現的目的,先來看(借用)下圖:
在實際開發中,註冊中心是存在多個節點。但從上面的例子當中,我們可以知道:
eureka server的同步遵循著乙個非常簡單的原則:只要有一條邊將節點連線,就可以進行資訊傳播與同步。
所以,如果存在多個節點,我們只需要將節點之間兩兩連線起來,形成通路,那麼他們之間的所有服務都可以共享。
而我們的服務只需要向集群中的任意乙個註冊中心中註冊,即可被所有註冊中心所共享,任意乙個註冊中心崩潰,都不會影響這個服務被呼叫。
缺點:不過這裡的缺點就是,如果peer1被關閉了,雖然peer2可以訪問到peer1上的服務,但是卻是不能實時監控的,因為這個不是向peer2中註冊的服務,所以當服務down之後,peer2中仍然會認為是up的。
HBase集群調優
2.5.2.1.zookeeper.session.timeout 這個預設值是3分鐘。這意味著一旦乙個server宕掉了,master至少需要3分鐘才能察覺到宕機,開始恢復。你可能希望將這個超時調短,這樣master就能更快的察覺到了。在你調這個值之前,你需要確認你的jvm的gc引數,否則乙個長時...
Kafka 集群調優
kafka 集群搭建鏈結 單個 kafka伺服器足以滿足本地開發或 poc要求,使用集群的最大好處是可以跨伺服器進行負載均衡,再則就是可以使用複製功能來避免因單點故障造成的資料丟失。在維護 kafka 或底層系統時,使用集群可以確保為客戶端提供高可用性。乙個 kafka 需要多少個 broker取決...
Mysql集群與調優
mysql集群與調優 實驗背景 1 安裝mysql cluster相關軟體包。2 依次配置管理 資料 sql節點。3 啟動並測試mysql cluster集群架構。實驗方案 使用6臺rhel 6.4虛擬機器,其中sqla和sqlb作為sql節點,ndba和ndbb作為資料節點,mgmd作為管理節點,...