互联网血统的MQ系统

0.引言：
  企业应用血统的MQ，无论是JMS还是AMQP的实现，都比较复杂而Scalability又马马虎虎. 打算找些真正有互联网血统的那些简单，简陋但务实的MQ系统来看下， 计划有Amazon的SQS，Linkedin贡献出来的Apache Karfka , 偏重于Log收集的Apache Flume 和 Facebook Scribe，或是借助一些NOSQL系统来简单搭建的方法。


1.Amazon SQS：
   Amazon SQS(Simple Queue Service)是亚马逊云上的MQ服务.
   核心API很简单，Sender方面的SendMessage和Receiver方面的ReceiveMessage，DeleteMessage，都是Restful的接口.
   Sender没什么好说的。Receiver方面则会：
  1. 先主动用ReceiveMessage轮询消息(JMS里的Pull模式，Message Driven Bean那种Push模式是没有的)，一次接收到若干条消息(受MaxNumberOfMessages参数限制，默认为1)。

  2. 处理完每条消息后，必须显式调用DeleteMessage在Server端删除消息(也就是JMS里的CLIENT_ACKNOWLEDGE模式，AUTO_ACKNOWLEDGE自动删除模式是没有的)。为了性能还有个BatchDeleteMessage的API，但就要冒一点消息被重复处理的风险了。

  3. 为了避免消息在被处理完Delete掉之前，被其他接收者接收，会有一段保护时间(Queue有个VisibilityTimeout属性, 默认30秒)，过期后消息还没被Delete掉，就会让其他接收者接手处理。还有个ChangeMessageVisibility的API可以延长此消息的保护期。

  简单，实用的保证消息被at lease once的处理，同时尽可能的避免被重复处理，是这些互联网血统MQ的设计特征。但如果消息真的被重复发送，就还是只能靠客户端那边的自我保护机制，消息属性里会提供SentTimestamp，ReceiveCount，FirstReceiveTimestamp的信息做参考。

  另外SQS有个好玩的Pattern，你可以用GetQueueAttributes获得Queue中待处理的消息数，如果过多了，可以临时启动多几个Receiver的EC2实例来处理，没什么剩了，就又shutdown回去，很经济的云计算。

其他MQ系统待续......