google的api key调用次数是多少_Sprint Boot如何基于Redis发布订阅实现异步消息系统的同步调用?...
前言
在很多互聯(lián)網(wǎng)應(yīng)用系統(tǒng)中,請(qǐng)求處理異步化是提升系統(tǒng)性能一種常用的手段,而基于消息系統(tǒng)的異步處理由于具備高可靠性、高吞吐量的特點(diǎn),因而在并發(fā)請(qǐng)求量比較高的互聯(lián)網(wǎng)系統(tǒng)中被廣泛應(yīng)用。與此同時(shí),這種方案也帶來了調(diào)用鏈路處理上的問題,因?yàn)榇蟛糠謶?yīng)用請(qǐng)求都會(huì)要求同步響應(yīng)實(shí)時(shí)處理結(jié)果,而由于請(qǐng)求的處理過程已經(jīng)通過消息異步解耦,所以整個(gè)調(diào)用鏈路就變成了異步鏈路,此時(shí)請(qǐng)求鏈路的發(fā)起者如何同步拿到響應(yīng)結(jié)果,就需要進(jìn)行額外的系統(tǒng)設(shè)計(jì)考慮。
為了更清晰地理解這個(gè)問題,小碼哥以最近正在做的共享單車的IOT系統(tǒng)為例,給大家來一張圖描述下,如圖所示:
在上述系統(tǒng)流程中,終端設(shè)備與服務(wù)端之間通過MQTT協(xié)議相連,而MQTT協(xié)議本質(zhì)上是一種異步消息的連接方式,因此業(yè)務(wù)應(yīng)用(如圖中的訂單系統(tǒng))發(fā)起開鎖請(qǐng)求后,IOT應(yīng)用系統(tǒng)會(huì)以MQTT協(xié)議的方式通過物聯(lián)網(wǎng)平臺(tái)(此處使用的是AWS IOT服務(wù))向設(shè)備發(fā)起開鎖下行消息,而這一過程在IOT應(yīng)用系統(tǒng)完成與物聯(lián)網(wǎng)平臺(tái)的交互后同步調(diào)用鏈路就結(jié)束了,因?yàn)槲锫?lián)網(wǎng)平臺(tái)與鎖設(shè)備之間通過MQTT消息服務(wù)異步解耦了,當(dāng)然物聯(lián)網(wǎng)平臺(tái)會(huì)通過一系列可靠消息機(jī)制來確保開鎖消息能夠發(fā)送到指定設(shè)備的監(jiān)聽MQTT隊(duì)列。而至于鎖設(shè)備是否能夠及時(shí)接收到開鎖下行MQTT消息,則取決于鎖設(shè)備當(dāng)時(shí)的移動(dòng)網(wǎng)絡(luò)情況。
鎖設(shè)備在收到MQTT開鎖消息后,會(huì)通過嵌入式軟件系統(tǒng)觸發(fā)硬件設(shè)備完成開鎖動(dòng)作,之后就需要通過MQTT上行消息將開鎖結(jié)果反饋到服務(wù)端,從而由服務(wù)端系統(tǒng)判斷是否創(chuàng)建騎行訂單并計(jì)算費(fèi)用。這一過程需要物聯(lián)網(wǎng)平臺(tái)監(jiān)聽指定鎖設(shè)備相應(yīng)的MQTT上行消息隊(duì)列,由于物聯(lián)網(wǎng)平臺(tái)需要與上萬個(gè)設(shè)備進(jìn)行連接,因而不可能將每一個(gè)鎖設(shè)備所產(chǎn)生的MQTT上行消息都直接轉(zhuǎn)發(fā)給Iot應(yīng)用系統(tǒng),因此在物聯(lián)網(wǎng)平臺(tái)可以將一類的設(shè)備MQTT消息轉(zhuǎn)發(fā)至特定的業(yè)務(wù)消息隊(duì)列中,例如開鎖上行消息,所有設(shè)備的MQTT開鎖響應(yīng)上行消息都可以轉(zhuǎn)發(fā)到表示開鎖響應(yīng)的Iot業(yè)務(wù)消息隊(duì)列,如“iot_upstream_lock_response”,這樣Iot業(yè)務(wù)系統(tǒng)則不需要再關(guān)注底層設(shè)備的MQTT消息,可以用更利于業(yè)務(wù)理解的方式去處理開鎖響應(yīng)結(jié)果。
現(xiàn)在的問題是通過MQTT協(xié)議的開鎖下行消息、上行消息已經(jīng)完全處于兩條不同的異步網(wǎng)絡(luò)鏈路,而鏈路的發(fā)起者此時(shí)卻需要同步等待開鎖結(jié)果,但是實(shí)際上同步鏈路早已在Iot應(yīng)用系統(tǒng)向物聯(lián)網(wǎng)平臺(tái)發(fā)送開鎖消息后就已經(jīng)完成,所以為了滿足調(diào)用方的同步請(qǐng)求/響應(yīng)需要就需要在Iot應(yīng)用系統(tǒng)的下發(fā)開鎖消息后進(jìn)行額外的同步阻塞等待,并監(jiān)聽開鎖響應(yīng)的Iot業(yè)務(wù)消息隊(duì)列“iot_upstream_lock_response”關(guān)于此次開鎖請(qǐng)求的上行消息,之后再結(jié)束掉之前的同步阻塞等待邏輯,從而實(shí)現(xiàn)向業(yè)務(wù)調(diào)用方返回實(shí)時(shí)開鎖響應(yīng)結(jié)果的同步調(diào)用效果。那么在上述流程中如何實(shí)施額外的同步阻塞以及如何進(jìn)行回調(diào)消息的監(jiān)聽呢?在接下來的內(nèi)容中就和大家一起探討具體的實(shí)施方案!
解決方案分析
以上問題在使用消息服務(wù)進(jìn)行異步解耦的應(yīng)用場(chǎng)景中是比較普遍的需求,由于異步調(diào)用鏈路非常長(zhǎng)所以通用的解決思路是在調(diào)用鏈的起始端進(jìn)行同步阻塞,而在調(diào)用鏈的結(jié)束端通過回調(diào)的方式來實(shí)現(xiàn),如下圖所示:
在上述圖示中,鏈路起始隊(duì)列處在發(fā)送第一次異步消息后會(huì)開啟一個(gè)臨時(shí)隊(duì)列并同步阻塞監(jiān)聽該臨時(shí)隊(duì)列的回調(diào)消息,而鏈路的結(jié)束隊(duì)列在完成邏輯處理后需要回調(diào)起始隊(duì)列監(jiān)聽的臨時(shí)隊(duì)列,而由于請(qǐng)求線程一直處于阻塞監(jiān)聽該臨時(shí)隊(duì)列的狀態(tài),所以一旦收到回調(diào)消息就可以結(jié)束阻塞執(zhí)行后續(xù)流程,從而完成整個(gè)鏈路的同步響應(yīng)。
雖然常見的消息中間件都可以實(shí)現(xiàn)以上邏輯,例如小碼哥之前所在的公司就基于RabbitMQ通過臨時(shí)隊(duì)列的方式實(shí)現(xiàn)過消息鏈路的同步調(diào)用,但是基于消息中間件的方式多少還是顯得有些繁瑣,對(duì)于常見的消息中間件如RocketMQ、RabbitMQ來說異步消息才是其強(qiáng)項(xiàng),如果以大量臨時(shí)隊(duì)列的創(chuàng)建和銷毀為代價(jià)來實(shí)現(xiàn)消息調(diào)用鏈路的同步,不僅從使用上來說顯得有些麻煩,并且也會(huì)對(duì)消息中間件的穩(wěn)定性帶來一些不好的影響。
因此在前面提到的IOT系統(tǒng)中,我們采用了基于Redis的發(fā)布/訂閱功能來實(shí)現(xiàn)異步消息鏈路的同步化調(diào)用。而由于Redis的高性能以及Redis的應(yīng)用場(chǎng)景非常豐富,并且非常適合數(shù)據(jù)頻繁變動(dòng)的場(chǎng)景,在系統(tǒng)中既可以作為NoSQL數(shù)據(jù)庫(kù)來使用,同時(shí)還支持分布式鎖等功能,因而維護(hù)的性價(jià)比也相對(duì)較高。接下來我們就基于Spring Boot的開發(fā)框架來演示如何利用Redis的發(fā)布/訂閱來實(shí)現(xiàn)異步消息鏈路的同步回調(diào)!
Redis發(fā)布訂閱機(jī)制
Redis本身可以通過發(fā)布訂閱機(jī)制實(shí)現(xiàn)一定的消息隊(duì)列功能,在Redis中通過subscribe/publish等命令可以實(shí)現(xiàn)發(fā)布訂閱功能,基于此原先的IOT系統(tǒng)處理示意圖如下:
如上圖所示,在IOT應(yīng)用端發(fā)送異步MQTT消息后會(huì)以消息ID組成的Key作為頻道****,并保持請(qǐng)求線程對(duì)該頻道的同步監(jiān)聽,直到收到Iot業(yè)務(wù)消息隊(duì)列的開鎖結(jié)果上行消息后,在消息隊(duì)列的消費(fèi)端將該上行消息發(fā)布至同樣以消息requestId組成的頻道中,從而實(shí)現(xiàn)基于Redis發(fā)布訂閱機(jī)制的異步消息系統(tǒng)同步調(diào)用效果。
Spring Boot代碼實(shí)現(xiàn)
下面我們基于Spring Boot演示如何通過代碼進(jìn)行實(shí)現(xiàn),創(chuàng)建Spring Boot工程后引入Spring Boot Redis集成依賴包,如下:
<!--之后在項(xiàng)目的配置文件中添加Redis服務(wù)連接信息,如下所示:
spring:此時(shí)項(xiàng)目就具備了訪問Redis的能力,接下來我們通過具體的代碼實(shí)現(xiàn)來進(jìn)行功能演示。訂閱監(jiān)聽代碼如下:
@RestController在上述代碼中,我們模擬了一個(gè)開鎖請(qǐng)求,在完成異步消息處理后會(huì)開啟Redis訂閱監(jiān)聽,為了實(shí)現(xiàn)異步阻塞還需要我們創(chuàng)建消息任務(wù)對(duì)象,代碼如下:
public在消息任務(wù)對(duì)象中我們通過JDK1.8新提供的CompletableFuture類實(shí)現(xiàn)線程阻塞效果,并通過定義消息監(jiān)聽對(duì)象及超時(shí)時(shí)間完善處理機(jī)制。此外根據(jù)Controller層代碼還需要自定義定義消息監(jiān)聽處理對(duì)象,代碼如下:
public此時(shí)就完成了Redis服務(wù)訂閱這部分邏輯的編寫,在后續(xù)的邏輯處理中需要完成消息的發(fā)布才能正常結(jié)束此處的阻塞等待,接下來我們寫一段代碼來模擬消息發(fā)布,代碼如下:
@RestController此時(shí)啟動(dòng)Spring Boot應(yīng)用調(diào)用開鎖模擬接口,邏輯就會(huì)暫時(shí)處于訂閱等待狀態(tài);之后再模擬調(diào)用開鎖回調(diào)Redis消息發(fā)布邏輯,之前的阻塞等待就會(huì)因?yàn)楸O(jiān)聽回調(diào)而完成同步返回。
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯,堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)總結(jié)
以上是生活随笔為你收集整理的google的api key调用次数是多少_Sprint Boot如何基于Redis发布订阅实现异步消息系统的同步调用?...的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: axure 组件_技巧分享 | Axur
- 下一篇: 互联网加大赛历届作品_匠心筑梦 ——家具