消息cache，我真得需要你吗（1）？

        由于JTangMQ提供的消息服务是异步的服务，消息的发送者和接收者可以不需要时刻在线或同时在线，也不需要知道彼此的身份，发送者和接收者只需要同MQ的服务器进行交互。因此，在实际应用中可能会出现两种场景：一是消息的发送者和接收者同时在线并分别不断进行收发操作。此时，对于服务器来说有一个消息接收流量和消息发送流量，如果消息接收流量大于消息发送流量，则服务器上的消息数就会越来越多，最终将会耗尽服务器的内存。二是，如果只有消息的发送者，没有消息的接收者，服务器就一直在接收消息，自然也会导致服务器的内存耗尽。为了避免出现由上述两种情况导致的服务器内存溢出问题，就需要在服务器内存吃紧的时候把暂时还没有被取走的消息储存到辅存上，腾出内存。而到底要存储多少消息，存储哪些消息到辅存上呢？这就需要一个消息cache来处理了。消息cahce的作用就是既要避免内存溢出，而且还要考虑到消息的访问数度，即不能把即将要被接收的消息置换出内存，而把不知到猴年马月才会被接收的消息一直保留在内存中。

        JTangMQ的消息cache实现了上述的功能，的确有效的避免了内存的溢出问题，也保证了消息的命中率，但同时也带来了新的问题。这些新问题的严重程度并不亚于内存溢出。由于消息cache发现内存不足之后，就要把消息存储到辅存上，众所周知，IO向来是一个瓶颈，尽管pc硬盘的转速从原来的蹒跚步履发展到如今的7200转/秒，但相比较cpu而言，依旧还是慢得很。因此，一旦到了需要大量存储消息的时候，就只看见硬盘的红灯狂闪，服务器就基本上处于down机状态。当然，这也跟我们采取的存取策略有关。采用文件存储的速度自然会快些，但是文件存储的格式比较复杂；采用数据库存储要方便些，但性能上就比不上文件了，另外，还同不同的DBMS有关。我们采用的是数据库存储方式，由于是实验室的产品，自然要用些开源的数据库，所以，就出现了类似down机的恶劣情况。另外，由于服务器上只有一个消息cache，所有的消息都要从cache中进进出出。消息cache不是电影院，消息不可以在电影开始之前像潮水般涌进去，散场之后又涌出来。消息cache管理消息的进出是单线程的，one by one的模式，也就是说，同一个时刻，只有一个消息获得消息cache的权限，这个消息有权进出消息cache，其余的消息只能等着。想象一下，如果同时有1000个发送者在发送消息到服务器，1000个接收者要从服务器上接收消息，因为消息cache，这2000个消息客户端就排成一个队伍，挨个对消息cache操作，这岂不慢死了？或许，有人会怀疑在服务器是单个cpu的情况下，即使你有2000个线程同时在跑，照样还不是一个cpu在执行吗？对，没错。但是，我们不能忽略的一点是，为了访问临界资源消息cache，线程就要获得消息cache上的锁，还要释放锁。就好比关门和开门，不需要时间吗？另外，这2000个线程谁能获得锁还不一定，还得竞争，如果此时一个线程获得了cpu时间，但同时发现它不能获得消息cache上的锁，还得被挂起来，这一来一去又要消耗许多资源。所以，采用消息cache以后引出的这两个问题是十分令人头痛的。