Message Queue的设计和实现（7）
http://mp.weixin.qq.com/s/zQdDBAHu1UgJJzxH2eCHgQ
数据发送中的推与拉。
当MQ要把数据给消费者的时候，就涉及到数据的传递方式。一种是MQ主动的将数据推给消费者；而另一种，则是消费者主动去拉取。两种方式各有优缺，我们就一个个的来讲。（无非就是在爱情中谁主动的问题^_^）
推模式
推模式很明显，主动方应该是MQ。在实现的时候却有两种方式。
1、MQ知道消费者的IP和端口，主动发起连接，推送数据。
这种方式是最容易想到和实现的。socket在connect的时候，需要IP：Port。只要这两个数据存在了，MQ就很轻松的将数据推送出去。但是，问题来了，怎么知道IP和Port。
这里有两种方式：
A、MQ存储有所有消费者的列表。就是手动或者半自动的将所有消费者的列表配置到MQ中。这种方式实现简单，但是灵活性太差，扩展性不好；
B、消费者自动注册到MQ。当消费者启动以后，调用MQ提供的regist方法，自动将自己的IP和Port提交到MQ。注册成功后，MQ将信息放入发送meta数据中，进行推送。
第二种方式扩展性比第一种好很多，但是复杂性也相对比第一种要大一些。
2、消费者主动连接到MQ，再由MQ进行信息推送。
这种方式的实现必须采用长连接的方式。即：消费者主动connect到MQ，然后两者维持连接不断开。当有数据到来时，MQ利用这个已有的长连接，将对应的数据推送到消费者。
这种方式实现的难度比较高，涉及到长连接维持，以及连接的存活管理。而且如果后端有大量的消费者的话，MQ会消耗比较多的连接资源。
以上聊的是推的模式。这种模式及时性非常好，数据一到达，立马可以push到消费者，基本没有延迟。但是实现复杂度和灵活性会稍微麻烦一些。
拉模式
这种模式就比较简单，就是消费者主动。每次由消费者主动去获取信息。不论长短连接都可以。MQ也不用维持连接状态和消费者信息，只要你来获取，我就把数据给你。
这种方式的好处在于实现非常简单，MQ无负担，不用记录消费者的信息。如果服务挂掉或者重启，也不用担心消费者信息状态丢失。因为他自己会来主动获取。
不足之处在于有可能存在短暂延迟。
在实现的时候，也可以有改进。比如，消费者去MQ拉取数据，如果拉取后没有数据，可以停留一定时间（比如：100毫秒）再去拉取。如果拉取有数据，则不用停留，直接拉取。拉的时候也可以走批量拉取，避免数据堆积。
总的来讲，推拉模式都是可行的，实现复杂度其实也都还好，大家可以根据自身业务的特点来定制这两种模式。