7月安卓手機性能榜：紅魔8S Pro再奪榜首
7月份的手機市場風平浪靜，除了紅魔和努比亞帶來了兩款搭載驍龍8Gen2領先版處理器的新機之外，別的也想不到有什么新品了，這也正常，通常6月7月都是手機廠商修整的時間，進入8月份之
圖片
消息中間件MQ（Message Queue）是一種常用的異步通信技術，它通過將消息存儲在隊列中，實現(xiàn)生產(chǎn)者和消費者之間的解耦。MQ的主要作用是保證消息的可靠傳輸和冪等性。本質是隊列，遵循FIFO先進先出原則。只不過隊列中存放的內容是message而已，還是一種跨進程的通信機制，用于上下游傳遞消息。在互聯(lián)網(wǎng)架構中，MQ是一種非常常見的上下游“邏輯解耦+物理解耦”的消息通信服務。使用了MQ之后，消息發(fā)送上游只需要依賴MQ，不用依賴其他服務。
主要是利用高效可靠的消息傳遞機制進行與平臺無關的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進行分布式系統(tǒng)的集成。
圖片
當前業(yè)界比較流行的開源消息中間件包括:ActiveMQ、RabbitMQ、RocketMQ、Kafka、 ZeroMQ等，其中應用最為廣泛的要數(shù)RabbitMQ、RocketMQ、Kafka這三款。
RabbitMQ是一套開源（MPL）的消息隊列服務軟件，是由 LShift 提供的一個 Advanced Message Queuing Protocol (AMQP) 的開源實現(xiàn)，由以高性能、健壯以及可伸縮性出名的 Erlang 寫成。
優(yōu)點：
erlang語言開發(fā)，性能極其好，延時很低；
吞吐量到萬級，MQ功能比較完備；
健壯、穩(wěn)定、易用、跨平臺、支持多種語言、文檔齊全；
有消息確認機制和持久化機制，可靠性高；
高度可定制的路由；
管理界面較豐富，在互聯(lián)網(wǎng)公司也有較大規(guī)模的應用；
社區(qū)活躍度高，幾乎每個月都發(fā)布幾個版本。
缺點：
實現(xiàn)了代理架構，意味著消息在發(fā)送到客戶端之前可以在中央節(jié)點上排隊。此特性使得RabbitMQ易于使用和部署，但是使得其運行速度較慢，因為中央節(jié)點增加了延遲，消息封裝后也比較大。
erlang語言開發(fā)，很難看懂源碼，無法進行源碼級別的研究和定制，不利于二次維護和開發(fā)。
rabbitmq集群動態(tài)擴展比較麻煩。
RocketMQ 出自 阿里公司的開源產(chǎn)品，用 Java 語言實現(xiàn)，在設計時參考了 Kafka，并做出了自己的一些改進，消息可靠性上比 Kafka 更好。RocketMQ在阿里集團被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog分發(fā)等場景。
優(yōu)點：
缺點：
Apache Kafka是一個分布式消息發(fā)布訂閱系統(tǒng)。它最初由LinkedIn公司基于獨特的設計實現(xiàn)為一個分布式的提交日志系統(tǒng)( a distributed commit log)，，之后成為Apache項目的一部分。Kafka系統(tǒng)快速、可擴展并且可持久化。它的分區(qū)特性，可復制和可容錯都是其不錯的特性。
圖片
優(yōu)點：
客戶端語言豐富，支持java、、php、ruby、python、go等多種語言；
性能卓越，單機寫入TPS約在百萬條/秒，消息大小10個字節(jié)；
提供完全分布式架構, 并有replica機制, 擁有較高的可用性和可靠性, 理論上支持消息無限堆積；
支持批量操作；
消費者采用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費且僅被消費一次;
有優(yōu)秀的第三方Kafka Web管理界面Kafka-Manager；
在日志領域比較成熟，被多家公司和多個開源項目使用。
缺點：
Kafka單機超過64個隊列/分區(qū)，Load會發(fā)生明顯的飆高現(xiàn)象，隊列越多，load越高，發(fā)送消息響應時間變長；
使用短輪詢方式，實時性取決于輪詢間隔時間；
消費失敗不支持重試；
支持消息順序，但是一臺代理宕機后，就會產(chǎn)生消息亂序；
社區(qū)更新較慢。
圖片
常用于高并發(fā)場景，進行削峰。例如：現(xiàn)在有一個訂單系統(tǒng)，高峰期訂單量過多，而系統(tǒng)最多只能處理1w次/s。此時可以通過消息隊列使得這些超出處理能力的下單請求處于隊列中進行等待，而不至于將所有的請求全部一次性打到訂單系統(tǒng)中，造成訂單系統(tǒng)宕機。這就相當于將實際一秒鐘內的訂單拆分成多個段來進行處理，這樣的處理方式雖然加長了等待時間，但是有缺點總比不能用好。這樣可以緩解業(yè)務量對系統(tǒng)帶來的沖擊，避免系統(tǒng)宕機而造成不能使用。
Redis緩存預熱。緩存預熱實際上是將熱點數(shù)據(jù)提前緩存到Redis中進行儲存，避免高峰期數(shù)據(jù)請求直接下達到數(shù)據(jù)庫造成數(shù)據(jù)庫崩潰。同樣流量消峰，也是達到此效果，只不過一個針對的是數(shù)據(jù)庫方面，一個針對的是服務層的請求。
參考案例：springBoot對接kafka,批量、并發(fā)、異步獲取消息,并動態(tài)、批量插入庫表
圖片
若訂單系統(tǒng)耦合調用支付系統(tǒng)、庫存系統(tǒng)或者物流系統(tǒng)，一旦這三個系統(tǒng)發(fā)生故障，訂單系統(tǒng)就會處于不可用的狀態(tài)。如果轉變?yōu)橛孟㈥犃刑幚碚{用請求，可以減少很多問題。當故障發(fā)生時，子系統(tǒng)要處理的內存會被緩存在消息隊列中，而用戶的下單操作還是可以正常完成；故障處理完之后，再處理用戶的訂單信息即可。整個過程中的故障對于用戶來說是無感的，可以提高系統(tǒng)的可用性。
圖片
當A需要調用B，B需要花很長時間來處理調用，A需要得知B何時處理完畢。可以實現(xiàn)的方式很多，但是很不方便。使用消息隊列可以很輕松實現(xiàn)。只需要監(jiān)聽B處理完成的消息即可，當B處理完畢，將處理完畢的信息發(fā)送給消息隊列，之后消息隊列將消息反饋給A即可。這樣的方式，A既不用循環(huán)調用B的查詢API，也不需要B提供callback API(回調API)，同時B也不用完成這些操作；A還能及時得到B服務處理完成的信息。
參考案例：springBoot對接kafka,批量、并發(fā)、異步獲取消息,并動態(tài)、批量插入庫表
圖片
個人建議：對于大部分公司，可以優(yōu)選選擇使用RabbitMQ，其次選擇Kafka，相比Kafka，RabbitMQ適合對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場景，有消息確認機制和持久化機制，可靠性非常高。
圖片
本文鏈接：http://www.tebozhan.com/showinfo-26-14727-0.html聊聊消息中間件MQ
聲明：本網(wǎng)頁內容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號