用Redis搞远程设备控制，感觉挺方便也挺复杂的，有点意思

（一）

前几天在网上瞎逛,看到有人在一个技术论坛里发帖，标题大概是“用Redis做个简单的远程设备控制器”，我点进去一看，感觉这想法挺有意思的，发帖的楼主没说太多高深的理论，就是用了一种我们平时常用来缓存数据的工具——Redis，来实现对远处设备的控制，你在电脑前点个按钮，远在另一个房间的灯就亮了，或者一个小风扇就转起来了，这听起来好像很科幻，但用Redis来实现，感觉路子一下子变野了，也变简单了。

（二）

Redis这东西,我平时就用它来存点用户登录信息啊，或者给数据库减减压，当个高速缓存用，它的特点就是快，数据都在内存里，读写得嗖嗖的，那个楼主的核心思路特别直接：他把Redis当成一个“中转站”或者“消息信箱”，想象一下，你想控制一个设备，比如让它“开灯”，你不需要直接给这个设备发指令（因为可能隔得很远，网络环境也复杂），你只需要往Redis这个“公共信箱”里，放入一条写着“开灯”的消息，那个设备呢，它啥也不干，就隔一会儿来检查一下这个信箱，看看有没有属于自己的新指令，一旦它发现了一条“开灯”指令，它就执行动作，然后把这条指令从信箱里拿走，表示“我已收到，办完了”。

（三）

这个方法妙在哪里呢？首先就是省事儿，你不用自己去搭建复杂的消息队列系统（比如用RabbitMQ或者Kafka那些，光听名字就头大），Redis本身就很轻量，安装配置也简单，它解耦做得好，控制端（比如一个网页后台）和被控制的设备，它们俩可以完全不知道对方在哪儿，长啥样，只知道中间有这个Redis信箱，控制端只管往里面扔命令，设备端只管从里面取命令，谁也不碍着谁，哪怕设备暂时掉线了，只要命令还在Redis里存着（Redis可以设置数据持久化），等设备一上线，还能拿到指令，不会丢。

（四）

但帖子后面也有人讨论,说这事儿想想是方便，真做起来细节上还挺复杂的，第一个麻烦就是，怎么保证设备能及时收到命令？如果设备是隔30秒才检查一次信箱，那从你点击按钮到灯亮，可能就要等半分钟，这体验可就太差了，解决办法也有，比如用Redis的“发布/订阅”模式，这个模式就像电台广播：控制端不再是往信箱里塞纸条，而是像一个电台主播一样“发布”一条“开灯”的消息，设备端呢，它早就“订阅”了这个频道，所以消息一“发布”，它马上就能听到，几乎是实时的，就不用傻傻地每隔一会儿去查一次了。

（五）

第二个复杂的地方是安全,Redis默认配置下，好像不怎么设防，如果暴露在公网上，谁都能连上来往里写命令，那岂不是谁都能随便开我家的灯、关我家的风扇？这太吓人了，所以真要用到实际中，必须给Redis设上密码认证，甚至可能要把网络端口限制死，只允许特定的控制端和设备端IP地址来访问，这就增加了设置的步骤和难度。

（六）

第三个是状态管理的问题,设备现在到底是开还是关？如果只是发一次性的命令“开灯”，那设备执行完就完了，但如果控制端想显示设备当前的状态，它就不知道了，这就需要在Redis里不仅存命令，还要存状态，设备执行了“开灯”后，还得自己往Redis里写一条记录，说“我现在是开启状态”，控制端要显示状态时，就来读这个状态记录，这样一来，数据往来更频繁了，还要考虑万一状态更新失败了怎么办，会不会出现控制端显示的状态和设备的实际状态不一致的情况。

（七）

我顺着帖子的思路自己琢磨了一下,感觉这确实是一个典型的“看起来简单，深究下去坑不少”的例子，用Redis做远程控制，核心思想非常清晰和巧妙，利用了它速度快、结构简单的优点，避开了重型消息中间件的复杂性，对于一个小型的、对实时性要求不是极其苛刻的、并且网络环境可控的个人项目或者原型演示来说，绝对是一个值得一试的“野路子”。

（八）

但另一方面,它又把分布式系统里常见的一些难题，比如实时性、安全性、状态一致性，这些本来可能由更专业的框架去解决的问题，一下子摆到了台面上，需要开发者自己动手去填补，这就好比给你一把非常锋利的瑞士军刀，切水果、开瓶子很方便，但你要是想用它来完成木工活，就得自己琢磨很多技巧，甚至可能还得搭配其他工具，感觉这事儿“有点意思”的点就在于：它用一种意想不到的简单工具，打开了一扇门，让你能快速尝到远程控制的甜头，但门后的路能走多远、多稳，却取决于你愿意花多少心思去处理那些随之而来的复杂细节，这种简单与复杂的交织，正是动手实践的乐趣所在吧。