回复问题 | netty请求响应的拟同步处理

公众号首个正式受理问题出炉啦！！！

感谢这位读者对我文章的仔细阅读，而他提到的这个点也确实是项目中尚未解决的，做项目的时候其实并没有这个业务点，因为当时为了快，直接拟定不需要通讯的应答信息。

我在这里再次解释下，第一个问题的核心，就是小程序或者APP等用户端下达开锁指定的时候，Iot中心向单片机等借书柜发送对应的开锁指令，然后单片机做了操作后应答我们，返回说开锁成功，我们再重新通知用户端说“开锁成功，请拿去图书！”，等类似的信息。

提问中说到一点就是，一键开启多个柜子，这里其实在我所了解的业务中和开启一个柜子其实是差不多的，因为项目中的指令都是“gzF5690137563CC8syyyyyyyyyyyyyyyyynnnnnnnf92fxr”，指令中的“yyyyyyyyyyyyyyyyynnnnnnn”就表示这24个锁的开启关闭状态，如果是统一开启就都是y，一个关闭就对应的位置为n，当然这个要看具体项目的协议。

那么接下来我们就拿开启单个锁，调用API下达开锁指令，Iot中心等待单片机应答后，提示用户端：“开锁成功！”的这个例子来实现一遍。

从受理问题开始我就边吃饭边思考，明天早上要吃什么呢？···emmm，说错了，应该是这个问题要如何解决呢？

我立马拿起《netty实战》看了看EvenLoop和线程模型，我一开始想到的就是线程，结果看到了这样一句话。

好吧，官方叫我不要去等待，一切都是异步，这样才是最好的，那么我就跳出了要去如何等待TCP的单片机返回信息后再次回到线程处理的圈子里面。

那么只能用其他方式了，API而言就是用户端对后台服务的请求，而这里的API针对性就是发送信息给单片机，那么我就不修改它的核心功能，那么我们还需要一个向用户的通知，push？？？

这让我立马想到了WebSocket，现在的双向通信一般都是万金油，小程序、APP、PC？这些WebSocket都可以！

然后就开始构思流程了，以下是我的草稿图

说了是草稿了，不要见笑哈~

好像不太好看，我重新画一个大致的架构图吧。

那么我接下来详细介绍下我的思路：

1、WebSocket也是netty，用户的小程序使用WebSocket连接的时候附带Toekn信息，我将以键值对的形式存储Token-Channel（用户标识—链接实例）

2、单片机启动的时候，会自动连接Iot中心，连接的时候也是将唯一标识上传，Iot校验后存储，ID-Channel（标识—链接实例）

3、小程序调用API发起开锁命令，参数（ID、开锁信息、Token），ID用于查找单片机实例，Token是关键，我会有一个中转层用于存储ID-Dto（属性：Token、开锁信息），记录这个用户对某单片机有开锁操作

4、Iot向单片机发起开锁信息，这个比较简单，之前实现了，使用ID拿到单片机链接实例，然后发送开锁信息

5、开锁完毕，返回开锁成功，因为信息中存在ID，所有我们可以做校验，中转层是否存在这个ID，如果存在，这个开锁信息是否也有存在，如果存在，那么我们就找到了将要通知的用户Token，然后通过WebSocket向用户发送“开锁成功”

6、想用户发送开锁成功，这里一定要注意，发送完后，一定要将中转层的这个信息完全删除，以便下一次对应

注意：最后就是实现过程中的一些业务问题还有对应的协议了，基本上是没有其他太大的问题。

大家来看看效果吧！（PS：PostMan模拟API调用后，立即返回的是发送成功，接着0.4秒后页面才显示“开锁成功”，这里才是真正的用户通知）

https://v.qq.com/x/page/x1352dd3t0v.html

最后，当然也是上传到GitHub啦！

还是InChat项目（tcp-wechat分支哦）！

地址：https://github.com/UncleCatMySelf/InChat

快点来是发现BUG吧！（发现了也要自己试试处理哦！）