聊天系统设计调研

总体架构分层

• 接入层,无状态
• 逻辑层
• 存储层

这里是参考了陌陌设计

连接层

这里有2种方案选择

• WebSocket
• MQTT

关于MQTT,有EMQX中间件.

消息上线可以走HTTP接口,即客户端发给服务端消息

消息下行可以走EMQX订阅主题,即服务端推送消息给客户端

连接层属于无状态,支持水平扩展.

逻辑层

通用消息格式定制

以及业务路由分发决策

设计规则

不丢消息

需要业务ACK机制

消息去重

服务端与客户端都需要做到

时序一致性

可以用snowflake算法.

利用局部性原理减少id生成器压力,有利于水平扩展

缓存设计

由于实时系统,基本上有一层cache,类似内核系统的buffer。

多级缓冲,面向c端场景的话一般链路不会太长,而且要考虑数据回种,分布式一致性挑战.

大概local cache -> redis （读写分离)-> database（读写分离)

其他考虑场景

• 接入APP推送
• 接入风控
• 数据多端同步
• 多条消息打包与压缩格式设计
• 万人大群的数据扇出
• 明星突发性空降某频道
• 数据埋点监控
• 系统自动扩容

存储层

离线消息

如果需求量不大,Mysql即可以解决.

聊天应用的读写比例大概是1:1.

数据库

Cassandra

Discord公司有在用.偏向AP场景

HBase

Facebook公司有在用.偏向CP场景

个人想法

前期用Mysql,但是封装一层接口,为后期数据库迁移作准备.

大数据库选择要还看云数据库商支持程度,说不定还有其他云产品合适.

对象存储

minio

消息队列

rabbitMQ比较适合业务,

但是追求高吞吐的kafka,自己必须封装多一层机制来保证业务的一致性.