本篇作為MD-SAL核心內容的第二篇，我們將從OpenDaylight的數據存型、DataStore是什么，如何實現等幾個方面進行介紹。

圖片來自網絡

一、OpenDaylight需要的數據存儲

1.1數據庫簡單介紹

我們熟知的軟件系統有學校的“圖書館管理系統”，企業里面的“客戶關系管理系統”，這些系統本質上只需要易操作就可以了，不需要高并發，這種系統的典型架構如下圖所示：

我們注意到這些系統都包含一個數據庫。而提到數據庫，我們可能先想到的是MySql、oracle之類的關系型數據庫，有人可能還會想到MangoDB、redis的非關系型數據庫，使用Java語言編程的人員可能會想到ehcache、memcache等緩存數據庫。如下圖所示：

我們來看下什么是內存數據庫？在Wiki上，我們可以看到：“內存數據庫（in-memory database，IMDB），也稱為主內存數據庫系統或內存駐留數據庫，是一種數據庫管理系統，主要依賴主存儲器進行計算機數據存儲。它與采用磁盤存儲機制的數據庫管理系統形成對比。內存數據庫比磁盤優化數據庫更快，因為磁盤訪問比內存訪問慢，內部優化算法更簡單，執行的CPU指令更少”。事實上，在具有實時計費能力的電信運營商，采用的基本上都是內存數據庫。它的好處是訪問速度快，一般來說，內存數據庫要比磁盤數據庫快10000倍。不好之處在于

數據是直接存在系統主內存中，如果內存數據庫重啟或崩潰后，可能會導致數據全部丟失。所以內存數據庫很重要的一點就是如何保證數據的安全可靠，并能在出現問題時能夠快速恢復數據。

1.2 OpenDaylight能力需求

SDN起源于校園網，發揚光大于數據中心，現廣泛用于廣域網，SDN控制器，可能管理著數十萬臺軟交換機，下發數百萬乃至上千萬條路由信息。因此，作為SDN控制器的開源項目OpenDaylight，無論是業務邏輯還是數據存儲，都需要具備如下能力：

l高并發：支持大規模的網絡設備控制、網絡路由計算和生成、海量的業務消息處理；

l高可靠：在控制器軟硬件發生故障時，依然能夠對外提供服務；

l實時性：SDN網絡能夠做到秒級或毫秒級的收斂；

1.3 OpenDaylight存儲選型

從上面的分析可知，OpenDaylight選用內存數據庫極為合適。下面我們來看下OpenDaylight的存儲選型：

Lithium 版本之前 ，OpenDaylight采用基于AD-SAL的架構設計，數據存儲采用的是Infinispan。它是基于內存的分布式鍵值存儲系統。那么，如何理解鍵值存儲呢？可以簡單地將理解為“鍵與值的映射”，在內存中的具體形式體現HashMap和有序樹。Infinispan可以作為一個Java Lib進行使用，也可以通過一系列主流的遠程協議方式（如REST、WebSockets）來提供獨立的服務。

Ininispan包可通過Maven的方式獲取，Infinispan jar包含所需的OSGi manifest headers，可以作為OSGi包OSGi運行時環境中使用。除此之外，還需要安裝所需的第三方依賴項。詳細安裝方法可參照：

http://infinispan.org/docs/9.3.x/getting_started/getting_started.html

Lithium版本之后， OpenDaylight轉向基于MD-SAL的架構設計，存儲實現也相應的轉為DataStore。

二、如何理解DataStore？

2.1DataStore是什么

在OpenDaylight控制器中，使用YANG作為建模語言，用于對數據存儲的內容和行為進行建模，YANG可以轉換成XML的格式。作為MD-SAL核心的Datastore實現了W3C DOM Document樹，并使用XML進行數據的表示。需要說明的一點：DataStore并不是完全基于XML的，OpenDaylight子項目YANGTools提供了優化YANG XML并使其適應XML DOM的模塊。

DataStore由DataTree組成，Yang定義了該樹的地址空間，由根節點、葉子節點和內部節點組成，如下圖所示：

圖片來自網絡

而DataTree分為兩個邏輯數據存儲：operational和config。這兩部分都有統一的視圖，并且可以使用實例標識符InstanceIdentifier來定位特定節點。如下圖所示：

圖片來自網絡

2.2DataStore如何實現？

2.2.1如何進行并發控制？

數據庫中經常發生并發的場景：應用邏輯A在讀取數據的同時，應用邏輯B可能正在寫入數據，應用邏輯A就可能讀到不一致的數據，也就是臟讀。為了解決上述出現的問題，實現并發控制，大家想到最簡單的方法便是加鎖，讓所有讀數據的應用程序等待寫數據的應用程序工作完成，這相當于串行工作，效率非常低。現在大多數據庫實現的是MVCC(Multi-Version Concurrency Control，多版本并發控制機制)，基本思想是通過對同一份數據保持多版本來并發問題，在不加鎖的情況下，實現讀與寫事務完成隔離。具體機制是：

l當應用邏輯需要讀取或更新數據時，數據庫會創建該數據的快照，數據庫中存在同一份數據的多個版本。

l每個應用邏輯擁有一份獨立快照，數據更新在沒有完全提交之前，其他應用邏輯不可見。

l數據庫會定期清理舊版本數據，以最新版本數據替換主數據。

l數據庫讀通過timestamp 或 transaction id 來標識數據最新的版本。

但如果是多個寫事務并發，則有可能發生沖突，可通過樂觀鎖來解決。

同時，我們從第一部分分析OpenDaylight能力需求中可以看出，OpenDaylight內存數據庫DataStore需要具備高并發、高性能的能力，DataStore同樣實現了MVCC。如果對MVCC感興趣，可以閱讀《數據庫村的旺財和小強》。

2.2.2 如何實現高可靠？

DataStore作為內存數據庫，在遇到突然斷電或系統宕機的情況，將會是毀滅性的。因此，需要定時將數據保存到硬盤里面，也就是要做持久化的操作。

DataStore持久化的實現機制是在控制器啟動時對其創建快照，并在后續操作過程記錄日志。我們查看控制器的部署目錄，snapshots目錄用來保存快照，而journal目錄用來操作日志信息，如下圖所示：

現在我們將snapshots和journal目錄中的文件刪除掉，然后重啟OpenDaylight控制器，觀察目錄中又重新生成對應的文件：

當發生斷電或宕機等情況后，將取這兩個目錄的文件，恢復內存數據庫。

事實上，上述實現是EV(Event Sourcing，事件溯源)思想的實現，下面我們大致介紹下EV：生活中最常見的例子就是電信運營商業務中的繳費、扣費、調賬、轉賬以及退款等業務流程，BOSS系統中會記錄每一筆交易發生的詳細信息，從而能夠得到某個時間點用戶的“錢”是多少。因此，EV也就是將數據的增刪改查每一操作都按照順序記錄，順次保存在日志文件中，如果想回到某個時間點的狀態，則可以順次回放就可以了。

具體到DataStore內存數據庫，將多個操作封裝到一個事務中，并生成本次事務的操作樹，持久化時按照操作日志的順序記錄下來就可以了。

2.2.3 如何實現高性能？

面對海量數據，數據庫系統采用分庫、分表、分區、分片等手段來實現高性能，DataStore使用了分片(Sharding)技術。

YANG建模的DataStore是一個樹型結構。一個分片就是一個子樹。子樹之間如果存在包含關系，則被包含的子樹作為一個獨立的分片，事實上是從根節點按照最長路徑匹配其父路徑所指定的分片。整個大樹是Default分片，Shard1作為一個新分片后，Default分片將不包含Shard1部分的數據，其分片類同。當啟用集群后，一個分片可以位于多臺機器上。如下圖所示：