如何保證訊息佇列的高可用？
圍繞著mq進行面試，肯定會聊到高可用相關的話題，因為引入了mq中介軟體導致了系統的可用性降低。mq所帶來的一些坑，在實際專案中是如何解決的。
如果回答只是單純的在mq，並沒有考慮過各種有可能出現的問題，那面試的印象分就會迅速降低。
是讓你結合專案說一說在實際的生產環境中如何實現mq的高可用性。
kafka的乙個最基本的架構認知：kafka由躲個broker組成，每個broker就是乙個節點，當建立乙個topic的時候，會劃分為多個partition，每個partition可以存在於不同的broker上，每個partition存放一部分資料。
這就是天然的分布式系統，乙個topic的資料會分散在不同的機器上面。與此相比，rabbitmq之類並不是真正意義上的分布式系統，因為沒有做到訊息分片，每台機器上都存放著完整的資料，只是提供了一些高可用的機制。
kafka從0.8版本之後，提供了ha機制，就是replica機制。每個partition的資料都會同步到其他機器上，形成多個replica副本。所有的replica會投票選舉出來乙個leader，其他節點都會跟這台leader打交道，進行資料的同步，所有的讀寫請求也是走leader。
這個會引申出乙個問題為什麼讀寫請求只走leader？因為如果可以隨意訪問follower，就要處理一致性問題，系統的複雜性將會成倍增長，因此follower只參與到備份操作。
這樣一來，就實現了所謂的高可用性，如果某台leader宕機了，就會從副本當中選舉乙個出來，其他節點繼續跟這個新的leader節點進行同步，此時集群仍是可用的。
寫資料的時候，生產者將資料傳送給leader節點，leader節點將資料落地到磁碟，接著其他的follwer主動從leader節點中pull資料到自己本地，並傳送ack給leader節點。當所有的follower節點都將資料同步完成好之後，leader節點才返回給生產者成功的訊息（這是一種策略）。
讀資料的時候，只會從leader上面去讀，但是只有所有的follower節點同步操作完成之後，這個時候資料才會被讀到。
如何保證訊息佇列的高可用
1 面試題 如何保證訊息佇列的高可用啊？2 面試官心理分析 如果有人問到你mq的知識，高可用是必問的，因為mq的缺點，我剛才已經說過了，有好多，導致系統可用性降低，等等。所以只要你用了mq，接下來問的一些要點肯定就是圍繞著mq的那些缺點怎麼來解決了。要是你傻乎乎的就乾用了乙個mq，各種問題從來沒考慮...
如何保證訊息佇列的高可用
rabbitmq有三種模式 單機模式，普通集群模式，映象集群模式 單機模式就是在本地啟動自己玩，是demo級別的，在生產環境不會使用！普通集群模式 就是在多台機器上啟動多個rabbitmq例項，當建立乙個queue的時候，只會放在乙個例項上，但是每乙個例項都會同步queue的元資料，當進行消費的時候...
如何保證訊息佇列的高可用啊？
1 面試題 如何保證訊息佇列的高可用啊？2 面試官心理分析 如果有人問到你mq的知識，高可用是必問的，因為 mq的缺點，我剛才已經說過了，有好多，導致系統可用性降低，等等。所以只要你用了 mq，接下來問的一些要點肯定就是圍繞著 mq的那些缺點怎麼來解決了。要是你傻乎乎的就乾用了乙個mq，各種問題從來...