物流系統路由查詢解決方案

我供職的在上家是一家物流公司，我主要從事架構方面的工作，但偶爾也會寫一些跟演算法相關**。專案組曾乙個查詢全路徑的需求，系統現在的方法是迴圈查詢資料庫，迭代出所有資料。但資料量過多，且方法呼叫過於頻繁，給資料庫造成了嚴重的負擔。於是我便用簡單的資料結構加演算法重新實現了。

以下是系統中的資料表：

station（站點表） id

name1上海

2崑山3蘇州

4常州5鎮江

6南京7揚州

8西安9鄭州

站點表用於記錄所有分拔與網點的資訊

route（路徑表）

station

destination_station

next_station

status16

2126

3136

4146

5156

6176

6118

2128

3138

4148

5158

6178

6168

9198

路由資訊的基礎資料表，用於記錄從當前網點（station）前往目前網點（destination_station）的下一網點(next_station)。以及這個路由的啟動狀態（status ,1，啟動，2關閉）

要生成一條完整的路由。為了緩解資料庫壓力，加快查詢速度。決定將原資料庫查詢更換成純演算法實現。

定義資料結構，及其演算法。利用map進行快速查詢。

public
class
station
implements
serializable
else
p.setextra
(extra)
; p.
setdestination
(destination)
; p.
setnext
(next)
; pathmap.
put(destination.
getid()
,p);
path nextpath = next.
getpath
(destination);if
(nextpath==null)
nextpath.
addprevious
(this);
}/**
* 獲聚首當前路是徑
* @param des
* @return
*/public path getpath
(station des)
public
void
detach
(station des)
if(path.
getprevious()
.size()
==0)else
}}

@data
public
class
path
public
void
addprevious
(station station)
}public
void
removeprevious
(station station)
@override
public string tostring()
sb.("]");
return
"path';}
}

pathfinder類主要是用來儲存所有站點的集合，以及提供所有路徑想著的操作（可能我要重新命名），因為業務中要根據網點id查詢網點（或路由資訊），所以用map來儲存網點。路徑資訊可能隨時會出變動，而每段路徑的變動，都會影響到整個路由。所以我在此處用到了讀寫鎖，每段路徑的變動，只會影響到與其相同終點的路徑，我讓每個station都持有乙個讀鎖和寫鎖。在做讀取或更改操作時，我獲取目的節點上的鎖，並對其進行加鎖操作（這種不鎖全部，只鎖部門的思想在longadapter和concurrentmap中都有應用）。

@service
public class pathfinder
reentrantreadwritelock.writelock lock = des.writelock();
lock.lock();
try 
}curt.linkto(des, next, extra);
}finally 
}public list> findroute(station begin,station des)
}}finally 
return list;
}}

原計畫是在程式啟動時，載入整張表資料。但測試之後，2000萬條資料，載入速度很慢，之少要20分鐘之久。

資料全載入保證了使用者訪問時的查詢速度，以及執行緒安全等問題。但增長了系統啟動時間。

懶載入不影響系統啟動時間。但可能會帶來兩個問題：

多執行緒下資料重複載入問題，比如有幾個請求同時請求上海南京的節點，可能造成兩個執行緒同時載入資料。

可能會降低查詢速度，使用者第一次請求查詢某路徑時，因為要從資料庫載入資料，可能會出現延遲。

目前2000個網點，生成的節點數所約500萬條，得用jmap檢視記憶體發現，總共占用記憶體不到1g, 如果以後再增加網點數，可以考慮lru策略進行淘汰，目前我儲存網點用的的是concurrentskiplistmap，如果要實現lru策略，可能要換成hashlinkedmap實現。當然我也可以用資料分片，不管是lru或資料分片，都可以利用目的網點對資料進行分割。這要比傳統的那種尋找最小路徑演算法簡單多了（因為如果是傳統的圖，我想不到什麼好的辦法，對資料進行分割）。因為不想增加複雜性，我只對該服務進行單節點部署（多節點部署要考慮資料一致性問題，而且當前擁有有的伺服器資源也不適做多節點部署），以後如果要做節點部署，可以考慮應用資料一致性演算法，加樂觀鎖機制。

演算法很簡單，應用的技術也不算太複雜，關鍵是選擇合適的方案來解決當前的問題。

物流系統路由查詢解決方案

物流EDI解決方案

SOA電子物流解決方案

教務系統解決方案

物流系統路由查詢解決方案

物流EDI解決方案

SOA電子物流解決方案

教務系統解決方案

相關推薦