学步园

 架构

Apollo初衷是想让ActiveMQ在多核机器上运行更好。当然结果在broker上面也更加文档，可靠，扩展性也更强。

 架构改变

主要的变化有以下几个方面：

Reactor Based Thread Model （Reactor 模型）

Scala 2.8 Implementation （采用scala2.8）

Protocol Agnostic （从协议中抽象出来）

REST Based Management（采用REST设计）

 基于线程的Reactor 模型

    Apollo 使用HawtDispatch 实现服务器多线程非阻塞式的Reactor设计模型。 HawtDispatch是一个java版本的调度库（又称：Grand
Central Dispatch）。这种设计让非阻塞任务执行在固定线程数目的线程池中。

    这种线程模型让Apollo能够有很高的效率，但同时也给开发者带来了不小的限制。所有任务的执行都是非阻塞的，不受控制的上锁和解锁，等待被解锁。这就意味着之前的ActiveMQ不得不进行大修。所有同步broker接口都要变化，以便支持异步回调。

 scala2.9 实现

虽然Apollo是基于activeMQ5.X版本，但是因为采用Reactor模型带来的限制，需要改变原来网络IO实现方式（虽然这也导致存储接口的变化）。还好scala提供了一种简便的方式来实现回调（Scala provided a much more concise way to express callbacks, namely by it's support for
partial functions and closures.）。

 协议无关

ActiveMQ这些年已经支持多种协议，但是这些协议的实现都是基于OpenWire协议。所以这种方式并不是一种最佳的方式实现既要有效的支持其他各种协议，又不会受到OpenWire协议的限制。

Apollo Server 更好的实现模块化设计和协议无关性。所有的协议都是平等的，通过插件的方式整合到broker中，这些协议插件就利用broker暴露的路由选择，流控制，消息队列等。这就意味着 消息一开始是被固化的。所以除非消息被处理，消息不会被协议转换（All protocols are equal and are built as a plugin to the
the broker which just make use of exposed broker services for routing, flow control, queueing services etc. For example, this means that messages will be persisted in a Store in the original protocol's encoding. There is no protocol conversion occurring under
the covers unless it is required.）

 Rest 基本管理

ActiveMQ 选择JMX暴露他的管理接口。因为ActiveMQjava编写的，所以JMX是一个很自然的选择。但是JMX也有一些限制：

No cross language support （不能跨语言支持）

Not scaleable for exposing many objects. Registering and unregistering management objects in JMX can become a bottle neck. （因为暴露很多对象，导致伸缩性不够。JMX注册和注销管理对象也是他的短板）

Rich data types are hard to expose（富消息类型难以处理）

Apollo 通过利用基于Json服务的REST模型提供更多，更详细的服务器状态。

 Client用其他语言实现更加容易。

 因为没有特别的注册管理模块，几乎就不会有管理开销。REST 模型也知道调用内部结构访问所有必需的状态和统计信息。

更多信息参考：Management
API 文档

 消息转化

Apollo可以很有效的处理大量喝少量的消息队列，归因于其消息转换的实现方式。如果你有一个包含数百万的消息的消息队列，然后慢慢的处理它，那么毫无疑问会将这些消息毫无意义的留在了内存。其实这些消息只需要在需要的时候（Client准备接受的时候）加载就行。 

Apollo总的队列有一个叫做 consumer_buffer ，他是一段内存空间专用来预存储一系列用户将要用到的消息。这个队列从存储中异步加载消息，以便Client已经准备接受消息的时候，消息已经在内存了。

Client接收的速度，以及消息在队列中的位置也影响新进队列消息的处理。如果消息在队尾，但是Client没有在，就用新消息替换原来的消息。如果队尾的消息，有Client在等待接收，那么就要确保该消息在内存中呆尽量长的时间，避免换出内存，又被加载进来。

当一个消息被置换出内存，系统将其标志为  'swapped' or 'swapped range' 其中一个状态。交换状态：在消息维护队列中人人有一个参考指针指向他。这个指针包含一些信息让系统能够快速的从消息存储中检索到该消息。一旦消息队列的swapped消息数目接近10000,这个消息队列就会被一个范围指针代替。这个时候，原来swapped 状态，就变为swapped
range 状态。