基于Go实现的分布式MQ

想要了解更多，加QQ群72132378

一、RPC与MQ之间对比

我们通常接触到的RPC同步调用的种类非常多比如fb 的thrift/阿里的dobbo

腾讯的taf、淘宝的hsf这类同步调用框架

从图里面可以看到作为一个业务完成后端要发生非常多的RPC通信

随着业务的复杂度提高，各服务间的依赖度也逐步加大，那么服务间的响应时间也就各有参差了

在一个请求链路上如果存在一个慢的服务那么可能会引起雪崩的效用，短板非常明显

最重要的时在一些要求一致性高的场景下，对错误的处理也是非常重要的。所以个服务也都要去做容错处理的代码保证逻辑和数据一致

A、B、C。。。服务之间通过共同的消息协议进行通信，数据一致性问题完全交给MQ去处理即可

A、B、C服务的同步响应效率得到提升

总结：

所以在我理解的消息中间件就是以消息作为信息载体实现系统间的可靠异步的调用，减少系统间耦合的中间层框架

二、消息传输模型

队列模式或者也可以叫点对点

很明显看到这个图很多人就会联想到redis的list结构

rpush—>lpop，没错

通过轮训去完成消息的送达

但是对于点对点模型来说存在的问题是，没法做到消息被B、C、D服务都消费的目标。

例如日常开发中我们想将用户登录“陌陌”的消息同时要给用户中心、anti-spam

这个时候就非常的不方便，那么PUB、SUB模式就呼之欲出了

pub/sub模式 以Topic为单位进行对消息的订阅、发布

B、C、D这些订阅了该Topic的服务均可以处理该Topic的消息

就好比你打开收音机，你在听91.5飞鱼秀、别人也订阅了飞鱼秀，可以同时收听感兴趣的主题的信息一样的道理

三、KiteQ是什么？

<