一、传统的请求响应

请求响应同步：之前大家理解了线程同步（所有的线程不是一起进入到方法中执行，而是按照顺序一个一个进来)，今天要讲解的是请求响应同步，在这可以理解为同一个步骤，不另起炉灶。意思是当客户端和服务端进行通信时，客户端发送了请求，必须等到服务端所有的操作都做完，才返回给用户。（举例），这个过程就是请求响应同步的过程。

基于以上过程，我们会发现，如果服务端某一个流程出了问题，客户端很久就不会收到响应，一直处于请求状态。这样在用户看来，感觉程序卡死了一样，会极大的影响用户的体验感。

请求响应异步：首先要和线程异步区分下，线程异步是多个线程可以同时去访问某一资源。然而，请求响应异步是相当于给程序开几条路，各个路线互不影响。这样好处就很明显了，当客户端发送一个请求，不需要等待即可发送下一个请求，至于响应情况客户端不用管，它只需要请求就对了。

二、请求响应可能产生的问题？

阻塞和超时：以上已说明

接口重复提交

数据的幂等性问题

二、如何做到请求响应异步？

消息队列（缓存机制）：要做到请求响应异步，可以利用缓存机制，将某一操作请求数据实时的保存到消息队列中，然后立即相应到客户端。至于消息队列里面的处理可以慢慢来做。

备注   

    请求数据：登录成功后需要将用户登录信息(userId,userName,userPhone......)写入到数据库登录日志表，那么用户的相关信息就是请求数据。

    某一操作：不影响主业务流程的操作。比如用户登录包括登录成功状态和登录成功日志写入，那么登录成功后日志写入就是不影响主业务流程的操作，可以进行异步处理。

三、什么是消息中间件？

中间件：提到中间件，就想到中间人，他的作用是起到中介的作用。例如二手房中介链家，它的作用是联系房东与买房人的。

而软件系统中对应的中间件是帮助应用程序与其他应用程序、网络、硬件、操作系统交互或通信的软件。日常用的Redis、Nginx、Zookeeper、Memcached等等都是「中间件」。

消息中间件：个人理解为和消息有关的中间件。比如kafka ，activeMQ，Redis(也可以作为消息中间件)。

大家可以发留言讨论,redis作为消息中间件的应用场景。