即时通讯系统为什么选择 GaussDB(for Redis)？

每当网络上爆出热点新闻，混迹于各个社交媒体的小伙伴们全都开启了讨论模式。一条消息的产生是如何在群聊中传递的呢？让我们一起来探索即时通讯系统(IM)的原理。

IM 系统架构的原理

当你在群聊“相亲相爱一家人”中，发送了一条“我找到女朋友了，今天带回家吃饭”，你自然是希望全家人都收到你的喜讯，为你女朋友的到来分头准备。那么正常的流程应该是这样：遍历群成员、查询每个成员的在线状态、如果小伙伴们在线则实时进行推送，如果小伙伴们不在线则暂存至离线库待上线后主动拉取。

这种模式就是传统的 IM 架构，由于发送成功的消息不会落入离线库，因此聊天记录多端漫游无法实现。如果在线用户推送发生异常，会导致个别人员丢失关键发言，错失重要信息。为了保证消息存储的可靠性，我们对 IM 系统架构进行了优化，不管成员是否在线都要先把消息和发送对象存储起来，再进行推送。流程变成：遍历群成员、为群聊的每一个人对应的消息队列都存一份消息、查询每个成员的在线状态、对在线成员进行推送。这就是所谓的写扩散模型。

这里显然还存在一个问题，我们向每个小伙伴的消息队列中都存储了相同的“我找到女朋友了，今天带回家吃饭”消息，对磁盘和带宽造成了很大的浪费，这是写扩散的最大弊端。所以我们继续优化，群消息实体存储一份，用户只存消息 ID 索引。流程优化为：遍历群聊的成员、先存一份消息实体、群聊所有人都存一份 ID 引用、查询每个成员的在线状态、对在线成员进行推送。这就是所谓的读扩散模型。

简单总结下：

1.读扩散：读取操作很重，写入操作很轻，资源消耗相对小一些。 

2.写扩散：读取操作很轻，写入操作很重，资源消耗相对大一些。

IM 系统架构优化实践

接下来，让我们使用 GaussDB(for Redis) 来实现一个简单的 IM 应用。

• 使用 GaussDB(for Redis)的 List 类型实现一个消息队列，防止发送端瞬时高流量会压爆消息处理模块；

• 收到消息后，先生成一个全局唯一 ID 标识该信息，将消息 ID 和消息内容存入 String 类型的消息存储库中，如果消息字段复杂也可以考虑使用 Hash 类型；

• 对于消息中可索引的信息，将消息的索引信息存入 Zset 类型的消息索引库中，这样无论是接收者还是发送者，都可以按照一定规则对历史消息进行检索；

• 通过查询 Set 类型的消息关系群组库，查询该信息的接收者集合，这个集合可以根据一定的规则动态增删；

• 将消息 ID 推入 Stream 类型的消息同步库，每个 Stream 对象对应一个接收者，接收者可以通过 XRANG 命令获取一个范围内的未读信息 ID；

• 最后，接收者再通过这组 ID，从消息存储库中读取消息原始内容，即完成了一次消息传递。

Why GaussDB (for Redis)?

IM 系统有哪些痛点？高斯 Redis 如何解决这些痛点？

1. 开源 Redsi 数据库可靠性差，甚至丢数据，会直接导致 IM 系统瘫痪。

GaussDB(for Redis)对数据进行分片，在故障场景下可以自动进行接管，最多可以满足 N-1 个计算节点故障；存储层使用华为自研的企业级存储池 DFV Pool，基于分布式、强一致、高性能的先进架构，实现 3AZ6 副本存储，保证了在任何时间点的数据强一致，故障情况下数据不丢失。

1. 大流量、高并发场景如何支持连接管理，按业务况分散压力？

GaussDB(for Redis)可以满足 IM 系统对可用性的要求，客户端程序通过 ELB 接入 GaussDB(for Redis)实例，可实现自动负载均衡。

1. 突发的高流量、大量的历史消息数据如何处理？

GaussDB(for Redis)采用先进的存算分离架构，在 IM 系统持续运营的过程中，如果出现突发流量，可以迅速对计算层资源进行秒级扩缩容，快速扛住流量尖峰；历史消息持续增长时，也可以单独对存储层资源大小进行秒级动态调整，最高可扩容至 PB 级。

GaussDB(for Redis)广泛适用于社交媒体、游戏、电商、推荐系统等领域，在海量并发场景具备极强的高可用能力。如果你需要一款稳定可靠的高性能企业级 KV 数据库，不妨试试 GaussDB(for Redis)。