上文我们已经利用websocket实现微信二维码支付的业务。

　　上述实现在单机环境中实现是没有什么问题的，无非就是客户端连接服务端，首先将连接的websocketsession存在一个map里面，当异步响应的时候，

根据流水号获取map里面对于的websocketSession，给指定的客户端发送消息。

但实际生产环境中，服务器一般是采用集群模式，首先，比方支付来说，接收第三方响应的服务器可能是有多台，然后具体是根据nginx随机路由转发，

假设异步响应的服务器有2台，A和B,而且连接websocket的代码是写在响应工程里面的，这时p1客户端去连接websocket的时候，通过域名实现websocket协议

，具体可在nginx里面配置，是随机转发到某一台，假设连接到A,这时session信息保存在A服务器，假设用户支付完成后，第三方异步通知也是随机转发A和B，

如果运气好，转发到A,此时异步响应能拿到session值，则能成功通知到客户端。如果不巧，转发到了B，则异步通知逻辑是执行了，但发现客户端一直没有收到

消息，因为B服务器根本拿不到这个session值。

解决上面的问题，首先考虑websocket是否可以在两台机器上共享，实现数据共享，当时想到的是是否可以将websocketsession序列化后存储到redis里面，然后

从redis里面获取给用户发送通知，最终发现不可行，因为websocketsession没有实现序列化接口，不能存在redis里面，另外就算能存储，客户端连接的是A，B就算拿到

session，但不能保证推送过去能成功，所以想到是否可以将上次连接的服务端记录下来，只要连接A，我就让A去发送，连接B，我就让B发送，既然不能将session存到redis

里，我可以考虑将流水号连接的服务端的ip存到redis里面，然后将发送消息的代码转移到一个controller，在异步通知的地方本来是直接执行发送消息的业务代码，改成调用

Http请求同时传递一个参数，根据这个参数可由流水号获取之前连接的服务器的ip，然后配置nginx解析参数指定转发到那一台。

通过上面的程序问题其实已经解决，其实如果从架构上优化的话，可以将websocket工程单独拆分成一个工程，不和异步通知的代码整在一起，由于异步通知的代码需要在

外网部署多套，而websocket可以只部署一套，这样nginx也不需要做指定参数转发的处理，比上述的方案更加优化。

然而实际中，如果websocket真的集群了，那么这个问题依然还是会出现，当然依靠redis和nginx指定参数转发，还是能做到点对点，只要所有websocket工程都不会宕机，

上述实现方案其实并没有实现websocketsession的共享，假设p1连接到A，异步的时候A宕机，这时p1就收不到消息，实际中集群按理说B还是可以给p1发送成功的消息，这就

可以利用消息队列的订阅发布的功能来模拟发送这个消息。