项目中在API登录接口采用了ActiveMQ消息队列中间件，采用三台MQ做集群
执行API登录脚本前的消息数目
执行一次脚本后
刚生产的消息在8161实例上消费了
Number Of Pending Messages ：等待消费的消息，这个是当前未出队列的数量； 可以理解为总接收数-总出队列数
Messages Enqueued ：进入队列的消息；（ 这个数量只增不减，重启acmq后会清零），进入队列的总数量,包括出队列的。 这个数量只增不减
Messages Dequeued ：出了队列的消息 可以理解为是消费这消费掉的数量 （重启acmq后会清零）
一般情况下，
1、当有生产者在发送消息，同时有消费者在消费消息的话，Number Of Pending Messages=0，Messages
Enqueued=Messages Dequeued.即：等待消费数量为0，入队的和出队的消息相等（最终）。
2、当有生产者在发送消息，没有消费者的时候，Number
Of Pending Messages=Messages Enqueued.即：入队的消息数等于待消费的数。
3、当acmq重启后，Messages
Enqueued=Messages Dequeued = 0（即：清零），如果设置了消息的持久化，那么重启前没有被消费的消息会在Number
Of Pending Messages中显示。
这个要分两种情况理解
在queues里它和进入队列的总数量相等(因为一个消息只会被成功消费一次),如果暂时不等是因为消费者还没来得及消费。
在 topics里 它因为多消费者从而导致数量会比入队列数高。
简单的理解上面的意思就是
当有一个消息进入这个队列时，等待消费的消息是1，进入队列的消息是1。
当消息消费后，等待消费的消息是0，进入队列的消息是1，出队列的消息是1.
在来一条消息时，等待消费的消息是1，进入队列的消息就是2.
没有消费者时 Pending Messages 和 入队列数量一样
有消费者消费的时候 Pedding会减少 出队列会增加
到最后 就是 入队列和出队列的数量一样多
以此类推，进入队列的消息和出队列的消息是池子，等待消费的消息是水流。