别写秒杀系统了，我告诉你消息管理平台实现原理吧

没错，我又给自己挖了个坑。

为什么想写项目相关的文章呢？原因有以下：

• 当我还没正式开始工作时，我经常会想：”网上的视频项目我是看过了，但真正的商业项目究竟长什么样？会不会很难？“我是挺想知道真正的商业项目跟自己练习的项目区别在哪。我估摸还没工作的同学应该也有跟我类似的思考吧？

• 变相推动自己持续输出，在这个过程中学习和成长。关注我可能有小白，也可能有跟我做同一领域的大佬。我把我所了解的写下来：可能我这边的实现方案被大佬们唾弃，交流和学习后，改善了我系统的实现方案。也有可能给正准备踏进该领域的同学提供一些参考价值。岂不美哉？

这个系列就以「消息管理平台」来打个样吧，这是我维护近一年的系统了。这篇文章可以带你全面认识「消息管理平台」是怎么设计和实现的，有兴趣的同学欢迎在评论区下留言和交流。

这篇文章可能稍微会有些许长，我是打算一篇就把该系统给讲清楚。「消息管理平台」原理并不难，没有很多专业名词，实现起来也不会复杂，你要是觉得学到了，欢迎给我点个赞👍

简单认识《消息管理平台》

「消息管理平台」可能在不同的公司会有不同的叫法，有的时候我会叫它「推送系统」，有的时候我会叫它「消息管理平台」，也有的同事叫它「触达平台」，甚至浮夸点我也可以叫它「消息中台」

但是不管怎么样，它的功能就是给用户发消息。在公司里它是怎么样的定位？只要以官方名义发送的消息，都走消息管理平台。

一般你注册一个APP/网站，你可以收到该APP/网站给你发什么消息呢？一般就以下吧？

• 站内信（IM）消息：其实就是APP内聊天的消息

• 通知栏（PUSH）消息：系统弹窗消息

• 邮件（Email）消息

• 短信（Sms）消息

• 微信服务号消息

• 微信小程序（服务通知）消息

好了，我相信你已经知道这个系统是用来干嘛的了。那为什么要有这个系统呢？

为什么要有消息管理平台？

可以说，只要是做APP的公司几乎都会有消息管理平台。

我们很多时候都会想给用户发消息：

• 有可能是用户想要这样的功能（预约活动提醒通知）

• 也有可能是我们想通过发消息来「唤醒」/「告知」等操作，告诉用户我们还在（大爷来玩啊）

那么问题来了，发消息困难吗？发消息复杂吗？

显然，发消息非常简单，一点儿也不复杂。

发短信无非就是调用第三方短信的API、发邮件无非就是调用邮件的API、发微信类的消息（手Q/小程序/微信服务号）无非就是调用微信的API、发通知栏消息（Push）无非就是调APNS/手机厂商的API、发IM消息也可以使用云服务，调云服务的API...

可能很多人的项目都是这么干的，无非发条消息，自己实现也不是不可以。

但这样会带来的问题就是在一个公司内部，会有很多个项目都会有「发送消息」的代码实现。假设发消息出了问题，还得去自己解决。

首先是系统不好维护，其次是没必要。我一个搞广告的，虽然我要发消息，凭什么要我自己去实现？

我们在写代码时，可能会把公用的代码抽成方法，供当前的项目重复调用。如果该公用的代码被多个项目使用，可能我们又会抽成组件包，供多个项目使用。只要该公用的代码被足够多的人去用，那它就很有可能从组件上升为一个平台（系统）级的东西。

如何实现消息管理平台？

回到消息管理平台的本质，它就是一个可以发消息的系统。那怎么设计和实现呢？我们从接口说起吧。

接口设计

消息管理平台是一个提供消息发送服务的平台，如果让我去实现，我的想法可能是把每种类型的消息都写一个接口，然后把这些接口对外暴露。

所以，可能会有以下的接口：

/**
* content：发送的文案
* receiver：接收者
*/

sendSms(String content,String receiver);
sendIm(String content,String receiver);
sendPush(String content,String receiver);
sendEmail(String content,String receiver);
sendTencent(String content,String receiver);
//....

这样实现好像也不是不可以，反正每个接口都挺清晰的，要发什么类型的消息，你调用哪个接口就好了。

假设我们定义了如上的接口，现在我们要发消息了，我们会有以下的场景：

1. 文案：「你好，我是三歪」，接收人：「woshisanwai」 （一次只发给一个人）

2. 文案：「你好，我是三歪」，接收人：「woshisanwai,java3y,javayyy」（相同的文案发给多个人）

假如你是新手，你可能会想：这简单，我每种类型分开两个接口，分别是单发和批量接口。

sendSingleSms();
sendBatchSms();
//...

上面这样设计有必要吗？其实没啥必要。我将接收人定义为一个Array不就得了？Array的size==1，那我就把该文案发给这个人，Array的size>1，那我就把这个文案发给Array里边的所有人。

所以我们的接口还是只有一个：

/**
* content：发送的文案
* receiver：接收者（可多个，可单个）
*/
sendSms(String content,Set<String> receiver);

其实在我们这也不是定义Array，我的接口receiver仍然是String，如果有多个用,号分隔就可以了。

/**
* content：发送的文案
* receiver：接收者（可多个，可单个），多个用逗号分隔开
*/
sendSms(String content,String receiver);

现在还有个场景，不同的文案发给不同的人怎么办？有的人就说，这不已经实现了吗？直接调用上面的接口就完事了啊。你又不是不能重复调用，比如说：

1. 文案：「你好，我是Java3y」，接收人：「woshisanwai」

2. 文案：「你好，我是三歪」，接收人：「3y」

3. 文案：「你好，woshisanwai」，接收人：「三歪」

4. .....

确实如此，本来就可以这样做的。但不够好

举个真实的场景：现在有一个主播开播了，得发送一条消息告诉订阅该主播的人赶紧去看。为了提高该条通知的效果 ，在文案上我们是这样设计的：{用户昵称}，你订阅的主播三歪已经开播了，赶紧去看吧！

这种消息我们肯定是要求实时性的（假设推送消息的速度太慢了，等到用户收到消息了，主播都下播了&#