現代IM系統中的消息系統架構——實現篇

序

消息類場景是表格存儲（Tablestore）主推的方向之一，因其數據存儲結構在消息類數據存儲上具有天然優勢。爲了方便用戶基於Tablestore爲消息類場景建模，Tablestore封裝Timeline模型，旨在讓用戶更快捷的實現消息類場景需求。在推出Timeline（v1、v2兩個版本）模型以來，受到了大量用戶關注。伴隨模型推廣與輸出，Tablestore陸續發佈了一系列專題文章，重點討論介紹了IM場景的架構設計、模型概念以及Feed 流系統架構的設計方案，相信給很多用戶提供了場景實現新思路。文章列表見《表格存儲權威指南》。

但依然會有用戶困惑，“框架、結構、模型等概念介紹了這麼多，該如何基於Timeline模型，實現具體場景呢？”。

本文就是爲了讓用戶更快速的上手，帶用戶基於Timeline2.0 模型，詳細講解如何實現一個簡易的IM系統。並開源了相應的實現代碼。源碼鏈接

梗概

生活中最常見的即時聊天類軟件如：釘釘、微信等，都可以描述爲：實現了即時通訊能力的聊天工具。其中聊天會話可分爲兩大類，分別是：單聊、羣聊（公衆號類似單聊）。這裏我們以釘釘（Ding Talk）的功能爲參照，詳細說明相應的功能基於Tablestore的Timeline模型如何實現。如：新消息提醒，未讀消息數統計，查看會話中更久的聊天內容，羣名模糊檢索，關鍵字查詢歷史記錄，以及多客戶端同步等。讓用戶在實現方案上有更清晰的認識，對模型的抽象概念、接口有更好的理解。

下面會按照聊天系統的功能模塊分段，分別介紹每一部分的功能、方案介紹、表設計以及實現代碼等。功能模塊主要分爲：消息存儲、關係維護、即時感知、多端同步。

功能模塊

消息存儲

消息系統中，消息存儲是最基本的功能。對於消息存儲（提供消息的讀、寫、持久化），一方面需要持久化寫入，保證消息數據的不丟失，另一方面，適合用戶的快速、高效查詢。在IM場景中，寫入方式通常是單行、批量寫入，而讀取需要按照消息隊列範圍讀取。有時用戶還有對於歷史消息的模糊查詢需求，這時就需要使用多維檢索、全文檢索的能力。

消息的存儲都是基於Timeline模型，具體模型見文章《Tablestore發佈Timeline 2.0模型》。樣例中，消息數據的表結構見下圖：

表設計：im_timeline_store_table

存儲庫

功能：會話窗口消息展示

存儲庫是聊天會話消息所對應的存儲表，消息以會話分類存儲，每個會話是一個消息隊列。單個消息隊列（TimelineQueue）通過timelineId唯一標識，所有消息基於sequenceId有序排列。消息體中含有發送人、消息id（消息去重）、消息發送時間、消息體內容、消息類型（類型包含圖片、文件、普通文本，本文僅適用文本）等。

圖片來自公開交流羣截圖

如上圖，當用戶點擊某一個會話時，窗口會展示相應會話的最新一頁消息。圖片裏的消息都是從存儲庫拉取的，通過timelineId獲取該會話的Queue實例，然後調用Queue的scan接口與ScanParam參數（sequenceId範圍+倒序）拉取最新的一頁消息。當用戶向上滾動，展示完這一頁消息後，客戶端會基於第一次請求的最小sequencId發起第二次請求，獲取第二頁消息記錄，單頁消息數通常選擇20-30條。會話的消息可以選擇在客戶端持久化，然後在感知到新消息之後更新本地消息，增加緩存減少網絡IO。

核心代碼

    public List<AppMessage> fetchConversationMessage(String timelineId, long sequenceId) {
        TimelineStore store =  timelineV2.getTimelineStoreTableInstance();

        TimelineIdentifier identifier = new TimelineIdentifier.Builder()
                .addField("timeline_id", timelineId)
                .build();

        ScanParameter parameter = new ScanParameter()
                .scanBackward(sequenceId)
                .maxCount(30);

        Iterator<TimelineEntry> iterator = store.createTimelineQueue(identifier).scan(parameter);

        List<AppMessage> appMessages = new LinkedList<AppMessage>();
        while (iterator.hasNext() && counter++ <= 30) {
            TimelineEntry timelineEntry = iterator.next();
            AppMessage appMessage = new AppMessage(timelineId, timelineEntry);

            appMessages.add(appMessage);
        }

        return appMessages;
    }

存儲庫的消息需要永久保存，是整個應用的全量消息存儲。存儲庫數據過期時間（TTL）需要設爲-1。

功能：多維組合、全文檢索

全文檢索能力就是對存儲庫的消息內容做模糊查詢，因而需要對存儲庫的數據建立多元索引。具體索引字段，需要根據設計需求設計。如釘釘公開羣的檢索，需要對羣ID、消息發送人、消息類型、消息內容、以及時間建立索引，其中消息內容需要使用分詞字符串類型，從而提供模糊查詢的能力。

核心代碼

public List<AppMessage> fetchConversationMessage(String timelineId, long sequenceId) {
    TimelineStore store =  timelineV2.getTimelineStoreTableInstance();

    TimelineIdentifier identifier = new TimelineIdentifier.Builder()
            .addField("timeline_id", timelineId)
            .build();

    ScanParameter parameter = new ScanParameter()
            .scanBackward(sequenceId)
            .maxCount(30);

    Iterator<TimelineEntry> iterator = store.createTimelineQueue(identifier).scan(parameter);

    List<AppMessage> appMessages = new LinkedList<AppMessage>();
    int counter = 0;
    while (iterator.hasNext() && counter++ <= 30) {
        TimelineEntry timelineEntry = iterator.next();
        AppMessage appMessage = new AppMessage(timelineId, timelineEntry);

        appMessages.add(appMessage);
    }

    return appMessages;
}

另外，爲了做消息的權限管理，僅允許用戶檢索自己有權限查看的消息，可在消息體字段中擴展接收人ID數組，這樣對所有羣做檢索時，需要增加接收人字段爲自己的用戶ID這一必要條件，即可實現消息內容的權限限制。樣例中沒有實現這一功能，用戶可根據需求自己增加、修改。

同步庫

功能：新消息即時統計

當客戶端在線時，應用的系統服務會維護客戶端的長連接，因而可以感知客戶端在線。當用戶的同步庫有新消息寫入時（即有新消息），應用會發出信號通知客戶端有新消息，然後客戶端會基於同步庫checkpoint點，拉取同步庫中該sequenceId之後的所有新消息，統計各會話的新消息數，並更新checkpoint點。

如上圖，對於一個在線客戶端，每個會話都會維護一個未讀消息的計數（小紅點），也會有一個總未讀數的計數，這個數量一般會存儲在客戶端本地，或者通過redis持久化。這些未讀消息，指的就是通過同步庫拉取並統計過，但是還未被用戶點開的消息數量。在拉取到新消息列表後，客戶端（或應用層）會遍歷所有新消息，然後將新消息所對應會話的未讀計數累加1，這樣實現了未讀消息的即時感知與更新。只有當用戶點開會話後，會話的未讀計數纔會清零。

在更新未讀數的同時，會話列表中還會有最新消息的簡短摘要信息以及最新消息的發送時間等。這些可以在遍歷新消息列表時不斷更新。這些統計、摘要都是依託同步庫，而非存儲庫實現的。

核心代碼

public List<AppMessage> fetchSyncMessage(String userId, long lastSequenceId) {
    TimelineStore sync =  timelineV2.getTimelineSyncTableInstance();

    TimelineIdentifier identifier = new TimelineIdentifier.Builder()
            .addField("timeline_id", userId)
            .build();

    ScanParameter parameter = new ScanParameter()
            .scanForward(lastSequenceId)
            .maxCount(30);

    Iterator<TimelineEntry> iterator = sync.createTimelineQueue(identifier).scan(parameter);

    List<AppMessage> appMessages = new LinkedList<AppMessage>();
    int counter = 0;
    while (iterator.hasNext() && counter++ <= 30) {
        AppMessage appMessage = new AppMessage(userId, iterator.next());
        appMessages.add(appMessage);
    }

    return appMessages;
}

在統計到會話列表中不存在的會話時，客戶端會做一次額外請求。通過timelineID獲取會話的基本描述信息，如羣頭像或好友的頭像、羣名稱等，並初始化未讀數計時器0，然後累加新消息數、更新最新消息摘要等。

同步庫對於IM場景下的新消息即時感知統計這一核心功能，就是通過寫入冗餘的方式，提升新消息讀取統計的效率與速度。對於IM場景沒有收件箱的概念，因而同步庫中冗餘消息並沒有永久保存的價值，提供7天過期時間已經足夠保證功能正常。用戶可以根據自身需求，調整同步庫的數據過期時間（TTL）。

功能：異步寫擴散

在本文的樣例中，單聊會話的消息在寫完存儲庫後同時寫入了同步庫，只有兩行的寫入開銷很小。但是對於羣會話，寫完存儲庫後要獲取羣用戶列表，然後依次寫入相應用戶的同步庫。這種方式在羣少、用戶少時不會有問題，但隨着用戶體量、活躍度的增加，同步的寫的方式就會面臨性能問題，因此建議用戶對羣寫擴散使用異步任務實現。

用戶可以基於表格存儲實現一個任務隊列，將寫擴散任務寫入隊列中後直接返回，然後由其他進程保證任務隊列的執行。任務隊列保存了羣ID、消息的完整信息，消費進程不斷輪詢讀取新任務，獲取任務後，纔會從羣關係表中獲取完整的羣成員列表，並做相應的寫擴散。

任務隊列可以直接基於Tablestore實現，表設計爲兩列主鍵，第一列爲topic，第二列爲自增列，一個topic對應一個隊列，任務會被有序寫入單個隊列中。當併發量持續膨脹後，可對任務做hash分桶，隨機寫入多個topic。這樣可以增加消費者數量（消費併發量），提升寫擴散效率。對應任務隊列消費，用戶只需要維護每個topic的checkpoint點。checkpoint點之前的爲已完成任務，通過getRange的方式順序獲取checkpoint點之後未執行的新任務，保證任務的執行。失敗的任務可以重新寫入任務隊列來提升容錯，並增加重試計數。出現多次失敗後放棄重寫，然後將該任務寫入特殊的問題隊列，方便應用的開發者們查詢、定位問題。

元數據管理

所謂元數據，就是描述數據的數據。在這裏主要體現爲兩類：用戶元數據、會話元數據。這裏羣的元數據信息：羣ID（複用羣的timelineId）、羣名稱、創建時間等信息，可以直接基於timelineMeta的管理表完成實現，所有Group類型的TimelineMeta可以映射爲一個Group。但是用戶的元數據卻不能複用TimelineMeta，所以需要單獨的表實現。

用戶元數據

即用戶的屬性信息，通過用戶ID識別特定用戶。在上面提到的用戶關係中，通過用戶的標識ID確認用戶身份，但用戶的屬性信息，如：性別、簽名、頭像等信息，還是需要單獨維護。因此需要單獨維護。

表設計：im_user_table

用戶元數據以user_id爲標識，與同步庫中的timeline_id一一對應。用戶同步新消息時，只會拉取同步庫中自己對應的單個消息隊列（TimelineQueue）。因此，爲了唯一ID的方便管理，我們可以選擇user_id與用戶同步庫的timeline_id使用同一個值。這樣一來，在消息寫擴散時，只需知道羣內用戶的user_id列表回好友user_id，即可以完成寫擴算。

功能：用戶檢索

對於用戶，添加好友的需求有很多種，這裏我們只需要維護用戶表，並且創建多元索引，即可輕鬆實現。樣例中沒有實現，用戶可以根據自己需求配置不同的索引字段設置，這裏我們僅簡單分析一下需求：

通過用戶ID：主鍵查詢；
二維碼（含用戶ID信息）：主鍵查詢；
用戶姓名：多元索引，用戶名字段設置分詞字符串；
用戶標籤：多元索引，數組字符串索引提供籤檢索、嵌套索引提供多標籤打分檢索排序；
附近的人：多元索引，GEO索引查詢附近、特定地理圍欄的人；

詳細的多元索引功能，用戶可參看官網文檔：多元索引

會話元數據

即會話的屬性信息，通過唯一會話ID識別特定會話，屬性信息會包含：會話類別（羣、單聊、公衆號等）、羣名稱、公告、創建時間等。同時，通過羣名稱模糊查找羣，也會是會話元數需要的重要能力。

在Timeline模型中，提供了Timeline Meta的管理能力，只需通過相應的接口便可實現會話meta的管理。

存儲庫中管理的是會話的消息隊列（TimelineQueue），這裏與會話元數據中的行一一對應。客戶端用戶選中特定會話後，應用從相應的消息隊列倒序批量拉取消息展示到客戶端，羣聊單聊的使用方式一樣，因而並不做會話類型的區分。

功能：羣檢索

用戶如果有加入羣的需求，首先需要查詢到特定的羣。查詢羣的方式與用戶查詢方式類似，功能也可以做相同的實現。用戶可以根據自己需求定製不同的索引字段設置，需求實現方式如下：

羣ID：主鍵查詢；
二維碼（含用戶ID信息）：主鍵查詢；
羣名：多元索引，用戶名字段設置分詞字符串；
羣標籤：多元索引，數組字符串索引提供籤檢索、嵌套索引提供多標籤打分檢索排序；

注：會話元數據可以直接維護單聊會話與人的映射關係。對於單聊的meta增加一列users字段，存放兩個用戶ID，這樣不用額外維護關係表（基於單聊關係表im_user_relation_table創建timeline_id爲第一列主鍵的二級索引）。

關係維護

完成了元數據管理以及用戶和羣的檢索，剩下的就是如何添加好友、加入羣聊了。這裏就涉及到IM體統中另一個重要的功能點。關係維護包含：人與人的關係、人與羣的關係以及人與會話的。下面我們介紹如何基於Tablestore解決這一關係維護的需求。

單聊關係

功能：人與單聊會話的關係

單聊場景下，參與者僅有兩個人，同時不考慮順序。無論是我聯繫小明或是小明聯繫我，對應的會話必須有且僅有一個。如果使用表格存儲維護這個關係，建議用如下的設計方式。

第一列爲主用戶ID、第二列爲次用戶ID，在兩個人成爲好友後，關係表中需要插入兩行數據，分別以自己的用戶ID爲main_user，以好友的用戶ID爲sub_user，然後將共同的會話timline_id作爲屬性列，並且可以維護相互之間不同的暱稱、顯示。

表設計：im_user_relation_table

基於該單聊關係表，還可以建立多元索引，方便用戶好友列表的獲取，同時支持加好友時間排序、暱稱排序等功能。如果考慮到延時、費用等因素，即時使用多元索引，直接通過getRange接口也可以快速拉、高效的獲取自己所有好友列表，實現好友關係的維護與查詢。

功能：人與人的關係

藉助以上表，人與人的關係可以很簡單實現，比如我判斷我與小明的好友關係，直接通過單行查詢知道我們的好友關係是否存在，如果存在就不會展示加好友按鈕。而如果非好友，這是完成好友添加後，寫入兩行不同主鍵順序行，並生成一個唯一的timelineId即可。這個設計的好處在於用戶可以直接通過自己的ID與好友的ID快速獲取會話信息。只要用戶在寫入兩行時做好一致性維護。

如果好友關係一旦解除，可以直接拼出關係表中兩行主鍵對用戶關係，通過做物理刪除（刪除行）或邏輯刪除（屬性列狀態修改）結束兩兩個人的好友關係即可；

核心代碼

public void establishFriendship(String userA, String userB, String timelineId) {
    PrimaryKey primaryKeyA = PrimaryKeyBuilder.createPrimaryKeyBuilder()
            .addPrimaryKeyColumn("main_user", PrimaryKeyValue.fromString(userA))
            .addPrimaryKeyColumn("sub_user", PrimaryKeyValue.fromString(userB))
            .build();

    RowPutChange rowPutChangeA = new RowPutChange(userRelationTable, primaryKeyA);
    rowPutChangeA.addColumn("timeline_id", ColumnValue.fromString(timelineId));

    PrimaryKey primaryKeyB = PrimaryKeyBuilder.createPrimaryKeyBuilder()
            .addPrimaryKeyColumn("main_user", PrimaryKeyValue.fromString(userB))
            .addPrimaryKeyColumn("sub_user", PrimaryKeyValue.fromString(userA))
            .build();

    RowPutChange rowPutChangeB = new RowPutChange(userRelationTable, primaryKeyB);
    rowPutChangeB.addColumn("timeline_id", ColumnValue.fromString(timelineId));

    BatchWriteRowRequest request = new BatchWriteRowRequest();
    request.addRowChange(rowPutChangeA);
    request.addRowChange(rowPutChangeB);

    syncClient.batchWriteRow(request);
}

public void breakupFriendship(String userA, String userB) {
    PrimaryKey primaryKeyA = PrimaryKeyBuilder.createPrimaryKeyBuilder()
            .addPrimaryKeyColumn("main_user", PrimaryKeyValue.fromString(userA))
            .addPrimaryKeyColumn("sub_user", PrimaryKeyValue.fromString(userB))
            .build();

    RowDeleteChange rowPutChangeA = new RowDeleteChange(userRelationTable, primaryKeyA);

    PrimaryKey primaryKeyB = PrimaryKeyBuilder.createPrimaryKeyBuilder()
            .addPrimaryKeyColumn("main_user", PrimaryKeyValue.fromString(userB))
            .addPrimaryKeyColumn("sub_user", PrimaryKeyValue.fromString(userA))
            .build();

    RowDeleteChange rowPutChangeB = new RowDeleteChange(userRelationTable, primaryKeyB);

    BatchWriteRowRequest request = new BatchWriteRowRequest();
    request.addRowChange(rowPutChangeA);
    request.addRowChange(rowPutChangeB);

    syncClient.batchWriteRow(request);
}

羣聊關係

功能：羣聊會話與人的關係

羣聊時，主要的查詢需求還是獲取當前羣內用戶的列表。一方面方便羣屬性的展示，另一方面爲應用做寫擴散提供快速獲取收件人列表的查詢。因而在表設計上，我們會建議用戶使用兩列主鍵：第一列爲羣ID，第二列爲用戶ID。通過這樣的設計，可以直接給予getRange接口拉取羣所有用戶的信息。

羣聊關係表解決了羣到用戶的映射關係，但我們還需要用戶到羣的映射關係。如果爲了查詢用戶所在羣的列表而新鍵一張表，冗餘成本、一致性維護成本就很高。這裏可以使用兩種索引來解決反向的映射關係。樣例中，我們使用了二級索引，將用戶ID字段作爲索引主鍵，從而可以直接基於索引查詢單用戶的羣列表。同步實時性更好，成本更低。

當然用戶也可以使用多元索引：對羣、用戶、入羣時間做索引，可以查詢到某用戶的所有在羣列表，並且基於入羣時間排序。

表設計：im_group_relation_table

基於羣關係表，可以直接基於關係主表通過getRange的方式獲取單個羣內所有的用戶。在做寫擴散時，可以直接獲取羣內用戶ID列表，提升寫擴散的效率。同時，也方便展示羣內用戶列表。

核心代碼

public List<Conversation> listMySingleConversations(String userId) {
    PrimaryKey start = PrimaryKeyBuilder.createPrimaryKeyBuilder()
            .addPrimaryKeyColumn("main_user", PrimaryKeyValue.fromString(userId))
            .addPrimaryKeyColumn("sub_user", PrimaryKeyValue.INF_MIN)
            .build();

    PrimaryKey end = PrimaryKeyBuilder.createPrimaryKeyBuilder()
            .addPrimaryKeyColumn("main_user", PrimaryKeyValue.fromString(userId))
            .addPrimaryKeyColumn("sub_user", PrimaryKeyValue.INF_MAX)
            .build();

    RangeRowQueryCriteria criteria = new RangeRowQueryCriteria(userRelationTable);
    criteria.setInclusiveStartPrimaryKey(start);
    criteria.setExclusiveEndPrimaryKey(end);
    criteria.setMaxVersions(1);
    criteria.setLimit(100);
    criteria.setDirection(Direction.FORWARD);
    criteria.addColumnsToGet(new String[] {"timeline_id"});

    GetRangeRequest request = new GetRangeRequest(criteria);
    GetRangeResponse response = syncClient.getRange(request);

    List<Conversation> singleConversations = new ArrayList<Conversation>(response.getRows().size());

    for (Row row : response.getRows()) {
        String timelineId = row.getColumn("timeline_id").get(0).getValue().asString();
        String subUserId = row.getPrimaryKey().getPrimaryKeyColumn("sub_user").getValue().asString();
        User friend = describeUser(subUserId);

        Conversation conversation = new Conversation(timelineId, friend);

        singleConversations.add(conversation);
    }

    return singleConversations;
}

功能：人與羣聊會話的關係

獲取單用戶所有加入羣列表，可以基於主表創建二級索引，將用戶字段設爲索引的第一列主鍵。索引的數據結構見下圖。這樣基於二級索引，可以直接通過getRange的方式獲取單用戶加入的羣的TimlineId列表。

二級索引：im_group_relation_global_index

核心代碼

public List<Conversation> listMyGroupConversations(String userId) {
    PrimaryKey start = PrimaryKeyBuilder.createPrimaryKeyBuilder()
            .addPrimaryKeyColumn("user_id", PrimaryKeyValue.fromString(userId))
            .addPrimaryKeyColumn("group_id", PrimaryKeyValue.INF_MIN)
            .build();

    PrimaryKey end = PrimaryKeyBuilder.createPrimaryKeyBuilder()
            .addPrimaryKeyColumn("user_id", PrimaryKeyValue.fromString(userId))
            .addPrimaryKeyColumn("group_id", PrimaryKeyValue.INF_MAX)
            .build();

    RangeRowQueryCriteria criteria = new RangeRowQueryCriteria(groupRelationGlobalIndex);
    criteria.setInclusiveStartPrimaryKey(start);
    criteria.setExclusiveEndPrimaryKey(end);
    criteria.setMaxVersions(1);
    criteria.setLimit(100);
    criteria.setDirection(Direction.FORWARD);
    criteria.addColumnsToGet(new String[] {"group_id"});

    GetRangeRequest request = new GetRangeRequest(criteria);
    GetRangeResponse response = syncClient.getRange(request);

    List<Conversation> groupConversations = new ArrayList<Conversation>(response.getRows().size());

    for (Row row : response.getRows()) {
        String timelineId = row.getPrimaryKey().getPrimaryKeyColumn("group_id").getValue().asString();
        Group group = describeGroup(timelineId);

        Conversation conversation = new Conversation(timelineId, group);

        groupConversations.add(conversation);
    }

    return groupConversations;
}

即時感知

讓客戶端即時感知消息的實現方案，可以參考《Feed 流設計總綱》一文中會話池的維護方式，這裏作簡要描述，不會在樣例中實現。

會話池方案

即時感知新消息正是IM（Instant Message）場景下核心所在。讓客戶端及時感知到新信息的到來，然後客戶端接收到通知後纔會從同步庫中拉取更新的消息，讓用戶更快速、更及時地提醒用戶閱讀新消息。可是，接受者如何才能快速感知到自己有了新消息呢？

讓在線的客戶端週期性的刷新拉取？這樣的方式毫無疑問可以滿足需求，但伴隨而來的是大量無效的網絡資源浪費。同時應用的壓力也會隨着用戶量的不斷增長變得更沉重。而當白天大量非活躍用戶在線時，壓力更爲明顯。面對這一問題，應用通常會維護一個推送會話池。會話池記錄了在線客戶端與用戶信息，當在線用戶有新的消息寫入，通過推送池獲取該用戶的會話，然後通知客戶端拉取同步庫新消息。這樣同步消息的壓力只會隨着真實消息量而增長，避免了大量不必要的同步庫查詢請求。

實現會話推送池的方案很多，可以使用內存型數據庫，也可以直接使用表格存儲，同時保證會話推送池的持久化。

在即時感知上，最直觀的就是會話表中變動的未讀消息數統計了。統計新消息的實現方式上，已在本文的【消息存儲 > 第二類：同步庫 > 新消息即時統計】部分做了詳盡描述，不理解的可返回去重新看一下。持久化未讀消息數是很必要的，否則在更換設備或重新登錄後。未讀消息數被清零，將會忽略很多新消息提醒，這是我們不能接受的。

其他

多端同步

實現了以上功能，IM系統的基本需求已經完成。但實現多端數據同步上，還有兩個注意事項。

其一，我們對於單客戶端情況下，用戶同步庫做了一個checkpoint點的持久化，對應的概念是：“已讀最新消息的sequenceId”。此時，checkpoint點無客戶端的區分，如果使用本地做持久化，多端同步時就會出現問題，不同客戶端統計的未讀消息數就會不一致。這是需要通過應用服務端維護checkpoint點，同時會話的未讀消息數也需要在應用服務側維護，這樣才能保證多端統計數一致。同時，當有未讀消息的會話被點擊，會話未讀數清0時，要讓服務有感知，然後通知到其他在線端，維護實時一致性。

其二，多端情況下，自己在一個客戶端發送了新消息，其他客戶端在沒有其他新消息時，是無法感知並刷新自己的發送消息，這在多端同步中也是要解決的小問題。這時，簡單的解決方案就是將自己發送的消息，也寫入自己的同步庫。只要再統計未讀信息時，對自己的信息不計數，但在最新消息摘要中需要做更新。這樣，多端同步問題很容易實現。

添加好友、入羣申請

添加好友或入羣，不是主動發起請求就會直接完成的，這裏需要主動方申請後，審覈方完成統一纔會真實完成。因而只有在審覈方纔會有權限發起關係的創建。

那如何讓被添加用戶或羣主感知到申請？當然是藉助同步庫，作爲一種新的消息類型或者特殊的會話，讓用戶即時感知到新申請，儘早完成審批。申請列表如果需要持久化，也可單獨建表維護，只要保證用戶新申請的即時感知即可。

樣例實操

本位爲了與用戶一起梳理IM系統應用的功能點，基於Tablestore實現的樣例簡單功能，完整的樣例代碼已完成開源，代碼地址：源碼鏈接。用戶可以結合文章、代碼一起閱讀。代碼在本地運行，使用前請確保：

開通服務、創建實例
獲取AK
設置樣例配置文件
實例支持二級索引（需要主動申請）；

樣例配置

在home目錄下創建tablestoreCong.json文件，填寫相應參數如下：

# mac 或 linux系統下：/home/userhome/tablestoreCong.json
# windows系統下: C:\Documents and Settings\%用戶名%\tablestoreCong.json
{
  "endpoint": "http://instanceName.cn-hangzhou.ots.aliyuncs.com",
  "accessId": "***********",
  "accessKey": "***********************",
  "instanceName": "instanceName"
}

endpoint：實例的接入地址，控制檯實例詳情頁獲取；

accessId：AK的ID，獲取AK鏈接提供；

accessKey：AK的密碼，獲取AK鏈接提供；

instanceName：使用的實例名；

樣例入口

樣例中共有三個入口，用戶需要根據先後順序執行，使用後及時釋放資源，避免不必要的費用浪費；

入口	入口類名	功能
初始化	InitChartRoomExample	創建所有需要的表，同時根據配置創建相應的多元索引與二級索引
模擬調用	ClientRequestExample	應用的接口使用，樣例未做前後端聯調調用，用戶可通過接口返回數據的打印瞭解使用方式。
釋放資源	ReleaseChartRoomExample	釋放所有資源，先釋放索引後刪表

項目結構

本文轉載自阿里云云棲社區。

原文鏈接：

https://yq.aliyun.com/articles/710363

現代IM系統中的消息系統架構——實現篇

序

梗概

功能模塊

消息存儲

存儲庫

功能：會話窗口消息展示

功能：多維組合、全文檢索

同步庫

功能：新消息即時統計

功能：異步寫擴散

元數據管理

用戶元數據

功能：用戶檢索

會話元數據

功能：羣檢索

關係維護

單聊關係

功能：人與單聊會話的關係

功能：人與人的關係

羣聊關係

功能：羣聊會話與人的關係

功能：人與羣聊會話的關係

即時感知

會話池方案

其他

多端同步

添加好友、入羣申請

樣例實操

樣例配置

樣例入口

項目結構

Spring Cloud 部署時如何使用 Kubernetes 作爲註冊中心和配置中心

現代IM系統中的消息系統架構——實現篇

建立在Tablestore的Wifi設備監管系統架構實現

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結