前言

在當(dāng)今互聯(lián)網(wǎng)時(shí)代，高效的用戶(hù)服務(wù)是提升用戶(hù)體驗(yàn)的關(guān)鍵。轉(zhuǎn)轉(zhuǎn)自研的客服IM系統(tǒng)作為用戶(hù)與客服溝通的橋梁，承擔(dān)著傳遞信息、解決問(wèn)題的關(guān)鍵角色。然而，消息數(shù)據(jù)的流轉(zhuǎn)并非一帆風(fēng)順，本文將深入探討IM系統(tǒng)在消息傳遞過(guò)程中遇到的問(wèn)題和挑戰(zhàn)，以及相應(yīng)的技術(shù)解決方案。

如圖是IM系統(tǒng)中一條消息的流轉(zhuǎn)鏈路：

IM消息流轉(zhuǎn)

相較于普通web系統(tǒng)，IM系統(tǒng)的消息數(shù)據(jù)流轉(zhuǎn)鏈路更長(zhǎng)、更復(fù)雜。從客戶(hù)端到服務(wù)端，再?gòu)姆?wù)端到另一個(gè)客戶(hù)端，任何一個(gè)環(huán)節(jié)的故障都可能導(dǎo)致消息延遲、丟失、亂序或重復(fù)，從而影響用戶(hù)體驗(yàn)。

網(wǎng)絡(luò)波動(dòng)和客戶(hù)端設(shè)備性能的不穩(wěn)定性是影響IM系統(tǒng)性能的主要因素，這些因素可能導(dǎo)致消息的實(shí)時(shí)性、可靠性和完整性受到威脅。

實(shí)時(shí)性

首當(dāng)其沖的就是消息延遲問(wèn)題：當(dāng)一條消息發(fā)出后，我們的系統(tǒng)需要確保這條消息最快被接收人感知并獲取到，并且保證資源消耗較少。這里關(guān)鍵的幾個(gè)點(diǎn)是：最快觸達(dá)，且耗費(fèi)資源少。

方案1：長(zhǎng)短輪詢(xún)

在PC web早期，大部分應(yīng)用都是采用“一問(wèn)一答”的請(qǐng)求響應(yīng)模式來(lái)獲取數(shù)據(jù)，IM系統(tǒng)采用客戶(hù)端輪詢(xún)的方式，定期、高頻輪詢(xún)獲取服務(wù)端的新消息。這種方式開(kāi)發(fā)成本較低、容易實(shí)現(xiàn)，但是高頻輪詢(xún)很多請(qǐng)求是無(wú)用請(qǐng)求，客戶(hù)端浪費(fèi)流量和電量，服務(wù)端資源壓力很大。

后來(lái)基于短輪詢(xún)進(jìn)化出長(zhǎng)輪詢(xún)模式，相較于前者，后者在請(qǐng)求時(shí)獲取到新數(shù)據(jù)時(shí)不會(huì)立即返回，而是在服務(wù)端保持連接等待一段時(shí)間，如果等待期間有新消息就立即返回響應(yīng)，長(zhǎng)輪詢(xún)僅僅解決了客戶(hù)端的無(wú)用消耗，但是服務(wù)端資源高負(fù)載情況依然未能解決。

方案2：WebSocket

隨著HTML5的出現(xiàn)，全雙工的WebSocket成為解決這一問(wèn)題的關(guān)鍵?；赪ebSocket實(shí)現(xiàn)的IM服務(wù)，客戶(hù)端和服務(wù)端只需要完成一次握手，就可以創(chuàng)建持久的長(zhǎng)連接，并進(jìn)行隨時(shí)的雙向數(shù)據(jù)傳輸。

經(jīng)過(guò)比較轉(zhuǎn)轉(zhuǎn)客服IM系統(tǒng)采用了WebSocket協(xié)議，具體使用方式見(jiàn)WebSocket使用。當(dāng)服務(wù)端接收到新消息時(shí)，可以通過(guò)建立的WebSocket連接，直接進(jìn)行推送，保證了消息到達(dá)的實(shí)時(shí)性。

可靠性

如圖是一條消息發(fā)送的核心步驟，整個(gè)過(guò)程中可以分為兩個(gè)部分，消息由客戶(hù)端發(fā)送到服務(wù)端(第1、2步)，服務(wù)端將消息推送至另一個(gè)客戶(hù)端(第3步)，發(fā)送過(guò)程中任何一步出現(xiàn)問(wèn)題都會(huì)導(dǎo)致消息發(fā)送失敗。

消息發(fā)送示例

如何保證消息觸達(dá)？

我們參考使用了TCP/IP協(xié)議中的ACK機(jī)制來(lái)實(shí)現(xiàn)防丟邏輯。ACK機(jī)制是TCP/IP協(xié)議三次握手重要的一環(huán)，用于確認(rèn)對(duì)方發(fā)送信息無(wú)誤。ACK響應(yīng)機(jī)制如下：

1. 發(fā)送者發(fā)送消息時(shí)會(huì)攜帶一個(gè)消息標(biāo)識(shí)符(此處使用發(fā)送方id和消息發(fā)送時(shí)間戳)、并在本地維護(hù)一個(gè)“等待ACK消息列表”
2. 接收者收到消息后對(duì)消息進(jìn)行存儲(chǔ)得到消息id
3. 隨后再將該標(biāo)識(shí)回傳給發(fā)送方(ACK消息)
4. 發(fā)送方收到ACK消息后將消息從“等待ACK消息列表”刪除
5. 當(dāng)發(fā)送方?jīng)]有在約定時(shí)間內(nèi)收到ACK消息時(shí)，就需要執(zhí)行失敗消息處理邏輯：自動(dòng)重發(fā)、客戶(hù)端標(biāo)記發(fā)送失敗等

服務(wù)端實(shí)現(xiàn)與客戶(hù)端稍有不同，服務(wù)端需要要維護(hù)全量用戶(hù)的消息，使用定時(shí)任務(wù)檢查等待ACK消息列表效率比較低，此處通過(guò)mq的延遲消息來(lái)實(shí)現(xiàn)：

當(dāng)消息發(fā)出時(shí)同時(shí)發(fā)送一個(gè)延遲mq，延遲消息被消費(fèi)時(shí)對(duì)應(yīng)的消息仍在等待ACK列表中，則表示消息未能在規(guī)定時(shí)間內(nèi)被確認(rèn)，需要進(jìn)行重試發(fā)送。

如圖為完整的ACK實(shí)現(xiàn)機(jī)制：

ACK機(jī)制

另外客戶(hù)端也會(huì)在頁(yè)面刷新、WebSocket重連時(shí)觸發(fā)http接口重新拉取當(dāng)前會(huì)話(huà)的所有消息進(jìn)行渲染，保證消息不丟失。

數(shù)據(jù)重復(fù)

消息重推解決了消息丟失的問(wèn)題，但是因?yàn)锳CK消息本身就可能會(huì)丟失從而導(dǎo)致消息重復(fù)，因此我們需要保證推送消息和重推消息有相同且唯一的消息id，接收方可以根據(jù)該消息id進(jìn)行數(shù)據(jù)去重。

發(fā)送方：客戶(hù)端使用發(fā)送人id和消息發(fā)送時(shí)間戳作為唯一的ACK標(biāo)識(shí)，傳遞給服務(wù)端。

服務(wù)端：使用雪花算法接收到的消息生成消息id，將ACK標(biāo)識(shí)與消息id建立映射關(guān)系；服務(wù)端再將消息id推送至發(fā)送方和接收方。

一個(gè)完整的消息發(fā)送流程如圖所示：

IM消息流轉(zhuǎn)

心跳機(jī)制

IM系統(tǒng)中接收和發(fā)送消息都是使用長(zhǎng)連接實(shí)現(xiàn)，但是如果連接斷開(kāi)，那發(fā)送和接收數(shù)據(jù)就會(huì)出現(xiàn)問(wèn)題。在客服業(yè)務(wù)中，人工客服席位有限，系統(tǒng)需要可靠的機(jī)制保證人工客服資源有效利用。

為此我們?cè)趹?yīng)用層設(shè)計(jì)心跳消息，使用該機(jī)制更新用戶(hù)當(dāng)前狀態(tài)、保證會(huì)話(huà)有序退出。

心跳機(jī)制設(shè)計(jì)如下：

客戶(hù)端

• 設(shè)置定時(shí)器，用戶(hù)建立連接后，定時(shí)發(fā)送(30s)心跳消息給服務(wù)端

服務(wù)端

• 接收心跳消息，更新心跳時(shí)間
• 設(shè)置定時(shí)任務(wù)，定時(shí)掃描在線(xiàn)用戶(hù)上次心跳時(shí)間，執(zhí)行以下邏輯

• 上次心跳時(shí)間超出30s，將其標(biāo)記為離線(xiàn)狀態(tài)，關(guān)閉連接，等待用戶(hù)重連
• 上次心跳時(shí)間超出2分鐘則認(rèn)為用戶(hù)已經(jīng)徹底離開(kāi)，執(zhí)行會(huì)話(huà)關(guān)閉邏輯釋放人工客服資源

應(yīng)用層心跳消息僅用于?；詈蜖顟B(tài)更新，因此數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)十分精簡(jiǎn)，不攜帶額外信息。

消息協(xié)議

在IM系統(tǒng)中消息格式的設(shè)計(jì)也十分重要，良好的數(shù)據(jù)格式可以準(zhǔn)確傳遞消息內(nèi)容并具有極高的可讀性。我們根據(jù)消息類(lèi)型和發(fā)送流向?qū)⑾?shù)據(jù)格式大致分為如下幾部分：

• 消息類(lèi)型：用于描述消息的用途、流向，如心跳消息、用戶(hù)/客服消息、系統(tǒng)消息等
• 客服id：接收或者發(fā)送消息的客服標(biāo)識(shí)
• 用戶(hù)id：接收或者發(fā)送消息的用戶(hù)標(biāo)識(shí)
• 消息內(nèi)容：實(shí)際的消息，與消息類(lèi)型相關(guān)

• 消息格式：用于描述用戶(hù)/客服消息格式，如文本、圖片、視頻、訂單卡片、優(yōu)惠券等
• 消息文本：消息的展示內(nèi)容

不同類(lèi)型的消息

結(jié)語(yǔ)

轉(zhuǎn)轉(zhuǎn)客服IM系統(tǒng)通過(guò)引入WebSocket協(xié)議、ACK機(jī)制、消息重推和數(shù)據(jù)去重等策略，有效應(yīng)保障了消息傳遞過(guò)程中的實(shí)時(shí)性、可靠性和完整性。這些技術(shù)的應(yīng)用，不僅提升了用戶(hù)與客服之間的溝通效率，也為轉(zhuǎn)轉(zhuǎn)平臺(tái)提供了更加穩(wěn)定、高效的服務(wù)支持。

在未來(lái)的發(fā)展中，我們將繼續(xù)優(yōu)化和完善，以應(yīng)對(duì)不斷變化的需求和用戶(hù)期望，為用戶(hù)提供更加優(yōu)質(zhì)的服務(wù)體驗(yàn)。