流量控制器＋消息cache实现高性能稳定的MQ服务器

      本来想把MQ的消息cache改造过程详细写写，由于到年关了，项目要验收了，时间紧得很，只好把新的想法写下来，原来的改造想法就先搁着吧，等有空了再说（估计是不会有空的了）。

        消息cache对MQ性能的影响是不必说了，肯定是导致MQ性能下降的一个重大原因。既然不能抛弃它，那就好好利用它。如果能在资源宽裕的情况下不使用消息cache，保持MQ的性能；而只有在资源吃紧的情况下再使用消息cache，这样的话，由于资源原因导致的性能下降，却能保证功能的正确性，那么估计用户也会见谅的，要责备的话，只能先建议你买一台高档点的服务器了：）。当然，我们不能随随便便就使用消息cache，而是万不得以的时候才这么做。这便是流量控制器的由来。

        流量控制器的功能很简单，就是根据服务器资源的使用情况（主要是内存），调整消息的流量，达到控制服务器内存不会溢出的目的。流量控制器的功能虽然简单，但实现起来并非易事。主要考虑的因数有三个：1）降低发送者的速度而不能降低接收者的速度，如果两者都降低，又有什么用呢？ 2）同一个服务器上的连接数是一个动态变化的过程，每个连接上的客户端发送消息的大小是一个未知数，怎样计算出某个时刻消息的流量，然后决定各个连接的发送数度？ 3）流量的控制级别，即不同情况下流量的控制力度问题，什么情况下才能启用消息cache呢？    这些问题都不好解决。

       使用流量控制器后，消息cache的使用又应该遵循什么策略呢？把消息加入到cache的时候，要不要直接做成SoftReference，还是把Soften的工作交给消息cache来完成？ 消息被接收的时候也相应得要变成复杂了，被接收的消息在不在cache中，如果在cache中，消息又在不在辅存上呢？对消息＆消息cache的并发问题，还要考虑到持久化、非持久化的情况。一大堆的问题，头都要晕了。

       写一个试行的方案吧，看看有什么问题。

       流量控制器的设计先不提了，就想加入流量控制器以后，服务器端的工作模式。

      原来的时候，服务器每次接收到消息时都要先把消息封装成消息引用，然后再把消息引用加入到消息cache，所有关于服务器内存的处理都有消息cache自己完成。那么，现在有了流量控制器，就先去看看流量控制器的级别，如果流量控制器觉得不必要加入消息cache，就直接把消息封装成消息引用，而不把其加入消息cahce。但是，如果流量控制器处于在非常严重的级别，那么，就要把消息引用加入到消息cache中，同时把消息引用Soften， 并把消息存入到辅存中。消息cache的功能就简化成在内存吃紧的时候剔除软引用，就不必进行软引用化和辅存存储。这样的话，由于在内存吃紧的时候，既通过流量控制器降低消息的发送数度，又通过存储降低发送速度，可以保证消息的流量降低，内存增长缓慢（PS：还是没法不让内存增长啊，如果只有发者没有消息接收者，最终还是会内存溢出，不过就是死的慢了些，谁能解决这个问题？？？）。

       消息在被接收的时候，先要看看消息在不在cache中，如果不在cache中，那么肯定不会在辅存中了（持久化的消息还是在辅存中的），那就不需要考虑同步的问题，直接发送到客户端，收到客户端应答的时候，不需要理会cache，直接删除完事。这里的关键点是给消息引用一个状态：在或不在cache中。 当然，对于持久化的消息，还要去辅存中删除的。 如果消息在cache中，情况稍为复杂些，那就是消息在不在辅存中。不管消息在不在辅存中，如果消息要被接收走，那就必须把消息从cache中删除， 然后发送给客户端。此时，需要考虑cache的并发访问问题，同时还要考虑到消息的并发访问问题，因为在消息cache中的消息只有软引用，没有强引用，如果发生下面这种情况：

        if (softReference != null)   strongReference = softReference. 如果在这两个语句的中间执行时刻，即判断了还没赋值的时候，出现了GC把softReference收走的情况，那么，只要我们发现strongRefernce还是null的话，直接从辅存上取消息付给strongRefernce就行了。虽然，对于队列中的消息，因为只有一个接收者可以接收，也就是说更改消息状态只有一个线程，自然是不需要并发的。但是，如果对于Topic的情况，如果同时有多个接收者的话，就要考虑消息的并发问题，此时，只允许一个线程更改消息的状态，其余的线程就免为操心了。至于应答之后从辅存中删除的问题，就交给后台的线程吧，反正那个已经不重要了。