搞懂DDS数据分发服务

1.什么是DDS?

数据分发服务（DDS™）是一个由对象管理组（OMG）发布的以数据为中心的中间件协议和API标准。采用分布式发布/订阅体系架构，以中间件的形式提供通信服务，强调以数据为中心。DDS中间件是一个软件层，从操作系统、网络传输和底层数据格式的细节中抽象出应用。相同的概念和api提供给不同的编成语言，使得应用在不同的操作系统、编成语言和处理体系架构之间交换信息。底层细节包括数据传输格式、发现、连接、可靠性和、协议、Qos策略等由中间件来管理。

扩展：中间件

在分布式系统中，中间件是介于操作系统和应用程序之间的软件层，使系统的各个组件能够更容易地通信和共享数据。中间件简化了分布式系统的开发，使软件开发人员专注于应用程序的业务本身，而不是花费精力研究应用程序和系统之间传递信息的机制。

2.为啥要用DDS？

计算机网络发展这么多年，物理层、数据链路层、传输层等7层各自都已经有很多相对成熟的协议，那么DDS究竟是为了解决什么问题而产生的呢？

先说结论：DDS是物联网的最佳选择之一

也就是说随着物联网的发展，传统的通信协议在物联网和大数据等新场景下会有暴漏出很多的弊端，所以需要设计一些新的方法去适用新的应用场景需求。笔者个人总结为以下几个方面（个人理解，有局限性欢迎交流）：

1.物理网场景下：需要低延迟数据连接、高可靠性以及高可扩展的体系结构，以适应商业级物联网（IoT）应用程序的需求。

2.物联设备的增多必然会导致数据的增多，所以需要一个方法能够让开发人员关注数据本身，而不用处理繁杂的消息收发过程代码。市面上虽然存在多种通信中间件标准和产品，唯独DDS是以数据为中心，是工业物联网的理想选择。

3.物联设备的加入会增加兼容性、同步性等问题从而提升整个系统架构的复杂度，所以分层设计就会更加重要，中间件的需求就会更强烈。

3.什么项目适合用DDS

如果项目存在以下问题，DDS可能是适合该项目的最佳连接框架技术之一:

1.存在通信延迟问题，比如需要以毫秒为单位或更短的时间来衡量延迟。

2.存在网络带宽/吞吐量或扩展问题，比如有超过10个不同的软件，或者需要共享超过一千种数据项。

3.系统离线5分钟（甚至5毫秒）将导致严重的问题。

4.在配置、启动或故障转移到备份服务器方面存在困难。

5.构建的系统将花费一年甚至更多的时间编写，并且涉及多个版本或需要与旧版应用程序进行集成。

4.DDS技术细节

4.1 分布式发布/订阅体系架构

1.全局数据空间是一个抽象的概念。

在实现时，数据仍然是分别存储在每一个应用程序的本地空间中。在系统运行时，数据是按需传输或存储的，数据的发布者仅仅发送对方需要的数据，订阅者仅接受本地应用程序中需要的数据。

2.实际场景中，每个应用程序既可以是发布者又可以是订阅者

4.2以数据为中心

DDS提供Qos控制功能。应用程序通过发布和订阅主题进行通信。订阅可以指定时间和内容筛选器，并且只能获取发布主题的数据的子集。不同的DDS域彼此完全独立，跨DDS域无法进行数据通信。

以数据为中心的本质是DDS知道它存储什么数据，并控制如何共享这些数据。使用传统的以消息为中心的中间件的程序员必须编写发送消息的代码；而使用以数据为中心的中间件的时，只需指定数据如何共享、何时共享，编写少量代码即可直接共享数据值。DDS使用户无需在应用程序的代码中管理所有这些复杂的操作，而是直接为用户实现了受控、托管、安全的数据共享。

4.3 全局数据空间

DDS在概念上创建了一个 “全局数据空间”的本地的数据存储空间。对应用程序来说，全局数据空间看起来像是通过API访问的本地内存：发送端应用程序写入数据时，就像是写到了本地的存储空间；而实际上，由DDS发送消息以更新远程节点上的存储内容；接收端应用程序方可通过读取本地存储获取到数据。

 在DDS域中，信息共享的单位是主题的数据对象。主题由其名称标识，数据对象由一些“键（Key）”属性标识。这类似于在数据库中用键属性来标识数据。上述是一张概念性的图示， DDS进行点对点通信，不需要服务器或云代理进行转发。

4.4 QoS(Quality of Service)服务质量策略

在一个真实系统中，并不是所有其他端点都需要另一个节点本地存储中的所有内容 ，DDS在提供最基础的发布订阅功能之外，还可以根据不同使用场景向用户提供满足对应需求的服务。QoS有可靠性、持久性、紧迫性等，可单独或组合使用

1.可靠性（RELIABILITY）

“尽力而为”模式（BEST_EFFORT_RELIABILITY_QOS）：对样本的可靠性没有任何保证，在某些情况下可能会丢弃样本。（通俗解释：在外界环境不稳定的时候，可能会导致丢包，但是DDS为了保证整体数据分发效率，不会重新分发丢包的数据）

“可靠”模式（RELIABLE_RELIABILITY_QOS）：该服务最终应将所有值传递给合格的数据读取器。（通俗解释：万一出现丢包现象，会重新分发数据，保证订阅者能够收到）

数据读取器和主题的此策略的默认值为“尽力而为”，而数据写入器的默认值为“可靠”。在创建数据写入者和数据读取者之间的关联时会考虑此策略。 关联双方的值必须兼容才能创建关联。 数据写入器的可靠性类型必须大于或等于数据读取器的值。

2.基于时间过滤（TIME_BASED_FILTER）

过滤出指定时间的数据。例如：某应用会在循环一定时间周期时发布数据，订阅者只需要关注某一时间发布的数据。

3.接收端顺序（DESTINATION_ORDER）

在网络抖动等情况下，确保订阅者能够按顺序接受报文

例如：发送者发送：1 2 3 4 5

特殊情况导致乱序：3 2 1 4 5

需要确保订阅者收到：1 2 3 4 5

4.持久性（DURABILITY）

订阅者的应用程序离线时，先缓存历史数据。当订阅者应用程序上线时，可以接收到缓存中的历史数据