基于分布式網(wǎng)絡(luò)設(shè)備的分布式數(shù)據(jù)庫設(shè)計*

萬維威，谷 鵬

（中國電子科技網(wǎng)絡(luò)信息安全有限公司，四川 成都 610041）

0 引言

隨著互聯(lián)網(wǎng)的應(yīng)用和需求不斷擴大，組成互聯(lián)網(wǎng)的網(wǎng)絡(luò)設(shè)備，正在朝著速度更快、服務(wù)質(zhì)量更好、運行更可靠和高并發(fā)性能的方向發(fā)展。例如，核心網(wǎng)的路由器從傳統(tǒng)的集中式架構(gòu)向分布式架構(gòu)轉(zhuǎn)變。對于分布式架構(gòu)的網(wǎng)絡(luò)設(shè)備，在追求高性能、高轉(zhuǎn)發(fā)效率、高可靠性的同時，其內(nèi)部模塊的復(fù)雜度、耦合性、可靠性、可復(fù)用性等隱性指標(biāo)都比傳統(tǒng)的集中式設(shè)備復(fù)雜，由此帶來的隱患風(fēng)險也遠高于集中式設(shè)備，而這些隱患主要集中在不同模塊對控制平面的數(shù)據(jù)在各分布式部件間的分發(fā)、存儲、管理、異常等行為上的不一致，對于分布式網(wǎng)絡(luò)設(shè)備的更新迭代和維護極為不利。

為解決此問題，可以通過分布式數(shù)據(jù)庫來管理各部件的數(shù)據(jù)，在市場上，分布式數(shù)據(jù)庫經(jīng)過多年發(fā)展[1]，已經(jīng)有成熟的項目可供選擇，如傳統(tǒng)關(guān)系型數(shù)據(jù)庫（Traditional Relational Database，TRDB）的Oracle[2]、Access、Foxpro[3]、DBll、Mysql等，不僅僅是結(jié)構(gòu)化查詢語言（Not only Structured Query Language，NoSQL）的Redis[4]、KeyDB、MonetDB[5]、BigTbale 等，NewSQL的PostgreSQL[6]、SequoiaDB、SAPHANA、MariaDB、VoltDB、Clustrix等。但這些數(shù)據(jù)庫在數(shù)據(jù)分發(fā)上都不是主要關(guān)注點，更傾向于數(shù)據(jù)存儲部分，并且都不能同時兼顧如錯誤恢復(fù)功能、可靠性、時序性、效率性等，所以本文從上述痛點出發(fā)，提出對分布式數(shù)據(jù)庫的需求，具體如下文所述。

（1）可以引導(dǎo)各個應(yīng)用模塊將自身的信息分解成具體的表結(jié)構(gòu)，有利于模塊對自己的信息進行規(guī)范化處理，從而減少各應(yīng)用模塊對數(shù)據(jù)管理不統(tǒng)一、不規(guī)范的情況。

（2）結(jié)合集中式應(yīng)用模塊低復(fù)雜度和分布式系統(tǒng)高效的優(yōu)點，對各模塊容易產(chǎn)生差異的數(shù)據(jù)分發(fā)、存儲、管理等行為進行統(tǒng)一接管，虛擬出一個數(shù)據(jù)庫，向應(yīng)用模塊屏蔽分布式特性，使得應(yīng)用模塊在操作控制平面數(shù)據(jù)時和在集中式設(shè)備上一樣，讓其專心于業(yè)務(wù)的管理，提高分布式網(wǎng)絡(luò)設(shè)備的可靠性和可維護性。

（3）提供靈活的存儲擴展，可以根據(jù)各應(yīng)用模塊自身的需求來決定使用何種存儲，或者不使用存儲管理，直接使用分布式部件間數(shù)據(jù)分發(fā)功能。

（4）借鑒一些數(shù)據(jù)庫公共機制（比如事務(wù)、光標(biāo)、視圖等），以標(biāo)準(zhǔn)的數(shù)據(jù)庫行為來規(guī)范數(shù)據(jù)的管理，減少應(yīng)用模塊私自接管數(shù)據(jù)管理在設(shè)計上出現(xiàn)欠考慮的問題。

（5）依托于分布式數(shù)據(jù)庫的公共接口，可以建立一套靈活的版本移植性解決方案。

基于以上需求，本文設(shè)計了一款分布式數(shù)據(jù)庫（Embedded Distributed database，EDdb）。本文首先從整體架構(gòu)、軟件層次、接口、實時分發(fā)和批量分發(fā)、存儲擴展性、異常處理這幾個方面進行論述，其次分析EDdb的不足，最后探討應(yīng)用于分布式網(wǎng)絡(luò)設(shè)備上的分布式數(shù)據(jù)庫的進一步發(fā)展方向。

1 EDdb 整體架構(gòu)

1.1 相關(guān)概念

分布式部件是指以插卡的方式為分布式設(shè)備提供特定功能的板卡，一般來說，分布式網(wǎng)絡(luò)設(shè)備默認(rèn)需要主控卡（Master Main Processing Unit，Master MPU）、備用主控卡（Slave Main Processing Unit，Slave MPU）和業(yè)務(wù)卡（Line Processing Unit，LPU）。

（1）Master MPU 管理分布式路由器的基礎(chǔ)事務(wù)，為系統(tǒng)正常工作提供基礎(chǔ)保障。

（2）Slave MPU 為Master MPU的備份，在主控卡發(fā)生故障時，在不間斷系統(tǒng)功能的情況下接替主控卡的所有工作。

（3）LPU 為路由器提供網(wǎng)絡(luò)數(shù)據(jù)包的接收、轉(zhuǎn)發(fā)等功能。

對于EDdb 而言，以上板卡只會劃分為兩類部件，即源部件和目的部件，源部件只有一個，而目的部件可以有多個。在分布式網(wǎng)絡(luò)設(shè)備中，源部件即是Master MPU，而除此以外的所有板卡都是目的部件。需要注意的是，EDdb 在數(shù)據(jù)分布上是單向的，即只能源向目的分發(fā)，而不能目的向源分發(fā)，這保證了分布式網(wǎng)絡(luò)設(shè)備的Master MPU 具有全部的控制權(quán)。

1.2 EDdb 軟件層次

EDdb 作為系統(tǒng)的公共基礎(chǔ)模塊，為系統(tǒng)里的應(yīng)用模塊提供數(shù)據(jù)存儲和分發(fā)的功能，它不與具體的操作系統(tǒng)平臺和網(wǎng)絡(luò)產(chǎn)品緊密相關(guān)，因此EDdb為系統(tǒng)軟件的一部分，具體如圖1 所示。

圖1 EDdb 層次

EDdb 與分布式部件之間的通信需要有一個抽象層。對于不同的產(chǎn)品，如果各個分布式部件之間的通信機制有變化，則需要該抽象層進行屏蔽。此外，EDdb 也需要從分布式部件的熱拔插和熱切換的事件中獲得通知，包括分布式部件進入系統(tǒng)和退出系統(tǒng)的事件通知。

1.3 EDdb 功能架構(gòu)

EDdb 存在于整個設(shè)備的各個分布式部件中，但這些EDdb的角色并不是平等的，分為源EDdb和目的EDdb，主控卡（Master MPU）上的EDdb 是源EDdb（所屬板卡也稱為源部件），除此以外的其他所有部件上的EDdb 都是目的EDdb（所屬板卡也稱為目的部件）。圖2 展示了EDdb 在系統(tǒng)設(shè)備上的功能和架構(gòu)。在分布式網(wǎng)絡(luò)設(shè)備上，各個板卡部件都是獨立存在的，要想將各個板卡組合在一起實現(xiàn)完整的功能，它們之間的數(shù)據(jù)通信就顯得尤為重要。為了規(guī)范板卡間的數(shù)據(jù)通信，并且為各板卡上的應(yīng)用模塊屏蔽分布式特性，即不關(guān)心數(shù)據(jù)的同步及分發(fā)，需要在各板卡之間虛擬出EDdb的模塊，對各板卡間所要同步或分發(fā)的數(shù)據(jù)進行集中管理，同時使用數(shù)據(jù)庫的公共機制（如事務(wù)、光標(biāo)、視圖等），以標(biāo)準(zhǔn)的數(shù)據(jù)庫行為來為各板卡上的應(yīng)用模塊提供數(shù)據(jù)庫操作接口。

圖2 中，通道A、B、C 分別為應(yīng)用模塊和分布式數(shù)據(jù)庫的交互接口，為應(yīng)用模塊提供添、刪、改、查等數(shù)據(jù)庫操作接口，通過這些接口，應(yīng)用模塊可以快速地在各個板卡間使用自己需要的數(shù)據(jù)。通道D 是EDdb 實時分發(fā)、批量的通道，管理各應(yīng)用模塊存儲在數(shù)據(jù)庫的數(shù)據(jù)的實時分發(fā)和批量，除此以外，EDdb 自身的異常處理、源和目的數(shù)據(jù)庫切換、目的部件離開或加入的管理都通過通道D 來實現(xiàn)。因此，從整體架構(gòu)上來看，EDdb 為分布式系統(tǒng)內(nèi)部各部件間的數(shù)據(jù)傳輸提供了統(tǒng)一的管理，使得分布在各板卡上的應(yīng)用模塊可以隨時隨地管理自己的數(shù)據(jù)，而不用關(guān)心數(shù)據(jù)是怎么分發(fā)的。

圖2 EDdb 架構(gòu)

1.4 EDdb 組織結(jié)構(gòu)

EDdb的數(shù)據(jù)組織方式還是參考傳統(tǒng)的數(shù)據(jù)庫標(biāo)準(zhǔn)，以連接（connection）取代database，即為每個應(yīng)用模塊的一個數(shù)據(jù)需求分配一個連接，在該連接下可以創(chuàng)建多張表，對每張表的操作可以采用句柄的方式來進行，這里的句柄是指將要操作的列描述轉(zhuǎn)換成句柄，再對表進行添、刪、改、查時傳入數(shù)據(jù)庫即可進行表操作。

對于應(yīng)用模塊而言，所有的表都在源部件上，而其他目的部件上的表需要由應(yīng)用模塊來決定是否同步，而同步的表，應(yīng)用模塊能獲取到和源部件一樣的數(shù)據(jù)。

2 EDdb 分發(fā)數(shù)據(jù)行為設(shè)計

2.1 發(fā)送表操作行為狀態(tài)機

對于表項分發(fā)的過程，是將數(shù)據(jù)、表、列句柄等數(shù)據(jù)信息和操作（即添、刪、改）發(fā)往目的部件，在協(xié)商過程中會有狀態(tài)，其狀態(tài)含義如下文所述。

（1）初始化：操作緩存進入分布式數(shù)據(jù)庫，還未進行分發(fā)。

（2）分發(fā)未執(zhí)行：操作緩存已經(jīng)被發(fā)送，但是在發(fā)送端還未接收到各個分布式部件確認(rèn)。

（3）分發(fā)執(zhí)行未確認(rèn)：發(fā)送端已經(jīng)發(fā)出操作緩存執(zhí)行的信息，但是還未接收到各個分布式部件執(zhí)行的結(jié)果。

（4）錯誤未確認(rèn)：發(fā)送端接收到各個分布式部件執(zhí)行的結(jié)果，其中有錯誤報告，發(fā)送端將匯總的錯誤又通知各個分布式部件，還未接收到分布式部件的錯誤確認(rèn)。

（5）應(yīng)用未確認(rèn)：應(yīng)用模塊對分發(fā)操作完結(jié)或突發(fā)事件所做的回應(yīng)。

（6）終結(jié)：操作已經(jīng)分發(fā)并被各個模塊確認(rèn)。操作緩存銷毀。

狀態(tài)轉(zhuǎn)換和對應(yīng)事件如表1 所示。

表1 發(fā)送表狀態(tài)轉(zhuǎn)換和對應(yīng)事件

2.2 接收表操作行為狀態(tài)機

在接收方接收表項和操作，各個狀態(tài)含義如下文所述。

（1）接收未執(zhí)行：接收到操作緩存，還未接收操作執(zhí)行報文。

（2）執(zhí)行返回未確認(rèn)：接收到操作執(zhí)行，并且執(zhí)行完畢返回結(jié)果，還未接收到發(fā)送端返回的所有分布式部件結(jié)果。

（3）錯誤未確認(rèn)：接收到發(fā)送端的所有分布式部件結(jié)果，結(jié)果中有錯誤報告，已經(jīng)發(fā)出對這個錯誤的確認(rèn)，還未獲得終結(jié)報文。如果結(jié)果中沒有錯誤報告，操作緩存的這個狀態(tài)會跳過直接到終結(jié)狀態(tài)。

（4）終結(jié)：接收到發(fā)送端發(fā)出的操作緩存終結(jié)報文。

圖3 發(fā)送表操作行為狀態(tài)機

圖4 接收表操作行為狀態(tài)機

狀態(tài)轉(zhuǎn)換和對應(yīng)事件如表2 所示。

表2 接收表狀態(tài)轉(zhuǎn)換和對應(yīng)事件

2.3 表數(shù)據(jù)分發(fā)行為

應(yīng)用模塊的數(shù)據(jù)是以表的形式存在的，應(yīng)用模塊對數(shù)據(jù)的操作也是對表的操作，EDdb 為應(yīng)用模塊提供了對表進行添、刪、改的操作接口，由于只有這3 個操作能對表數(shù)據(jù)產(chǎn)生變化，所以在表數(shù)據(jù)進行數(shù)據(jù)分發(fā)時，其分發(fā)的數(shù)據(jù)報文都是帶有這3種操作指令的。圖5 展示了應(yīng)用模塊發(fā)起的數(shù)據(jù)流在源部件和目的部件中的流程，其中涉及多個任務(wù)協(xié)同工作。根據(jù)數(shù)據(jù)分發(fā)的場景不同，可以分為實時分發(fā)和批量分發(fā)兩種方式。

圖5 數(shù)據(jù)分發(fā)

（1）實時分發(fā)：適用于已經(jīng)處于就緒狀態(tài)的目的部件，在這種情況下，應(yīng)用模塊對源部件上表項的添、刪、改操作會實時分發(fā)到目的部件上。

（2）批量分發(fā)：適用于剛進入系統(tǒng)的目的部件，在這種情況下，表的批量任務(wù)會將源部件上所有表項一次性以添加指令的方式分發(fā)到目的部件上。

2.3.1 實時分發(fā)流程

實時分發(fā)操作可以分為5 步，也可以分為兩個階段，第一階段是保證操作的一致性，該階段完成時，操作能夠保證在所有目的部件上都存在數(shù)據(jù)和操作指令，第二階段是實際的操作。多目的部件實時分發(fā)時序如圖6 所示。如果分發(fā)時發(fā)生了錯誤，則分發(fā)操作如圖7 所示。

圖6 多目的部件實時分發(fā)時序

圖7 多目的部件實時分發(fā)出錯時序

添、刪、改操作本身會在源、目的部件上緩存，這個緩存中包含了操作的上下文，同時每個連接的每個操作都會分配唯一的操作序列號，以便于對于結(jié)果的回溯。

在源部件中，該緩存有分發(fā)未確認(rèn)和分發(fā)執(zhí)行未確認(rèn)兩種狀態(tài)。分發(fā)未確認(rèn)對應(yīng)于源部件發(fā)送操作，但是還未接收完所有目的部件響應(yīng)的狀態(tài)。分發(fā)執(zhí)行未確認(rèn)對應(yīng)于源部件發(fā)送了分發(fā)執(zhí)行的消息，但是還沒有接收到所有目的部件執(zhí)行結(jié)果的狀態(tài)。

在目的部件中，該緩存有接收未執(zhí)行和執(zhí)行返回未確認(rèn)兩種狀態(tài)。每個操作會帶上操作序列號下發(fā)到各個分布式部件，目的部件接收后隨即緩存，并回應(yīng)該序列號；源部件接收回應(yīng)后，發(fā)送操作執(zhí)行報文；目的部件接收到操作執(zhí)行后立即執(zhí)行操作，并將結(jié)果返回。

EDdb 在源部件匯總結(jié)果，并且將結(jié)果返回給應(yīng)用模塊，源部件所在的應(yīng)用模塊在接收到返回的結(jié)果以后，按照結(jié)果來控制下一步行為，EDdb 提供應(yīng)用模塊結(jié)果確認(rèn)回調(diào)函數(shù)，應(yīng)用模塊調(diào)用該回調(diào)函數(shù)將操作結(jié)果返回給各個目的部件，即完成此次下發(fā)動作，操作在本地數(shù)據(jù)庫中的緩存清除。

2.3.2 批量分發(fā)流程

在目的部件剛進入系統(tǒng)時，會發(fā)送批量數(shù)據(jù)請求，在源部件收到該請求后，會把本地目的部件關(guān)心的表項批量分發(fā)給該目的部件，其數(shù)據(jù)分發(fā)指令是添加操作，數(shù)據(jù)為源部件上需要分發(fā)的所有表項，即一行表項對應(yīng)一個添加指令；其批量分發(fā)的具體流程和實時分發(fā)的流程一致，這里就不再贅述。

需要注意的是，在批量分發(fā)的過程中，應(yīng)用模塊可能會操作源部件上正在批量的表，此時，實時操作的表項需要與當(dāng)前正在批量的表項位置進行比較：如果所操作的表項在當(dāng)前批量表項的后面，則只做本地操作，不做分發(fā)動作，因為批量操作會在遍歷到當(dāng)前實時操作的表項；如果所操作的表項在當(dāng)前批量表項之前或重合時，本次的實時操作必須分發(fā)到目的部件上。

2.4 EDdb 存儲方案

由于嵌入式設(shè)備的資源不能和專業(yè)的服務(wù)器相比，因此在數(shù)據(jù)存儲功能方面的需求要比數(shù)據(jù)分發(fā)的需求弱很多。嵌入式網(wǎng)絡(luò)設(shè)備以數(shù)據(jù)處理效率為主要指標(biāo)，所以EDdb的存儲功能只提供良好的可擴展存儲插件注冊機制和默認(rèn)的基本hash 存儲功能。如果應(yīng)用模塊在沒有效率優(yōu)先的情況下，可以使用默認(rèn)的hash 存儲功能；如果應(yīng)用模塊對于數(shù)據(jù)的使用有效率要求，則可以自己實現(xiàn)存儲插件，甚至更極端的情況下，自己實現(xiàn)的插件可以不具備存儲功能，在插件中將收到的數(shù)據(jù)直接處理。所以，EDdb 更適合分布式架構(gòu)的網(wǎng)絡(luò)設(shè)備使用。

2.5 EDdb 接口關(guān)系

為了讓EDdb 提高可移植性和可擴展性，應(yīng)該盡可能少地讓EDdb 依賴于和系統(tǒng)相關(guān)的特有基礎(chǔ)模塊，而讓EDdb 依賴于屬于公共特性的基礎(chǔ)模塊。

圖8 展示了EDdb 所相關(guān)的外部接口關(guān)系，可以看出，和EDdb 相關(guān)的內(nèi)部模塊普遍存在于分布式網(wǎng)絡(luò)設(shè)備中，包括內(nèi)部部件通信機制、部件插拔通告機制、系統(tǒng)重啟機制、操作系統(tǒng)公共機制，都是分布式網(wǎng)絡(luò)設(shè)備所必需的基礎(chǔ)機制。此外，就算沒有和分布式架構(gòu)相關(guān)的機制，如內(nèi)部部件通信機制、部件插拔通告機制（如集中式網(wǎng)絡(luò)設(shè)備），EDdb 也可作為普通數(shù)據(jù)庫來使用，所以EDdb 可以做到適配于幾乎所有的網(wǎng)絡(luò)設(shè)備。

圖8 數(shù)據(jù)庫接口關(guān)系

3 EDdb 異常處理

3.1 異常處理框架

源EDdb 通過位圖的方式對目的部件的狀態(tài)進行管理，其中位圖有注冊位圖、發(fā)送位圖、隔離位圖3 個概念，具體如下文所述。

（1）注冊位圖：在數(shù)據(jù)分發(fā)模塊中，為了能夠使源部件知道將要把數(shù)據(jù)分發(fā)到哪些目的部件上，就需要目的部件在自己初始化完成后主動告知源部件進行注冊，等注冊完畢后，源部件將該目的部件在注冊位圖上置位。該位圖的作用是在與目的部件有交互的流程上提供目的部件的序號。

（2）發(fā)送位圖：告知數(shù)據(jù)分發(fā)模塊要將數(shù)據(jù)分發(fā)到哪些目的部件上的位圖。

（3）隔離位圖：告知所有和目的部件有交互的流程該部件是被隔離的。

EDdb的異常處理方法采用注冊的方式，當(dāng)前只有隔離和重啟兩種方式，但可以根據(jù)后續(xù)的需求進行擴展。異常處理的整體流程如圖9 所示。

圖9 異常處理的整體流程

3.2 異常隔離處理

隔離操作的目的是讓源EDdb 不再往該隔離部件上發(fā)送數(shù)據(jù)，并對該部件在發(fā)送位圖上做標(biāo)記，同時令該異常部件清空數(shù)據(jù)庫，后續(xù)如果源部件上的表項有變化，在進行實時分發(fā)時會根據(jù)隔離位圖來避免發(fā)送數(shù)據(jù)到隔離部件上。

解隔離操作的目的是讓異常目的部件解決不嚴(yán)重的問題并恢復(fù)工作。如在數(shù)據(jù)分發(fā)過程中出現(xiàn)錯誤，一般情況下，對其重新批量一次，其問題即可解決，所以解隔離就是清除該部件的隔離位圖，并對其重新批量分發(fā)一次。

3.3 異常重啟處理

對于目的部件上比較嚴(yán)重的問題，如內(nèi)存不足、CPU 繁忙、部件間通信故障等，一般可以通過重啟部件解決，所以源EDdb 會給分發(fā)操作設(shè)定超時時間、報告基礎(chǔ)故障等機制，一旦收到此類異常，便可對問題部件進行重啟操作。

4 EDdb 實現(xiàn)結(jié)果

在對EDdb 做測試時，采用的是某廠商分布式路由器測試環(huán)境，由于EDdb 如2.5 節(jié)所描述，可以適配幾乎所有的網(wǎng)絡(luò)設(shè)備，所以可以單獨在設(shè)備上運行，不和其他功能相互依賴，這為測試提供了良好的前提。

本次測試創(chuàng)建一條連接testApp 和這條連接下的一張表testMode|testSubMode|testTable，源部件序號為2，目的部件序號為4，在此基礎(chǔ)上進行測試。

4.1 創(chuàng)建數(shù)據(jù)庫

創(chuàng)建數(shù)據(jù)庫分兩個步驟，第一步是調(diào)用創(chuàng)建連接接口，創(chuàng)建屬于應(yīng)用模塊自己獨有的連接；第二步是創(chuàng)建表和相關(guān)的列句柄，可以在連接下創(chuàng)建多張表，列句柄的作用是在進行添、刪、改、查時作為索引或輸出時使用。

由于連接是所有表的歸屬，所以連接的一個重要功能是管理所有表項的分發(fā)，即2.3 節(jié)所述功能。連接的信息可以通過EDdb的可維護性子模塊向外界展現(xiàn)，具體如圖10 和圖11 所示。

圖10 源EDdb 連接信息

圖11 目的EDdb 連接信息

圖10、圖11 即是創(chuàng)建的連接信息，主要分為3個部分：第一部分為連接的基本信息，包括連接名字、連接ID、魔數(shù)等；第二部分為數(shù)據(jù)分發(fā)信息，包括發(fā)送隊列信息、發(fā)送緩存信息、應(yīng)用確認(rèn)回調(diào)函數(shù)等，在發(fā)送隊列信息上，noSendSeq、execNoAck、appNoAffirm 信息和2.3 節(jié)的分發(fā)時序相對應(yīng)，可以通過隊列信息了解當(dāng)前表項的分發(fā)情況；第三部分為連接的統(tǒng)計信息，基本上是所有錯誤的統(tǒng)計。

需要注意的是，源EDdb 和目的EDdb的連接信息展示有所不同，這和它們各自角色是相關(guān)的。在源EDdb 上，主要的功能是分發(fā)表項，而目的EDdb 沒有這個功能（1.1 節(jié)有說明），所以在目的EDdb 上關(guān)于分發(fā)的信息為0。

從圖10 可以看出，在源部件上，maxAppAffirm WaitCnt的統(tǒng)計為1，證明應(yīng)用模塊確認(rèn)過1 條表項分發(fā)的結(jié)果，所以這1 條表項是分發(fā)成功了，但具體分發(fā)到哪張表，需要進一步在表信息里去查看。表信息如圖12、圖13 所示。

圖12 源部件所屬表信息

圖13 目的部件所屬表信息

從圖12 來看，表信息也分為基礎(chǔ)信息、列句柄信息、所要分發(fā)的目的部件信息和統(tǒng)計信息，其中統(tǒng)計信息中，insertOp 顯示為1，說明在源部件上做過一次表項的插入，并且在ready dpart list 上顯示dpartId 為4的部件已經(jīng)就緒，所以結(jié)合源部件連接信息可知這條表項成功分發(fā)到ID 為4的目的部件上，并且通過bulkWakeUpCnt 為1 得知已經(jīng)批量分發(fā)成功。從圖13 中也可以看到，insertOp 為1，可以得出從源部件分發(fā)來的表項已經(jīng)插入成功，這樣就實現(xiàn)了EDdb的功能。

4.2 數(shù)據(jù)分發(fā)

打開EDdb的debug 信息，在源部件上插入一條表項，會得到相關(guān)的實時分發(fā)debug 信息，如圖14、圖15 所示。

圖14 源部件上分發(fā)debug 信息

圖15 目的部件上分發(fā)debug 信息

從圖14 和圖15 可以看出，其分發(fā)表項的流程和圖6的時序圖是一致的，分別進行了分發(fā)未執(zhí)行、執(zhí)行未確認(rèn)和應(yīng)用模塊確認(rèn)的步驟，確保數(shù)據(jù)的正確分發(fā)，其中任何一步的失敗都將導(dǎo)致表項分發(fā)失敗，而EDdb 也會通過異常處理流程來處理失敗結(jié)果，盡可能地保證數(shù)據(jù)正確下發(fā)。

4.3 EDdb 異常處理結(jié)果

通過自身制造目的部件異常，使源部件對ID為4的目的部件進行隔離，如圖16 所示。

圖16 是源部件表信息，從中可以看出，對于隔離次數(shù)的統(tǒng)計為1，并且在no ready dpart list 下看到ID 為4的目的部件已經(jīng)處于未就緒范圍內(nèi)，狀態(tài)為隔離狀態(tài)（即0x3），在quarantine dpart list下可見隔離部件位圖已經(jīng)置位（0x10的二進制是0001 0000，第四位置位代表序號4的隔離部件已記錄），再對源部件上的表執(zhí)行插入表項動作，沒有分發(fā)的debug 信息，證明源部件表項的插入已經(jīng)不會分發(fā)到隔離的目的部件上，在對其解隔離后，源部件上的所有表項會進行一次批量動作，這時目的部件上的表項又和源部件同步成功。重啟就是直接調(diào)用重啟接口，過程比較簡單，這里就不做贅述了。

圖16 隔離目的部件信息

5 結(jié)語

EDdb 可以很好地滿足分布式架構(gòu)下的網(wǎng)絡(luò)設(shè)備對于內(nèi)部部件間的數(shù)據(jù)分發(fā)、可靠性、可擴展性的需求，方便各應(yīng)用模塊在不同部件上使用源部件的數(shù)據(jù)。但在實際使用中仍有不足，未來需要關(guān)注和解決的方向主要有以下幾點：

（1）表之間的依賴關(guān)系需要考慮。在實際使用過程中，如果應(yīng)用模塊的某張表必須由另一張表來決定，則在批量分發(fā)過程中，先要把依賴的表批量完成后，才能批量這張表。實現(xiàn)依賴關(guān)系有利于應(yīng)用模塊的邏輯時序，這點后續(xù)需要考慮如何來實現(xiàn)。

（2）存儲機制需要加強。雖然EDdb 存儲機制不是重點，并且在可擴展性上預(yù)留了可能，但現(xiàn)階段的存儲只有hash 方式，在大量表項存儲方面可能遇到瓶頸，后續(xù)可以參考標(biāo)準(zhǔn)數(shù)據(jù)庫存儲方式增強其存儲性能。

（3）對于在設(shè)備資源耗盡的情況下，EDdb 如何運行，以及資源恢復(fù)正常后該如何恢復(fù)業(yè)務(wù)，這也是需要考慮的問題。