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

梗概

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

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

功能模塊

消息存儲

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

樣例中，消息數據的表結構見下圖：表設計：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; }

即時感知

會話池方案

即時感知新消息正是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：使用的實例名；

樣例入口

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

項目結構

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的如何造一个“钉钉”？谈谈消息系统架构的实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。