1. 程式人生 > >Kafka,Mq,Redis作為訊息佇列使用時的差異?

Kafka,Mq,Redis作為訊息佇列使用時的差異?

redis 訊息推送(基於分散式 pub/sub)多用於實時性較高的訊息推送,並不保證可靠。
其他的mq和kafka保證可靠但有一些延遲(非實時系統沒有保證延遲)。redis-pub/sub斷電就清空,而使用redis-list作為訊息推送雖然有持久化,但是又太弱智,也並非完全可靠不會丟。

另外一點,redis 釋出訂閱除了表示不同的 topic 外,並不支援分組,比如kafka中釋出一個東西,多個訂閱者可以分組,同一個組裡只有一個訂閱者會收到該訊息,這樣可以用作負載均衡。

比如,kafka 中釋出:topic = "釋出帖子" data="文章1" 這個訊息,後面有一百臺伺服器每臺伺服器都是一個訂閱者,都訂閱了這個 topic,但是他們可能分為三組,A組50臺,用來真的做釋出文章,A組50臺裡所有 subscriber 都訂閱了這個topic。

由於在同一組,這條訊息 (topic="釋出帖子", data="文章1")只會被A組裡面一臺當前空閒的機器收到。而B組25臺伺服器用於統計,C組25臺伺服器用於存檔備份,每組只有一臺會收到。

用不同的組來決定每條訊息要抄送出多少分去,用同組內哪些訂閱者忙,哪些訂閱者空閒來決定訊息會被分到哪臺伺服器去處理,生產者消費者模型嘛。

redis完全沒有這類機制,這兩點是最大的區別。。。。。

相關推薦

Kafka,Mq,Redis作為訊息佇列差異

RabbitMQ是使用Erlang編寫的一個開源的訊息佇列,本身支援很多的協議:AMQP,XMPP, SMTP, STOMP,也正是如此,使的它變的非常重量級,更適合於企業級的開發。同時實現了一個經紀人(Broker)構架,這意味著訊息在傳送給客戶端時先在中排隊。對路由(Ro

KafkaMqRedis作為訊息佇列使用時的差異

redis 訊息推送(基於分散式 pub/sub)多用於實時性較高的訊息推送,並不保證可靠。 其他的mq和kafka保證可靠但有一些延遲(非實時系統沒有保證延遲)。redis-pub/sub斷電就清空,而使用redis-list作為訊息推送雖然有持久化,但是又太弱智,也並非完全可靠不會丟。 另外一點,red

redis作為訊息佇列的原理

Redis佇列功能介紹 List 常用命令: Blpop刪除,並獲得該列表中的第一元素,或阻塞,直到有一個可用 Brpop刪除,並獲得該列表中的最後一個元素,或阻塞,直到有一個可用 Brpoplpush Lindex獲取一個元素,通過其索引列表 Linsert在列

php使用redis作為訊息佇列--守護程序模式執行

  出隊指令碼 編寫指令碼,通過crontab定時執行指令碼,從list的右邊取出錯誤處理。 這種方式的優點是不會出現資料的丟失,只有定時指令碼處理完相關資訊之後,才從佇列中取出;缺點也是顯而易見的,響應不夠及時,因為是定時訪問redis的list隊形,所以不能實時的處理佇列中

Redis作為訊息佇列與RabbitMQ的效能對比

週末測試了一下RabbitMQ的效能,RabbitMQ是使用Erlang編寫的一個開源的訊息佇列,本身支援很多的協議:AMQP,XMPP, SMTP, STOMP,也正是如此,使的它變的非常重量級,更適合於企業級的開發。個人認為,在網際網路開發中,使用訊息佇列,更多的因為在高併發環境下,由於來不及

[轉]Redis作為訊息佇列與RabbitMQ的效能對比

週末測試了一下RabbitMQ的效能,RabbitMQ是使用Erlang編寫的一個開源的訊息佇列,本身支援很多的協議:AMQP,XMPP, SMTP, STOMP,也正是如此,使的它變的非常重量級,更適合於企業級的開發。個人認為,在網際網路開發中,使用訊息佇列,更多的因為在高併發環境下,由於來不及同步處理,請

NoSQL初探之人人都愛Redis:(3)使用Redis作為訊息佇列服務場景應用案例

一、訊息佇列場景簡介   “訊息”是在兩臺計算機間傳送的資料單位。訊息可以非常簡單,例如只包含文字字串;也可以更復雜,可能包含嵌入物件。訊息被髮送到佇列中,“訊息佇列”是在訊息的傳輸過程中儲存訊息的容器。   在目前廣泛的Web應用中,都會出現一種場景:在某一個時刻,網站會迎來一個使用者請求的高峰期(

Redis作為訊息佇列與RabbitMQ的效能對比

週末測試了一下RabbitMQ的效能,RabbitMQ是使用Erlang編寫的一個開源的訊息佇列,本身支援很多的協議:AMQP,XMPP, SMTP, STOMP,也正是如此,使的它變的非常重量級,更適合於企業級的開發。個人認為,在網際網路開發中,使用訊息佇列,更多的因為

Redis + DB +訊息佇列 實現高效的文章點贊點踩功能

需求說明 使用者可點贊或踩,每贊一次,“贊”數量+1,每踩一次,“踩”數量+1,“點贊”和“點踩” 當天內二選一當天內有效 場景:使用者A 點贊 文章a,文章a 點贊量+1 ,同一使用者,同一文章 當天再次點選無效,贊與踩二選一,隔天再次點選有效 表設計 文章的

程式設計師過關斬將--redis訊息佇列香嗎?

Redis訊息佇列 在程式設計師這個圈子打拼了太多年,見過太多的程式設計師使用redis,其中一部分喜歡把redis做快取(cache)使用,其中最典型的當屬儲存使用者session,除此之外,把redis作為訊息佇列使用也不在少數,可見redis在網際網路中應用是多麼的廣泛。 redis作為訊息佇列使用,r

Redis與RabbitMQ作為訊息佇列的對比

RabbitMQ RabbitMQ是實現AMQP(高階訊息佇列協議)的訊息中介軟體的一種,最初起源於金融系統,用於在分散式系統中儲存轉發訊息,在易用性、擴充套件性、高可用性等方面表現不俗。訊息中介軟體主要用於元件之間的解耦,訊息的傳送者無需知道

Redis與RabbitMQ作為訊息佇列的比較

本文僅針對RabbitMQ與Redis做佇列應用時的情況進行對比 具體採用什麼方式實現,還需要取決於系統的實際需求 簡要介紹 RabbitMQ RabbitMQ是實現AMQP(高階訊息佇列協議)的訊息中介軟體的一種,最初起源於金融系統,用於在分散式系統中儲存轉發訊

通訊方式詳解無名管道pipe有名管道fifo共享記憶體share memory,訊息佇列msg

常用的程序通訊方式有: 傳統的程序通訊方式:無名管道(pipe),有名管道(fifo),訊號(signal) system V IPC物件:共享記憶體(share memeory),訊息佇列(message queue),訊號燈(semaphore) BSD:套接字(soc

Redis中的Stream資料型別作為訊息佇列的嘗試

Redis的List資料型別作為訊息佇列,已經比較合適了,但存在一些不足,比如只能獨立消費,訂閱釋出又無法支援資料的持久化,相對前兩者,Redis Stream作為訊息佇列的使用更為有優勢。   相信球迷小夥伴們對文字直播這個東西都不陌生,時常在想,這個功能是怎麼實現的? 具體說就是用什麼技術

定義一個帶參的巨集使兩個引數的值互換並寫出程式輸入兩個數作為使用巨集的實參。輸出已交換後的兩個值。

import java.util.Scanner; public class Main {     public static void main(String[] args) {         Scanne

Qt應用Redis實現訊息佇列

    類似BS模式,客戶端傳送任務請求給服務端,服務端將處理結果返回給客戶端。 redis負責訊息的儲存和轉發。 模擬病人掛號看病,Patient程序進行掛號,Doctor程序進行看病 ,程式程式碼如下: /////////////

基於redis訊息佇列的設計及實現

訊息佇列 所謂訊息佇列,就是一個以佇列資料結構為基礎的一個真實存在的實體,如陣列,redis中的佇列集合等等,都可以。 為什麼要使用佇列 主要原因是由於在高併發環境下,由於來不及同步處理,請求往往會發生堵塞,比如說,大量的insert,update之類的請求同時到達MySQL,直接導致無

Redis訊息佇列

SpringBoot 結合redis實現訊息佇列功能 釋出者: 配置連線工廠 @Bean public StringRedisTemplate template(RedisConnectionFactory connectionFactory){ retu

Redis 非同步訊息佇列與延佇列

        訊息中介軟體,大家都會想到  Rabbitmq 和 Kafka 作為訊息佇列中介軟體,來給應用程式之間增加非同步訊息傳遞功能。這兩個中介軟體都是專業的訊息佇列中介軟體,特性之多超出了大多數人的理解能力。但是這種屬於重量級的應

Redis訊息佇列

一、訊息佇列的適用場景 非同步處理,應用解耦,流量削鋒和訊息通訊 四個場景。 二、藉助 Redis 阻塞佇列實現簡單的訊息佇列功能 redis相關:java程式碼操作redis資料庫 1、引入redis 依賴包。 2、java程式碼操作redis阻塞佇列。 ja