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