如何造一個「釘釘」？談談消息系統架構的實現

時間 2019-11-24

原文原文鏈接

阿里妹導讀：消息類場景是表格存儲（Tablestore）主推的方向之一，因其數據存儲結構在消息類數據存儲上具備自然優點。爲了方便用戶基於Tablestore爲消息類場景建模，Tablestore封裝Timeline模型，旨在讓用戶更快捷的實現消息類場景需求。在推出Timeline（v一、v2兩個版本）模型以來，受到了大量用戶關注。但依然會有用戶困惑，「框架、結構、模型等概念介紹了這麼多，該如何基於Timeline模型，實現具體場景呢？」。本文詳細講解如何實現一個簡易的IM系統。linux

梗概

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

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

功能模塊

消息存儲redis

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

樣例中，消息數據的表結構見下圖：表設計：im_timeline_store_tablejson

存儲庫windows

功能：會話窗口消息展現數組

存儲庫是聊天會話消息所對應的存儲表，消息以會話分類存儲，每一個會話是一個消息隊列。單個消息隊列（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;
}

即時感知

會話池方案

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

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

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

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

其餘

多端同步

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

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

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

添加好友、入羣申請

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

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

樣例實操

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

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

開源地址

基於Tablestore實現的樣例簡單功能，完整的樣例代碼已完成開源。開源地址：
https://github.com/aliyun/tablestore-examples/tree/master/demos/ImChart

樣例配置

在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：使用的實例名；

樣例入口

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

項目結構

原文連接本文爲雲棲社區原創內容，未經容許不得轉載。