SDN学习之Opendaylight浅析(三)

    上讲讲到datatore，为了保证合理的篇幅先结束了，这讲接着上讲，datastore里面的数据可以利用listener来监听数据变化，在数据变化的时候触发event处理。

    早期是使用DataChangeListener来监听数据变化，使用AsyncDataChangeEvent来获取变更的信息，目前已弃用。

                         

                           

     目前较新的是使用DataTreeChangeListener，如果使用DataTreeChangeListener来监听，则使用DataTreeModification来获取变更信息。

                            

      首先可以利用databroker注册listener，第二个接口中的DataTreeIdentifier<DataObject> treeId是由第一个接口中的store和path来构造的。如下所示。第一种接口有指定scope，而第二种接口没有，表示对treeId下的子树中的所有节点变更都监听。

                            

   在注册数据变动监听之后就可以处理数据变更之后的逻辑，具体处理是将datatreechangelistener实现

                               

    例如，有一个对Vlan配置的监听器，我简单结合代码说明一下，首先注册步骤实在实例创建的时候进行，利用注入的databroker调用注册方法：

public class VlanConfigListener implements DataTreeChangeListener<ConfigVlan> {

	private static final Logger LOG = LoggerFactory.getLogger(VlanConfigListener.class);

	private final DataBroker dataBroker;

	private final VlanConfigUtils vlanConfig;

	public VlanConfigListener(DataBroker dataBroker, VlanConfigUtils vlanConfig) {
		super();
		this.dataBroker = dataBroker;
		this.vlanConfig = vlanConfig;
		// Register ECMP-MODE dataTreeChangeListenerRegistration
		ListenerRegistration<VlanConfigListener> dataTreeChangeListenerRegistration = dataBroker
				.registerDataTreeChangeListener(new DataTreeIdentifier<>(LogicalDatastoreType.CONFIGURATION,
						InstanceIdentifier.builder(ConfigVlans.class).child(ConfigVlan.class).build()), this);
	}

       然后进行相关逻辑的处理，在datachange的时候做相关的处理，例如这个listener根据配置数据中的configvlan树中的数据变化，配置相应的设备创建vlan：

@Override
	public void onDataTreeChanged(@NonNull Collection<DataTreeModification<ConfigVlan>> changes) {
		// TODO Auto-generated method stub
		for (DataTreeModification<ConfigVlan> change : changes) {
			DataObjectModification<ConfigVlan> rootNode = change.getRootNode();
			if (rootNode.getModificationType() == DataObjectModification.ModificationType.WRITE) {
				ConfigVlan oldConfig = rootNode.getDataBefore();
				ConfigVlan newConfig = rootNode.getDataAfter();

				LOG.info("oldConfig {}", oldConfig);
				LOG.info("newConfig {}", newConfig);
				String hostId = newConfig.getHostId();
				List<Device> devices = newConfig.getDevice();
				List<String> vlanIds = this.getVlansByHostId(hostId);
				// TODO异常处理
				vlanConfig.creatVlanAndConfigInterface(devices, vlanIds);

			} else if (rootNode.getModificationType() == DataObjectModification.ModificationType.DELETE) {
				ConfigVlan oldConfig = rootNode.getDataBefore();
				ConfigVlan newConfig = rootNode.getDataAfter();
				LOG.info("oldConfig {}", oldConfig);
				LOG.info("newConfig {}", newConfig);

			} else if (rootNode.getModificationType() == DataObjectModification.ModificationType.SUBTREE_MODIFIED) {

			}
		}
	}

       另外还有一点是事务链的处理上，多个事务一起提交没法保证执行顺序，于是可以提交给事务链，保证事务按照预设的顺序执行，这点其实很好理解。

                                               

   利用transactionChain.createTransaction可以创建事务链

                                      

   

      简单事务：可以用dataBroker创建多个事务。而对于transactionChain而言，创建一个事务时候，必须submit之后才能创建其他的事务，否则是不允许创建第二个事务的。Submit不一定执行完毕了，调用了submit即可。

     通常事务链submit后无需调用get来等待执行的结果。如果调用了get来等待执行结果，那么事务链就没什么意义了，因为每个事务都调用get来等待结果，就成了同步的执行。而事务链的机制是异步地且按照所提交的事务顺序地执行。

    具体代码例如：

                                     

                                     

                                     

      Queue.take会阻塞直到队列有数据才返回。而queue.poll则不会阻塞，有数据则返回数据，无数据则返回NULL。

                                    

                                               

     事务链也存在乐观锁异常。因为事务链它本身可以保证按顺序地执行，但是当它和其他简单事务冲突时，则会导致乐观锁异常。

                                                               

                                                              

                                                              

          事务链中的某个事务，可以先执行多个操作(put、merge、…)之后，再统一submit，这样做的目的是为了提高效率。