ONOS提供了管理分布式状态的一组核心原语。其目标是简化分布式状态的管理和协同，简化app开发者的工作。这些原语满足不同的使用情况场景，提供高可用性，耐用性和2种一致性模式的选择(强一致性和最终一致性)。所有这些原语设计时考虑了正确性，可用性和性能等关键因素。应用程序可以创建这些原语的不同实例，管理它们的状态。 ### 最终一致性映射(EventuallyConsistentMap) 所有最终一致性映射提供弱一致性保证，以提供良好的读写性能。所有的读操作在本地状态上执行，所有的写操作首先更新到本地状态，并后续传播到集群中的其它副本。用户可以使用`ClockService` 配置该映射，为所有更新事件打上时间戳。这些时间戳用来确保每个副本均能按照正确的顺序更新。通过轻量级的`anti-entropy`，映射修复不同步的副本。所有副本的系统状态最终收敛于正确的状态值。 最终一致性映射拷贝它的所有状态。也就是说，集群中的每个节点均有该map内容的完全拷贝。状态存储在每个节点的内存中，那么集群的重新启动将导致数据丢失。 ### 一致性映射(ConsistentMap) 要求强一致性的应用程序可以使用`ConsistentMap`原语。`ConsistentMap `支持类似`java.util.concurrent.ConcurrentMap` 风格的操作，确保针对所有key的所有操作序列化。底层协议是Raft。而且，整个key空间被分割以保证扩展性，也就是，`ConsistentMap `中的每个key映射到单个的shard中。每个shard的一致性通过单独的Raft协商集群来维护。那么针对映射到不同shard 的key的操作可以独立地处理。在N个节点的集群中，ONOS默认创建N个shard。每个shard被放置到是哪个不同的节点，确保在其中一个节点失效后仍能工作。 ### LeadershipService ONOS提供了一个服务以方便地实现任意话题(topic)的领导者选举。该服务确保在任何时候，只有单个控制器是该主题的领导者。`LeadershipService`可以简化多话题的领导者选举，每个控制节点可以同时成为多个话题的领导者。 ### DistributedSet 这里所有的名称都是一个数据结构，提供分布式上下文中的集合语义。 ### DistributedQueue 提供一个分布式的FIFO队列抽象，支持基于长轮训的非阻塞方式的出队列操作。 ### AtomicCounter 该类类似于AtomicLong，但是用于分布式环境下，提供全局唯一的计数值。 ### AtomicValue AtomicReference的分布式版本 ### LogicalClockService 该服务用于为各种事件分配全局的按序时间戳。这在分布式上下文中的有序事件很有用。 ### ClusterCommunicationService 该服务用于一个控制器实例通过RPCs与其它实例通信。一个控制可以注册句柄，处理接收到的特定类型的消息。服务支持各种集群通信原语，例如单播、多播和广播。 ### ClusterService 该服务可以用于发现集群中的其它节点及其状态(存活或死亡)。