如果是集群的話，我考慮需要流暢運行的話，2核4G配置是可以滿足的。因為這個集群形式，用于適用于物聯(lián)網(wǎng)、車聯(lián)網(wǎng)、監(jiān)控、安全風(fēng)控、即時通訊、消息存儲等行業(yè)場景，所以數(shù)據(jù)量是比較大的，所以配置太低了跑不動，會卡死的。
奎屯網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站等網(wǎng)站項目制作，到程序開發(fā)，運營維護(hù)。創(chuàng)新互聯(lián)公司2013年開創(chuàng)至今到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)公司。
因為hadoop是海量數(shù)據(jù)的處理能力，所以服務(wù)器一定不能太小配置了，跑不動了就沒實際用途了。最好使用4核8G內(nèi)存及以上配置。
因為這方面內(nèi)容較多，這里也寫不開那么多內(nèi)容，所以你可以留言或到我的博客上搜索相關(guān)內(nèi)容，老魏有寫過教程，還不止一篇，都挺詳細(xì)的內(nèi)容，可以幫助你入門。
本文將以阿里云在GIAC的分享《云原生InfluxDB高可用架構(gòu)設(shè)計》為例，剖析阿里云的自研InfluxDB集群方案的當(dāng)前實現(xiàn)，在分析中會盡量聚焦的相對確定的技術(shù)、架構(gòu)等，考慮到非一線信息，在個別細(xì)節(jié)上難免存在理解偏差，歡迎私聊討論:
0x0 初步結(jié)論
目前是一個過渡性質(zhì)的公測方案，具備數(shù)據(jù)一致性，但接入性能有限，缺乏水平擴(kuò)展能力。缺乏自定義副本數(shù)和水平擴(kuò)展等能力，通過Raft或Anti-entroy提升了數(shù)據(jù)的可靠性，但受限于節(jié)點和副本的強(qiáng)映射，集群接入性能有限，約等同于單機(jī)接入性能，另外，基于時序分片和分布式迭代器等核心功能未提及，可能仍在預(yù)研中。
0x1 集群方案剖析
1. 背景補(bǔ)充：InfluxDB是DB-Engines上排名第一的TSDB，針對時序數(shù)據(jù)多寫、少讀、成本敏感等特點而設(shè)計的TSDB，并做了多輪架構(gòu)迭代和優(yōu)化，是一款實時、高性能、水平擴(kuò)展（InfluxDB Enterprise）、具有成本優(yōu)勢的TSDB。但在2016年，Paul Dix基于商業(yè)化和持久運營的考慮，尚未成熟的集群能力在v0.11.1版后，選擇閉源，推出了收費版的InfluxDB Enterprise和InfluxDB Cloud。
2. 通過Raft協(xié)議實現(xiàn)Meta節(jié)點的數(shù)據(jù)一致性，考慮到Meta節(jié)點存放的是Database/Rention Policy/Shard Group/Shard Info等元信息，這些信息敏感，是系統(tǒng)穩(wěn)定運行的的關(guān)鍵，CP的分布式架構(gòu)，合適。
3. 通過Raft協(xié)議實現(xiàn)Data節(jié)點的數(shù)據(jù)一致性，考慮到Data節(jié)點存儲的是具體的時序數(shù)據(jù)，性能和水平擴(kuò)展性是挑戰(zhàn)，對一致性性要求不高（PPT中亦提到這一點），采用CP的分布式架構(gòu)，節(jié)點和副本強(qiáng)映射，不僅對實時性有影響，集群接入性能亦有限，約等同于單機(jī)接入性能，不能很好的支持海量數(shù)據(jù)的實時接入的時序需求。
4. 2節(jié)點集群方案，通過Anti-entroy實現(xiàn)Data節(jié)點的數(shù)據(jù)一致性，應(yīng)該還實現(xiàn)了Hinted-handoff能力，AP的分布式架構(gòu)，但節(jié)點和副本還是強(qiáng)映射，未見提及基于時序分配、自定義副本數(shù)、分布式迭代器等能力，暫無法水平擴(kuò)展。
5. 云盤能保障數(shù)據(jù)的可靠性，但無法保障接入的可用性，可用性敏感的業(yè)務(wù)或?qū)崟r要求高的業(yè)務(wù)，還是推薦多節(jié)點的集群模式。
6. 開源版InfluxDB（單機(jī)）性能不錯，InfluxDB Enterprise性能不錯，但如何保障補(bǔ)齊集群能力的卓越性能，取決于集群架構(gòu)、并發(fā)架構(gòu)等，是由集群功能的開發(fā)者決定的，這次未見提及性能數(shù)據(jù)，期待后續(xù)的公布。
0x2 附錄
如果RabbitMQ集群只有一個broker節(jié)點，那么該節(jié)點的失效將導(dǎo)致整個服務(wù)臨時性的不可用，并且可能會導(dǎo)致message的丟失（尤其是在非持久化message存儲于非持久化queue中的時候）。可以將所有message都設(shè)置為持久化，并且使用持久化的queue，但是這樣仍然無法避免由于緩存導(dǎo)致的問題：因為message在發(fā)送之后和被寫入磁盤并執(zhí)行fsync之間存在一個雖然短暫但是會產(chǎn)生問題的時間窗。通過publisher的confirm機(jī)制能夠確?？蛻舳酥滥男﹎essage已經(jīng)存入磁盤，盡管如此，一般不希望遇到因單點故障導(dǎo)致服務(wù)不可用。
如果RabbitMQ集群是由多個broker節(jié)點構(gòu)成的，那么從服務(wù)的整體可用性上來講，該集群對于單點失效是有彈性的，但是同時也需要注意：盡管exchange和binding能夠在單點失效問題上幸免于難，但是queue和其上持有的message卻不行，這是因為queue及其內(nèi)容僅僅存儲于單個節(jié)點之上，所以一個節(jié)點的失效表現(xiàn)為其對應(yīng)的queue不可用。
為了提高程序的吞吐量，保持消息的可靠性，一臺機(jī)器掛了后，RabbitMQ能夠正常生產(chǎn)，消費消息。
rabbitmq有三種模式：單機(jī)模式，普通集群模式，鏡像集群模式
Demo級別的，一般只是本機(jī)測試玩玩而已，生產(chǎn)環(huán)境下不會用的。
在多臺機(jī)器上啟動多個rabbitmq實例，每個機(jī)器啟動一個。
但是你創(chuàng)建的queue，只會放在一個rabbtimq實例上，但是每個實例都同步queue的元數(shù)據(jù)(存放含queue數(shù)據(jù)的真正實例位置)。消費的時候，實際上如果連接到了另外一個實例，那么那個實例會從queue所在實例上拉取數(shù)據(jù)過來。
示意圖
這種方式確實很麻煩，也不怎么好，沒做到所謂的分布式，就是個普通集群。
普通集群的方式，確實達(dá)到了消息的高可用，但沒辦法保證可靠性，沒做到分布式，簡而言之，只是一個普通的集群。
這種模式，才是所謂的rabbitmq的高可用模式，跟普通集群模式不一樣的是，你創(chuàng)建的queue，無論元數(shù)據(jù)還是queue里的消息都會存在于多個實例上，然后每次你寫消息到queue的時候，都會自動把消息到多個實例的queue里進(jìn)行消息同步。
上圖中每個節(jié)點有一個queue，生產(chǎn)者生產(chǎn)完畢數(shù)據(jù)后投遞到指定交換機(jī)的隊列，交換機(jī)的隊列進(jìn)行消息同步。
每個節(jié)點queue都有一個完整的rabbitmq節(jié)點，所以這種方式叫做鏡像集群
好處： 任何一個節(jié)點宕機(jī)后，其它節(jié)點不受影響，正常使用
壞處：
確保機(jī)器中安裝了Docker，若未安裝，可看：【云原生】Docker入門 – 阿里云服務(wù)器Linux環(huán)境下安裝Docker
查看拉取的鏡像
成功運行
設(shè)置節(jié)點1
瀏覽器輸入 您的ip地址:15673
再次測試即可成功~
File — New — Project — Maven — 直接Next 進(jìn)入下一步創(chuàng)建普通的Maven工程即可
創(chuàng)建一個默認(rèn)的Maven聚合工程，將src文件夾刪除，該工程就是一個Maven聚合工程
引入依賴如下：
在項目內(nèi)，新建一個Moudle，rabbitmq-order-producer 默認(rèn)Maven工程，下一步即可
在項目內(nèi)，新建一個Moudle，rabbitmq-order-cousumer 默認(rèn)Maven工程，下一步即可
Maven聚合工程創(chuàng)建完成圖
Maven依賴圖
自行手寫MainApplication即可
創(chuàng)建完成！
編寫完成！
啟動消費者
交換機(jī)
=
15674
15675
成功消費數(shù)據(jù)！
已成功同步消息~
重慶分公司
重慶分公司
