小雪你好紧好烫好爽_k频道导航入口国产精品_91成人爽a毛片一区二区_羞羞漫画入口在线观看

大數據、云計算、分布式存儲系統、區塊鏈等新技術的提出,不斷創造出獨特的新互聯網模式,同時也向人們展示了去中心化分散基礎設施建立的模型。基于多元化的現代倉儲系統也逐漸得到研究與重視,現代化的倉儲區域規劃與管理的智能化程度直接影響倉儲作業效率和儲存能力[1],這些現象在帶來海量數據頻繁存取問題[2]的同時,隨著倉儲企業規模的不斷擴大,也出現了物資可能會存放于不同部門、不同地域,尤其是多層級倉庫的貨品管理及各組織的倉庫資源賬目不能及時掌控庫存的情況,導致產生大量繁瑣數據、數據不統一、無法及時統計分析,造成倉儲企業管理效率低下的現象[3]。為了實現高效、智能化的企業倉庫管理,許多學者針對智能化倉儲管理系統應用進行了深入研究[4]。復旦大學的許嘉勛提出了一種基于云數據庫的企業資產管理,并以MongoDB數據庫為例,分析了MongoDB數據庫建模的可行性,設計并實現了一個基于MongoDB數據庫的高可靠、高擴展的分布式企業資產管理系統[5]。

在基于Web的架構中,數據庫難以實現橫向擴展[6],非關系數據庫中利用查詢語言對數據進行查詢沒有行的概念,數據在存儲的時候沒有固定的鍵值模式,一般都是通過文檔的形式進行存儲[7]。朱愛華等針對經典的倉儲信息服務系統大都使用關系型數據庫,結合前端交互技術以及非關系型數據庫MongoDB來搭建Web服務,并通過性能測試證明了該架構比傳統的數據庫操作在處理速度和資源占用上具有更好的性能優勢[8]。文獻[9]也證明了在非關系型數據庫NoSQL中引入Web的架構系統,可以利用NoSQL優勢來彌補關系型數據庫的不足。

該文在充分研究分析非關系型數據庫MongoDB在分布式存儲方面的特性,利用前端開源框架Angular設計實現軟件邏輯操作功能;通過將Angular與RFID技術融合設計實現一種分布式智能倉儲管理系統,并利用基于MongoDB云數據庫的高可用性構架特性將倉儲企業的各分支機構的數據存儲系統整合起來建立一個私有云,解決對異地分布的倉儲的物資、設備容量不斷擴容的需求與倉儲管理運營成本之間的矛盾,旨在為多站點多倉庫共享數據的倉儲系統Web管理應用提供可擴展的高性能數據存儲解決方案。

針對建立數據倉庫時存在的系統需求不斷變化、語義斷層以及數據倉庫改動難、代價大等問題,建立數據倉庫采用分層架構是一種很常見的模式,也叫N層架構[10]。該文提出一種4層數據倉庫體系結構模型,包括表述層、控制層、業務邏輯層、數據庫物理層。系統分層結構示意參見圖1。

圖1 系統分層結構   

建立系統云架構,首先要解決的就是需對大量分散的數據進行分區存儲的問題,即將數據拆分并分散儲存在不同的服務器上。

該文利用MongoDB能夠支持數據自動分區的特性,將數據庫中的數據按相關屬性劃分成若干數據組,并將這些數據組分散到若干較大的分區中,每個分區負責總數據的一部分。系統主控程序中在對數據庫進行數據分區之前先建立兩個路由進程,一個是用于對多個分區的數據庫進行路由探測并提出連接申請的進程Mongo_sq;另一個是用于系統在沒有數據分區(隱藏數據分區的細節)的時候提供給客戶端連接路由的進程Mongo_pt,可以實現在不修改系統程序的情況下對系統分布的節點進行增加或刪減。

具體的做法是在對系統進行數據分區時,從數據屬性集選擇某個具有代表性的字段作為一個共享“鍵”(Shard key),該“鍵”的鍵值即作為數據分區的主要依據,并對這些鍵進行編號(如Shardkey_01,Shardkey_02,……)。如可以使用“倉庫ID”來定義各倉庫、產品存儲位置、庫位設置等數據庫或數據表的共享“鍵”,在此基礎上建立不同數據的分區,并存放于不同的服務器或本地計算機上,當系統查詢“倉庫ID”如果是屬于“物資庫存管理”時即直接將該共享“鍵”有針對性地發送到“物資庫存管理”數據分區所在的服務器或本地計算機上,同樣,如果RFIDI設備掃描到的產品隸屬于某個倉庫,就直接將該產口的相關信息發送到對應的分區數據庫中。

云數據庫系統用例(包括普通用戶和管理員用戶)參見圖2。

圖2 云數據庫系統用例   

普通管理員可以按照一定的需求條件申請所需的云數據庫(如果是企業外的用戶需繳納一定的費用才能獲得),通過系統自動分配成功后,提供給相應的普通管理用戶對相應云數據庫訪問的地址、端口及數據庫名稱等信息;相應地,如果普通管理員放棄對該數據庫的使用權,系統會根據自動對相關數據進行處理后回收該云數據庫所占用資源。

超級管理員通過硬件設備的管理功能子模塊、對普通管理員的管理子模塊以及對云數據庫的管理操作等對云數據庫進行訪問,包括設置綁定終端節點的ip地址,使得僅被綁定的ip才有權訪問選定云數據庫、為普通管理員用戶設定初始化的用戶名、登錄條件及啟/停云數據庫服務等功能。普通管理員對云數據庫的操作功能則主要包括通過啟/停云數據庫、更改用戶信息、變更數據庫訪問權限、日常功能維護以及通過倉庫管理系統對商品的信息采集與管理等功能模塊對云數據庫進行訪問。

系統高可用性架構(Replica Set)是MongoDB系統為了構建具有自動容錯及恢復功能的一項非常實用的高可用性方案[11]。該文提及的系統設計建立的基礎思想是,將一些位于同一地點或不同地點的服務器集合起來建立業務服務器云,數據庫層采用分布式的物理結構進行云架構,系統云架構示意參見圖3。

圖3 系統云架構示意   

系統依據數據庫的規模設定一個或多個數據分區并配置相應的能夠表明數據位于哪個分區的共享數據元素“鍵”的拷貝,這樣就構成了一個Replica Set節點,每個節點可進一步分為一個或多個子節點,但每個節點須持有相同數據的拷貝。同時,還需定義主從節點,即一個節點為主節點,其他為從節點,且這些節點均需具有系統重構功能,即如果主節點出現故障,可選擇一個從節點自動承擔主節點的工作。

每個節點服務器需配置—個或多個路由器提出連接申請的進程Mongo_sq路由器提供給客戶端路由申請服務,并將請求分發到相應的數據分區服務器上。分區服務器配置內容主要包括服務器名稱、IP地址、端口三個方面。

其中端口配置的內容比較復雜,主要應包括:

(1)整個系統所有分區共享“鍵”(Shard key)訪問端口的分配(各個“鍵”可分配同一端口),該“鍵”的鍵值即作為數據分區的主要依據,并對這些鍵進行編號(如Shardkey_01,Shardkey_02,……);

(2)用于訪問沒有數據分區的時候提供給客戶端連接路由的Mongo_pt端口;

(3)用于對多個分區的數據庫進行路由探測并提出連接申請的進程Mongo_sq;

(4)服務器配置詳細過程就不贅述。

對MongoDB數據庫操作必然會存在對各節點的文檔訪問操作的均衡性問題,而且須對這個均衡問題進行協調控制,否則系統很容易因為對某個節點文檔的高密度訪問而造成數據擁堵問題。

利用文獻[12]提出的基于數據操作的頻率(FODO)改進的均衡算法設計,以解決對數據庫操作的均衡問題,算法可描述如下:

(1)初始化。

設集群有p個節點,有d個文檔塊被集合在一起形成由MongoDB自動分隔的集群文檔;

(2)定義變量。

Int i=1,2,…,n;

Int Bi,Oi,Ii,Fi,Ci,DOi,DOi,λ;

Int SUM_DOi,SUM(SUM_DO);

//Bi是文檔塊數,Oi、Ii、Fi、Ci分別存放對文檔塊的操作頻率、插入操作頻率、查詢操作頻率和更改操作頻率;DOi表示每個節點中文檔塊數據某個操作的頻率;SUM_DOi存放每個節點中所有文檔塊數據的所有操作頻率之和;λ表示調節負載均衡過程中分配各節點各文檔塊數據操作的比重參數,SUM(SUM_DO)存放整個集群分區各個節點中數據操作頻率之和[13]。

(3)計算各節點各文檔塊數據操作頻率。

DOi=Oi∑i=1nOiDΟi=Οi∑i=1nΟi

(4)計算各節點各文檔塊數據所有操作頻率。

SUM_DOi=Ii∑i=1nIi+Fi∑i=1nFi+Ci∑i=1nCiSUΜ_DΟi=Ιi∑i=1nΙi+Fi∑i=1nFi+Ci∑i=1nCi

(5)計算帶有均衡修正系數λ(λ>1)的各節點各文檔塊數據所有操作頻率之和。

SUM_DOi=λIi∑i=1nIi+Fi∑i=1nFi+Ci∑i=1nCiSUΜ_DΟi=λΙi∑i=1nΙi+Fi∑i=1nFi+Ci∑i=1nCi

(6)計算整個分區的操作頻率可以用每個節點中所有文檔數據的操作頻率之和。

SUM(SUM_DO)=∑i=1nBi(SUM_DOi)_DΟ)=∑i=1nBi(SUΜ_DΟi)

其中λ是為了調整插入操作與查找、修改操作的均衡關系參數。由于MongoDB對數據的訪問與修改時會對前一次查詢過或修改過的數據進行記憶并將其保存到緩存中,當下一次需對這些訪問過的數據查詢或修改時相當于訪問的是本地緩存的數據;MongoDB對每個分區的操作會提供一個包含分別承擔數據的寫、讀負載的primary和secondary兩個節點的replica set,使數據最大限度被利用。因此,MongoDB系統對數據插入操作負載的影響要比讀和寫操作負載的影響要大得多,尤其是每當在進行插入數據操作時,每一個數據塊所在的節點中的數據信息均會造成負載不均衡,而當不均衡的數據量達到一定程度時,系統的數據遷移閾值會觸發啟動,對不均衡的現象進行調節,在這個過程中,系統資源被極大地浪費[14]。因此,為平衡插入與讀寫操作的比重,在計算插入操作頻率中增加一個系數調節參數λ(λ>1)[15],確保節點負載的均衡。

系統主要由統計分析、庫存管理、記錄查詢、產品管理、RFID讀頭管理、倉庫管理、系統設置七大部分組成。系統通過B/S(Browser/Server)結構進行布置,物料或貨品的基礎數據和系統對數據進行管理的程序可分別運行于不同的服務器,系統終端的控制程序可以同時運行于不同的微機上。

用戶對近期出庫入庫趨勢及流動物資總量有一個直接的了解,如庫存總量、入庫總量、出庫總量;

包括物資出庫、入庫、調撥、移庫、報損、盤點等功能;

針對物資操作后的記錄進行查詢,通過不同的搜索條件聚合查詢,快速準確地定位到用戶需要的記錄信息;

主要對批量標簽綁定商品的管理,設置了產品型號管理和商品添加功能,可以實現對單獨一個型號的產品管理;

依據不同環境下對不同的讀著性能進行調整設置;

每個倉庫中包含了多個門,門與讀頭屬于對應關系,以表明其出庫還是入庫屬性,倉庫內也有很多個庫位,庫位也包含了庫位容量、庫位屬性等屬性的設置、修改與綁定等功能;

超級管理員才有操作權限,可以添加普通管理員,修改賬號信息等。

頂層數據流主要描述管理員之間的角色數據關系,不同角色對應操作不同功能模塊,并將操作結果數據存儲到云端數據庫。管理員之間的數據流(頂層)參見圖4所示。

圖4 管理員之間的數據流(頂層)   

描述不同管理員與對應功能模塊的數據流向關系。超級管理員無權限限制,包括硬件信息管理、出庫、入庫、調撥、移庫、報損、盤點操作及記錄查詢、庫存查詢、對產品產品類型的定義、添加商品等功能。而普通管理員主要針對邏輯操作及查詢功能,沒有進行硬件信息管理的權限。管理員與對應功能模塊的數據流(第二層)參見圖5。

圖5 管理員與各模塊的數據流(第二層)   

數據庫的設計充分考慮業務場景、數據讀寫頻率、安全一致性等方面的需求,以及主節點服務器出現系統崩潰后能夠迅速切換到其他節點,采用MongoDB分布式副本集架構為基礎,共設計了6張表:用戶信息表、倉庫表、商品信息表、倉庫門信息表、倉庫位信息表、商品庫存表。

用戶名、用戶密碼、用戶ID、用戶角色、用戶郵箱;

倉庫ID、倉庫名稱、管理員、倉庫地址、屬性;

商品序列號、編號、名稱、生產日期、商品EPC碼、商品NFC碼、型號、類別、圖片地址;

門ID、名稱、類型,庫位ID、庫位名稱、庫位規模;

所屬倉庫、倉庫位ID、管理員、倉庫地址、倉庫位規模、當前存放量;

商品序列號、編號、名稱、入庫時間、商品EPC碼、商品NFC碼、型號、類別,倉庫編號、倉庫名稱、庫位編號、庫位名稱等。

前端使用Angular封裝的httpClient模塊,在ng-alain中又被封裝成更為便捷的httpClient方法,可以很方便地自動添加請求頭并處理返回的對應的數據格式,其實質上仍然還是使用http方法請求數據,返回的數據用rxjs中的observable訂閱處理。該文的數據接口用postman軟件進行梳理和測試、調試,最后將所有項目打包部署在服務器上。為了數據安全,運行中的數據請求應用改為https請求。

著重介紹登錄,RFID讀頭管理,庫存管理中的入庫、出庫、調撥、移庫、報損、盤點,并以登錄功能實現主要代碼及登錄主界面、RFID讀頭管理主界面截圖(其他模塊的界面圖略)為例。

登錄模塊主要是在用戶輸入時進行了表單驗證和登錄失敗時提示信息,并且在登錄成功后顯示用戶頭像、用戶郵箱等信息。在Session Storage中存儲用戶角色以及攜帶的Token,Token精度設置在秒,有效期為兩個小時。用戶登錄主界面參見圖6,實現代碼可簡單表述如下(其他功能模塊的實現代碼詳略)。

//清空路由復用信息

this.reuseTabService.clear(); //設置用戶Token信息

this.tokenService.set(res);

//重新獲取StartupService內容,信息一般都會受當前用戶授權范圍而影響

const user={

name:res.name,//avatar:res.avatar,avatar:'./assets/tmp/img/avatar.jpg',userId:res.id,

};

this.settingsService.setUser(user);this.startupSrv.load().then(()=>{let url=this.tokenService.referrer.url||'/';

if (url.includes('/passport')) url='/';

this.router.navigateByUrl(url);

});

}

圖6 用戶登錄主界面   

讀頭設置需要先獲取模式等相關硬件參數,包括讀寫器硬件屬性信息、射頻輸出功率、天線、蜂鳴器、標簽過濾規則等,可依據不同的場景的需要調整讀頭配置。讀頭詳細功能設置參見圖7。

圖7 RFID讀頭詳細設置 

利用數據實時傳輸通信功能的ngx-mqtt插件,獲取倉庫/門主題并將接收到的數據存入數據庫提供給查詢系統,將得到相應的商品信息轉換成用戶需要的格式展示在表格中,并在表格的底部顯示匯總統計信息。操作員確認后點擊入庫按鈕、填寫入庫單號、選擇庫位、提交入庫。

商品出庫功能先進行掃描然后過濾重復的商品信息,填寫出庫單號,執行出庫。與入庫操作不同的是,出庫時掃描的商品是在庫存里查找,入庫的信息則是在商品信息庫中查找。

調撥是物資從一個倉庫轉移到另一個倉庫的過程,拆分開就是先執行出庫再入庫,在執行調撥時需要選擇目的倉庫,在目的倉庫入庫時選擇庫位就完成了整個調撥過程。

移庫與調撥是不同的概念,是在同一個倉庫內不同的庫位周轉的過程。在確認物資信息正確之后選擇新庫位與舊庫位,執行移庫操作。

在物資使用或者存放過程中會出現損壞情況,報損功能為了及時分離這些損壞商品,功能流程與出庫一致。找出損壞商品,讀頭掃描,執行報損,數據庫實時更新報損數據,并做統計。

按照倉庫管理的要求,需要進行不定期的盤點。前端網頁按照需要盤點的物資條件查詢到指定商品,生成盤點信息單,發送到手持機,手持機拉取盤點單,在指定庫位進行掃描,將掃描結果進行對比,將結果展示給操作員。

記錄查詢主要是搜索條件比較多,接口也相應地做了聚合查詢。可以單條查詢,也可以多條。正因為搜索條件較多,為了得到更好的用戶體驗也加上了清除功能,用來清除表單中已經有的值,方便重新輸入。查詢結果中,查看按鈕對應每條數據的詳情單,可以選擇查看并打印。

調撥與盤點、報損、移庫搜索條件均為相應單號和操作時間,搜索結果以單號分類,點擊單條單跳轉到相應的單詳情頁,所有的詳情單提供導出pdf功能。

在項目中是沒有出現過硬件信息這條的,但是因為從倉庫到讀頭、庫位、門這些都屬于硬件范疇。而且規劃好了之后一般是不會去修改的,所以就把它們統一劃分到硬件范疇,但是功能還是獨立的,也設置了單獨的功能頁面。

人員管理主要針對密碼和郵箱的修改。這是只有超級管理員才有的權限。如果需要添加超級管理員賬號需要聯系我們在數據庫添加,這也保證了一定程度的數據安全。

通過非關系數據庫系統建立分布式云存儲系統,針對在多點多級倉儲管理系統所涉及的復雜應用管理,系統結合RFID技術對物資二維碼標簽進行唯一性的識別,以使系統管理的可靠性、穩定性得到有力的保證。系統綜合考慮倉儲業務多元化發展的需求,探索了在同構系統中將分布式數據庫與云存儲原理結合在倉儲企業的應用,對于異地性、分布式的倉儲企業的大規模物品管理具有一定的借鑒意義,系統也可拓展應用于其他具有分布式需求的企業倉儲管理。下一步將從兩個方面進一步開展研究:(1)在異構系統中對信息查詢訪問、數據庫之間的數據遷移、數據歸并、所定義的數據結構等方面的性能評價還需做進一步的探索與研究;(2)該文只是涉及設計實現分布式倉儲管理系統的關鍵功能,但對各不同倉儲系統的權限、角色、功能等的可擴展性還需進一步研究。