張聰聰 孫二鑫

(中汽數(shù)據(jù)有限公司,天津 300384)

0 引言

隨著物聯(lián)網(wǎng)技術(shù)的飛速發(fā)展,車(chē)聯(lián)網(wǎng)技術(shù)作為物聯(lián)網(wǎng)在道路交通方面的具體體現(xiàn)也隨之發(fā)展壯大。目前我國(guó)車(chē)聯(lián)網(wǎng)產(chǎn)業(yè)鏈已初步形成,車(chē)聯(lián)網(wǎng)作為汽車(chē)產(chǎn)業(yè)轉(zhuǎn)型升級(jí)的創(chuàng)新驅(qū)動(dòng)力,具有極強(qiáng)的賦能效應(yīng)[1]。而共享出行市場(chǎng)從2015年發(fā)展至今,經(jīng)歷爆發(fā)式擴(kuò)張、又迅速收縮、質(zhì)疑、重整后,也在回歸理性和成熟,尤其在車(chē)聯(lián)網(wǎng)技術(shù)的共同發(fā)展下,更是加速了行業(yè)發(fā)展[2-3]。傳統(tǒng)的共享汽車(chē)模式一般是查看當(dāng)前可用車(chē)輛,然后進(jìn)行鎖定預(yù)約。這種模式不能有效提高車(chē)輛的使用率。本系統(tǒng)針對(duì)本企業(yè)的共享汽車(chē)需求及對(duì)系統(tǒng)穩(wěn)定性的要求,采用RabbitMQ消息隊(duì)列管理服務(wù),對(duì)預(yù)約審批流程進(jìn)行分布式高并發(fā)優(yōu)化,充分利用RabbitMQ自由路由、多協(xié)議、高可靠性等特點(diǎn)對(duì)不同時(shí)間點(diǎn)的不同流程任務(wù)進(jìn)行有效處理,對(duì)不同的消息特點(diǎn)進(jìn)行實(shí)時(shí)推送,完美的實(shí)現(xiàn)了動(dòng)態(tài)推送時(shí)間的消息推送方法,大幅提高了車(chē)輛的使用率,并有效的保障了系統(tǒng)的穩(wěn)定性。

1 RabbitMQ消息隊(duì)列介紹

消息隊(duì)列(Message Queue),是分布式系統(tǒng)中重要的組件,當(dāng)不需要立即獲得結(jié)果,但是并發(fā)量又需要進(jìn)行控制的時(shí)候,就是需要使用消息隊(duì)列的時(shí)候。比如活動(dòng)秒殺、多應(yīng)用并發(fā)、消息隊(duì)列主要解決了應(yīng)用耦合、異步處理、流量削鋒等問(wèn)題。當(dāng)前使用較多的消息隊(duì)列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等,而部分?jǐn)?shù)據(jù)庫(kù)如Redis、Mysql以及phxsql也可實(shí)現(xiàn)消息隊(duì)列的功能[4-6]。

RabbitMQ在是一個(gè)在A(yíng)MQP(高級(jí)消息隊(duì)列協(xié)議,Advanced Message Queuing Protocol)基礎(chǔ)上完成的、開(kāi)源的、可復(fù)用的消息隊(duì)列服務(wù)系統(tǒng),是當(dāng)前最主流的消息中間件之一。RabbitMQ有幾點(diǎn)特點(diǎn):(1)高可靠性,RabbitMQ提供了很多技術(shù)供開(kāi)發(fā)者在性能和可靠性之間進(jìn)行權(quán)衡;(2)靈活的路由,消息在到達(dá)隊(duì)列前是通過(guò)交換機(jī)進(jìn)行路由的。RabbitMQ為典型的路由邏輯提供了多種內(nèi)置交換機(jī)類(lèi)型,同時(shí)開(kāi)發(fā)者也可自由定制組合路由;(3)支持多種消息隊(duì)列協(xié)議;(4)管理界面,RabbitMQ有一個(gè)易用的豐富的用戶(hù)界面,使得用戶(hù)可以監(jiān)控和管理消息。本平臺(tái)綜合考慮采用RabbitMQ來(lái)實(shí)現(xiàn)共享汽車(chē)的預(yù)約審批業(yè)務(wù)消息推送。

2 面向共享汽車(chē)的消息推送

2.1 基于消息推送的共享汽車(chē)預(yù)約審批業(yè)務(wù)流程

本企業(yè)的共享汽車(chē)預(yù)約審批流程如圖1所示。用戶(hù)登錄手機(jī)端共享汽車(chē)APP,選擇取車(chē)網(wǎng)點(diǎn)和還車(chē)網(wǎng)點(diǎn)、預(yù)計(jì)取車(chē)時(shí)間和還車(chē)時(shí)間等信息進(jìn)行預(yù)約,服務(wù)端將生成“已預(yù)約待審核”的訂單,審批員登錄WEB端后臺(tái)管理系統(tǒng)進(jìn)行審批,如果審批通過(guò),訂單狀態(tài)為“已預(yù)約已審核”。在已預(yù)約待審批中狀態(tài)時(shí),用戶(hù)可隨時(shí)取消訂單。服務(wù)端自動(dòng)修改訂單狀態(tài)變?yōu)椤坝脩?hù)主動(dòng)取消”。如果到了取車(chē)時(shí)間點(diǎn)預(yù)約單還未審批,系統(tǒng)將自動(dòng)取消訂單,同時(shí)將訂單狀態(tài)修改為“預(yù)約超時(shí)自動(dòng)取消”。已經(jīng)審批通過(guò)的訂單,在預(yù)計(jì)取車(chē)時(shí)間點(diǎn)前30分鐘即可用車(chē),服務(wù)端將自動(dòng)判斷用戶(hù)是否可以取車(chē),如果可以取車(chē),則修改訂單狀態(tài)為“待取車(chē)”。在待取車(chē)狀態(tài)時(shí),用戶(hù)可開(kāi)始用車(chē)。如果訂單達(dá)到“待取車(chē)”狀態(tài),但到預(yù)計(jì)取車(chē)時(shí)間點(diǎn)還未取車(chē),則服務(wù)端自動(dòng)修改訂單狀態(tài)為“取車(chē)超時(shí)異?！?。如果已預(yù)約已審批的訂單,到還車(chē)時(shí)間還未取車(chē)的,則服務(wù)端會(huì)自動(dòng)取消該訂單,同時(shí)修改訂單狀態(tài)為“系統(tǒng)自動(dòng)取消”。

2.2 消息推送服務(wù)

從業(yè)務(wù)流程上看,共享汽車(chē)預(yù)約審批消息推送服務(wù)主要分為主動(dòng)式和觸發(fā)式兩種。主動(dòng)式服務(wù)通過(guò)WE B端或AP P端人員主動(dòng)發(fā)起請(qǐng)求,將消息推送給服務(wù)端或AP P端;觸發(fā)式服務(wù)則為根據(jù)所設(shè)定的條件,系統(tǒng)自動(dòng)判斷是否滿(mǎn)足要求,自動(dòng)觸發(fā)服務(wù),將消息發(fā)送給服務(wù)端或APP端。

(1)主動(dòng)式服務(wù):1)審批員對(duì)訂單進(jìn)行審批后,將審批結(jié)果主動(dòng)推送給用戶(hù)。2)當(dāng)訂單狀態(tài)變化時(shí),推送訂單變化后的數(shù)據(jù)信息給用戶(hù)。3)用戶(hù)主動(dòng)取消訂單,服務(wù)端應(yīng)將訂單取消,同時(shí)將車(chē)輛狀態(tài)改變,自動(dòng)判斷下一訂單是否滿(mǎn)足用車(chē)要求,進(jìn)入延時(shí)隊(duì)列。(2)觸發(fā)式服務(wù):1)用戶(hù)預(yù)約下單,到了取車(chē)時(shí)間點(diǎn)預(yù)約單還未審批,系統(tǒng)將自動(dòng)取消訂單。2)審批員審批通過(guò),在預(yù)計(jì)取車(chē)時(shí)間點(diǎn)前30分鐘時(shí),服務(wù)端自動(dòng)修改訂單狀態(tài)為“待取車(chē)”。3)訂單達(dá)到“待取車(chē)”狀態(tài),但到預(yù)計(jì)取車(chē)時(shí)間點(diǎn)還未取車(chē),則服務(wù)端自動(dòng)修改訂單狀態(tài)為“取車(chē)超時(shí)異?！?。4)已預(yù)約已審批的訂單,到還車(chē)時(shí)間還未取車(chē)的,則服務(wù)端會(huì)自動(dòng)取消該訂單,同時(shí)修改訂單狀態(tài)為“系統(tǒng)自動(dòng)取消”。

3 基于動(dòng)態(tài)推送時(shí)間的消息推送方法

3.1 消息推送流程

各訂單發(fā)起時(shí)間不同,預(yù)約時(shí)間也不盡相同,預(yù)計(jì)取車(chē)時(shí)間和還車(chē)時(shí)間也不一定都相同,但傳統(tǒng)的消息推送方法一般是同一隊(duì)列Queue中的消息將按照先進(jìn)先出方式進(jìn)入Consumer,無(wú)法滿(mǎn)足共享汽車(chē)消息平臺(tái)要求,因此平臺(tái)需要建立可動(dòng)態(tài)處理推送時(shí)間的消息推送機(jī)制。消息推送流程如圖2所示。

圖2 消息推送流程

當(dāng)用戶(hù)在WEB端或APP端進(jìn)行操作或在特定情況被觸發(fā)服務(wù)時(shí),一方面將執(zhí)行相關(guān)業(yè)務(wù)邏輯并將數(shù)據(jù)狀態(tài)持久化到數(shù)據(jù)庫(kù)中,另一方面將消息存入RabbitMQ隊(duì)列中,在特定條件下被Consumer消費(fèi)掉,在Consumer中再執(zhí)行對(duì)應(yīng)的業(yè)務(wù)邏輯并將數(shù)據(jù)持久化到數(shù)據(jù)庫(kù)中,一些業(yè)務(wù)還會(huì)生成新的消息存入RabbitMQ中,比如向APP端推送消息等。需要說(shuō)明的是,本平臺(tái)中消息一旦被消費(fèi)之后,即從隊(duì)列Queue中清除,不必二次消費(fèi),因此此動(dòng)態(tài)推動(dòng)時(shí)間的消息推送方法是點(diǎn)對(duì)點(diǎn)模式的。

3.2 功能實(shí)現(xiàn)

平臺(tái)基于Spring開(kāi)發(fā),因此使用Spring提供的相關(guān)功能組件進(jìn)行以上功能模塊開(kāi)發(fā):

(1)創(chuàng)建延時(shí)消息DTO。延時(shí)消息DTO包含消息id和消息到期時(shí)間targetDelayDate,targetDelayDate一般為觸發(fā)式服務(wù)中的時(shí)間節(jié)點(diǎn)。比如用戶(hù)預(yù)約下單,消息的到期時(shí)間targetDelayDate為取車(chē)時(shí)間。(2)發(fā)送消息和消費(fèi)消息。平臺(tái)通過(guò)RabbitTemplate類(lèi)的convertAndSend()方法將消息發(fā)送到指定的隊(duì)列和路由上,同時(shí)設(shè)置MessagePost Processor中的Expiration屬性值等于延時(shí)消息DTO的消息到期時(shí)間與當(dāng)前時(shí)間的時(shí)間差,避免消息一直存在隊(duì)列中。平臺(tái)設(shè)置有2種隊(duì)列,延時(shí)隊(duì)列DelayQueue和死信隊(duì)列DLXQueue(DLX:Dead Letter Exchange)。延時(shí)隊(duì)列DelayQueue屬于正常隊(duì)列,Consumer消費(fèi)者通過(guò)配置@RabbitListener注解從指定隊(duì)列中獲取到消息,同時(shí)通過(guò)@RabbitHandler的方法處理相關(guān)業(yè)務(wù)邏輯,例如圖示實(shí)線(xiàn)路徑。延時(shí)隊(duì)列DelayQueue2與DelayQueue1不同的是,添加參數(shù)配置隊(duì)列TTL(Time To Live),即通過(guò)來(lái)設(shè)定消息存活時(shí)間。當(dāng)隊(duì)列TTL時(shí)間過(guò)期時(shí),隊(duì)列中的所有消息就會(huì)變成死信被重新publish到DLXQueue死信隊(duì)列中,在DLXQueue死信隊(duì)列的消費(fèi)者處理方法中判斷當(dāng)前時(shí)間是否到達(dá)消息到期時(shí)間targetDelayDate,如果到達(dá)則正常執(zhí)行業(yè)務(wù)邏輯,如果沒(méi)有到達(dá)則將消息重新convert AndSend到對(duì)應(yīng)的隊(duì)列和路由中,例如圖示虛線(xiàn)路徑。這種循環(huán)將保證在一個(gè)T T L 時(shí)間段內(nèi),所有消息都將被Consumer消費(fèi)一次,這樣可以有效保證后進(jìn)入的消息需要先執(zhí)行的情況被及時(shí)消費(fèi),同時(shí)可根據(jù)消息的到期時(shí)間targetDelayDate來(lái)判斷消息是否需要真正的被Consumer消費(fèi)。(3)向APP端推送消息。平臺(tái)在一些特定情況下需要給APP端推送實(shí)時(shí)消息,比如審核消息等,平臺(tái)采用極光推送(JPush)服務(wù)進(jìn)行向APP端推送消息。極光推送,是一個(gè)面向普通開(kāi)發(fā)者開(kāi)放的,免費(fèi)的第三方消息推送服務(wù)。相較于websocket,作為平臺(tái)端和APP端間的實(shí)時(shí)通信,JPush更加便捷,開(kāi)發(fā)簡(jiǎn)單,時(shí)效性強(qiáng)。在平臺(tái)中,可簡(jiǎn)單的按照消息產(chǎn)生順序進(jìn)行推送消息,因此采用圖示實(shí)線(xiàn)路徑實(shí)現(xiàn)平臺(tái)到APP端的實(shí)時(shí)消息推送。

3.3 功能測(cè)試

本文的主要測(cè)試點(diǎn)是發(fā)送消息、消費(fèi)消息、向APP端推送消息三大部分。發(fā)送消息部分主要采用Junit進(jìn)行單元測(cè)試,主要測(cè)試用戶(hù)觸發(fā)的消息是否與RabbitMQ中消息數(shù)是否保持一致。消費(fèi)消息部分主要通過(guò)查看數(shù)據(jù)庫(kù)中相關(guān)業(yè)務(wù)邏輯狀態(tài)是否在預(yù)定時(shí)間改變。向APP端推送消息部分主要通過(guò)檢查JPush服務(wù)中的消息數(shù)是否與原邏輯一致。經(jīng)過(guò)測(cè)試統(tǒng)計(jì),消息推送成功率在100%,達(dá)到預(yù)期效果。

4 結(jié)語(yǔ)

本文基于共享汽車(chē)預(yù)約審核需求,利用靈活路由的RabbitMQ消息隊(duì)列服務(wù)提出了一種基于動(dòng)態(tài)推送時(shí)間的預(yù)約審核系統(tǒng),實(shí)現(xiàn)了任意時(shí)間下準(zhǔn)時(shí)推送消息的機(jī)制,為企業(yè)的共享汽車(chē)預(yù)約平臺(tái)提供高可靠性的保障,同時(shí)也為共享汽車(chē)的使用率提升提供了一種方向。