1 引言
在互聯(lián)網(wǎng)支持的大數(shù)據(jù)應(yīng)用系統(tǒng)中，實體行為通常通過消息交流產(chǎn)生相互影響，實體行為之間是并發(fā)的、獨立的、自演化的。所有實體的行為決定了系統(tǒng)的行為，在系統(tǒng)的穩(wěn)定態(tài)下個別實體的變異不會影響整個系統(tǒng)的功能，雖然每個實體的行為具有確定性，但它們所作用的系統(tǒng)演化結(jié)果具有不確定性。也就是說，互聯(lián)網(wǎng)中的所有個體構(gòu)成了巨大的并發(fā)計算機，每一個個體通過與其他個體進行信息交互實現(xiàn)各自的計算，并且得出整個系統(tǒng)的運行結(jié)果。如果將這種在互聯(lián)網(wǎng)世界表現(xiàn)出來的行為方式運用到程序架構(gòu)設(shè)計中，由個體的消息來驅(qū)動程序，降低個體變異對整個系統(tǒng)的影響，形成一種新的開發(fā)框架，將會是程序設(shè)計的一種新思路，可以看作在程序?qū)用婺M自然系統(tǒng)的行為。比如，很多大數(shù)據(jù)應(yīng)用系統(tǒng)由于個體行為與整個系統(tǒng)性能有著強關(guān)聯(lián)性，其編程方法和開發(fā)模式就需要解決實體的動態(tài)性、不確定性、并發(fā)性，通過模擬自然系統(tǒng)的行為和演化模式，實現(xiàn)程序的靈活性、頑健性等問題。
在大數(shù)據(jù)應(yīng)用系統(tǒng)中，已出現(xiàn)很多實際問題需要采用新的程序架構(gòu)來完成特定的功能要求。比如在智慧城市中，許多用戶之間共用一套消息管理系統(tǒng)，消息管理系統(tǒng)可將消息主動推送給相應(yīng)的用戶，而用戶之間很少進行聯(lián)系。在傳統(tǒng)的面向?qū)ο蟮某绦蛟O(shè)計方法中，對象之間是相互通信且彼此聯(lián)系的，任何一個對象的加入或者退出都需要告知其他對象，簡單來說就是每個對象內(nèi)部都有一套自己的消息管理系統(tǒng)。但是在大數(shù)據(jù)應(yīng)用中，多元數(shù)據(jù)的融合卻成為重要的問題，這就給程序設(shè)計帶來新的問題，即動態(tài)融合的數(shù)據(jù)如何更好地應(yīng)用于系統(tǒng)，以實現(xiàn)“融合、跨界、基礎(chǔ)、突破”。
針對這類大數(shù)據(jù)應(yīng)用，一種新的程序開發(fā)架構(gòu)正在形成，這就是面向?qū)嶓w、基于消息驅(qū)動的開發(fā)架構(gòu)——消息驅(qū)動架構(gòu)（massage drivenframework，MDF）。MDF在結(jié)構(gòu)上沒有傳統(tǒng)的主程序，而是分為3個模塊，即實體模塊、消息模塊和數(shù)據(jù)及顯示模塊。實體類似于對象，封裝了數(shù)據(jù)和操作，形成獨立的運行單元。但是實體之間沒有直接聯(lián)系，所有的實體都是基于消息控制的。MDF提供了一種在網(wǎng)絡(luò)環(huán)境下，共同開發(fā)系統(tǒng)的機制，遵守事先規(guī)定好的規(guī)范，開發(fā)人員不需要有溝通聯(lián)系，根據(jù)規(guī)范自行開發(fā)應(yīng)用模塊（實體），然后加入系統(tǒng)中運行，并且還可以隨時退出，這些操作都無需與系統(tǒng)其他用戶和管理人員打招呼。所有這些實體（用戶）行為決定了系統(tǒng)的行為，個別實體的消亡或變化不影響整個系統(tǒng)的功能。MDF是一種在互聯(lián)網(wǎng)環(huán)境下的編程框架，支持眾多實體參與的共同開發(fā)模式，它建立一種直接模擬自然和社會系統(tǒng)復(fù)雜行為運行的編程方法，排除個別變異實體對整個系統(tǒng)功能的影響；探索一種新的應(yīng)對大數(shù)據(jù)問題高并發(fā)、大流量、用戶獨立的解決方案，滿足新的應(yīng)用需求。
消息管理是MDF重要的組成部分，可以說是整個系統(tǒng)的中樞，所有實體的運行要靠消息管理進行協(xié)同，因此消息管理模塊的設(shè)計與開發(fā)是整個系統(tǒng)的關(guān)鍵內(nèi)容。這里面主要有三大挑戰(zhàn)：一是在MDF中，所有的通信方式都被嚴(yán)格定義為消息，不同類型的消息有著不同的處理方式，消息管理器如何在消息數(shù)量龐大的情況下識別消息類型，盡可能提高消息的處理準(zhǔn)確率；二是在消息維護過程中，如何通過調(diào)度策略，以優(yōu)化各種不同類型消息的處理和管理，使得在消息交互過程中盡量減少資源開銷和成本；三是在消息接收和發(fā)送過程中，尤其在消息數(shù)量龐大的情況下，消息必然出現(xiàn)排隊情況，如何設(shè)計合理算法，保證不同優(yōu)先級的消息能夠及時得到發(fā)送，又避免出現(xiàn)消息長期等待不被處理的情況。
本文中指的消息，相對于已有的事件驅(qū)動（event-driven）中的事件有所不同，事件的定義更加廣泛，可以是程序本身發(fā)出的信息，也可以是終端設(shè)備發(fā)出的請求。事件的管理和處理需要有一套復(fù)雜的硬軟件設(shè)備來完成。消息只是用戶程序（終端應(yīng)用程序）發(fā)出的一些文字序列，因此比起事件來說，在類型和內(nèi)容上要簡單的多。理論上說，事件驅(qū)動的技術(shù)可以用來產(chǎn)生消息驅(qū)動程序，但是不如另外為消息驅(qū)動重新定制一種架構(gòu)，在應(yīng)用系統(tǒng)開發(fā)中會更加有效和簡單。
消息管理模塊在MDF中起到了中心的作用。本文設(shè)計并實現(xiàn)了MDF的消息管理模塊，包括以下3個方面：
● 定義了消息的基本格式，制定了消息池的語言規(guī)范，通過消息表單的配置，實現(xiàn)不同類型消息的區(qū)別管理；
● 利用現(xiàn)有的編程語言Java開發(fā)了消息維護中間件，根據(jù)消息規(guī)范的表單配置自動生成消息類型管理，實現(xiàn)消息的接收、維護、存儲和發(fā)送等核心功能；
● 開發(fā)了中間件，接受實體對于消息管理模塊的操作，包括查詢、檢索以及對于各種類型消息的定義變更，滿足了MDF中實體運行和變化的需要。
在MDF中，實體的數(shù)量是可變的，實體的類型是多樣的。所有實體發(fā)送的消息和接收的消息將遵循統(tǒng)一的格式，實體需要向系統(tǒng)聲明的是它的URL地址、消息類型、消息發(fā)送要求等。URL 地址提供了該實體消息發(fā)送和接收的接口。消息類型和消息發(fā)送要求提供了消息的處理方式，這種要求被消息管理模塊響應(yīng)，并被正確維護。一個系統(tǒng)中的實體類型是多種的，每一種實體類型被定義了消息格式，同一類型的實體必須按照相同的消息格式發(fā)送消息，系統(tǒng)的消息管理模塊在邏輯上是唯一的。所以消息管理模塊的設(shè)計為實現(xiàn)MDF的并發(fā)性、動態(tài)性、頑健性、不確定性和跨平臺性等重要特性奠定了基礎(chǔ)。
2 相關(guān)工作
隨著計算機經(jīng)驗和軟件技術(shù)的發(fā)展，計算機編程語言經(jīng)歷了機器語言、匯編語言、面向過程的程序設(shè)計語言以及面向?qū)ο蟮某绦蛟O(shè)計語言階段[6]。具體的語言不勝枚舉，見表1。
表1 編程語言的發(fā)展
隨著編程語言的發(fā)展，計算機程序設(shè)計的方法也主要經(jīng)歷了3個階段的發(fā)展：面向機器的程序設(shè)計、面向過程的程序設(shè)計和面向?qū)ο蟮某绦蛟O(shè)計。
人類和計算機進行交流最開始的語言是由計算機可以直接識別的二進制指令組成的機器語言，在這個時期，計算機的程序架構(gòu)就是直接描述機器操作，因此這時的程序稱為面向機器的程序架構(gòu)。隨著高級程序語言的出現(xiàn)，面向過程的程序架構(gòu)被提出，這種結(jié)構(gòu)化的程序設(shè)計采用了“自頂向下，逐步求精”的思想，將計算問題模塊分化，功能分解，大的問題化解為若干個小問題，大大提高了工作效率，也利于程序的維護。當(dāng)然，面向過程的設(shè)計方法也存在一定缺點，最主要的是該方法編寫的程序是一系列的線性步驟，這種編程方式必須按照線性步驟從頭到尾編寫代碼，過程枯燥且不易修改，代碼的靈活性和可移植性都較差。為了克服這一困難，面向?qū)ο蟮某绦蚣軜?gòu)應(yīng)運而生，其主要思想是“注重對象，抽象成類”，不再強調(diào)過程，更側(cè)重于對對象的操作。對象是數(shù)據(jù)和操作的封裝體，與客觀實體直接對應(yīng)。通過封裝使對象變得獨立，只能通過預(yù)先設(shè)定的方法與對象交談，在構(gòu)建代碼的過程中通過繼承，減少冗余代碼的同時又可擴展現(xiàn)有代碼；封裝可減少外界對程序的干擾；且面向?qū)ο蟮南到y(tǒng)很容易切分成很多獨立的部分，將系統(tǒng)化繁為簡，同時這種方法可以使系統(tǒng)從小到大逐步升級。但傳統(tǒng)的面向?qū)ο蠹軜?gòu)仍存在不足，對象之間需要建立自己的通信通道，所有對象都需要了解一定的環(huán)境參數(shù)。但是在互聯(lián)網(wǎng)環(huán)境中某些由眾多用戶動態(tài)參與的應(yīng)用系統(tǒng)中，例如購物、游戲、社區(qū)等，它們的特點是用戶眾多且不確定，并且在大多數(shù)情況下，用戶不需要了解過多的運行要求和參數(shù)，而且用戶之間是透明的，也就是用戶之間可能不知道對方的存在，因此也不能有直接的溝通，對于這類程序的開發(fā)就需要提供一種更為自由和開放的編程模式。從目前主要是個人和小團隊開發(fā)的模式，逐步過渡到可以由彼此互不認(rèn)識的眾多用戶共同開發(fā)的模式，讓眾多的用戶包括非計算機專業(yè)的用戶也可以參與到系統(tǒng)的開發(fā)和運行中，使得每一個用戶既是程序的應(yīng)用者也是程序的開發(fā)者，將更加能夠體現(xiàn)大數(shù)據(jù)應(yīng)用的特點。
本文提出的MDF的程序設(shè)計方法的主要思想是“實體獨立，消息驅(qū)動”，各個實體之間遵循相同的消息通信協(xié)議，參與設(shè)計和開發(fā)的人員只需輸入框架指定的幾個參數(shù)就可參與開發(fā)，因此開發(fā)人員不需要相互溝通，大家只需要根據(jù)協(xié)議和規(guī)范就可以進行各自的應(yīng)用開發(fā)，最終組成一個龐大的應(yīng)用系統(tǒng)，讓更多的用戶根據(jù)個性化的要求方便地使用。
3 MDF架構(gòu)與消息管理模塊
3.1 MDF架構(gòu)
MDF沒有傳統(tǒng)意義上的主體程序，而是由實體、消息和數(shù)據(jù)顯示3個部分組成�？傮w來說，MDF是模擬自然和社會系統(tǒng)的運行模式，MDF所有運行都是通過消息驅(qū)動的。任何用戶都可以成為系統(tǒng)的組成部分，稱之為實體，或者系統(tǒng)對象。程序開發(fā)者只發(fā)布系統(tǒng)規(guī)范，系統(tǒng)規(guī)范指明實體的類型、實體的動作定義、實體的消息構(gòu)成、實體消息的內(nèi)容格式與解釋以及實體的登錄方法、實體生命周期等。一般地，規(guī)范提供實體樣式。系統(tǒng)規(guī)范還會提供實體與數(shù)據(jù)顯示部分的數(shù)據(jù)交換方式、運行結(jié)果顯示的方式以及相應(yīng)的顯示控制軟件，由數(shù)據(jù)顯示部分具體執(zhí)行。規(guī)范是開放的，用戶可以根據(jù)系統(tǒng)規(guī)范開發(fā)實體，或者實體樣式填好參數(shù)進行注冊，進入系統(tǒng)運行；也可以根據(jù)規(guī)范自行開發(fā)顯示模塊，獲取個性化的顯示方式。實體的地位是平等的，實體的加入和退出完全是自由的，雖然會影響系統(tǒng)的運行結(jié)果，但是一般不會影響系統(tǒng)的功能。消息部分是實體之間進行信息交互的中介，實體之間并不直接通信，而是借助消息部分進行轉(zhuǎn)發(fā)。實體的動作由消息定義，實體通過發(fā)送和接收消息來實行具體動作。實體的功能以及如何由消息定義動作在系統(tǒng)規(guī)范中予以說明。數(shù)據(jù)顯示部分提供運行結(jié)果和過程的顯示。MDF通過3個模塊實現(xiàn)這些功能，分別是實體管理模塊、消息管理模塊和由數(shù)據(jù)庫和輸出控制組成的數(shù)據(jù)顯示模塊。其具體架構(gòu)如圖1所示。
圖1 MDF架構(gòu)
●實體管理模塊：是整個軟件開發(fā)的主要部分。開發(fā)者編制、發(fā)布實體規(guī)范，規(guī)范提供實體描述定義、實體動作定義以及消息內(nèi)容格式與解釋，用戶根據(jù)規(guī)范自行開發(fā)實體程序，或者根據(jù)開發(fā)者提供的實體樣板注冊登錄。實體管理模塊根據(jù)實體規(guī)范協(xié)議管理所有的實體，包括實體的登錄和退出以及生存期間的運行管理。
●消息管理模塊：管理實體之間用于交互的消息。消息管理模塊發(fā)布一個消息格式協(xié)議，其中定義了消息格式的內(nèi)容與解釋。消息管理模塊根據(jù)消息格式協(xié)議管理消息的接收、發(fā)行、維護以及存儲等。
●數(shù)據(jù)顯示模塊：提供系統(tǒng)運行數(shù)據(jù)的顯示，包括結(jié)果顯示和過程顯示，數(shù)據(jù)顯示模塊與實體進行通信，接收實體提供的數(shù)據(jù)，通過輸出控制器執(zhí)行數(shù)據(jù)顯示的功能。同時該模塊還提供公共性數(shù)據(jù)和永久性數(shù)據(jù)的存儲和查詢，這些功能同樣通過與實體消息交互來驅(qū)動和實現(xiàn)。
本文主要介紹消息管理模塊的設(shè)計原理和實現(xiàn)，其他兩個模塊將另文撰寫。
3.2 消息格式協(xié)議
消息管理模塊最重要的是消息格式協(xié)議（message format propotol，MFP）。M FP定義消息為一個文本信息，分為4種類型，分別為：發(fā)送消息、查詢消息、測試消息和名單消息，所有消息都用表示消息類型的代碼開頭，后面跟隨消息本體。其中，A表示發(fā)送消息，即實體之間傳遞的消息；B表示查詢消息，即實體發(fā)出的查詢某個消息的請求；C表示測試消息，即實體用于測試通信鏈路狀態(tài)的消息；D表示名單消息，即實體發(fā)出的名單，這個名單提供當(dāng)前實體的變動，或者在多播狀態(tài)下提供接收實體的列表。
MFP定義消息head部分有7個屬性（見表2）。各部分內(nèi)容如下。
●name：符號串類型，表示消息的名稱。字長限制為128 byte。
●from：URL類型+時間類型，消息發(fā)送方的URL地址，后跟發(fā)送時間，中間用“+”號隔開。
●to：消息接收方地址，使用“X+P”形式表示，其中，X表示發(fā)送形式，分別是U（單播）、M（多播）和B（廣播）。P表示發(fā)送對象，在單播時為URL地址，多播時為接收方的URL地址，最多為16個地址，或者是分組文件名稱，這個分組文件事先存放在消息管理模塊中。廣播時，P為空，此時由消息管理模塊根據(jù)內(nèi)部存放的實體名單向各實體發(fā)送消息。X和P之間用“+”隔開。
●type：消息發(fā)送類型，使用單個字符表示，其中A表示主動發(fā)送，即該消息根據(jù)設(shè)定的時間自動發(fā)送到接收方；P表示消息只在接收方查詢時發(fā)送。
●life：消息生存時間，使用“單個字符+時間類型”形式表示，單個字符表示消息銷毀時間，后面是具體的時間，中間用“+”隔開。其中，單個字符L表示該消息發(fā)送后即銷毀；L+time表示該消息在time這個時間點銷毀；K+time表示消息在保存time時間后銷毀。
●time：時間類型，表示消息發(fā)送的時間，這個參數(shù)只在主動發(fā)送時有效，在查詢發(fā)送的消息中，該欄目可以為空。
●priority：整數(shù)類型，取值為1~3，表示該消息的優(yōu)先等級，消息的優(yōu)先等級由系統(tǒng)規(guī)范定義。
表2 消息的基本格式
表2列出了發(fā)送消息name、from、to、type、life、time、priority的全部7種屬性。消息管理模塊會針對消息的屬性描述進行不同的處理。
發(fā)送消息（以A開頭）的消息內(nèi)容由head和body兩段組成。head定義了消息的聲明部分，用以描述消息的屬性；body定義了消息的內(nèi)容部分，用以描述消息的正文。MFP僅對消息的head部分進行了格式要求，其屬性值對消息的傳輸、保留、銷毀、發(fā)送以及與實體之間的交互起著重要的作用。MFP對body未做要求，只是限定了body的長度。body的內(nèi)容語義解釋由程序開發(fā)者定義，所有實體必須按照這個定義來編排消息內(nèi)容。在MFP和消息管理模塊中，不涉及對于消息內(nèi)容的任何讀寫，只是根據(jù)消息head部分的要求進行消息管理，而消息body部分的內(nèi)容理解是由實體完成的。
查詢消息（以B開頭）由消息名稱（name）（必有）、查詢方的URL地址（to）以及查詢內(nèi)容（body）組成。查詢內(nèi)容是消息的屬性，該模塊支持屬性匹配查詢，消息管理模塊在匹配檢查完成后，將符合條件的消息根據(jù)URL地址發(fā)送給查詢方。查詢內(nèi)容部分可以是空，表示這部分不用匹配。在本文的版本中，暫不支持模糊查詢和通配符查詢，也暫不支持多條件查詢。
測試消息（以C開頭）是由發(fā)送方的URL地址加上任意的64byte的文本，中間用“+”隔開。消息管理模塊在收到該消息后，向發(fā)送方返回該64 byte的文本。測試消息是為了檢查當(dāng)前通信線路是否可用，當(dāng)實體發(fā)送測試消息并正確回收發(fā)送的文本后，就可以執(zhí)行正常的消息傳送了。
名單消息（以D開頭）有兩種格式：名單定義與名單刪除。名單定義用于表示實體定義的多播名單，一般情況下，實體可以隨時發(fā)送多播名單，多播名單有多個，編號加以區(qū)別，該多播名單聲明實體名稱和多播對象URL地址。當(dāng)實體提交一個多播消息時，應(yīng)在屬性to中指明多播名單的編號，以便于消息管理模塊生成發(fā)送消息對象。名單刪除表示需要刪除的名單，所有名單通過名單名稱進行識別。
3.3 消息管理模塊
消息由實體產(chǎn)生，并以消息格式協(xié)議規(guī)定的形式由消息管理模塊處理，其中消息名稱name是消息的唯一標(biāo)識。
每一個實體在登錄系統(tǒng)時，會向消息管理模塊發(fā)送一個身份登錄信息，從而在消息管理模塊中產(chǎn)生一個動態(tài)的實體名單，該名單維護當(dāng)前登錄實體名稱。同時每一個實體需要發(fā)送多播消息時，會向消息管理模塊提交多播名單編號。如果未提交多播名單，協(xié)議允許發(fā)送方在消息屬性to部分臨時指定不超過16個發(fā)送對象的URL地址。實體名單和多播名單都由消息管理模塊維護。
圖2演示了消息從接收到發(fā)送的完整流程。實體1發(fā)送控制指令與通信線程1建立消息傳輸通道1，發(fā)送消息msg2。消息管理模塊接收到msg2，經(jīng)過合法性和完整性的驗證，將消息存放在消息池中。如果消息屬于主動發(fā)送類型，則將該消息加入發(fā)送隊列，根據(jù)指定的優(yōu)先級發(fā)送消息。如果是被動發(fā)送消息，則在接收到查詢消息后，將該消息加入發(fā)送消息隊列，根據(jù)該消息的優(yōu)先級發(fā)送到實體2。
由圖2可以看出，消息管理模塊主要分為2個部分：消息池和消息數(shù)據(jù)庫。
圖2 消息的流向
消息池是3個消息隊列，分別對應(yīng)MFP中的3個優(yōu)先級。需要發(fā)送的消息根據(jù)優(yōu)先級放入相應(yīng)的消息隊列進行排隊。消息隊列的管理算法在下面單獨說明。
消息數(shù)據(jù)庫是一個數(shù)據(jù)庫，消息被接收后，經(jīng)過消息管理模塊的解析，如果不是即時發(fā)送，則存入相應(yīng)的數(shù)據(jù)庫。消息數(shù)據(jù)庫隨時檢查消息，當(dāng)某條消息達到發(fā)送條件時，即將該消息送入消息池排隊。如果接收到的消息是查詢消息，則進行相應(yīng)的查詢，并將查詢的信息返回發(fā)送方。如果某條消息需要銷毀，則消息數(shù)據(jù)庫進行相應(yīng)的操作。
除了這兩部分外，消息管理模塊還負(fù)責(zé)消息池和消息數(shù)據(jù)庫的維護，保證其正常運行和通信暢通。當(dāng)實體發(fā)送測試消息時，該模塊負(fù)責(zé)響應(yīng)該測試消息。當(dāng)實體發(fā)送名單消息時，該模塊負(fù)責(zé)讀取并存入相應(yīng)的存儲器管理，或從存儲器中刪除名單。
（1） 消息管理
消息與實體之間的聯(lián)系采取socket通信協(xié)議。socket為消息管理模塊和實體模塊之間的通信提供了進程通信的端點，每個socket都用一個半相關(guān)的描述（協(xié)議、本地IP地址、本地端口）。系統(tǒng)會根據(jù)實體的URL地址和端口號為其生成一個socket號；消息管理模塊向所有實體公布唯一的socket號，任何知道該socket號的實體都可以向消息管理器發(fā)出連接請求。
消息管理模塊與實體之間的連接過程分為3個步驟：通信線程的監(jiān)聽、實體端請求和消息管理模塊的連接確認(rèn)。由于消息在網(wǎng)絡(luò)中進行傳輸會有較大的時延，為了提高系統(tǒng)的實時性和吞吐量，每個實體與消息管理器之間都有一個消息傳輸通道。對于每一個消息傳輸通道，消息管理器中有一個用來收發(fā)消息的通信線程與其對應(yīng)。
通信線程接收到用戶實體發(fā)送的消息后，首先對消息進行完整性、合法性檢驗，然后再對檢驗合格的消息進行處理。
● 如果是發(fā)送消息，則解析消息head中的各個屬性，對于滿足發(fā)送條件的，則根據(jù)屬性中的指示，將消息加上需送達的實體URL地址以及其他一些輔助信息，根據(jù)其優(yōu)先級，加入相應(yīng)的發(fā)送隊列等待發(fā)送。
● 如果是查詢消息，根據(jù)查詢消息中的查詢內(nèi)容在消息庫中進行查詢；將查詢到的消息加上送達實體的UR L地址以及其他一些輔助信息，并根據(jù)其優(yōu)先級，加入相應(yīng)的發(fā)送隊列等待發(fā)送。
● 如果是測試消息，則根據(jù)協(xié)議規(guī)定，返回測試實體64 byte的文本。
● 如果是名單消息，則將名單加上發(fā)送實體的URL地址與編號作為文件名稱，存入相應(yīng)的存儲器，以備使用。
同時，消息管理模塊也支持一些控制指令，以保證系統(tǒng)通信的正常和完好。
（2） 消息池
消息池負(fù)責(zé)管理消息的發(fā)送，主要包括多個發(fā)送隊列（本文中是3個）、發(fā)送隊列維護線程、消息的發(fā)送線程。消息管理模塊與實體連接后，就會進行消息的傳遞，在消息的傳送過程中，將根據(jù)優(yōu)先隊列進行消息發(fā)送。
消息池經(jīng)常處于并發(fā)工作狀態(tài)，為此在消息池中對每條消息都標(biāo)記了優(yōu)先級，同優(yōu)先級的消息位于同一發(fā)送隊列，如圖3所示。具體算法如下。采用優(yōu)先隊列發(fā)送（priority queuesent，PQS）算法。
圖3 發(fā)送隊列設(shè)計
①讀取最高優(yōu)先級（priority=3）的隊列消息，如果該消息信道空閑，則發(fā)送該消息；如果信道繁忙，則轉(zhuǎn)向同隊列的下一條消息；如果下一條消息不存在，則將下一優(yōu)先級的第1個消息移入該隊列，并發(fā)送該消息。
②消息發(fā)出后，等待時間間隔γ，如果收到消息發(fā)送成功信息，則在隊列中刪去此消息。將次高優(yōu)先級（priority=2）和最低優(yōu)先級（priority=1）的隊列中的最前消息優(yōu)先級加1，并排到前一優(yōu)先級的隊尾；返回第①步。
③如果時間間隔γ后，未收到消息發(fā)送成功信息，則再次發(fā)送該消息。
④如果再次時間間隔γ后，仍未收到消息發(fā)送成功信息，將該消息移到同一優(yōu)先級的隊尾，返回第①步。
該算法可以設(shè)立通信進程而支持消息的并行發(fā)送，在前一個消息發(fā)出而未收到確認(rèn)信息時，后一條消息仍可以發(fā)送，而且確認(rèn)信息回復(fù)的次序可以與發(fā)送次序不同，后發(fā)的消息回復(fù)可能先收到。
消息池在消息隊列的內(nèi)部采用FIFO（first in first out，先進先出）算法；在隊列間，采用動態(tài)優(yōu)先權(quán)調(diào)度算法，即將消息加入發(fā)送隊列時，按其優(yōu)先級加入相應(yīng)的發(fā)送隊列，消息發(fā)送總是在最高優(yōu)先級隊列中進行，每處理一條消息后，就將其余隊列中的第1條消息的優(yōu)先級加1，并按更新后的優(yōu)先級將消息轉(zhuǎn)至相應(yīng)的發(fā)送隊列隊尾。梯度發(fā)送隊列之間用鏈表實現(xiàn)。發(fā)送隊列維護線程用于動態(tài)（按時間片）更新消息的優(yōu)先級。消息的發(fā)送線程用于從優(yōu)先級最高的發(fā)送隊列中取出消息，并根據(jù)消息head中的to字段調(diào)用相應(yīng)的通信線程發(fā)送消息。由于系統(tǒng)中有多個消息傳輸通道，等待一個消息被接收后再發(fā)送另一個消息會導(dǎo)致傳輸通道的空閑時間過長，為了提高系統(tǒng)的吞吐量，本文采用了多線程的消息發(fā)送模式，只要待發(fā)消息的信道空閑，就發(fā)送該消息，這樣的方法可以提高信道的利用率。
（1） 消息庫
消息庫是一個關(guān)系數(shù)據(jù)庫，本文使用的是MySQL。消息庫存放所有未被刪除的消息以及名單消息中提供的名單，并實現(xiàn)以下的操作。
● 接收消息后，經(jīng)過解析，如果需要立即發(fā)送，則按照優(yōu)先級送到相應(yīng)的發(fā)送隊列排隊，并存入信息庫；若不需要發(fā)送，則送入消息庫，消息的各屬性作為消息庫的字段，以便于按屬性查詢。
● 檢查消息庫：如果某條消息符合發(fā)送條件，則取出該消息，送入發(fā)送隊列；如果某條消息需要銷毀，則銷毀該消息。
● 收到查詢消息后，進行按屬性查詢，并將查詢結(jié)果返回查詢實體。如果被查詢消息需要發(fā)送，則送入發(fā)送隊列。
● 收到名單消息后，如果是名單定義，則將名單追加到消息庫；如果是名單刪除，則從消息庫中刪除指示名稱的名單
4 實驗設(shè)計
本文提供一個基于M D F 開發(fā)的實例——天文大數(shù)據(jù)模擬系統(tǒng)。天文科學(xué)是一個產(chǎn)生大數(shù)據(jù)的學(xué)科，例如在太陽與小行星的運行系統(tǒng)中，就有數(shù)以萬計的小行星，計算這些小行星的軌跡是一個典型的大數(shù)據(jù)應(yīng)用。這些小行星還會不斷增加和消失，如果把小行星看作用戶，這是非常有代表性的多用戶動態(tài)運行系統(tǒng)。因此通過MDF開發(fā)一個系統(tǒng)，隨時模擬小行星的運行，該系統(tǒng)支持小行星的隨時更新。在本文中，筆者做了一個簡化的實驗性版本，用以說明原理，以太陽、地球、火星、金星4個星體為例，模擬星體的運行軌跡。星體之間由于受到引力作用，以太陽為中心做橢圓軌跡的運動。太陽系的運行是包括太陽在內(nèi)的所有星體共同作用的結(jié)果，由于每個星體都是不停運動的，對其他星體引力的大小和方向在時刻變動。消息驅(qū)動框架正適宜去描述這類問題。在該模型中，每個星體都是一個實體，它們都具備相同的功能，而一個星體對另一個星體的引力影響可以認(rèn)為是該星體發(fā)出了一個消息給另一個星體，星體根據(jù)消息內(nèi)容做出自己的運行。在MDF方式下，每個星體只要給出自己的物理參數(shù)（質(zhì)量、位置、速度），整個太陽系的運行就可以自動建立起來，而且可以隨時添加新發(fā)現(xiàn)的星體（小行星），也可以隨時刪去星體。
圖4顯示了金星在太陽、地球和火星作用下的引力模型。金星有一個質(zhì)量和初速度V0使其能在引力作用下圍繞太陽轉(zhuǎn)動。
圖4 三行星的運行模型
在該引力模型中，實體管理模塊有兩種實體類型：太陽和行星。地球、火星、金星為行星類型。實體管理模塊定義太陽的位置固定不動，行星在引力的牽引下圍繞太陽作公轉(zhuǎn)運動。太陽實體具有質(zhì)量（weight）和位置（position）兩種屬性，以（weight， position）的消息格式發(fā)送并存放在消息管理模塊。每個行星實體都有質(zhì)量（weight）、位置（position）、速度（velocity）、時間（time）4種屬性，并將這4種屬性以（weight ，position， velocity， time）的形式加以封裝，作為消息相互傳遞通信。太陽的消息是被動查詢類型，而每個行星實體的消息都是主動廣播類型。以火星為例，火星實體向消息管理器發(fā)送一條查詢消息，消息管理器解析火星實體發(fā)送來的查詢消息的head部分，將查詢到太陽的消息發(fā)送給火星，火星實體解析出太陽的位置和質(zhì)量，又得到其他行星推送的消息，就可以計算出自己在當(dāng)前位置受到的來自太陽和其他行星的引力，并計算下一步的位移。
為了觀察實驗結(jié)果，將太陽、地球、金星和火星的運動軌跡以圖像的形式展現(xiàn)出來，本次實例使用的質(zhì)量、位置、速度數(shù)據(jù)均以目前太陽系運行模型為基準(zhǔn)，參數(shù)設(shè)置在表3中，而圖5則將表3的參數(shù)圖形化，顯示了各個星體的初始位置。
表3 行星參數(shù)
圖6顯示了太陽在靜止不動的情況下，地球、金星和火星圍繞太陽的運行軌跡。
圖5 星體的初始位置
圖6 星體的運行軌跡
在該天體模型中，可以隨時加入或撤銷星體。當(dāng)發(fā)現(xiàn)新的星體時，只要在實體管理模塊輸入星體正確的質(zhì)量、速度和初始位置，就可以加入該天體模型中。新星體的加入或撤銷會影響其他星體的運行軌跡，但不會導(dǎo)致整個模型的崩潰。
5 結(jié)束語：
在大數(shù)據(jù)應(yīng)用背景下，編程語言顯示出與機器的相關(guān)性越來越小，與客觀世界越來越貼近，程序的開發(fā)架構(gòu)也越來越與計算機執(zhí)行的過程脫離，而趨向于和問題結(jié)構(gòu)越來越靠近，“描述就是編程”已經(jīng)成為當(dāng)前編程架構(gòu)的關(guān)注點。編程語言已經(jīng)逐漸從專業(yè)高端走向普通大眾。本文研究的消息驅(qū)動框架的開發(fā)模式是一種典型的聲明式編程，其中，消息管理模塊是消息驅(qū)動框架的交通樞紐、神經(jīng)中樞，它控制著通信唯一媒介——消息的接收、存儲、發(fā)送以及維護等相關(guān)工作。這種編程框架模擬了許多自然和社會系統(tǒng)的行為方式，改變了人們的解決問題的方式，也將處理邏輯的重點從內(nèi)部轉(zhuǎn)移到外部，簡化了問題求解的復(fù)雜度。
在消息驅(qū)動的開發(fā)框架中，消息管理模塊的定義與設(shè)計是重點，目前也只是完成初步的描述，還有很多細(xì)節(jié)和功能方面需要改進，以下幾點是需要完善和考量的。
● 程序的頑健性：在消息管理模塊中有大量的中間件，要保證每個中間件必須是頑健的。因此建立錯誤恢復(fù)機制、為開發(fā)人員提供測試和調(diào)試的接口以及提供較為明確的錯誤報告對消息驅(qū)動框架的發(fā)展是相當(dāng)必要的。
● 消息管理：本文雖然對消息管理做了初步的約定和設(shè)計，但是在實際系統(tǒng)運行中，消息管理的要求是多樣的，如何適應(yīng)不同需求的消息管理模式，仍有待于繼續(xù)探討。
● 消息管理模塊與實體模塊和顯示模塊的對接：本文的工作主要是針對MDF的消息管理模塊，實體模塊以及數(shù)據(jù)管理和顯示模塊仍需要進一步完成和完善。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標(biāo)題：大數(shù)據(jù)應(yīng)用系統(tǒng)的消息驅(qū)動架構(gòu)
本文網(wǎng)址：http://www.oesoe.com/html/solutions/14019319924.html
相關(guān)文章
