如何设计一个简单的消息中间件

前言

我们日常开发当中需要用到消息中间件的场合很多，我们或许也用到了形形色色的消息中间件产品，有老牌的ActiveMQ、RabbitMQ，炙手可热的Kafaka，还有阿里研发的Notify、MetaQ、RocketMQ等等，但反过来思考一下，如果让我们自己来设计一个消息中间件，需要考虑哪些方面的问题，需要有什么样的特性来满足实际业务生产的需要呢？下面就这个问题展开讨论。

消息队列应该有什么样的特性

很多有经验的工程师看到这个问题，脑袋里最直接能想到的应该是：解耦、异步、削峰。

解耦

想象这样一种场景，有个业务系统A，在处理某个核心业务逻辑的时候，跟另外的B、C、D三个业务系统有关联，当前已有的处理流程是A系统在处理完自己本地的事务后，顺次调用B、C、D三个系统的接口去同步数据状态。但是，随着业务的发展，突然有一天另外一个业务系统D的数据也同样需要根据A系统当中数据记录的更新而同步更新，此时，开发不得不去修改原有代码，加上调用D系统同步更新数据的代码。然后某一天，业务需求又发生了变更，B系统不再维护对应的业务数据，开发又不得不修改原有代码，将调用B系统接口的代码给删掉。如此周而复始，开发就会很苦恼。其实，站在A系统的角度来看，可能“关心”A系统变更的应用有很多个，但A系统只需要发布变更消息即可，谁关心谁接入。

异步

另外一种情况就是，还是上面最初的场景，A系统处理业务逻辑时，需要调用B、C、D三个系统的接口，但是其中D接口是个耗时任务接口，