常见分布式高并发系统设计

最新推荐文章于 2024-07-24 17:11:21 发布

hust骚年

最新推荐文章于 2024-07-24 17:11:21 发布

阅读量151

点赞数

文章标签：分布式架构软件工程

本文链接：https://blog.csdn.net/u012588879/article/details/131164356

版权

高并发系统

高并发系统的设计其实主要围绕四点：高性能、高可用、高可扩展性、高可维护性

https://cloud.tencent.com/developer/article/1653881

<<分布式应用系统架构设计与实践>>

IM系统设计

https://xie.infoq.cn/article/19e95a78e2f5389588debfb1c

https://juejin.cn/post/7032512073502294053

https://www.bilibili.com/read/cv11325774?from=search

读扩散和写扩散

读扩散和写扩散的概念一般是出现在feed流或者IM消息系统中，一个用户关注或者被关注了多个人，那么当有人发消息时，其他跟该用户关联的用户如何获取消息的方式

读扩散

接收人维护了多个"信箱"，比如A关注了B, C，D，那么B，C，D有人发了消息，就会往AB，AC, AD信箱发送数据, 服务端可以维护那些信箱有新数据，那么A用户拉取的时候就从这些信箱拉取。（如果群有消息，那么群信箱加入数据，服务端可以标记某个群是否有消息）。

写扩散

接收人只有一个信箱，跟用户关联的人只要发了消息，那么就会将消息发到这个用户的信箱中，如果有群消息，那么会给群里所有人都发消息。

对比之下，读扩散，写操作时很方便，写扩散时，读操作很方便

底层数据结构

消息系统底层数据结构，一般情况下，message作为单独的表，message Id全局自增，另一张表是会话表，比如有to uid, from uid, message id的概念

推拉模式

一般可以采用推拉模式结合，比如一有新消息，就往客户端推送表示有新消息，然后客户端进行主动拉取具体的消息

消息的顺序性

在一对一聊天时，一般在客户端使用序列号，这样的话，消息就有顺序，接收方可以再排序

在群聊中，由于是不同的人发出的，客户端是没办法生成序列号，有两种方式：

1、一个专门的id序号服务，两个人发消息时都会生成一个序号，这样在所有人看到的群里，就是连续的。

2、同一个群消息，打到相同的service实例上，在实例上进行排序

http://www.52im.net/thread-714-1-1.html

比较完整的消息系统架构设计

https://www.cnblogs.com/hanease/p/16268095.html

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PyvPgAsF-1686538151922)(C:\Users\13045\AppData\Roaming\Typora\typora-user-images\1677984046075.png)]

一般来说消息主动推送，可以接外部的，比如google，融云的服务，他们来负责，本质上就是一个长连接。所以推送部分不是重点。

重点是整体的架构。

端：作为消息的发送和接收端，通过连接消息服务器来发送和接收消息。
消息服务器：一组无状态的服务器，可水平扩展，处理消息的发送和接收请求，连接后端消息系统。
消息队列：新写入消息的缓冲队列，消息系统的前置消息存储，用于削峰填谷以及异步消费。
消息处理：一组无状态的消费处理服务器，用于异步消费消息队列中的消息数据，处理消息的持久化和写扩散同步。
消息存储和索引库：持久化存储消息，每个会话对应一个Timeline进行消息存储，存储的消息建立索引来实现消息检索。
消息同步库：写扩散形式同步消息，每个用户的收件箱对应一个Timeline，同步库内消息不需要永久保存，通常对消息设定一个生命周期。
新消息会由端发出，通常消息体中会携带消息ID（用于去重）、逻辑时间戳（用于排序）、消息类型（控制消息、图片消息或者文本消息等）、消息体等内容。消息会先写入消息队列，作为底层存储的一个临时缓冲区。消息队列中的消息会由消息处理服务器消费，可以允许乱序消费。消息处理服务器对消息先存储后同步，先写入发件箱Timeline（存储库），后写扩散至各个接收端的收件箱（同步库）。消息数据写入存储库后，会被近实时的构建索引，索引包括文本消息的全文索引以及多字段索引（发送方、消息类型等）