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

序

消息類場景是表格存儲（Tablestore）主推的方向之一，因其資料存儲結構在消息類資料存儲上具有天然優勢。為了友善使用者基于Tablestore為消息類場景模組化，Tablestore封裝Timeline模型，旨在讓使用者更快捷的實作消息類場景需求。在推出Timeline（v1、v2兩個版本）模型以來，受到了大量使用者關注。伴随模型推廣與輸出，Tablestore陸續釋出了一系列專題文章，重點讨論介紹了IM場景的架構設計、模型概念以及Feed 流系統架構的設計方案，相信給很多使用者提供了場景實作新思路。文章清單見

《表格存儲權威指南》

。

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

本文就是為了讓使用者更快速的上手，帶使用者基于Timeline2.0 模型，詳細講解如何實作一個簡易的IM系統。并開源了相應的實作代碼。

源碼連結

相關系列文章見：

《現代IM系統中的消息系統架構 - 架構篇》

、

《現代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：主鍵查詢；
• 群名：多元索引，使用者名字段設定分詞字元串；
• 群标簽：多元索引，數組字元串索引提供簽檢索、嵌套索引提供多标簽打分檢索排序；

注：會話中繼資料可以直接維護單聊會話與人的映射關系。對于單聊的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	釋放所有資源，先釋放索引後删表

項目結構

專家服務

表格存儲有一批精通Timeline領域的技術專家，在打造IM、Feed流場景方面有着獨到的見解。更多文章歡迎前往

《表格存儲Tablestore權威指南》

。如果您：

• 渴望尋覓Timeline領域高手過招；
• 調研Timeline場景解決方案；
• 準備入門Timeline場景；
• 對表格存儲（Tablestore）産品感興趣；

歡迎加入“表格存儲公開交流群”。表格存儲 (Tablestore) 提供專業的免費的技術咨詢服務，期待為您服務。群号 : 11789671