[51CTO传媒TB]注意了！Kafka与RabbitMQ千万不要乱用…( 二 ) 作为一个有丰富经验的微服务系统架构师

另一方面，对于Kafka来说，它在消息处理方面提供了可靠的顺序保证。 Kafka能够保证发送到相同主题分区的所有消息都能够按照顺序处理。
回顾第一篇文章介绍，默认情况下， Kafka会使用循环分区器(round-robinpartitioner)把消息放到相应的分区上。
不过，生产者可以给每个消息设置分区键(key)来创建数据逻辑流(比如来自同一个设备的消息，或者属于同一租户的消息) 。
所有来自相同流的消息都会被放到相同的分区中，这样消费者组就可以按照顺序处理它们。
但是，我们也应该注意到，在同一个消费者组中，每个分区都是由一个消费者的一个线程来处理。结果就是我们没法伸缩(scale)单个分区的处理能力。
不过，在Kafka中，我们可以伸缩一个主题中的分区数量，这样可以让每个分区分担更少的消息，然后增加更多的消费者来处理额外的分区。
获胜者：显而易见， Kafka是获胜者，因为它可以保证按顺序处理消息。 RabbitMQ在这块就相对比较弱。
消息路由
RabbitMQ可以基于定义的订阅者路由规则路由消息给一个消息交换器上的订阅者。一个主题交换器可以通过一个叫做routing_key的特定头来路由消息。
或者，一个头部(headers)交换器可以基于任意的消息头来路由消息。这两种交换器都能够有效地让消费者设置他们感兴趣的消息类型，因此可以给解决方案架构师提供很好的灵活性。
另一方面， Kafka在处理消息之前是不允许消费者过滤一个主题中的消息。一个订阅的消费者在没有异常情况下会接受一个分区中的所有消息。
作为一个开发者，你可能使用Kafka流式作业(job) ，它会从主题中读取消息，然后过滤，最后再把过滤的消息推送到另一个消费者可以订阅的主题。但是，这需要更多的工作量和维护，并且还涉及到更多的移动操作。
获胜者：在消息路由和过滤方面， RabbitMQ提供了更好的支持。
消息时序(timing)
在测定发送到一个队列的消息时间方面， RabbitMQ提供了多种能力：
①消息存活时间(TTL)
发送到RabbitMQ的每条消息都可以关联一个TTL属性。发布者可以直接设置TTL或者根据队列的策略来设置。
系统可以根据设置的TTL来限制消息的有效期。如果消费者在预期时间内没有处理该消息，那么这条消息会自动的从队列上被移除(并且会被移到死信交换器上，同时在这之后的消息都会这样处理) 。
TTL对于那些有时效性的命令特别有用，因为一段时间内没有处理的话，这些命令就没有什么意义了。
②延迟/预定的消息
RabbitMQ可以通过插件的方式来支持延迟或者预定的消息。当这个插件在消息交换器上启用的时候，生产者可以发送消息到RabbitMQ上，然后这个生产者可以延迟RabbitMQ路由这个消息到消费者队列的时间。
这个功能允许开发者调度将来(future)的命令，也就是在那之前不应该被处理的命令。
例如，当生产者遇到限流规则时，我们可能会把这些特定的命令延迟到之后的一个时间执行。
Kafka没有提供这些功能。它在消息到达的时候就把它们写入分区中，这样消费者就可以立即获取到消息去处理。
Kafka也没用为消息提供TTL的机制，不过我们可以在应用层实现。
不过，我们必须要记住的一点是Kafka分区是一种追加模式的事务日志。所以，它是不能处理消息时间(或者分区中的位置) 。
获胜者：毫无疑问， RabbitMQ是获胜者，因为这种实现天然的就限制Kafka 。
消息留存(retention)
当消费者成功消费消息之后， RabbitMQ就会把对应的消息从存储中删除。这种行为没法修改。它几乎是所有消息代理设计的必备部分。
相反， Kafka会给每个主题配置超时时间，只要没有达到超时时间的消息都会保留下来。