主动复制结构

主动复制结构是（ARF）是针对物联网（IoT）边缘设备与远程系统上的数据库存储之间的数据交换的实现。

SmartEDB分布式物联网应用的核心在于主动复制结构（ARF）。由于边缘设备数量众多、资源和CPU能力有限，以及设备与后端处理器连接的不稳定，主动复制结构的分布式架构显得尤为合适。这种结构的应用程序能够对物联网数据执行深入分析，帮助企业发现使用模式，识别联网设备中的不足之处，并最终合理分配技术和财务资源，助力开发更优质的联网产品。

工作原理

在物联网的环境中，数据主要分为三类：边缘设备负责数据的收集；路由器和服务器则负责数据的分析。边缘设备在收集或生成数据后，可能会执行初步的筛选，并确保数据在特定时段内的安全性，之后将数据发送至服务器以进行更深入的处理。物联网路由器在服务器与边缘设备之间构建了一个或多个中间节点层。

物联网的网络结构类似于一棵树，其中服务器是树根，设备是树叶，而路由器则构成了树的内部节点。在这棵树状结构中，每个节点都分配有一个层级（一个2字节的整数）：服务器的层级固定为1，设备的层级为65535（即0xFFFF），路由器的层级介于2至65534之间。路由器的层级决定了其在网络中的位置——层级数值越小，节点距离服务器就越近。尽管路由器的层级（及其位置）可以在运行时调整，但其基本类型（设备、服务器或路由器）一旦数据库创建后便不可更改。

除了服务器和设备，每个路由器都必须拥有一个独特的代理 ID。需要指出的是，服务器的代理 ID 永远是固定的，即 agent_id = 1。服务器上的 UP/DOWN 表含有一个自动生成的字段 agent_id。在 UP 表中，它代表创建记录的节点；而在 DOWN 表中，它表示服务器创建的行的接收方。路由器的 UP/DOWN 表中包含两个自动生成的字段：src_agent_id（记录的创建者）和 dst_agent_id（记录的接收方）。设备数据库中的表则没有可访问的自动生成字段。

主动复制结构 API 允许基于设备的应用程序收集数据，并在连接时将数据传输到服务器；同时，它们也支持将服务器端的数据传送到物联网设备，通常用于设备的新配置和设置。这种数据流动完全由应用程序通过主动复制框架的推送/拉取接口控制。这些 API 提供了在数据收集点和服务器之间进行自动或按需数据交换的功能。

请参阅物联网数据库模式定义以了解更多。

实现

ARF提供了在收集点和服务器之间实现自动或按需数据交换的 API。一般来说，物联网应用程序通过以下步骤来利用 ARF：

初始化 ARF 运行时，创建一个内部虚拟回调函数表；
创建并连接到数据库；
创建通信器对象。通信器对象负责与底层网络层（套接字）进行的所有交互。
创建复制器对象。复制器管理复制过程，并在一边与通信器交互，在另一边与数据库交互。
注册回调函数。回调函数是用于对网络事件作出反应的手段，例如：连接/断开连接、数据传输（接收/发送）以及协议确认。
通过 listen 或 connect 操作激活网络通信。
在以“常规”方式管理数据库的同时，有时要对通知回调作出反应，或者明确调用 ARF 复制器函数来发送（推送）或接收（拉取）本地存储的数据，并清理过时的数据（已被对等方复制并确认的数据）。
终止复制器和通信器。

通信器和复制器对象属于创建它们的进程，不会在多个进程之间共享。原则上，一个进程可以成对地创建多个通信器和/或复制器。然而，在实际应用中，因为这些对象可以在多个并行任务中使用。

请注意，通信器能够监听多个配置不同的套接字（不同的端口、安全或非安全套接字、TCP/IP 或本地套接字）。

已注册的回调函数由通信器在响应各种网络事件时调用。在 ARF 运行时初始化期间，首先注册复制器回调函数。此外，应用程序还可以注册自己的回调函数来处理事件。例如，在建立网络连接时同步节点，或者在收到服务器确认后从设备容器中删除“过时”的数据。这些回调函数在通信器的服务任务上下文中运行，服务任务的数量在创建通信器时指定。

了解C 语言中的 ARF（物联网）应用

对于主动复制框架（物联网）应用程序，需要两个模式定义声明。

物联网数据库模式定义

在数据库模式定义中使用声明： iot server | router | device 来表明该数据库旨在用于主动复制框架（物联网）应用程序。

例如：

    iot server;

路由器声明必须指定level 在 2 到 65534 之间的级别，并且可选地指定一个 agentId。例如：

    iot router<100> 15;
    
    // 或者
    
    iot router<100>;

边缘设备的level 具有 65534 级别，并且可选择指定agentId。例如：

    iot device 1000;
     
     // 或者
     
     iot device;

The declaration defines the role for the database: as a server or router database or a device storage container. Optionally, the agentId for the database can be specified. The agentId is a unique identifier for the database. If this agentId is not specified through the schema, it must be specified as a database parameter when opening the database.

该声明定义了数据库的角色：作为服务器或路由器数据库或设备存储容器。

可选地，可以指定数据库的agentId。agentId是数据库的唯一标识符。如果未通过模式指定，则在打开数据库时必须将其指定为数据库参数。

当iot被声明后，数据库运行时会创建两个隐藏的类（表）：

@sys_iot_ts：包含从其他物联网节点发送或接收的数据的信息；
@sys_iot_del：包含从容器中删除的对象的信息，这对于将删除操作传播到其他物联网节点是必要的。

上表和下表类修饰符

“uptable”和“downtable”这两个类修饰符用于定义复制方向。定义为：

**“uptable”**类是从设备同步到服务器：对设备存储容器所做的任何数据修改都会传播到服务器的数据库。例如设备存储容器中收集的传感器数据，这些数据会被复制然后存储到服务器的数据库中。
**“downtable”**类则是向下同步，即从服务器同步到连接的设备。例如设备的配置参数，或者由服务器发出的指令，这些会被传播到设备。

请注意，未指定为“uptable”或“downtable”的类（表）不会被复制。

所有上行表和下行表的类都包含由模式编译器自动生成的字段 agent_id。

对于上行表的类，agent_id 标识接收对象（记录）的设备。
对于服务器的下行表，agent_id 标识必须将对象（记录）发送到的设备节点存储容器。

例如，可能会为服务器数据库定义以下类：

    uptable class TempSensor 
    {
        datetime          ts;
        unsigned<4>   sensorId;
        double             value;
        tree<ts, 
        agent_id, 
        sensorId> ats;
    };

agent_id字段在模式中未明确定义，但可在索引中使用。

对于下表类，默认的agent_id=MCO_IOT_ALL_AGENTS，这意味着默认情况下，服务器的数据会复制到所有设备存储容器。也可以明确指定agent_id的值，这会导致服务器的数据仅复制到指定的节点。

除了 agent_id 字段外，上表和下表类还生成了两个隐藏的索引字段，用于标识对象及其最后修改的时间戳。这两个字段及其索引会在数据库运行时自动更新，只要事务提交时修改了对象。

但请注意，这些内部管理的字段（iot_object_id@ 和 iot_timestamp@）应用程序无法访问。

iot_object_id@ 的值类似于自动 ID OID，只是它仅限于类本地，因此要创建全局标识，需将其与创建对象的节点的 agent_id 相结合。
iot_timestamp@ 的值是对象最后修改的逻辑时间戳（而非实际时间），每次事务都会递增此计数器并存储新值。这是为了执行 IoT 同步策略，该策略用于识别在同步期间需要发送到下一个 IoT 层级的对象。因此，如果应用程序需要时间戳值，则必须定义一个字段，例如上述模式中的 ts，以便能够访问并在需要时包含在索引中。

物联网面临的挑战

从车辆、建筑物到工厂车间和电源插头，我们周围的一切正越来越多地受到传感器的控制。数据采集点和边缘设备的数量不仅庞大且增长迅速。过去，我们处理的联网设备数量仅限于几十个，如工厂控制器、人脸识别或指纹扫描仪、电视调谐器等。而在当今的应用中，联网设备的数量以及成千上万了。

物联网中的边缘设备通常收集来自各种智能联网设备或流媒体源的原始数据以及由算法生成的数据等。即使在单一设置中，物联网设备的数量也可能迅速变化。新的传感器常常成百上千地上线，仪器和控制机制可能一夜之间被替换，网关被添加或移除等。在此过程中，物联网环境必须保持运行，这推动了将数据处理从后端转移到边缘设备的趋势，以扩展物联网环境及其数据管理的可扩展性。

从数据库管理的角度来看，这意味着以下几点：

需要无缝集成的通信服务；
在边缘设备上选择平衡良好的数据库管理功能，以保持资源消耗低，同时允许足够的分析以减少与云或服务器之间的数据流；
边缘数据库管理和其分析必须小巧快速，但又足够强大，以对设备的功能产生影响。

因此，高度可配置的数据库管理系统成为支撑边缘计算的关键。

本质上，“嵌入式”边缘设备永远不会有足够的内存和 CPU 功率来独立处理大量数据，至少在满足设备主要用途的同时无法做到。例如，汽车刹车系统的目的是让汽车停下来，而不是分析刹车模式以提高刹车的整体效率。因此，边缘设备的分析能力总是有限的。现代边缘设备是真正联网的；数据处理通常会在设备本身之外进行。

连接性

连接性方面，边缘节点的物理连接可能是间歇性和受限的。

在物联网的边缘节点中，物理连接的稳定性往往是一个挑战，带宽也相对有限。这些节点通常采用如ZigBee、NFC、RFID、LPWAN以及低功耗蓝牙等协议进行通信。由于这些协议的特性，边缘节点在数据传输过程中可能会遇到连接不稳定的问题，这需要特别的设计来确保数据传输的可靠性。
物联网设备在连接性方面面临诸多挑战，这要求系统必须支持“推送”和“拉取”这两种协议。通过这两种协议，可以确保当数据在边缘设备收集之后，能够被妥善保存并及时传输到需要这些数据的地方。这种机制对于保证物联网设备数据的完整性和实时性至关重要。
物联网设备通过互联网连接到网络，这使得数据可以通过Web客户端应用程序和Web服务进行访问。为了确保物联网系统的高效运行，这些应用程序和服务需要易于部署和集成，以便用户能够快速地接入和使用物联网系统提供的各种功能。
物联网设备产生的数据量巨大，这些大数据需要实时分析以提升服务质量和响应速度。然而，由于节点的存储和分析能力有限，通常只能依赖后端的复杂分析工具来进行深入的数据处理。这就要求物联网系统在设计时，要考虑到如何有效地将数据传输到后端进行处理。
云数据库管理系统在处理物联网数据时，需要采用优化CPU和存储的方法，例如垂直存储和向量处理技术，以及并行处理数据的能力。这些优化手段能够提高数据库的性能，确保物联网系统能够高效地处理和分析海量数据。
物联网边缘设备在运行过程中会生成大量的非结构化数据，这些数据通常需要非关系型数据库的支持。例如，JSON格式的数据因其灵活性和易用性，成为处理非结构化数据的首选格式。同时，为了实现近实时分析，需要对这些非关系型数据库进行优化，以提升数据处理的速度和效率。

安全性

物联网设备已经广泛地渗透到工业、汽车、医疗以及商业等多个领域之中，它们的存在和应用正在深刻地影响和改变着人们的生活方式。目前，互联网上广泛使用的SSL/TLS技术在保护边缘节点与后端服务器之间的通信方面已经展现出了良好的性能，但是我们更应该关注的是边缘节点自身的安全性问题。由于边缘节点通常资源有限，并且缺乏完善的网络安全机制，因此在数据加密方面，边缘节点的安全性显得尤为重要，甚至比服务器端更为关键。如果安全问题，如篡改节点数据或身份冒充等，得不到妥善处理，将会对用户产生直接的负面影响，例如可能会导致导航系统出现错误，或者引发车辆安全方面的问题。

边缘设备工具集和主动复制结构功能

过去的嵌入式系统编程领域要求开发者精通C语言和汇编语言，同时对底层技术有深入理解，包括寄存器操作和中断处理机制，以及掌握一些特殊的调试技术，这些技术通常需要耐心和细致的工作。

随着时现在的开发工作趋向简化，产品的上市时间大大缩短。尽管评估一个工具可能需要一些时间，但通常几天内就可以完成工具使用决策的过程，这使得开发流程更加高效和迅速。在现代开发环境中，开发者不再需要像过去那样拥有深厚的计算机基础知识、高超的编程技巧、以及无尽的耐心和毅力。相反，他们现在更需要的是简单易懂的工具集，这些工具能够帮助他们更快速、更高效地完成开发任务。

在提供替代方案方面，SQL、各种脚本语言、商业智能工具、图形用户界面访问工具以及在线文档等资源变得至关重要。这些资源为开发者提供了更多的选择和便利，使得他们能够更加灵活地应对各种开发挑战。

基于这些原因，我们提供：

边缘端组件模块化程度更高，支持从传感器的小型无操作系统单线程收集容器到工厂车间更智能的网关控制器等一系列硬件功能； -
边缘端和服务器端数据库 API 完全集成，以及 SQL 级别的连接性；
通过基于轻量级 REST 协议的 Web 服务实现 Web 连接；
符合 FIPS 140-2 标准的数据库加密以及通过 SSL 进行的安全通信；

在服务器端：

传递给 SQL 引擎的过程式语言；
更进一步的索引优化；
分布式 SQL；
垂直存储（时间序列）；
复杂的跟踪功能；
在线备份等。