假如有500w请求同时请求服务器,时间也很短,这就是多线程高并发的情况,然后我们在 服务器的前面添加一个 MQ,这500w个请求,每个请求过来都给mq发送一个消息,然后 这个消息就保存在了 MQ 中,因为我们使用的是点对点模式,是异步处理,所以 我们的服务器会自己主动到mq中获取 信息,获取到信息就等于获取到了请求,这样就减少了服务器的压力。-----------高并发环境才使用mq队列技术。
如果项目A和项目B直接连接,那么项目B down机了,项目A也不能正常工作了。
---------为什么需要集群?
因为【集群】 是 通过 横向增加【服务器】来提高性能的,所以 服务器也多,处理能力就越强,服务能力就越强,而且当发生故障的时候,一台服务器停机了,但是还有其他的服务器可以提供服务,所以可用性很高,解决了单点故障的发生。
1.原理:通过共享存储目录(kahaDB)来实现master和slave的主从信息同步;
因为我们的 ActiveMQ 默认是将消息进行持久化的,所以默认情况下ActiveMQ接收到了消息之后,=会将消息存储到 data目录下kahadb目录下。假如我们的ActiveMQ集群中配置了【 三台 ActiveMQ服务器】,而且这三台ActiveMQ服务器都在同一个【linux系统】中,所以我们就可以设置这三台ActiveMQ 服务器 同时 【共享 同一个 ActiveMQ 持久化消息的目录】。这样配置之后,当这三个ActiveMQ中有一个 服务器 停机了, 其他两个ActiveMQ 还是可以提供服务,而且依然可以从 共享的目录中 获取信息。
2.在集群当中,所有的 ActiveMQ 服务器都可以 不断的获取 共享目录的控制权,当前我们配置了三个ActiveMQ 服务器,这三个服务器 是【互相抢夺】共享目录的控制权,那个ActiveMQ服务器抢到了共享目录的控制权,这个ActiveMQ服务器就是主,那么其余的服务器都是从了。 而且只有我们的主服务器可以真正的操作 共享目录。
3.需要注意的是:只能有一个主,其余的都是从,而且只有主可以操作共享目录,当主停机了之后,那么剩余的从会争夺共享目录的 控制权,谁抢到了控制权谁就又称为主,然后这个新的主会接着上一个主的执行位置继续执行,而且我们ActiveMQ 只会去连接主服务器,也就是读写都是操作我们的主,所以 从 其实就是主的备用。
保留地址的写法:当不知道 安装到那台机器上,我们就采取保留ip地址,这样子我们的ip地址就活了,就不是死的了:不能写死,写死了就不能更换机器了。
0.0.0.0是保留地址,代表任意ip地址。
0.0.0.0:0 也是保留地址,代表任意ip地址,任意端口。
配置好三个ActiveMQ 服务器集群之后:然后开启三个ActiveMQ服务器,然后我们的这三个服务器就开始抢夺 对 共享目录 的 控制权,如果 其中的 一个ActiveMQ服务器抢夺到了 对共享目录的 控制权,就会在控制台中 提示下面这段话:
[ActiveMQ Task-1] INFO org.apache.activemq.transport.failover.FailoverTransport - Successfully connected to tcp://192.168.242.128:61617 这个提示连接上了那台主服务器中了。
当前主服务器是61617,然后我们手动将这个服务器关闭,关闭之后会报出:java.io.EOFException这个异常,然后过了没多长时间,这段时间内我们的服务器正在抢夺共享目录的控制权,当有一台抢夺到了之后,我们的控制台打印信息的操作就重新继续执行了,当前主机器变成了61618,这种故障转移 是 自动完成的,我们不用写任何的代码,当 主 服务器 停掉了,那么其他的从机器就会抢夺 控制权,谁抢到了谁就成为了 主机器。
上面 三个ActiveMQ服务器 是安装在同一个Linux中的 ,所以可以共享同一个linux中的目录,当这三个ActiveMQ服务器安装台 不同的 三个 独立的 linux中,那么怎么实现 目录的共享呢?
这样情况 我们就 需要【开启第四个Linux】,然后将第四个Linux中的磁盘,通过【linux命令】分别挂载到【另外三个linux上】,这样我们安装了ActiveMQ服务器的三台linux就可以访问第四台没有安装ActiveMQ服务器的linux的磁盘了,这样子 这三个ActiveMQ的消息都存放在这个【第四个linux的磁盘中】。这样子又实现了目录的共享。
这种方式和第一种方式是差不多的,因为这种方式是 共享数据库的方式,第一种是共享目录的方式,其中的原理是一样的。
注意: 因为我们是【共享数据库】,所以我们需要给 三个ActiveMQ服务器,提供一个存放消息的数据库,我们只需要 给这三个 ActiveMQ创建一个数据库就可以了,不用给他们创建表,因为表示ActiveMQ运行是自己创建的,所以说我们只需要提供数据库,不需要创建表。
(3)我们这种集群方式,正常运行的机器必须超过半数以上,我们的zookeeper才能帮助我们故障转移。如果小于半数就不能进行 投票选举,就不能选出新的主机器,就不能故障转移。
这种情况下就一台 zookeeper,所以这台zookeeper可能会出现单点故障,所以我们需要给 zookeeper进行集群设置:
3台zookeeper 和 4台 zookeeper 所 带来的效果是一样的。 所以我们不如使用3台zookeeper,因为少一台zookeeper,节省了资源,为什么4台和3台效果是一样的呢?
我们的 zookeeper的运行机制是:当【集成】中 所有可以 正常运行的zookeeper加起来是半数以上,我们的zookeeper 才能正常的运行,才能在一台主的zookeeper停掉之后,然后开始 选取投票算法,如果正常的运行的机器小于半数,zookeeper不能正常运行,更不用说 帮我们故障转移了。
3 台 zookeeper,主的 坏了,剩下两台: 2 > 3/2=1.5 故障转移,正常运行
主的又坏了,剩下一台,1 < 1.5 不能正常运行了。
4 台 zookeeper ,主的坏了,剩下3台, 3 > 4 / 2 = 2 故障转移,正常运行
主的又坏了,剩下2台,2 == 2 没有在半数一样,所以说 不能正常运行了。
从上面可以看出 3台和4台数量的zookeeper所带来的效果一样的。 我们不如配置3台,还能省一台的资源。