如何设计一个消息中心

在互联网公司都会有一个叫消息中心的基础平台，基于我以往做消息中心的经验，简单的分析一下我对于如何设计一个消息中心的看法。

对于一个消息中心要解决的主要问题有以下几个：

消息中心的上游系统很多是监控系统、或者是营销系统等，这些系统的特点就是瞬间的调用量大，比如当云厂商发生故障时，基本上所有的监控系统都在告警，往外push消息。又或者营销系统在某个时间点大量发送营销消息。这个问题的答案就是引入MQ来削峰。

业务方通常希望自己的消息越快越好，最好实时送达，但是我们的资源是有限的，所以我们应该给消息分级别和分泳道，因为重要的消息一般量小，需要低延时。而不重要的消息量大，往往可以接收一定时间的延时。按消息级别分泳道，不要让不重要的消息阻塞重要消息的发送。

消息要保证不丢失，不重复发送。我们要记录消息的状态，保证消息的幂等，还要支持发送失败的消息自动或手动重试。

一般消息中心会对消息做一个较长时间的备份，这方面有政策要求。另一方面，业务方通常也有查询消息来排查错误的需求。我们可以分库分表，或者定期归档到hdfs。

对消息的统计和分析主要用来治理我们的上游调用方，比如：有些业务大量的使用重要级别发送不重要消息，或者大量消息占用成本等等。

画了一个简单的架构图

message.jpg

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