标签：多个 out 之间 复杂 工作 SM 场景 worker 就是
本文不对三者之间的性能进行对比，只是从三者的特性上区分他们，并指出三者的不用应用场景。
发布订阅模式如下图所示可以具有多个生产者和发布者，redis、kafka、rebittMQ都满足这样的要求。
但是三者有各自的特色。
redis的特征就是快，由于其数据是存储在内存中的，处理速度相对另外两者快了不少。通过使用redis可以实现一个简单具有实时通信功能的聊天室。
kafka的设计初衷是一个日志系统，其队列中的数据能够持久化一段时间。因此后来的consumer能够通过自定义offset来实现获取之前的消息，而redis就不具备这样的能力。
rabittMQ设计的一个核心概念为Exchange，Exchange存在的意义是producer不会直接向queue发送消息，而是将消息先发给exchanger，而exchanger选择将数据转发给queue。rabittMQ的exchanger有4种转发策略，包括direct、topic、headers、fanout。因此rabittMQ在消息的路由方面相比redis和kafka更加灵活。
work queue模式相比发布订阅者模式更侧重负载均衡，我们可以把一个队列当做一个任务，而消费该队列的worker需要共同处理队列里的任务，同一条消息只能被处理一次。如下图所示是work queue的示意图：
redis可以使用list数据结构来实现这一任务，因为redis的单个操作是原子的，保障了一条消息只能被处理一次，但是缺点是consumer需要自己实现，还有一些负载均衡地策略也要自己去实现。
rabittMQ内部实现了这一功能，使用轮训的方式给worker发消息保证了负载均衡。缺点是可拓展性不好，当consumer相当多的时候，所有的consumer都要向同一个queue去获取数据，这样导致queue的性能称为了瓶颈。
kafka通过consumer group的方式实现了work queue，同一个group的消费者能够协调完成任务。kafka在分布式方面做得很好，在kafka中，一个queue和topic的概念等同，只是topic可以被分成多个partition，而这些partition分别存储在不同的服务器上，这样，同一个Consumer group中的consumer在消费数据的时候可以从不同的partition中获取数据，减少了单台服务器的压力。
如下图所示复杂的情况，以日志举例，error日志需要持久化，所有的日志都应该打印出来。那么这里有两个工作流，一个是持久化，一个是打印。
如果用redis和kafka来实现的话需要在producer上下功夫，将消息区分之后发送到不同的queue上，而rabittMQ则更加灵活，可以通过exchanger来实现消息的转发。
redis的特点就是快
kafka的特点是可拓展性高，可以持久化
rabittMQ的特点是灵活，能够实现各种消息需求。
出自：https://blog.csdn.net/maitianshouwei/article/details/57124155
标签：多个 out 之间 复杂 工作 SM 场景 worker 就是
原文地址：https://www.cnblogs.com/hellowzd/p/9182208.html
