IM系统设计之消息存储

最新推荐文章于 2024-12-25 07:00:00 发布
最新推荐文章于 2024-12-25 07:00:00 发布
阅读量819 收藏 6
点赞数 9
CC 4.0 BY-SA版权
分类专栏： IM系统 文章标签： go go-zero
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Wksycxy/article/details/136974673

IM系统设计之消息存储

项目地址：git@github.com:muyixiaoxi/Link.git

消息存储结构

消息存储结构如下图所示
在这里插入图片描述

当用户A向用户B发送一条消息时

  1. 将消息发送给 server
  2. server 将消息进行持久化
  3. 判断用户B是否在线，如果在线直接转发；如果离线，将离线消息存储到B的离线消息存储库里；如果此时B为离线状态，那么当B下次登录时拉取离线消息存储库即可同步消息。
  4. 将消息持久化到客户端本地（前端的工作）

消息持久库和离线消息存储库我分别使用的是：MySQL、Redis。众所周知，Redis是基于内存的，那么当Redis宕机后，离线消息就会丢失。

这里有两种解决思路，两种思路都需要记录消息持久库里面记录消息的已读状态

思路一：

  1. 用户上线后，拉取离线消息，并将其在持久库里面的状态修改为已读
  2. 用户上线后，拉取离线消息，如果离线消息为空，则去持久库里同步未读的消息

思路二：
当Redis宕机后，管理员手动拉取

如果有更好的方法，欢迎大家在评论区讨论

im 服务器优化,IM服务器设计--消息存储(转)
weixin_42127783的博客
07-30 1015
这部分专门讲述IM消息存储的设计。消息存储的难度在于，要考虑以下场景：离线消息存储。即发送消息时对方不在线该怎么处理单聊、群聊消息随着用户量越来越大，以后应该如何扩展说明： 工作多年，自己也亲身参与过一款IM系统相关模块的设计，但是对比本文有一些地方还是略有不足。本文转载自IM服务器设计-基础，主要是为了进一步从更高层次理解IM；另一方面也方便自己的后续查找，防止文章丢失。1. 读扩散 VS 写扩...
零基础入门 IM 系列——消息的存储篇
杏仁技术站
06-10 1694
前言在上一篇文章《零基础入门 IM 系列——可靠的消息篇》中，我们基于 Qos 机制了解了如何去保证消息能及时无误的发至用户手中。这篇开始我们会讲述，我们的消息是如何被高效的保存的。消息存...
现代IM系统中消息推送和存储架构的实现
weixin_34085658的博客
11-16 1622
前言 IM全称是『Instant Messaging』，中文名是即时通讯。在这个高度信息化的移动互联网时代，生活中IM类产品已经成为必备品，比较有名的如钉钉、微信、QQ等以IM为核心功能的产品。当然目前微信已经成长为一个生态型产品，但其核心功能还是IM。还有一些非以IM系统为核心的应用，最典型的如一些在线游戏、社交应用，IM也是其重要的功能模块。可以说，...
IM项目：进阶版即时通讯项目---消息存储
海绵宝宝de派小星的博客
08-25 1915
消息存储服务
IM 消息数据存储结构设计
weixin_44764152的博客
02-18 2045
1.背景 在移动互联网高速发展的时代，生活中 IM 类产品已经是我们离不开的应用了，像微信、钉钉等都是以 IM 为核心功能的社交产品。另外也有一些应用不是以 IM 为核心，但是也是其重要功能，比如在线游戏、电商直播等应用。 在 IM 庞大的体系中，消息系统无疑是最核心的，而消息系统中，最关键的部分是消息的分发和存储。 在以往传统消息系统中，对于在线的用户，消息会直接实时发送到在线的接收方，消息发送完成后，服务器端并不会对消息进行落地存储。对于离线的用户，服务器端会将消息存入到离线库，当用户登录后，从离线库.
即时聊天(IM)存储方案
coolmsn8786的博客
11-24 5827
单位即时聊天改版了. 正好趁着这次机会踢了MongoDB. 大家都拍手叫好..可见MongoDB这玩意多么的不得人心...都觉得不好用.. 场景描述: 我们的IM软件有PC端和手机端. 同时在线的用户,通过长连接转...
分层架构 IM 系统之系统消息功能逻辑设计与实现
wang_zong_sheng的专栏
12-25 917
分层架构 IM 系统，如何设计系统消息的处理流程？如何解决广播系统消息的高并发问题？
分层架构 IM 系统之未读数逻辑设计与实现
wang_zong_sheng的专栏
12-23 1101
IM 的未读数逻辑应该怎样设计？什么是离线存储模型和在线存储模型？离线存储模型和在线存储模型适用于怎样的业务场景？
现代im设计与mysql实现_现代IM系统中消息推送和存储架构的实现
weixin_27134495的博客
02-05 419
摘要：前言 IM全称是『Instant Messaging』，中文名是即时通讯。在这个高度信息化的移动互联网时代，生活中IM类产品已经成为必备品，比较有名的如钉钉、微信、QQ等以IM为核心功能的产品。当然目前微信已经成长为一个生态型产品，但其核心功能还是IM。前言IM全称是『Instant Messaging』，中文名是即时通讯。在这个高度信息化的移动互联网时代，生活中IM类产品已经成为必备品，比...
教你微信IM即时消息系统的架构设计
2401_83916283的博客
04-21 1276
Java架构进阶面试及知识点文档笔记这份文档共498页，其中包括Java集合，并发编程，JVM，Dubbo,Redis，Spring全家桶，MySQL，Kafka等面试解析及知识点整理Java分布式高级面试问题解析文档其中都是包括分布式的面试问题解析，内容有分布式消息队列，Redis缓存，分库分表，微服务架构，分布式高可用，读写分离等等！互联网Java程序员面试必备问题解析及文档学习笔记Java架构进阶视频解析合集《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》
一步一步打造WebIM(2)——消息缓存
doj4827的博客
04-27 191
WebIM系列文章 在一步一步打造WebIM(1)一文中，已经介绍了如何实现一个简单的WebIM，但是，这个WebIM有一个问题，就是每一次添加消息监听器时，都必须访问一次数据库去查询是否有消息，显然，如果用户比较多时，必然对数据库的压力比较大。解决这个问题的一个方法就是先将消息缓存在内存中，不立即写入数据库，等到缓存满了才写入数据库。本文将介绍如何实现消息缓存。 基本思路 ...
IM系统海量消息数据是怎么存储的？
诚的博客
03-03 4861
一、与消息相关的主要场景 1、存储和离线消息。 现在的IM系统，消息都要落地存储。这样如果接收消息的用户不在线，等他下次上线时，能获取到消息数据。 2、消息漫游 消息漫游包括主要两种场景， （1）用户新安装IM软件，要能看到以前的聊天记录 （2）聊天软件有PC版和App版，在App上聊的天，打开PC版要能够看到 二、不同场景读取 消息关键点 1、拉取离线消息 每个用户打开App就需要拉取离线，网络中断重连后要拉取离线，收到消息序列号不连续也要拉取离线，拉取离线消息是一个高频操作 。离线消息
现代 IM 系统中消息推送和存储架构的实现
架构文摘
04-04 664
前言IM 全称是“Instant Messaging”，中文名是即时通讯。在这个高度信息化的移动互联网时代，生活中 IM 类产品已经成为必备品，比较有名的如钉钉、微信、Q...
uniapp结合腾讯云及时通信IM的聊天记录本地存储方案
weixin_42119753的博客
02-27 5188
uniapp、IM、腾讯云及时通信、聊天记录、本地存储
【分布式webscoket】IM聊天系统消息如何存储 如何分库分表以及Seata解决事务以及ShardingSphere-Scaling解决数据迁移
qq_21561833的博客
03-04 2481
在实现IM（即时通讯）聊天系统时，随着用户数量和消息量的增加，数据库的压力会逐渐增大。为了保证系统的可扩展性和性能，通常需要对聊天消息进行分库分表。分表策略按时间分表优点：可以根据时间轴快速查询，旧数据归档处理也较为方便。实现：每个时间周期（如每月、每周）创建一个新表，表名包含时间标识。按用户分表优点：可以将用户的消息分散到不同的表中，减少单表数据量，提高查询效率。实现：根据用户ID的hash值分配到不同的表中，例如根据用户ID对表的数量取模来决定数据存储在哪个表。分库策略。
服务器接收消息写日志,IM服务器设计-消息存储
weixin_34634720的博客
08-06 444
这部分专门讲述IM消息存储的设计。消息存储的难度在于，要考虑以下的场景：离线消息存储。即发送消息时对方不在线该怎么处理。单聊、群聊消息。随着用户量越来越大，应该以后如何扩展。读扩散 VS 写扩散消息同步模型中，有写扩散和读扩散这两种模型。在开始讨论之前需要先了解两个相关的概念：收件箱(inbox)：该用户收到的消息。发件箱(outbox)：该用户发出的消息。写扩散(push)写扩散就是经常说的pu...
IM系统：消息推送及离线存储
LiPine的专栏
12-28 2392
一、服务端维护每条消息对用户的送达状态 二、利用标号标记最新已读消息
IM系统客户端消息存储在手机电脑浏览器分别存储在什么地方?对消息加密策略？如何保证服务端消息和客户端消息一致性【第18期】
qq_21561833的博客
03-07 1491
要在浏览器中加密存储在IndexedDB中的数据，需要在将数据写入数据库之前手动加密这些数据，并在从数据库读取时解密。这通常涉及到使用Web Crypto API，这是一个在现代浏览器中可用的加密标准，提供了包括加密、解密、签名和验证等多种加密操作的能力。SQLite因其轻量级和高效性，在桌面应用中非常流行。Electron等跨平台框架：使用Electron等框架开发的跨平台桌面应用，同样倾向于使用SQLite数据库，或者利用框架提供的本地存储API，如Electron的localStorage。
im系统 用户消息怎么存储
最新发布
02-28
<think>嗯，用户问的是IM系统中用户消息的存储方法。首先，我需要回忆一下IM系统的基本架构。IM，即时通讯，像微信、QQ这些应用，每天处理海量消息，存储肯定是个关键问题。 首先，消息存储要考虑实时性和可靠性。用户发送的消息必须快速送达，同时不能丢失。可能分为在线消息和离线消息。在线的话，用户在线时直接推送，存储可能用缓存，比如Redis或者Memcached，这样速度快。但缓存不是持久化的，所以还需要持久化存储，比如用MySQL或者PostgreSQL这样的关系型数据库，或者NoSQL如MongoDB，根据数据结构来选择。 然后是消息的持久化存储结构。每条消息可能有发送者、接收者、时间戳、内容、类型（文本、图片、视频等）、状态（已发送、已送达、已读）等字段。数据库表设计的话，可能需要消息表，包含这些字段，还有索引优化查询速度，比如按用户ID和时间查询历史记录。 不过，关系型数据库在处理海量数据时可能会有性能问题，特别是消息量大的时候。这时候可能需要分库分表，比如按用户ID哈希分表，或者按时间分表，比如每个月一张表。另外，写多读少的情况，可能要考虑读写分离，主库处理写，从库处理读。 另外，消息的可靠性，可能需要使用消息队列来异步处理。比如用户发送消息后，先存入队列，然后消费者处理存储和推送，这样避免高并发时的压力。比如用Kafka或者RabbitMQ。 还有，离线消息的处理。用户不在线时，消息需要存起来，等用户上线后再推送。这时候可能需要一个离线消息表，按用户ID存储，用户登录时查询并推送，然后删除或标记已发送。 对于附件，如图片、视频，通常不会直接存数据库，而是存对象存储服务，比如AWS S3、阿里云OSS，数据库中只存URL。 还有数据备份和容灾，防止数据丢失，需要定期备份，可能多地存储副本。另外，隐私和安全方面，消息内容可能需要加密存储，比如端到端加密，数据库里存密文。 还有消息的检索功能，用户可能需要搜索历史消息，这时候可以考虑使用Elasticsearch这类全文搜索引擎，提高检索效率。 最后，需要考虑存储系统的扩展性，随着用户量增长，如何横向扩展，比如使用分布式数据库，或者云数据库服务，根据负载自动扩容。 不过，可能我有没有遗漏的点？比如消息的顺序问题，如何保证消息在接收端的顺序和发送顺序一致，可能在存储时使用递增的时间戳或者序列号。还有消息的撤回和删除功能，需要软删除标记，或者物理删除，这会影响存储设计。 总之，IM的消息存储需要结合实时性和持久化，合理选择数据库，分库分表，结合缓存和队列，处理高并发，同时考虑数据的安全和扩展性。</think>IM（即时通讯）系统的用户消息存储是一个涉及高并发、低延迟、高可靠性的复杂问题。以下是其核心设计思路和常见实现方案： 1. **分层存储架构** - **在线消息缓存层**（毫秒级响应） - 使用Redis Cluster或Codis存储在线会话消息（最近N条） - 数据结构：Sorted Set（按时间戳排序） - 示例：`ZADD user:10086:chat:20010 1631234567 "Hello"` - **持久化存储层**（最终一致性） - 关系型数据库：MySQL（分库分表） ```sql CREATE TABLE messages ( msg_id BIGINT PRIMARY KEY, from_uid BIGINT, to_uid BIGINT, content TEXT, msg_type TINYINT, created_at TIMESTAMP, INDEX(to_uid, created_at) ) PARTITION BY HASH(to_uid); ``` - NoSQL方案：Apache Cassandra（适合写密集型场景） ```cql CREATE TABLE messages ( bucket_id INT, -- 时间分桶（如每小时一个桶） msg_id TIMEUUID, from_uid BIGINT, to_uid BIGINT, content TEXT, PRIMARY KEY ((to_uid, bucket_id), msg_id) ) WITH CLUSTERING ORDER BY (msg_id DESC); ``` 2. **消息分区策略** - **垂直拆分** - 单聊消息 vs 群聊消息分离存储 - 文本消息 vs 多媒体消息分离存储（大文件存OSS） - **水平拆分** - 按接收方UID哈希分片（如1024个分片） - 按时间分片（如每月一个表） 3. **消息同步机制** ```mermaid sequenceDiagram participant Sender participant Server participant Redis participant MySQL participant Receiver Sender->>Server: 发送消息 Server->>Redis: 写入发送方消息缓存 Server->>Redis: 写入接收方消息缓存 Server->>MySQL: 异步持久化 Server-->>Sender: 发送成功ACK Server->>Receiver: 实时推送 Receiver->>Server: 确认接收 Server->>Redis: 更新消息状态 ``` 4. **特殊场景处理** - **离线消息**：Redis HyperLogLog记录未同步消息数 - **消息漫游**：Elasticsearch建立倒排索引 - **消息撤回**：标记删除+逻辑删除 ```sql UPDATE messages SET is_deleted = 1 WHERE msg_id = ? AND created_at > NOW() - INTERVAL 2 MINUTE ``` 5. **性能优化技巧** - **批量写入**：Kafka做消息缓冲，批量写入数据库 - **冷热分离**： - 热数据：TiDB（HTAP混合负载） - 冷数据：HBase+对象存储 - **缓存穿透防护**：BloomFilter过滤无效查询 典型存储指标参考： - 单条消息存储成本：约0.1KB（压缩后文本） - 写入吞吐量：单集群10w+ QPS - 读取延迟：P99 < 50ms 最新趋势： - 存储计算分离（如TiDB+云原生存储） - 端到端加密存储（Signal协议） - 区块链存证（重要消息上链） 实际系统设计需根据业务场景（如社交IM vs 企业IM）在一致性、可用性、成本之间取得平衡。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值