中興AX5400Pro+上手體驗(yàn)：再升級(jí) 雙2.5G網(wǎng)口+USB 3.0這次全都有
2021年11月的時(shí)候，中興先后發(fā)布了兩款路由器產(chǎn)品，中興AX5400和中興AX5400 Pro，從產(chǎn)品命名上就不難看出這是隸屬于同一系列的，但在外觀設(shè)計(jì)上這兩款產(chǎn)品可以說是完全沒一點(diǎn)關(guān)系
消息隊(duì)列作為互聯(lián)網(wǎng)互聯(lián)網(wǎng)項(xiàng)目的一個(gè)可選中間件，被很多的項(xiàng)目、產(chǎn)品采用。就算你沒用過，肯定也多少了解一些，因?yàn)樗乾F(xiàn)代面試八股文必考科目之一。
消息隊(duì)列這個(gè)很形象，就是把消息推到一個(gè)隊(duì)列中，然后再到這個(gè)隊(duì)列里讀，是不是就這么簡(jiǎn)單。
圖片
聽說消息隊(duì)列最有用的功能是異步和解耦，而什么消峰填谷、分布式事務(wù)都是錦上添花而已。
RocketMQ 是阿里巴巴開發(fā)，現(xiàn)在已經(jīng)是 Apache 軟件基金會(huì)的頂級(jí)項(xiàng)目。RocketMQ 是用 Java 開發(fā)，很多使用 Java 技術(shù)棧的公司都用 RocketMQ 作為消息隊(duì)列。我們就主要使用 RocketMQ 作為消息隊(duì)列服務(wù)。
RabbitMQ 是一個(gè)開源的消息代理軟件，它采用了高級(jí)消息隊(duì)列協(xié)議（AMQP），用于在分布式系統(tǒng)中實(shí)現(xiàn)異步通信和消息傳遞，采用 Erlang 語(yǔ)言開發(fā)。最開始學(xué)習(xí)消息隊(duì)列就是用的 RabbitMQ。
pache Kafka 是一個(gè)分布式流處理平臺(tái)，最初由 LinkedIn 開發(fā)，并于2011年開源，之后成為 Apache 軟件基金會(huì)的頂級(jí)項(xiàng)目。Kafka 旨在處理實(shí)時(shí)數(shù)據(jù)流，具有高吞吐量、低延遲和高可靠性的特點(diǎn)，廣泛應(yīng)用于日志收集、流處理、數(shù)據(jù)集成等場(chǎng)景。
Apache ActiveMQ 是一個(gè)開源的消息代理和集成模式服務(wù)器，由 Apache 軟件基金會(huì)開發(fā)。ActiveMQ 在形式上和 RabbitMQ 比較像，ActiveMQ 也是用 Java 開發(fā)的。
除此之外，其實(shí) Redis 也可以做消息隊(duì)列。
消息隊(duì)列最厲害的地方并不是采用的技術(shù)有多厲害，而是它的應(yīng)用場(chǎng)景，只要把它加到某些應(yīng)用場(chǎng)景中，有很多問題都可以迎刃而解。所以說，它厲害在思想上。
說到異步就離不開解耦，說到解耦又脫離不了異步。
什么是異步呢？假設(shè)有個(gè)系統(tǒng)需要處理一個(gè)長(zhǎng)流程，最常見的例子就是下單場(chǎng)景，用戶下單購(gòu)買商品，后臺(tái)服務(wù)要在這個(gè)下單行為發(fā)生后做一系列的事情，要減庫(kù)存、加到用戶已購(gòu)買列表中、發(fā)通知、跟蹤訂單進(jìn)度等。
這一系列的動(dòng)作如果全都同步來做，那響應(yīng)時(shí)間會(huì)比較久，而且一旦其中某個(gè)環(huán)節(jié)失敗，將會(huì)更加麻煩。
所以針對(duì)類似的場(chǎng)景，就有了異步處理的思路，在同步響應(yīng)中只把最重要的動(dòng)作完成，剩下的都可以異步處理，比如購(gòu)買行為，收錢和減庫(kù)存是最重要的，這兩個(gè)成功了就算是購(gòu)買成功了，剩下的通知、跟蹤進(jìn)度都可以稍后進(jìn)行，也就是異步處理。
說到此，解耦也就出現(xiàn)了，收錢和減庫(kù)存可以是一個(gè)線程來做，或者一個(gè)單獨(dú)的服務(wù)來做，發(fā)通知又可以是另一個(gè)線程或者另一個(gè)服務(wù)來做，這樣一來，兩個(gè)動(dòng)作、兩個(gè)功能就解耦了，發(fā)通知的服務(wù)掛了不會(huì)影響真正的購(gòu)買行為，而等到發(fā)通知服務(wù)啟動(dòng)后，可以再處理歷史數(shù)據(jù)也沒問題。
這個(gè)場(chǎng)景下，用到消息隊(duì)列再合適不過。而且聽說，這個(gè)場(chǎng)景才是消息隊(duì)列有價(jià)值的地方，也是消息隊(duì)列思想的靈魂所在。
流量削峰是在高并發(fā)情況下，通過消息隊(duì)列將大量請(qǐng)求排隊(duì)處理，避免系統(tǒng)在短時(shí)間內(nèi)被大量請(qǐng)求壓垮。
假設(shè)一個(gè)系統(tǒng)本來日常只支持1萬(wàn)并發(fā)，但是某個(gè)時(shí)候突然有大量的用戶進(jìn)來，流量超過了系統(tǒng)所能承受的最大值，如果不加以控制，那等待系統(tǒng)的只有崩潰。
這種情況下，系統(tǒng)可以將處理不了的請(qǐng)求暫時(shí)放到消息隊(duì)列中，然后在系統(tǒng)所能支持的并發(fā)下依次處理隊(duì)列中的請(qǐng)求。這樣一來，系統(tǒng)既不會(huì)崩潰，也能將請(qǐng)求都一一處理掉。
當(dāng)然了，如果沒有消息隊(duì)列，本身系統(tǒng)也可以采取其他的處理措施，比如直接將請(qǐng)求丟棄，或者返回一個(gè)固定值。比如某些搶購(gòu)場(chǎng)景，本來就有數(shù)量限制，只有最先進(jìn)來的請(qǐng)求才能搶到，后面不管再進(jìn)來多少都搶不到，那后面多余的請(qǐng)求就沒必要處理。
很多公司都有專門的日志查看平臺(tái)，例如 Kibana，公司內(nèi)所有項(xiàng)目都會(huì)歸集到統(tǒng)一的地方，通過界面點(diǎn)點(diǎn)按鈕就能看到不同項(xiàng)目的日志了。
這背后的原理就是將用戶行為日志發(fā)送到消息隊(duì)列，再由專門的日志處理服務(wù)進(jìn)行分析和處理。自從 Kafka 一出來，再用消息隊(duì)列傳輸日志就好像被它壟斷了。沒辦法，誰(shuí)讓人家在這方面有特長(zhǎng)呢。
分布式事務(wù)通俗來說就是要么都成功，要么都不成功。
還是拿訂單系統(tǒng)為例，在訂單創(chuàng)建后，通過消息隊(duì)列通知庫(kù)存系統(tǒng)進(jìn)行庫(kù)存扣減，以保證數(shù)據(jù)的一致性。
下圖是 RocketMQ 中關(guān)于分布式事務(wù)的流程圖，我們之前的項(xiàng)目中一直用這種方式做分布式事務(wù)處理。
圖片
這是有些消息隊(duì)列本身支持的特性，只有本地事務(wù)完全成功執(zhí)行后，才會(huì)最終投遞消息，否則消費(fèi)者是看不到這個(gè)消息的。
比如我們?cè)?12306買票，預(yù)訂后鎖票，有30分鐘時(shí)間用來付款，這30分鐘內(nèi)，其他人是沒辦法看到這張票的。如果30分鐘內(nèi)未付款，那這張票就不屬于你了。
這種場(chǎng)景就是延時(shí)任務(wù)的經(jīng)典場(chǎng)景，每一個(gè)預(yù)訂都會(huì)有自己的一個(gè)任務(wù)，這種任務(wù)和系統(tǒng)定時(shí)在某時(shí)某刻的定時(shí)任務(wù)是完全不一樣的。
就是因?yàn)槊恳粋€(gè)預(yù)訂都有一個(gè)任務(wù)，總不能來一個(gè)任務(wù)就給系統(tǒng)加一個(gè)定時(shí)任務(wù)吧，這不現(xiàn)實(shí)。所以這種場(chǎng)景下，用延時(shí)隊(duì)列就最合適了，有些消息隊(duì)列是支持的。
在消息生產(chǎn)者投遞消息時(shí)，給消息一個(gè)延遲時(shí)間，只有到了規(guī)定的延遲時(shí)間后，這個(gè)消息才能被消費(fèi)者消費(fèi)掉。
消息隊(duì)列最厲害的地方在于它的思想，而不在于它使用的具體技術(shù)。
消息隊(duì)列的應(yīng)用場(chǎng)景眾多，但是這么多應(yīng)用場(chǎng)景中我覺得異步和解耦才是最重要的能力，你覺得呢？
本文鏈接：http://www.www897cc.com/showinfo-26-100337-0.html聽說異步和解耦才是消息隊(duì)列最有價(jià)值的功能
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)