Async service 提问

最近做了一些关于系统设计的小结， 对于什么时候该用message queue和pub/sub service还是有一些疑惑。 还有就是rabbitMQ和Kafka的简单区分方法

大家有更好的理解吗？有相关的资料也行
譬如如果像dropbox这样需要上传的request用message queue，如果是客户端需要因为xxx收到notification的就用pub/sub？

message queue是一个大类的统称，是在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能的中间件。

消息一般有两种传递模式——点对点（P2P，Point-to-Point）模式和发布/订阅（Pub/Sub）模式

- 对于点对点的模式而言，消息被消费以后，队列中不会再存储，所以消息消费者不可能消费到已经被消费的消息。虽然队列可以支持多个消费者，但是一条消息只会被一个消费者消费。如果你对AWS有经验的话，SQS就是这种。
- 发布订阅模式定义了如何向一个内容节点发布和订阅消息，这个内容节点称为主题（Topic），主题可以认为是消息传递的中介，消息发布者将消息发布到某个主题，而消息订阅者则从主题中订阅消息。主题使得消息的订阅者与消息的发布者互相保持独立，不需要进行接触即可保证消息的传递，发布/订阅模式在消息的一对多广播时采用。AWS中SNS+SQS就可以做成一个pub-sub的队列。

RabbitMQ是一种典型的点对点模式，而Kafka是一种典型的发布订阅模式。但是RabbitMQ中可以通过设置交换器类型来实现发布订阅模式而达到广播消费的效果，Kafka中也能以点对点的形式消费，你完全可以把其消费组（Consumer Group）的概念看成是队列的概念。不过对比来说，Kafka中因为有了消息回溯功能的存在，对于广播消费的力度支持比RabbitMQ的要强。

对于选kafka还是rabbitMQ，我觉得核心区别还是要看业务要求，对吞吐量，高可用，高并发，消息顺序，可回放等等有没有什么特别硬性的要求，如果两个组件都可以满足业务要求的话就看运维上哪个更简单。脱离业务谈架构就是耍流氓。

个人的一点想法，说的不对的话欢迎大家一起讨论。

很难想象除了更lightweight以为有什么需求一定要用rabbitmq

rabbitmq在多个consumer的时候不能保证ordering 而kafka可以同一个partition保证ordering

kafka persist data ，rabbitmq不

kafka本身也是pubsub的延伸 功能上只多不少

所有的写入，只要不是需要strong consistency或者要求完全realtime的，都可以用kafka 并且新版本保证one time delivery