189 8069 5689
如果是集群的话，我考虑需要流畅运行的话，2核4G配置是可以满足的。因为这个集群形式，用于适用于物联网、车联网、监控、安全风控、即时通讯、消息存储等行业场景，所以数据量是比较大的，所以配置太低了跑不动，会卡死的。
成都创新互联是一家专业提供新罗企业网站建设,专注与成都做网站、成都网站建设、成都外贸网站建设、H5场景定制、小程序制作等业务。10年已为新罗众多企业、政府机构等服务。创新互联专业的建站公司优惠进行中。
因为hadoop是海量数据的处理能力，所以服务器一定不能太小配置了，跑不动了就没实际用途了。最好使用4核8G内存及以上配置。
因为这方面内容较多，这里也写不开那么多内容，所以你可以留言或到我的博客上搜索相关内容，老魏有写过教程，还不止一篇，都挺详细的内容，可以帮助你入门。
如果RabbitMQ集群只有一个broker节点，那么该节点的失效将导致整个服务临时性的不可用，并且可能会导致message的丢失（尤其是在非持久化message存储于非持久化queue中的时候）。可以将所有message都设置为持久化，并且使用持久化的queue，但是这样仍然无法避免由于缓存导致的问题：因为message在发送之后和被写入磁盘并执行fsync之间存在一个虽然短暂但是会产生问题的时间窗。通过publisher的confirm机制能够确保客户端知道哪些message已经存入磁盘，尽管如此，一般不希望遇到因单点故障导致服务不可用。
如果RabbitMQ集群是由多个broker节点构成的，那么从服务的整体可用性上来讲，该集群对于单点失效是有弹性的，但是同时也需要注意：尽管exchange和binding能够在单点失效问题上幸免于难，但是queue和其上持有的message却不行，这是因为queue及其内容仅仅存储于单个节点之上，所以一个节点的失效表现为其对应的queue不可用。
为了提高程序的吞吐量，保持消息的可靠性，一台机器挂了后，RabbitMQ能够正常生产，消费消息。
rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
Demo级别的，一般只是本机测试玩玩而已，生产环境下不会用的。
在多台机器上启动多个rabbitmq实例，每个机器启动一个。
但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据(存放含queue数据的真正实例位置)。消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
示意图
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。
普通集群的方式，确实达到了消息的高可用，但没办法保证可靠性，没做到分布式，简而言之，只是一个普通的集群。
这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
上图中每个节点有一个queue，生产者生产完毕数据后投递到指定交换机的队列，交换机的队列进行消息同步。
每个节点queue都有一个完整的rabbitmq节点，所以这种方式叫做镜像集群
好处： 任何一个节点宕机后，其它节点不受影响，正常使用
坏处：
确保机器中安装了Docker，若未安装，可看：【云原生】Docker入门 – 阿里云服务器Linux环境下安装Docker
查看拉取的镜像
成功运行
设置节点1
浏览器输入 您的ip地址:15673
再次测试即可成功~
File — New — Project — Maven — 直接Next 进入下一步创建普通的Maven工程即可
创建一个默认的Maven聚合工程，将src文件夹删除，该工程就是一个Maven聚合工程
引入依赖如下：
在项目内，新建一个Moudle，rabbitmq-order-producer 默认Maven工程，下一步即可
在项目内，新建一个Moudle，rabbitmq-order-cousumer 默认Maven工程，下一步即可
Maven聚合工程创建完成图
Maven依赖图
自行手写MainApplication即可
创建完成！
编写完成！
启动消费者
交换机
=
15674
15675
成功消费数据！
已成功同步消息~
本文将以阿里云在GIAC的分享《云原生InfluxDB高可用架构设计》为例，剖析阿里云的自研InfluxDB集群方案的当前实现，在分析中会尽量聚焦的相对确定的技术、架构等，考虑到非一线信息，在个别细节上难免存在理解偏差，欢迎私聊讨论:
0x0 初步结论
目前是一个过渡性质的公测方案，具备数据一致性，但接入性能有限，缺乏水平扩展能力。缺乏自定义副本数和水平扩展等能力，通过Raft或Anti-entroy提升了数据的可靠性，但受限于节点和副本的强映射，集群接入性能有限，约等同于单机接入性能，另外，基于时序分片和分布式迭代器等核心功能未提及，可能仍在预研中。
0x1 集群方案剖析
1. 背景补充：InfluxDB是DB-Engines上排名第一的TSDB，针对时序数据多写、少读、成本敏感等特点而设计的TSDB，并做了多轮架构迭代和优化，是一款实时、高性能、水平扩展（InfluxDB Enterprise）、具有成本优势的TSDB。但在2016年，Paul Dix基于商业化和持久运营的考虑，尚未成熟的集群能力在v0.11.1版后，选择闭源，推出了收费版的InfluxDB Enterprise和InfluxDB Cloud。
2. 通过Raft协议实现Meta节点的数据一致性，考虑到Meta节点存放的是Database/Rention Policy/Shard Group/Shard Info等元信息，这些信息敏感，是系统稳定运行的的关键，CP的分布式架构，合适。
3. 通过Raft协议实现Data节点的数据一致性，考虑到Data节点存储的是具体的时序数据，性能和水平扩展性是挑战，对一致性性要求不高（PPT中亦提到这一点），采用CP的分布式架构，节点和副本强映射，不仅对实时性有影响，集群接入性能亦有限，约等同于单机接入性能，不能很好的支持海量数据的实时接入的时序需求。
4. 2节点集群方案，通过Anti-entroy实现Data节点的数据一致性，应该还实现了Hinted-handoff能力，AP的分布式架构，但节点和副本还是强映射，未见提及基于时序分配、自定义副本数、分布式迭代器等能力，暂无法水平扩展。
5. 云盘能保障数据的可靠性，但无法保障接入的可用性，可用性敏感的业务或实时要求高的业务，还是推荐多节点的集群模式。
6. 开源版InfluxDB（单机）性能不错，InfluxDB Enterprise性能不错，但如何保障补齐集群能力的卓越性能，取决于集群架构、并发架构等，是由集群功能的开发者决定的，这次未见提及性能数据，期待后续的公布。
0x2 附录
不建议用学生服务器来搭建CDH集群，跑不起来。买这个还不如去华为云买个搞活动的2C4G，一百出头搞定