01 redis發布訂閱和kafka區別(大型的 PHP應用 通常使用什么應用做 消息隊列 的)

大數據Kafka中常用Message Queue有哪些區別呢？

常用Message Queue對比

3.1RabbitMQ

RabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合于企業級的開發。同時實現了Broker構架，這意味著消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

3.2Redis

Redis是一個基于Key-Value對的NoSQL數據庫，開發維護很活躍。雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高于RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。

3.3ZeroMQ

ZeroMQ號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。ZeroMQ能夠實現RabbitMQ不擅長的高級/復雜的隊列，但是開發人員需要自己組合多種技術框架，技術上的復雜度是對這MQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務器或中間件，因為你的應用程序將扮演這個服務器角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應用程序之間發送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果宕機，數據將會丟失。其中，Twitter的Storm 0.9.0以前的版本中默認使用ZeroMQ作為數據流的傳輸（Storm從0.9版本開始同時支持ZeroMQ和Netty作為傳輸模塊）。

3.4ActiveMQ

ActiveMQ是Apache下的一個子項目。 類似于ZeroMQ，它能夠以代理人和點對點的技術實現隊列。同時類似于RabbitMQ，它少量代碼就可以高效地實現高級應用場景。

3.5Kafka/Jafka

Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發布/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分布式系統，Broker、Procer、Consumer都原生自動支持分布式，自動實現負載均衡；支持Hadoop數據并行加載，對于像Hadoop的一樣的日志數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的并行加載機制統一了在線和離線的消息處理。Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分布式系統。

上圖中一個topic配置了3個partition。Partition1有兩個offset：0和1。Partition2有4個offset。Partition3有1個offset。副本的id和副本所在的機器的id恰好相同。

如果一個topic的副本數為3，那么Kafka將在集群中為每個partition創建3個相同的副本。集群中的每個broker存儲一個或多個partition。多個procer和買粉絲nsumer可同時生產和消費數據。

redis也可以實現隊列，為什么還要用rabitmq或者kafka

拋開業務場景談這些組件的選擇就是耍流氓。 負載不大，可靠性要求不高，沒有擴容需求的情況下自然都一樣，甚至就像之前說的，不用redis，就寫文件都行，往某個文件夾里寫個文件=>入隊，拿出來刪掉=>出隊

至于ack啊，分布式啊，抗壓啊等等各種問題，redis基本沒有現成解決方案，有的可以自己變通解決，有的就是解決不了，所以才會有各種各樣的專業隊列組件，有的注重速度，有的注重分布式，有的注重可靠性，他們都會試圖解決redis解決不了的一些問題。就好像你磁盤寫文件當key-value用，IO的速度自然成為瓶頸，負載能力上不去，所以才會有專業的redis來做內存的kv

Kafka，Mq和Redis作為消息隊列使用

kafka是個日志處理緩沖組件，在大數據信息處理中使用。和傳統的消息隊列相比較簡化了隊列結構和功能，以流形式處理存儲（持久化）消息（主要是日志）。日志數據量巨大，處理組件一般會處理不過來，所以作為緩沖層的kafka，支持巨大吞吐量。為了防止信息丟失，其消息被調用后不直接丟棄，要多存儲一段時間，等過期時間過了才丟棄。這是mq和redis不能具備的。主要特點如下:巨型存儲量: 支持TB甚至PB級別數據。高吞吐，高IO：一般配置的服務器能實現單機每秒100K以上消息的傳輸。消息分區，分布式消費：能保消息順序傳輸。 支持離線數據處理和實時數據處理。Scale out：支持在線水平擴展，以支持更大數據處理量

redis只是提供一個高性能的、原子操作內存鍵值對，具有高速訪問能力，可用做消息隊列的存儲，但是不具備消息隊列的任何功能和邏輯，要作為消息隊列來實現的話，功能和邏輯要通過上層應用自己實現。

我們以RabbitMQ為例介紹。它是用Erlang語言開發的開源的消息隊列，支持多種協議，包括AMQP，XMPP, SMTP, STOMP。適合于企業級的開發。

MQ支持Broker構架，消息發送給客戶端時需要在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

還有ActiveMq，ZeroMq等。功能基本上大同小異。并發吞吐TPS比較，ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。

原文：

canal+Kafka實現mysql與redis數據同步

前言

上篇文章簡單介紹canal概念，本文結合常見的緩存業務去講解canal使用。在實際開發過程中，通常都會把數據往redis緩存中保存一份，做下簡單的查詢優化。如果這時候數據庫數據發生變更操作，就不得不在業務代碼中寫一段同步更新redis的代碼，但是這種 數據同步的代碼和業務代碼糅合在一起 看起來不是很優雅，而且還會出現數據不一致問題。那能不能把這部分同步代碼從中抽離出來，形成獨立模塊呢？答案是肯定的，下面通過canal結合Kafka來實現mysql與redis之間的數據同步。

架構設計

通過上述結構設計圖可以很清晰的知道用到的組件：MySQL、Canal、Kafka、ZooKeeper、Redis。

Kafka&Zookeeper搭建

首先在 官網 下載Kafka：

下載后解壓文件夾，可以看到以下幾個文件：

Kafka內部自帶了zookeeper，所以暫不需要去下載搭建zookeeper集群，本文就使用Kafka自帶zookeeper來實現。

通過上述zookeeper啟動命令以及Kafka啟動命令把服務啟動，可以通過以下簡單實現下是否成功：

Canal搭建

canal搭建具體可以參考上文，這里只講解具體的參數配置：

找到/買粉絲nf目錄下的canal.properties配置文件：

然后配置instance，找到/買粉絲nf/example/instance.properties配置文件：

經過上述配置后，就可以啟動canal了。

測試

環境搭建完成后，就可以編寫代碼進行測試。

1、引入pom依賴

2、封裝Redis工具類

在application.yml文件增加以下配置：

封裝一個操作Redis的工具類：

3、創建MQ消費者進行同步

創建一個CanalBean對象進行接收：

最后就可以創建一個消費者CanalConsumer進行消費：

測試Mysql與Redis同步

mysql對應的表結構如下：

啟動項目后，新增一條數據：

可以在控制臺看到以下輸出：

如果更新呢？試一下Update語句：

同樣可以在控制臺看到以下輸出：

經過測試完全么有問題。

總結

既然canal這么強大，難道就沒缺點嘛？答案當然是存在的啦，比如：canal只能同步增量數據、不是實時同步而是準實時同步、MQ順序問題等； 盡管有一些缺點，畢竟沒有一樣技術或者產品是完美的，最重要是合適。比如公司目前有個視圖服務提供寬表搜索查詢功能就是通過 同步Mysql數據到Es采用Canal+Kafka的方式來實現的。

大型的 PHP應用 通常使用什么應用做 消息隊列 的

一、消息隊列概述

消息隊列中間件是分布式系統中重要的組件，主要解決應用耦合，異步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。

目前在生產環境，使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。

二、消息隊列應用場景

以下介紹消息隊列在實際應用中常用的使用場景。異步處理，應用解耦，流量削鋒和消息通訊四個場景。

2.1異步處理

場景說明：用戶注冊后，需要發注冊郵件和注冊短信。傳統的做法有兩種1.串行的方式；2.并行方式。

（1）串行方式：將注冊信息寫入數據庫成功后，發送注冊郵件，再發送注冊短信。以上三個任務全部完成后，返回給客戶端。（架構KKQ：466097527，歡迎加入）

（2）并行方式：將注冊信息寫入數據庫成功后，發送注冊郵件的同時，發送注冊短信。以上三個任務完成后，返回給客戶端。與串行的差別是，并行的方式可以提高處理的時間。

假設三個業務節點每個使用50毫秒鐘，不考慮網絡等其他開銷，則串行方式的時間是150毫秒，并行的時間可能是100毫秒。

因為CPU在單位時間內處理的請求數是一定的，假設CPU

很赞哦!（59993）