这篇文章给大家分享的是有关复述和卡夫卡的区别有哪些的内容。小编觉得挺实用的,因此分享给大家做个参考。一起跟随小编过来看看吧。
, <强>卡夫卡与复述,PUB/SUB之间较大的区别在于卡夫卡是一个完整的系统,而复述,PUB/SUB只是一个套件(效用)——没有冒犯复述的意思,毕竟它的主要功能并不是PUB/SUB。
复述,消息推送(基于分布式PUB/SUB)多用于实时性较高的消息推送,并不保证可靠,
其他的mq和卡夫卡保证可靠但有一些延迟(非实时系统没有保证延迟).redis-pub/SUB断电就清空,而使用redis-list作为消息推送虽然有持久化,但是又太弱,智也并非完全可靠不会丢。
另外一点,复述,发布订阅除了表示不同的话题外,并不支持分组,比如卡夫卡中发布一个东西,多个订阅者可以分组,同一个组里只有一个订阅者会收到该消息,这样可以用作负载均衡。
复述,它首先是一个内存数据库,其提供的PUB/SUB功能把消息保存在内存中(基于通道),因此如果你的消息的持久性需求并不高且后端应用的消费能力超强的话,使用复述,PUB/SUB是比较合适的使用场景。比如官网说提供的一个网络聊天室的例子:模拟IRC,因为频道就是IRC中的服务器。用户发起连接,发布消息到通道,接收其他用户的消息。这些对于持久性的要求并不高,使用复述,PUB/SUB来做足矣。
而卡夫卡是一个完整的系统,它提供了一个高吞吐量,分布式的提交日志(由于提供了卡夫卡连接和卡夫卡流,目前卡夫卡官网已经将自己修正为一个分布式的流式处理平台,这里也可以看出卡夫卡的野心:-)。除了p2p的消息队列,它当然提供PUB/SUB方式的消息模型,而且,卡夫卡默认提供了消息的持久化,确保消息的不丢失性(至少是大部分情况下)。另外,由于消费元数据是保存在消费者端的,所以对于消费而言消费者被赋予极大的自由度.consumer可以顺序地消费消息,也可以重新消费之前处理过的消息。这些都是复述,PUB/SUB无法做到的。
<强>复述,PUB/SUB使用场景: <强>
1。消息持久性需求不高
2。吞吐量要求不高
3。可以忍受数据丢失
4。数据量不大
<强>卡夫卡使用场景:
上面以外的其他场景:)
1。高可靠性
2。高吞吐量
3。持久性高
4。多样化的消费处理模型
感谢各位的阅读!关于复述和卡夫卡的区别有哪些就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到吧!
