关于回调函数和分布式消息队列的认识

    回调，在平时工作中经常能够听到。字面意思就是，我调用某对象的某项服务，然后等到将来的某个时机，被调用对象返回我想要的数据。其实，从字面上这样理解就可以大致知道什么意思了，但是这里的我调用对象的某项服务换成我向某个对象注册一个感兴趣的事件更为合适。

   在java里面有很多例子，最典型的就是PubSub模型，也就是设计模式中的观察者模式，首先很多客户向Publisher订阅消息，也就是把自己的reference给Publisher，然后Publisher触发事件后遍历一个集合，然后调用对应的方法，这样只要向Publisher注册的对象都会收到消息。从上面我们可以看出回调是事件触发的，事件触发一般意味着异步。

   那么回调到底解决了什么问题呢？

比如说我们想知道有没有人去点某个按钮，如果不异步通信，那么就只能没隔一段时间去问一下，这种轮询其实并没有做什么有意义的事情，却占用着cpu资源。如果，异步的话，我只要向那个按钮注册一个点击事件，然后告诉我这个回调函数，那么我就可以做其他事情了，这样效率也就提高了。

但是异步比起同步就难多了，因为如果要异步的去做，一般都是多线程编程，多线程编程中安全性和数据的一致性是一个值得关注的点，还有一点就是，我虽然注册了某项服务，但是我并不知道什么时候他给我，所以这就要进行合理的设计，比如说，我注册了某个服务后，不是立即去用回调返回的数据，而是先去处理其他的一些业务逻辑，然后再处理这个回调数据，这样异步的作用就体现出来了，也不会阻塞，如果我注册之后立即调用那么会出现被调用方没有准备好，因此我这边会阻塞，不阻塞没有办法，因为想要的数据没有，虽然一些编程语言也提供设置等待超时时间，但是这样就违背设计的初衷了，如果不合适就别这样设计。

   在之前的公司，我用到过一个分布式消息队列，rabbitmq,解决的问题是分布式的PubSub的问题，而且功能很多，可以支持消息的持久化。解决了分布式通信的问题，可靠性，吞吐量都还可以。其实把队列设置成持久化之后，吞吐量大概会下降10被，毕竟需要io操作把消息持久化，等到subscriber收到消息后，给rabbitmq发送一个ack，mq才把持久化的消息给删除。

    之前用akka，一个akka系统由许多个actor组成，actor是最小单元而且actor之间的通信都是异步的。actor之间的通信又两种，一种是one to one，这种one to one和面向对象中的一个对象调用另一个对象不同，面向对象编程思想中，对象的调用一般都是同步的，除非来一个新的线程异步的去做。另一种是one to many ，actor system中有个总线，类似于计算机中的总线，每次我发送消息的时候，我会向总线中publish这个message，然后其他actor可以先向总线中注册以及感兴趣的消息，因为如果不涉及到集群的话所有actor都是在一个系统中的，所以是可行的。可以看出one to many也是PubSub模型。也是异步通信或者分布式通信的主要方法。