路由拓扑与消息模式
上一章我们介绍了有关RabbitMQ消息拓扑与路由模式，本章我们讨论Kafka的消息路由方式，我们将对比两者之间的不同。注意，接下来的对比将基于这样的一个上下文前提，应用是事件驱动架构而非数据处理作业流，尽管这两种类型的应用的区分界限并不是那么明朗。
第一个不同点在于对于Kafka来说，并没有重试和延迟消息模式。在RabbitMQ中，消息都是瞬时的，所以对于RabbitMQ来说，重试是有实际业务用例的，但对于Kafka来说，消息的本质是日志，添加重复消息无实际业务含义，并且还会破坏日志本身。对于Kafka来说，其强项之一就是在一个分区中消息的有序性保证，重复添加只会破坏消息的有序性。在RabbitMQ中，你可以重复添加消息到消息队列中，一个队列可以只指定一个消费者进行处理，但Kafka是一个统一的日志，其面向的是所有的消费者。从概念上讲，延迟于日志并不完全冲突，但Kafka自身并不提供延迟机制（后续章节，我们将会探讨在Kafka中如何实现消息重试）。
第二个影响RabbitMQ和Kafka实现模式的不同点在于两者的消息状态。在RabbitMQ中，消息是即时的，而在Kafka中，消息则相对持久。在RabbitMQ中，一旦消息被处理，那么消息就将被移除，甚至RabbitMQ都不会记录其存在的历史。而对于Kafka来说 ，每一消息都会被持久化到日志中直到专门的清理操作。Kafka的数据清理策略则依赖于当前的数据量，分配的实际空间以及你想要达到的消息模式。我们既可以基于windows时间保持最近几天/几周/几个月的消息来设置清理策略，也可以通过日志压缩的方式保持指定消息键值最近状态的方式设置清理策略。两种清理策略都允许消费者来回溯消息，与RabbitMQ重试模式不同，这Kafka提供另一种重试模式。
相较来说，RabbitMQ侧重消息路由，并通过强大的路由原语允许我们自由定义路由模式，而Kafka则侧重于消息状态的存储，记录一个系统的历史及当前状态。因此，Kafka可以作为验证事实的一个依据，而RabbitMQ则无法担此角色。
