引用阿里云对设备影子的描述

概念：

设备影子是一个JSON文档，用于存储设备上报状态、应用程序期望状态信息。
每个设备有且只有一个设备影子，设备可以通过MQTT获取和设置设备影子来同步状态，该同步可以是影子同步给设备，也可以是设备同步给影子。

设备影子应用场景：

• 场景1：网络不稳定，设备频繁上下线。 由于网络不稳定，设备频繁上下线。应用程序发出需要获取当前的设备状态请求时，设备掉线，无法获取设备状态，但下一秒设备又连接成功，应用程序无法正确发起请求。
  使用设备影子机制存储设备最新状态，一旦设备状态产生变化，设备会将状态同步到设备影子。应用程序在请求设备当前状态时，只需要获取影子中的状态即可，不需要关心设备是否在线。
  
• 场景2：多程序同时请求获取设备状态。 如果设备网络稳定，很多应用程序请求获取设备状态，设备需要根据请求响应多次，即使响应的结果是一样的，设备本身处理能力有限，无法负载被请求多次的情况。
  使用设备影子机制，设备只需要主动同步状态给设备影子一次，多个应用程序请求设备影子获取设备状态，即可获取设备最新状态，做到应用程序和设备的解耦。
  
• 场景3：设备掉线。
  • 设备网络不稳定，导致设备频繁上下线，应用程序发送控制指令给设备时，设备掉线，指令无法下达到设备。
    • 通过QoS=1或者2实现，但是该方法对于服务端的压力比较大，一般不建议使用。
    • 使用设备影子机制，应用程序发送控制指令，指令携带时间戳保存在设备影子中。当设备掉线重连时，获取指令并根据时间戳确定是否执行。
  • 设备真实掉线，指令发送失败。设备再上线时，设备影子功能通过指令加时间戳的模式，保证设备不会执行过期指令。

思考总结

根据上面描述的设备影子概念和应用场景，设备影子简单来说就是以下俩点：

1. 储存设备最新状态
   1. 让应用程序请求和设备解耦。既不用关系设备是否在线，也不用关心设备处理请求的能力。因为设备和设备影子是一对一同步，影子负责处理请求。
2. 储存服务端指令
   1. 让下发指令和应用程序解耦。不用关系设备是否收到指令，只要指令发到设备影子即可。设备上线后会获取影子中的指令，加时间戳判断是否执行。

      结论

      结论内容只是作者观点，有不同想法的欢迎留言。
      对于总结的第一点（也就是阿里描述的前俩个应用场景），可以说TB已经实现了，就是设备属性功能：
      设备属性上传到tb平台。应用程序要请求设备当前状态不需要给设备发指令，请求平台接口即可；多应用程序同时请求设备状态，也不需要将请求发送到设备，依然是tb平台处理请求，不用担心设备处理能力。

对于总结的第二点（也就是阿里描述的第三个场景），TB的发送命令节点有超时重试功能
需要配置文件做配置thingsboard.yml 下面第一个配置改为RETRY_FAILED_AND_TIMED_OUT。默认是跳过所有失败事件，改为重试失败和超时事件。

除了超时重试，也可以按照设备影子的思路,用tb的属性来实现。