项目第一弹：RabbitMQ先容

一、媒介

这是我项目标底子版本，目标是先实现一个底子功能的RabbitMQ消息队列，后续再对其进行扩展，丰富更多功能
1. 回首生产者消耗者模型

在学习了生产者消耗者模型之后，我们回首一下生产者消耗者模型的优点：

我们之前写生产者消耗者模型的壅闭队列和环形队列版本时，先容了解耦与并发。
但是没有提到过忙闲不均这一题目，也没有提到过负载平衡，下面我们谈一下二者
2.忙闲不均与负载平衡

忙闲不均就是指在多线程等并行处置惩罚环境当中，不同组件之间的工作负载分配不均，导致某些组件过忙，而另一些组件过闲，从而影响整体性能和资源利用率。

负载平衡是办理忙闲不均的一种有效处置惩罚方法。通过负载平衡器将工作负载均匀地分配到多个组件上，从而实现组件之间的负载平衡

因此我们的生产消耗模型就变成了下面这个样子：

3.改造线程池使其支持负载平衡

题目来了？
负载平衡器怎么分配任务呢？
我们之前的代码都是从线程在（互斥锁，条件变量）/（互斥锁、信号量）的束缚下实现的生产消耗模型
都是从线程自动取任务，有没有什么方法能让我们自动给从线程分配任务？
我们碰到的这种题目肯定都不大，首先就想：能不能加一层？
我现在要统计负载，那我给每个从线程单独维护一个任务队列不就可以实现负载平衡了吗？
如许的话乃至连互斥锁和条件变量这种维护线程互斥和同步的本领都不必要了，
也就是：把原先的一个任务队列直接拆分为多个任务队列，通过负载平衡器来将任务放到负载少的队列当中

怎么办呢？
再加一层，对于我们碰到的题目，大部门情况都能办理

引入一个监控线程和它的热备份加上心跳机制，就可以办理这一题目
实在在很多分布式体系的组件/主从服务器当中，心跳机制和热备份是非经常见的，好比：

1. 1. HDFS 2.0的活跃名称节点和待命名称节点与Zookeeper
2. 2. HBase当中的Master服务器与Region服务器
3. 3. MapReduce当中的JobTracker与TaskTracker
4. 4. Storm当中的Nimbus和Supervisor
5. 5. Spark当中的Dirver Program和Worker Node，（它的容错更强：采用基于血缘和管道化形成的RDD）

复制代码

不过加了监控线程之后的确不好写，写出来是完全没有题目标，只不过总以为不敷优雅，我们一个普平常通的线程池怎么都用上分布式体系的设计方式了呢？
是不是有点太大材小用了呢？
光看一眼上面那5个Hadoop当中的强盛框架，
咱就知道凭咱目前的实力不好整啊，我以为整是能整出来的，
只不过用的设计方式来重了吧…或者说不太适合~，
写出来之子女码也必要不停重构，而且代码不易扩展
4.MQ的引入

那怎么办呢？
我们就是想提高任务实行的容错性，
那我们把任务队列和消耗者的对应关系从1对1改成1对多，然后再任务队列内部加上负载平衡器不就行了吗？

那我们这个项目就是要实现这个？
当然不是，有一个更强