一加Ace2 Pro官宣：普及16G內(nèi)存 引領(lǐng)24G
一加官方今天繼續(xù)為本月發(fā)布的新機一加Ace2 Pro帶來預(yù)熱，公布了內(nèi)存方面的信息。“淘汰 8GB ，12GB 起步，16GB 普及，24GB 引領(lǐng)，還有呢？#一加Ace2Pro#，2023 年 8 月，敬請期待。”同時
就程序員而言，日后的職業(yè)發(fā)展可以走 3 個方向：專攻技術(shù)深度、轉(zhuǎn)團(tuán)隊管理、晉升架構(gòu)師。
成為一名優(yōu)秀的架構(gòu)師，是大多數(shù)技術(shù)人的追求。但資深架構(gòu)師的出現(xiàn)幾率僅約為 0.3%。
如果想在 3-5 年后穩(wěn)坐金字塔尖，必須有扎實的代碼功底和項目積累，也要意識地培養(yǎng)技術(shù)廣度和架構(gòu)思維能力。多學(xué)習(xí)牛人經(jīng)驗也可獲益良多。
圖片
同步調(diào)用是指在請求發(fā)起后，調(diào)用方一直阻塞等待調(diào)用處理完成的過程。在所提供的例子中，客戶端代碼 ClientCode 需要執(zhí)行發(fā)送郵件的操作 sendEmail，這會觸發(fā)對 EmailService 的調(diào)用。
EmailService 將調(diào)用 SmtpEmailAdapter 類來處理請求，而該類會通過 SMTP 和 TCP 協(xié)議調(diào)用遠(yuǎn)程服務(wù)，將請求發(fā)送到遠(yuǎn)程服務(wù)器。遠(yuǎn)程服務(wù)器收到消息后，會執(zhí)行一系列操作，然后將郵件發(fā)送出去，并返回結(jié)果。
Adapter 接收到返回后，再將結(jié)果返回給 EmailService。EmailService 收到返回結(jié)果后，再將其返回給 ClientCode。在整個 sendEmail 過程中，ClientCode 會一直阻塞等待最終調(diào)用結(jié)果的返回，以確定操作是成功還是失敗。由于這個等待過程是阻塞的，因此被稱為同步調(diào)用。
02 異步調(diào)用
異步調(diào)用與同步調(diào)用相反。在異步調(diào)用的過程中，以發(fā)送郵件的例子為例，用戶 ClientCode 調(diào)用 EmailService 后，EmailService 將調(diào)用請求發(fā)送到消息隊列，然后立即返回。
ClientCode 在收到返回后可以繼續(xù)向下處理，而不會繼續(xù)阻塞等待。實際上，消息被發(fā)送到隊列后，尚未被處理。在后續(xù)的消息消費階段，比 EmailService 的返回可能會稍晚一些。有一個消息隊列消費者 QueueConsumer 從消息隊列中取出消息，然后將其發(fā)送給 SmtpAdapter，即調(diào)用 SmtpAdapter。
處理邏輯與同步調(diào)用類似，SmtpAdapter 通過 SMTP 通信協(xié)議將消息發(fā)送到遠(yuǎn)程服務(wù)器，執(zhí)行郵件發(fā)送操作，通過 RemoteServer 進(jìn)行處理。處理完成后，收到返回結(jié)果后通知消息隊列 Queue。
在這個過程中，客戶端的調(diào)用（即應(yīng)用程序的調(diào)用）和實際的業(yè)務(wù)邏輯（發(fā)送郵件的操作）是異步的。在郵件發(fā)送操作的處理過程中，客戶端代碼已經(jīng)返回，它可以繼續(xù)執(zhí)行自己的后續(xù)操作，而不需要等待郵件的發(fā)送完成，這就是異步調(diào)用。
圖片
使用異步調(diào)用架構(gòu)的主要手段之一是通過消息隊列來構(gòu)建。以下是該架構(gòu)的圖示：
使用消息隊列構(gòu)建一個異步調(diào)用架構(gòu)，你需要了解3種角色，一種是消息的生產(chǎn)者，一種是消息隊列，還有一種是消息的消費者。
消息的生產(chǎn)者是客戶端應(yīng)用程序代碼的一部分，用來初始化異步調(diào)用處理流程。
在基于消息隊列的處理中，生產(chǎn)者的職責(zé)非常少，它要做的就是創(chuàng)建一個合法的消息，并把這個消息發(fā)送到消息隊列中，由應(yīng)用開發(fā)者決定生產(chǎn)者的代碼在哪里執(zhí)行，什么時候發(fā)送消息。
消息隊列是消息發(fā)送的目的地，也是消息發(fā)給消費者的一個緩沖區(qū)。實現(xiàn)消息隊列的方法有很多種，可以使用共享文件夾，也可以利用關(guān)系數(shù)據(jù)庫或者 NoSQL 系統(tǒng)。
然而，最主要且常見的做法是使用專門的分布式消息隊列服務(wù)器。這些消息隊列服務(wù)器被設(shè)計用于高效地存儲、傳遞和處理大量的異步消息。它們提供了可靠性、可伸縮性和高性能的特性，以滿足不同應(yīng)用場景的需求。
一些流行的分布式消息隊列系統(tǒng)包括：
業(yè)務(wù)架構(gòu)的第三個重要角色就是消息的消費者。消息的消費者從消息隊列中接受并處理消息，消息的消費者也是由應(yīng)用開發(fā)者實現(xiàn)的，但是它是一個異步處理的組件。
圖片
消息的消費者不需要知道生產(chǎn)者存在，它只依賴消息隊列中的消息。消息的消費者通常部署在獨立的服務(wù)器上，和消息的生產(chǎn)者完全隔離，并且可以通過添加硬件的方式進(jìn)行伸縮。
圖片
點對點模型是一種消息傳遞模型，其中消費者和生產(chǎn)者只需知道消息隊列的名稱。在這種模型中，生產(chǎn)者將消息發(fā)送到消息隊列，而消息隊列的另一端有多個消費者競爭消費消息。
圖片
每個到達(dá)消息隊列的消息只會被路由到一個消費者，因此每個消費者看到的是全部消息的一個子集。
在這張圖中，有多個消息生產(chǎn)者和多個消息消費者。多個生產(chǎn)者將消息發(fā)送到消息隊列，而多個消費者在消息隊列中競爭性地消費消息。
每條消息只會被一個消費者消費，每個消費者只會消費消息隊列中的一部分消息。這種點對點的模型適用于需要確保每條消息只被一個接收者處理的場景，以及在消息生產(chǎn)者和消費者之間實現(xiàn)解耦的需求。
在發(fā)布訂閱模型中，消息可能被發(fā)送到不止一個消費者，生產(chǎn)者發(fā)送消息到一個主題，而不是隊列中。
消息被發(fā)布到主題后，就會被克隆給每一個訂閱它的消費者，每個消費者接收一份消息復(fù)制到自己的私有隊列。
消費者可以獨立于其他消費者使用自己訂閱的消息，消費者之間不會競爭消息。
常用的分布式消息隊列都支持發(fā)布訂閱模型，也就是說消息的發(fā)布訂閱模型是分布式消息隊列的一個功能特性。
圖片
兩種消息傳遞模型通常會根據(jù)業(yè)務(wù)需求和特點進(jìn)行選擇。點對點模型適用于一些耗時較長、邏輯相對獨立的業(yè)務(wù)場景，例如發(fā)送郵件。因為發(fā)送郵件是一個比較耗時的操作，應(yīng)用程序?qū)τ卩]件發(fā)送是否成功并不太關(guān)心，而且發(fā)送郵件的邏輯相對獨立。在這種情況下，應(yīng)用程序只需要把郵件消息放入消息隊列中就可以立即返回。消費者則只需從消息隊列中取出郵件消息進(jìn)行處理，通過遠(yuǎn)程服務(wù)器將郵件發(fā)送出去。由于每封郵件只需要被發(fā)送一次，因此消息只需要被一個消費者消費即可。
圖片
相反，對于一些需要多個消費者協(xié)同處理的、涉及多個步驟的業(yè)務(wù)，例如新用戶注冊，通常會選擇發(fā)布訂閱模型。新用戶注冊成功后，可能需要發(fā)送激活郵件、歡迎短信，將用戶注冊數(shù)據(jù)寫入數(shù)據(jù)庫，并將新用戶信息發(fā)送給關(guān)聯(lián)企業(yè)的系統(tǒng)，以實現(xiàn)一次注冊即可登錄多個關(guān)聯(lián)產(chǎn)品的需求。在這種情況下，可以使用按主題發(fā)布的方式，即發(fā)布訂閱模型。新用戶注冊消息可以發(fā)布到一個主題，多個消費者可以訂閱這個主題，分別處理不同的任務(wù)，如發(fā)送郵件、發(fā)送短信、寫入數(shù)據(jù)庫等。這種模型允許多個消費者同時對同一消息進(jìn)行處理，實現(xiàn)了業(yè)務(wù)邏輯的解耦和靈活性的提高。
本文鏈接：http://www.www897cc.com/showinfo-26-55165-0.html同步架構(gòu)和異步架構(gòu)的區(qū)別，你知道嗎？
聲明：本網(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號