常见分布式应用系统设计图解（一）：即时消息系统
source link: https://www.raychase.net/6260
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
常见分布式应用系统设计图解（一）：即时消息系统
在自己学习各种各样软件系统，特别是分布式系统的过程中，我做了一些笔记，有许多常见的、经典的系统，是非常值得学习和总结的。它们数量不算多，但具有典型意义，可能这样的系统也就十几个。
我在回顾这些笔记的时候发现，有时候一张简单的图，包含最核心的几个设计，就可以很大程度地帮助理解和记忆。所以我想把这些笔记和图解的结合通过文章的形式发出来，预计每篇文章都很短，基本上一张图，加上一点说明性的文字。
Disclaimer：这些都来自我自己的阅读和理解，肯定有着相当的改变和简化，因此它并不代表任何系统实际的样子。
今天是第一篇，即时消息系统，但是基本上好多即时通讯软件都属于这一类，比如微信，比如 QQ，比如 Facebook Messenger，比如 WhatsApp。
- 用户发送消息，直接发给 Chat Service，它会做少量的处理并持久化，然后发给一个 channel，每一个对话（thread）都会有一个 channel，这个过程中，它并不关心这个对话有多少人参与（支持群聊）。由于单台机器和客户端的连接数量有限（比如小于 2^16=65536），因此 Notification Service 需要有很多机器，根据用户的 id 来 sharding，它们去订阅自己感兴趣的频道，有新的消息就发送给用户。
- Notification Service 获取客户端的心跳，保持来自客户端的连接（long polling 或者 socket）为了实时性肯定要用 pull 模型，不能用 push 模型。因此它知道用户的当前在线状态，也知道最后一条发送成功消息的时间戳（状态）。这个状态可以用于决定用户离线时消息是否要通过其它方式通知用户。
- 右侧的消息数据库，RDB 往往不太适合，因为消息数量太大，对于一组对话（thread）的展示，需要找到该对话 N 条最近的记录，行数据库效率较低，可以考虑列数据库，比如 HBase。这种方式下，同一 thread 下的消息都是按时序存放在一起的，读的效率非常高，写因为基本是 append，也很方便。
- 用户数据的存储，可以使用 RDB，也可以使用 KV 数据库。 这里面存放的数据库表包括：用户表；对话表；用户对话关联表：二者是 M:N 的关系，并且每个用户都可以有对于特定对话的设置，例如设置对话中的昵称，是否屏蔽消息通知等等。
- 对于图中的 Channel， 它并不是 Kafka 这样的复杂的消息系统，而更像 Chat Service 的一个缓存，它是为了提高多个 Notification Service 获取消息效率而设的，不用担心消息丢失，因为持久化的消息在 Message Storage 中。具体来说，因为数据 push 过程对于速率无法保证，那么数据消费的速率也就无法保证，同时数据也可能被多台 Notification Service 机器使用（比如群聊的情况），因此使用这个 Channel 来共享、缓存待推送新鲜数据。
- 对于用户上线、下线的实现，其实也类似，上线、下线的事件可以推送到一个特定的 Channel 里面。用户的好友，也就是感兴趣的 Notification Service 的个体去订阅消息；还有一种思路是把状态更新到用户表里面，这样所有人都可以查询得到，这后一种方式适合非好友也要查看用户状态的情况。上、下线需要保留缓冲时间，容许一定状态的延迟，没必要，也不应过于实时。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
Recommend
-
37
“ Top K 系统 ” 是非常常见的一种子系统，基本上，就是从全量巨大的统计数据中，筛选出数值最大的 K 个来并按序展示。这样的筛选可以是全时间内的，也可以是最近某一段时间内的；可以是全分类的，也可以是某个特定分类的。 具体...
-
27
输入提示系统，指的就是 “typeahead”，比如 Google 搜索，输入一个单词的前几个字母，后面最常用的几个搜索词会被联想出来。有时，它也需要具备一定程度的字符拼写错误自动更正能力。
-
12
常见分布式应用系统设计图解（十）：电商秒杀系统 这篇是关于电商平台秒杀系统的。 首先，我觉得 “秒杀” 是一个中国色彩浓重的词，这样的概念在西方电商系统中也有，但只有在中国，本来业务量就已经如此之巨大了，还将其如此发扬开来。...
-
17
常见分布式应用系统设计图解（五）：Proximity 系统 今天是介绍 Proximity 系统，我不知道怎么翻译恰当，就保留英文原文。虽说词义上说的只是 “相似度”，但多数说的是 “地理” 上的相似度。因此，这一类系统多为基于地理上的邻近程度来提...
-
15
常见分布式应用系统设计图解（四）：输入建议系统 输入建议系统，指的就是 “typeahead”，比如 Google 搜索，输入一个单词的前几个字母，后面最常用的几个搜索词会被联想出来。有时，它也需要具备一定程度的字符拼写错误自动更正能力。
-
18
常见分布式应用系统设计图解（二）：Feed 流系统 今天记录 Feed 流系统的设计学习笔记，Feed 流常见系统包括 Twitter、微博、Instagram 和抖音等等，它们的特点是，每个用户都是内容创作者，每个用户也都是内容消费者，每个用户看到的内容都是不...
-
10
这篇讲的是证券交易系统，这类系统包含的内容很多，但是我们还是把目光放在核心的交易部分，比如说股票交易。在某个可交易时间，如果卖家 A 要以至少 y 的价格卖掉股票 x，卖家 B 愿以至多 y 的价格买入股票 x，那么这个交易就可以发生。
-
11
短网址系统可能是最常见的分布式系统设计问题之一了，本身从业务需求上说，读远多过写，而且数据结构确定且简单，数据量小，还易于使用缓存，因此本身难度在分布式系统的问题里面算是比较低的。另外，这个系统本身 “分布式” 的特性也比较...
-
10
常见分布式应用系统设计图解（十四）：日志系统 典型的互联网应用的日志系统，从功能需求上看主要包括收集，存储和分析，以及展示这样三个部分，因此整个系统我觉得也可以按此思路大致可以分为三个部分： ...
-
9
常见分布式应用系统设计图解（十五）：支付系统 支付（Payment）系统可以很复杂，比如可以和银行打交道，和信用卡系统打交道。如果我们考虑用户在一家电商买东西，...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK