背景
在互联网公司都会有一个叫消息中心的基础平台,基于我以往做消息中心的经验,简单的分析一下我对于如何设计一个消息中心的看法。
问题
对于一个消息中心要解决的主要问题有以下几个:
- 调用量大
- 低延迟
- 不丢消息、不重复发送消息
- 历史消息查询和备份
- 消息统计分析
分析
调用量大
消息中心的上游系统很多是监控系统、或者是营销系统等,这些系统的特点就是瞬间的调用量大,比如当云厂商发生故障时,基本上所有的监控系统都在告警,往外push消息。又或者营销系统在某个时间点大量发送营销消息。这个问题的答案就是引入MQ来削峰。
低延迟
业务方通常希望自己的消息越快越好,最好实时送达,但是我们的资源是有限的,所以我们应该给消息分级别和分泳道,因为重要的消息一般量小,需要低延时。而不重要的消息量大,往往可以接收一定时间的延时。按消息级别分泳道,不要让不重要的消息阻塞重要消息的发送。
不丢消息&不重复发送消息
消息要保证不丢失,不重复发送。我们要记录消息的状态,保证消息的幂等,还要支持发送失败的消息自动或手动重试。
历史消息查询和备份
一般消息中心会对消息做一个较长时间的备份,这方面有政策要求。另一方面,业务方通常也有查询消息来排查错误的需求。我们可以分库分表,或者定期归档到hdfs。
消息统计分析
对消息的统计和分析主要用来治理我们的上游调用方,比如:有些业务大量的使用重要级别发送不重要消息,或者大量消息占用成本等等。
架构
画了一个简单的架构图

总结
以上,就是我在自己工作的过程中,对消息中心的一些经验,希望对建设消息中心的同学能有所启发。
网友评论