浅谈中转

大家好，这里是tiankonguse的公众号(tiankonguse-code)。
tiankonguse曾是一名ACMer，现在是鹅厂视频部门的后台开发。
这里主要记录算法，数学，计算机技术等好玩的东西。

这篇文章从公众号tiankonguse-code自动同步过来。
如果转载请加上署名：公众号tiankonguse-code，并附上公众号二维码，谢谢。

零、背景

之前曾介绍过《每秒千万级别服务之诞生》。
这个服务的特点是对数据生产与消费的解耦，即数据的生产者不需要关心谁在使用数据，数据的消费者不需要关心数据从哪里来。
这里还有一个隐形的特点没有说，那就是数据只生产一次，然后可以随时来重复消费。

今天我们来看看与之对应的另一个问题以及解耦方法。

一、初始问题

资料组有一个系统供编辑来维护视频的资料。
当视频的标题被编辑修改后，搜索组希望马上知道标题变更了，因为他们也储存了一份视频的数据，然后他们知道视频变更后会重新来拉取视频的全量数据。
这个时候最简单的做法就是资料组修改视频的标题时，随便调用搜索组的接口，告诉他们数据有变更。
后来客厅组也储存了一套视频的数据，也需要实时更新视频的数据，于是资料组也调用客厅组的接口了。

接着储存资料的小组越来越多，视频，人名，栏目等数据变更时会有不同的小组希望实时感知到数据变更。
这个时候发现每个资料变更时私自去调用对应的接口比较难维护，耦合太重。
某个接口异常会影响所有人。

而且当同一个资料有多个变更着时， 两个变更着都需要去调用所有的接口，后来心中的接口很容易遗漏。
即使没有遗漏，也需要修改所有的变更着，成本很高。

这个时候hades站出来了。
他说我们要做这样一个系统：为每种资料分配一个编号，这个资料变更时就把对应的主键加编号发给一个消息队列，希望实时感知数据变更的业务去订阅这个消息队列就行了。

二、中转

根据上面的故事，我们可以看到消息队列的作用是把数据的变更着和数据的感知着进行解耦，并可以异步处理。
资料的变更者不需要关心谁需要感知这个资料是否变更，数据的感知者也不需要关心谁在变更这个资料。

这里我们给消息队列一个更专业的名字–中转。

中转就像现在的快递行业，讲我们的数据原封不动的从一个地方送到另一个地方。
下面根据使用场景简单分为下面三种情况：

1. 路由中转

路由中转是一种很常见的中转。比如平常听说的代理，VPN，接入层，路由层等都属于接口中转。

生活中的跨网通信也是的。
比如你是深圳电信网络，你需要给广州联通网络的朋友发个消息。
数据会先到达北京的电信主干网络，然后通过统一的路由到达北京的联通主干网络，最后才到达广州的联通网络。
可能有人会问深圳和广州之间应该可以之间通信的，为什么还需要去北京呢？
实际上这是路由中转的特点，所有请求必须先到达指定的地方，然后才能分发到目的地。

另一个例子是微信传文件与QQ传文件吧。
对于微信传文件，符合路由中转。
A在微信上给B传文件，文件会先从A的手机上传到微信的服务器,然后从微信服务器传给B的手机上。
而对于QQ，以前和微信一样也是先去中心服务器，不过现在会先探测是否在一个局域网内，在一个局域网内的话就不去中心了。

2. 拉中转

拉中转常用的场景是消息的通信。
比如A想给B发送信息，结果B不在线。这个时候A的消息就储存在拉中转中，B上线了拉取对应的数据即可。
又如今日头条会给所有用户推送tips，如果用户未激活这个app，则不能马上把tips发给用户，tips也会先储存在拉中转中，等用户上线了回来拉这些数据的。

3. 推中转

推中转和拉中转不同，这里不会缓存数据。
推中转得到消息后会直接把消息发给所有消费者，对于不在线的消费者将收不到这个消息。

三、总结

其实上面介绍的三种中转很类似，只是具体的功能特点不同。
比如路由中转也可以说是推中转，而拉中转与推中转的区别仅仅时是否把消息缓存起来。
但是他们的本质都一样，都是数据的生产者和数据的消费者进行解耦，消费者可以异步处理数据。

路由中转由于太常用了，大家都不称为中转了，而成为接入层、代理层、路由层。但是其功能符合中转的定义。
不过这里稍微不同时路由中转还会反向传输消息，而平常的推中转和拉中转都是单向传递消息的。

对于拉中转和推中转，大家都称为消息队列了。
业界比较出名的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。

我所在的小组曾使用过ZeroMQ来实现一个消息队列， 还有一个内部开发的消息队列。
后面两篇文章来讲解这两个消息队列的简单实现吧。

对了现在开通了公众号和小密圈。
博客记录所有内容。
技术含量最高的文章放在公众号发布。
比较好玩的算法放在小密圈发布。
小密圈这周接受免费加入，欢迎大家加入看各种算法的思路。

长按图片关注公众号，接受最新文章消息。