本發(fā)明屬于網(wǎng)絡(luò)應(yīng)用開發(fā)領(lǐng)域，尤其涉及一種基于RESTful風(fēng)格的就業(yè)信息推薦系統(tǒng)。

背景技術(shù)：

就業(yè)信息推薦系統(tǒng)是一種計算機密集型的數(shù)據(jù)處理系統(tǒng)?，F(xiàn)有就業(yè)信息推薦系統(tǒng)主要存在以下問題，推薦算法與系統(tǒng)平臺之間具有復(fù)雜的耦合關(guān)系，推薦算法的改變將引起相應(yīng)的系統(tǒng)的重新設(shè)計。在系統(tǒng)數(shù)據(jù)的存儲上，由于數(shù)據(jù)量過大會造成不便，訪問速度會受影響，當(dāng)服務(wù)器重啟時會對交互有影響。另外，系統(tǒng)的負載均衡性能不好，穩(wěn)定性差，且可擴展性低。

技術(shù)實現(xiàn)要素：

本發(fā)明所要解決的技術(shù)問題之一是需要提供一種就業(yè)信息推薦系統(tǒng)以解決現(xiàn)有推薦系統(tǒng)推薦算法與系統(tǒng)平臺之間耦合關(guān)系復(fù)雜、訪問速度受限、系統(tǒng)穩(wěn)定性差的問題。

為了解決上述技術(shù)問題，本申請的實施例提供了一種基于RESTful風(fēng)格的就業(yè)信息推薦系統(tǒng)，包括：網(wǎng)站系統(tǒng)模塊，系統(tǒng)與用戶的接口模塊，接收用戶的輸入數(shù)據(jù)和服務(wù)請求及向用戶反饋查詢與推薦的結(jié)果；所述網(wǎng)站系統(tǒng)模塊進一步包括學(xué)生模塊與企業(yè)模塊，所述學(xué)生模塊用于完成學(xué)生用戶的注冊、登陸、個人引導(dǎo)以及對簡歷、職位、企業(yè)的建立、獲取、更新和刪除操作；所述企業(yè)模塊用于完成企業(yè)用戶的注冊、登陸、企業(yè)引導(dǎo)以及對簡歷、職位、招聘會的建立、獲取、更新和刪除操作；其中，與學(xué)生/企業(yè)用戶相關(guān)的信息均以URI資源的形式存儲，通過對所述URI資源的建立、獲取、更新和刪除操作獲取服務(wù)；個性化推薦模塊，基于與學(xué)生/企業(yè)用戶相關(guān)的信息進行就業(yè)信息的個性化推薦。

優(yōu)選地，所述系統(tǒng)基于瀏覽器/服務(wù)器和客戶端/服務(wù)器混合架構(gòu)搭建，其中，客戶端包括個人計算機瀏覽器和移動設(shè)備客戶端，能夠接收學(xué)生/企業(yè)用戶基于系統(tǒng)的URI資源的動態(tài)請求和靜態(tài)請求，將所述請求發(fā)送至服務(wù)器端以及接收服務(wù)器端的響應(yīng)結(jié)果；服務(wù)器端的Web服務(wù)器采用APACHE與TOMCAT集群的方式搭建，學(xué)生/企業(yè)用戶的靜態(tài)請求被直接存儲于服務(wù)器的靜態(tài)資源目錄中，動態(tài)請求經(jīng)由CXF控制器決定由哪個服務(wù)頁面或業(yè)務(wù)模塊來響應(yīng)該請求；服務(wù)器端的數(shù)據(jù)庫采用MYSQL與MONGODB聯(lián)合搭建，所述MONGODB用于存儲學(xué)生/企業(yè)用戶的認證信息和個性化推薦參數(shù)，所述MYSQL用于存儲學(xué)生/企業(yè)用戶除上述信息以外的其他信息。

優(yōu)選地，所述個性化推薦模塊通過調(diào)用ACTIVEMQ消息隊列服務(wù)器的客戶端接口響應(yīng)學(xué)生用戶的個性化推薦服務(wù)請求。

優(yōu)選地，所述個性化推薦模塊根據(jù)以下步驟響應(yīng)學(xué)生用戶的個性化推薦服務(wù)請求：Web服務(wù)器將學(xué)生用戶輸入的傾向性信息發(fā)送至ACTIVEMQ服務(wù)器的消息隊列中進行存儲；個性化推薦進程根據(jù)系統(tǒng)的時間和隨機數(shù)生成ID號并將所述ID號存儲于MONGODB數(shù)據(jù)庫中；個性化推薦進程監(jiān)聽消息隊列以獲取傾向性信息，根據(jù)所述傾向性信息得到推薦結(jié)果，并建立以所述ID號命名的隊列，將推薦結(jié)果存儲于該隊列中；Web服務(wù)器從MONGODB數(shù)據(jù)庫中查詢所述ID號，并從與所述ID號相匹配的隊列中獲取推薦結(jié)果。

優(yōu)選地，若Web服務(wù)器在設(shè)定的時間內(nèi)從與所述ID號相匹配的隊列中獲取到推薦結(jié)果，則通過頁面渲染顯示推薦結(jié)果，并將所述推薦結(jié)果存儲至MYSQL數(shù)據(jù)庫中；若Web服務(wù)器在設(shè)定的時間內(nèi)未獲取到推薦結(jié)果，則返回空數(shù)組，并通過頁面顯示無推薦項的提示信息。

優(yōu)選地，所述系統(tǒng)采用訪問控制過濾器監(jiān)聽學(xué)生/企業(yè)用戶對該系統(tǒng)的訪問與操作。

優(yōu)選地，當(dāng)學(xué)生/企業(yè)用戶發(fā)出訪問或操作請求時，所述訪問控制過濾器判斷所述請求的類型：若所述請求屬于能夠被放行的類型，則允許學(xué)生/企業(yè)用戶對系統(tǒng)的訪問或操作請求；若所述請求不屬于能夠被放行的類型，則通過所述學(xué)生/企業(yè)用戶的認證信息獲取用戶的類型，并執(zhí)行相匹配的用戶類型權(quán)限驗證與登錄狀態(tài)更新。

優(yōu)選地，所述訪問控制過濾器在執(zhí)行相匹配的用戶類型權(quán)限驗證與登錄狀態(tài)更新時，檢查所述學(xué)生/企業(yè)用戶的請求是否為與用戶登錄有關(guān)的請求，若為與用戶登錄有關(guān)的根路徑請求，則當(dāng)學(xué)生/企業(yè)用戶已經(jīng)處于有效的登錄狀態(tài)中時，響應(yīng)該請求轉(zhuǎn)發(fā)至用戶主頁；當(dāng)學(xué)生/企業(yè)用戶的登錄狀態(tài)已經(jīng)失效時，響應(yīng)該請求轉(zhuǎn)發(fā)至用戶的登錄頁面；若為與用戶登錄無關(guān)的一般業(yè)務(wù)請求，則檢查對應(yīng)用戶類型的登錄狀態(tài)并進行更新。

優(yōu)選地，所述訪問控制過濾器根據(jù)以下步驟檢查對應(yīng)用戶類型的登錄狀態(tài)并進行更新，若該類型用戶的請求時間距離上一次請求時間小于等于第一時間閾值，則放行該請求；若該類型用戶的請求時間距離上一次請求時間大于第一時間閾值且小于等于第二時間閾值，則更新該用戶的登錄時間并放行該請求；若該類型用戶的請求時間距離上一次請求時間大于第二時間閾值，則刪除本次會話并轉(zhuǎn)發(fā)至用戶的登錄頁面。

優(yōu)選地，所述系統(tǒng)在業(yè)務(wù)上劃分為業(yè)務(wù)邏輯層與持久化層，所述業(yè)務(wù)邏輯層、持久化層以及CXF控制器均通過SPRING容器進行管理。

與現(xiàn)有技術(shù)相比，上述方案中的一個或多個實施例可以具有如下優(yōu)點或有益效果：

通過把Web的所有請求建模成對資源的操作，并利用HTTP方法處理服務(wù)請求，使對系統(tǒng)的操作更加簡單靈活，提高系統(tǒng)可擴展性。同時由于采用了基于RESTful風(fēng)格的系統(tǒng)架構(gòu)，把計算機密集型的推薦處理與系統(tǒng)平臺解耦，提高了系統(tǒng)的性能和穩(wěn)定性。

本發(fā)明的其他優(yōu)點、目標(biāo)，和特征在某種程度上將在隨后的說明書中進行闡述，并且在某種程度上，基于對下文的考察研究對本領(lǐng)域技術(shù)人員而言將是顯而易見的，或者可以從本發(fā)明的實踐中得到教導(dǎo)。本發(fā)明的目標(biāo)和其他優(yōu)點可以通過下面的說明書，權(quán)利要求書，以及附圖中所特別指出的結(jié)構(gòu)來實現(xiàn)和獲得。

附圖說明

附圖用來提供對本申請的技術(shù)方案或現(xiàn)有技術(shù)的進一步理解，并且構(gòu)成說明書的一部分。其中，表達本申請實施例的附圖與本申請的實施例一起用于解釋本申請的技術(shù)方案，但并不構(gòu)成對本申請技術(shù)方案的限制。

圖1為根據(jù)本發(fā)明實施例的基于RESTful風(fēng)格的就業(yè)信息推薦系統(tǒng)的功能示意圖；

圖2a和圖2b分別為根據(jù)本發(fā)明實施例的基于RESTful風(fēng)格的就業(yè)信息推薦系統(tǒng)的學(xué)生模塊和企業(yè)模塊的工作流程示意圖；

圖3為根據(jù)本發(fā)明實施例的基于RESTful風(fēng)格的就業(yè)信息推薦系統(tǒng)的系統(tǒng)架構(gòu)示意圖；

圖4為根據(jù)本發(fā)明實施例的基于RESTful風(fēng)格的就業(yè)信息推薦系統(tǒng)的個性化推薦服務(wù)請求的數(shù)據(jù)流向示意圖；

圖5為根據(jù)本發(fā)明實施例的基于RESTful風(fēng)格的就業(yè)信息推薦系統(tǒng)的個性化推薦服務(wù)請求的作業(yè)步驟示意圖；

圖6為根據(jù)本發(fā)明實施例的基于RESTful風(fēng)格的就業(yè)信息推薦系統(tǒng)的訪問控制過濾器的工作流程示意圖。

具體實施方式

以下將結(jié)合附圖及實施例來詳細說明本發(fā)明的實施方式，借此對本發(fā)明如何應(yīng)用技術(shù)手段來解決技術(shù)問題，并達成相應(yīng)技術(shù)效果的實現(xiàn)過程能充分理解并據(jù)以實施。本申請實施例以及實施例中的各個特征，在不相沖突前提下可以相互結(jié)合，所形成的技術(shù)方案均在本發(fā)明的保護范圍之內(nèi)。

本實施例的就業(yè)信息推薦系統(tǒng)主要包括兩個功能模塊，網(wǎng)站系統(tǒng)模塊與個性化推薦模塊。

其中，網(wǎng)站系統(tǒng)模塊是系統(tǒng)與用戶的接口模塊，用于接收用戶的輸入數(shù)據(jù)和服務(wù)請求及向用戶反饋查詢與推薦的結(jié)果。對于用戶來說，其平臺體驗除了擴展的移動終端外，網(wǎng)站模塊是最核心的，很多邏輯的設(shè)計首先是基于網(wǎng)站設(shè)計，個性化推薦的數(shù)據(jù)來源也是來源于網(wǎng)站模塊，推薦結(jié)果也是反饋到網(wǎng)站模塊。網(wǎng)站系統(tǒng)模塊進一步包括學(xué)生模塊與企業(yè)模塊。

學(xué)生模塊用于完成學(xué)生用戶的注冊、登陸、個人引導(dǎo)以及對簡歷、職位、企業(yè)的建立、獲取、更新和刪除操作。具體的，學(xué)生用戶通過該模塊完成如下操作，用戶注冊及登錄，學(xué)生基本信息引導(dǎo)(創(chuàng)建默認簡歷，通過地域+領(lǐng)域進行公司推薦)，查看推薦的職位，收藏推薦的職位，取消收藏，查看收藏的職位，查看投遞的職位，查看推薦的公司，查看關(guān)注的公司，取消關(guān)注，創(chuàng)建簡歷，編輯簡歷，預(yù)覽簡歷，投遞簡歷，查看所有領(lǐng)域，查看關(guān)注的領(lǐng)域，搜索公司，搜索職位。

企業(yè)模塊用于完成企業(yè)用戶的注冊、登陸、企業(yè)引導(dǎo)以及對簡歷、職位、招聘會的建立、獲取、更新和刪除操作。具體的，企業(yè)用戶通過該模塊完成如下操作，用戶注冊及登錄，企業(yè)基本信息引導(dǎo)(上傳營業(yè)執(zhí)照，等待人工審核)，發(fā)布招聘會、發(fā)布職位(校園招聘職位+普通招聘職位)，查看已發(fā)布職位，查看已發(fā)布招聘會，查看職位投遞記錄，查看學(xué)生簡歷。

用戶模塊和企業(yè)模塊的工作流程分別如圖2a和圖2b所示。

個性化推薦模塊主要基于與學(xué)生/企業(yè)用戶相關(guān)的信息進行就業(yè)信息的個性化推薦。該模塊是數(shù)據(jù)分析與處理的特色模塊，其對外提供調(diào)用接口。主要處理用戶信息不足，職位行為不充分時的推薦問題。在推薦系統(tǒng)模塊中，實現(xiàn)的還有推薦過濾，與推薦反饋。推薦過濾主要是處理重復(fù)被推薦的職位，削弱馬太效應(yīng)；推薦反饋則是為了改善推薦引擎的結(jié)果而設(shè)計。本模塊的數(shù)據(jù)來自于數(shù)據(jù)采集接口格式化或者過濾的數(shù)據(jù)。

本實施例的功能框圖如圖1所示，網(wǎng)站系統(tǒng)模塊主要負責(zé)收集數(shù)據(jù)，比如用戶信息，用戶日志，用戶行為等，為原生數(shù)據(jù)。網(wǎng)站系統(tǒng)模塊也會輸出從數(shù)據(jù)分析與處理得到的結(jié)果。個性化推薦模塊根據(jù)推薦請求生成推薦結(jié)果，并將推薦結(jié)果返回給網(wǎng)站系統(tǒng)模塊展示。

進一步地，在本實施例中，與學(xué)生/企業(yè)用戶相關(guān)的信息均以URI資源的形式存儲，通過對URI資源的建立、獲取、更新和刪除操作獲取服務(wù)。

RESTful架構(gòu)風(fēng)格是以資源為中心的，其在網(wǎng)絡(luò)開發(fā)應(yīng)用中可以大大降低開發(fā)的復(fù)雜性。RESTful架構(gòu)風(fēng)格強調(diào)所有的操作是無狀態(tài)的，即沒有上下文的約束，如果做分布式，集群將不需要考慮上下文和會話保持的問題，極大的提高了系統(tǒng)的可伸縮性。使用RESTful風(fēng)格主要考慮資源本身的抽象和識別，如果操作對象本身類似增刪改查的操作，那么抽象成資源就比較容易。在本發(fā)明中，對簡歷、職位、招聘會等的操作，就是基本的增刪改查，抽象成資源是很容易的。

表1給出了根據(jù)本發(fā)明實施例的URI資源的一些示例。本發(fā)明實施例的推薦系統(tǒng)的URI體系結(jié)構(gòu)在整體上是一個樹形結(jié)構(gòu)，Icareer作為根，分出student和enterprise兩個分支，在student下面又大致分為個人引導(dǎo)、簡歷操作、企業(yè)信息操作、職位和企業(yè)搜索操作、主頁操作(包括職位相關(guān)操作)。在enterprise下面大致分為企業(yè)引導(dǎo)、企業(yè)信息操作、招聘會操作、職位操作、簡歷操作等。

另外，每個URI都對應(yīng)一個處理方法，以讀取操作(GET)為例：

表1系統(tǒng)URI資源舉例

本發(fā)明實施例的就業(yè)信息推薦系統(tǒng)是一種類Web Service的平臺，能夠讓系統(tǒng)被更多的系統(tǒng)利用，采用RESful風(fēng)格在功能上提供Web Service的的接口功能，從而衍生出HTTP協(xié)議，操作更加簡單靈活，提高系統(tǒng)可擴展性。

在本發(fā)明的實施例中，把Web的所有請求建模成對資源的操作，利用HTTP原生的get、post、put和delete等方法處理要求，可以為任何支持HTTP協(xié)議的系統(tǒng)包括移動端提供完美的數(shù)據(jù)接口服務(wù)。

進一步地，本發(fā)明實施例的就業(yè)信息推薦系統(tǒng)基于瀏覽器/服務(wù)器和客戶端/服務(wù)器混合架構(gòu)搭建，具體如圖3所示。

客戶端包括個人計算機(PC機)瀏覽器與手機等移動設(shè)備客戶端，能夠接收學(xué)生/企業(yè)用戶基于系統(tǒng)的URI資源的動態(tài)請求(例如jsp、servlet等)和靜態(tài)請求(例如js、css、php、jpg、png、gif、html、htm、json等)，并將動態(tài)請求和靜態(tài)請求發(fā)送至服務(wù)器端以及接收服務(wù)器端的響應(yīng)結(jié)果。

服務(wù)器端的Web服務(wù)器采用APACHE與TOMCAT集群的方式搭建，學(xué)生/企業(yè)用戶的靜態(tài)請求被直接存儲于服務(wù)器的靜態(tài)資源目錄中，動態(tài)請求經(jīng)由CXF控制器決定由哪個服務(wù)頁面或業(yè)務(wù)模塊來響應(yīng)該請求。

CXF控制器是一個RESTful風(fēng)格的控制器，其功能類似于MVC模式中的Controller，它將決定由哪個業(yè)務(wù)方法來響應(yīng)對應(yīng)請求，然后把響應(yīng)結(jié)果以json或xml的格式返回去，客戶端拿到返回的json或xml格式的數(shù)據(jù)，通過AJAX對頁面進行渲染，實現(xiàn)局部刷新、避免閃屏，達到良好的用戶體驗，CXF控制器也可以控制由哪個視圖來響應(yīng)請求(頁面跳轉(zhuǎn)的控制)。

TOMCAT是Servlet和JSP的容器，隨著TOMCAT的版本升級，它已經(jīng)具有獨立承擔(dān)Web服務(wù)器的能力，但在對靜態(tài)資源(如HTML或圖片等)的處理速度，以及提供對Web服務(wù)器的管理功能方面還是不如專業(yè)的HTTP服務(wù)器，如APACHE。所以在本實施例中，把TOMCAT服務(wù)器和APACHE服務(wù)器集成起來，APACHE服務(wù)器不支持Servlet和JSP，它只負責(zé)處理靜態(tài)資源，動態(tài)資源交給TOMCAT應(yīng)用服務(wù)器來處理。

當(dāng)TOMCAT服務(wù)器與APACHE服務(wù)器集成時，TOMCAT服務(wù)器是進程外的Servlet容器，TOMCAT服務(wù)器和APACHE服務(wù)器之間的通信是通過專門的插件來完成的。TOMCAT通過Connector連接器與客戶機程序建立連接，Connector組件負責(zé)接收客戶端請求并且把服務(wù)器端響應(yīng)返回給客戶端。

連接器在TOMCAT的server.xml中配置。第一個連接器監(jiān)聽8080端口，瀏覽器通過HTTP協(xié)議訪問TOMCAT服務(wù)器的Web應(yīng)用。第二個連接器監(jiān)聽8009端口，通過AJP協(xié)議和其它HTTP服務(wù)器建立連接。

TOMCAT提供了JK插件負責(zé)與APACHE服務(wù)器通信，應(yīng)該把JK插件安置在APACHE服務(wù)器上，當(dāng)APACHE服務(wù)器收到請求時，它會通過JK插件來過濾URL，JK插件根據(jù)URL映射決定把哪些請求轉(zhuǎn)發(fā)給TOMCAT服務(wù)器來處理。AJP協(xié)議是為TOMCAT與APACHE服務(wù)器通信而制定的協(xié)議，能提供較高的通信速度和效率。

通過采用APACHE與TOMCAT集群的方式搭建系統(tǒng)架構(gòu)，可以充分利用兩者的處理優(yōu)勢，實現(xiàn)負載均衡。

在本發(fā)明實施例的就業(yè)信息推薦系統(tǒng)的實現(xiàn)架構(gòu)中，服務(wù)器端的數(shù)據(jù)庫采用MYSQL與MONGODB聯(lián)合搭建，其中，MONGODB數(shù)據(jù)庫用于存儲學(xué)生/企業(yè)用戶的認證信息和個性化推薦參數(shù)，MYSQL數(shù)據(jù)庫用于存儲學(xué)生/企業(yè)用戶除上述信息以外的其他信息。

MONGODB數(shù)據(jù)庫是非關(guān)系型數(shù)據(jù)庫，相比于關(guān)系型數(shù)據(jù)庫MYSQL更適合做分布式集群。采用MONGODB主要是為了存儲用戶的認證信息和個性化推薦參數(shù)，例如用戶ID，會話ID，用戶類型，訪問時間以及學(xué)生的引導(dǎo)信息。因為RESTful風(fēng)格的API對安全問題目前仍顯得無可奈何，把用戶認證信息存儲在客戶端很不安全，保存在服務(wù)器內(nèi)存中，又違反了RESTful約束。所以為了能夠?qū)崿F(xiàn)負載均衡和故障轉(zhuǎn)移，在本發(fā)明的實施例中，采用適合做分布式的MONGODB數(shù)據(jù)庫，把用戶IDuserid和用戶會話記錄sessionid保存在分布式數(shù)據(jù)庫中。對MONGODB數(shù)據(jù)庫的操作通過調(diào)用模板類MongoTemplate(類似于JdbcTemplate)進行。

在本發(fā)明的實施例中，由于采用了非相關(guān)數(shù)據(jù)庫MONGODB進行數(shù)據(jù)的存儲，操作更加靈活。MONGODB的安裝使用簡便，而且MONGODB是內(nèi)存數(shù)據(jù)庫，存儲性能非常強大，在讀取速度上有很不錯的優(yōu)勢。系統(tǒng)把推薦記錄和用戶會話記錄session存儲在MONGODB數(shù)據(jù)庫中，訪問非?？?，這樣系統(tǒng)平臺服務(wù)端就不會保存用戶會話狀態(tài)和推薦狀態(tài)，服務(wù)端重啟可以說對用戶沒有任何影響，所以系統(tǒng)平臺非常有利于做成具有負載均衡性質(zhì)的分布式系統(tǒng)，甚至做成云平臺。

進一步如圖3所示，本發(fā)明實施例的就業(yè)信息推薦系統(tǒng)在業(yè)務(wù)上劃分為業(yè)務(wù)邏輯層與持久化層，可以實現(xiàn)良好的業(yè)務(wù)封裝。持久化層主要調(diào)用了Hibernate框架，該框架可以適配各種關(guān)系型數(shù)據(jù)庫，包括主流的MYSQL和Oracle，而且它對數(shù)據(jù)庫操作的封裝和優(yōu)化做得很全面。

業(yè)務(wù)邏輯層、持久化層以及CXF控制器均通過SPRING容器進行管理。有利于減少層與層之間的耦合性，提高開發(fā)效率。

學(xué)生用戶利用本實施例的推薦系統(tǒng)進行個人信息引導(dǎo)時，通過填寫期望的工作地域和工作領(lǐng)域，能夠獲取系統(tǒng)為其推薦的符合這些條件的公司。本發(fā)明實施例的個性化推薦模塊通過調(diào)用ACTIVEMQ消息隊列服務(wù)器的客戶端接口響應(yīng)學(xué)生用戶的個性化推薦服務(wù)請求。

ACTIVEMQ服務(wù)器是消息隊列服務(wù)器，它很好的實現(xiàn)了AMQP(高級消息隊列協(xié)議)來進行異步消息處理。ACTIVEMQ服務(wù)器響應(yīng)學(xué)生用戶的個性化推薦服務(wù)請求的數(shù)據(jù)流向示意圖如圖4所示，其作業(yè)步驟如圖5所示，具體包括：

步驟S510、Web服務(wù)器將學(xué)生用戶輸入的傾向性信息發(fā)送至ACTIVEMQ服務(wù)器的消息隊列中進行存儲。

步驟S520、個性化推薦進程根據(jù)系統(tǒng)的時間和隨機數(shù)生成ID號并將ID號存儲于MONGODB數(shù)據(jù)庫中。

步驟S530、個性化推薦進程監(jiān)聽消息隊列以獲取傾向性信息，根據(jù)傾向性信息得到推薦結(jié)果，并建立以ID號命名的隊列，將推薦結(jié)果存儲于該隊列中。

步驟S540、Web服務(wù)器從MONGODB數(shù)據(jù)庫中查詢ID號，并從與ID號相匹配的隊列中獲取推薦結(jié)果。

舉例而言，學(xué)生用戶在個人引導(dǎo)過程中，通過發(fā)送端接口把期望地域和期望領(lǐng)域以json格式({"address":"河北石家莊河北秦皇島廣東廣州","industry":"服務(wù)業(yè)科技產(chǎn)品"})發(fā)送到ACTIVEMQ服務(wù)器的消息隊列COMPANY.DEFAULT4中，并根據(jù)系統(tǒng)當(dāng)前時間及隨機數(shù)產(chǎn)生一個ID號(如1396252479545-752762703，這個ID號將會成為另一個隊列的名稱)。發(fā)送的過程中會即時返回這個ID的值，它將被保存在MONGODB數(shù)據(jù)庫中。

消息消費者的異步處理過程是，消費者通過監(jiān)聽消息隊列COMPANY.DEFAULT，拿到要處理的數(shù)據(jù)(地域+領(lǐng)域)，調(diào)用推薦算法得到推薦出的公司(json數(shù)組形式)，然后新建一個以上述得到的ID號為名稱的隊列，向該隊列發(fā)送推薦公司的處理結(jié)果。最后學(xué)生用戶從MONGODB數(shù)據(jù)庫中拿到對應(yīng)自己的推薦公司的ID號，通過ID去名稱相匹配的隊列下拿處理結(jié)果。

若Web服務(wù)器在設(shè)定的時間內(nèi)從與該ID號相匹配的隊列中獲取到推薦結(jié)果，則通過頁面渲染顯示推薦結(jié)果，并將推薦結(jié)果存儲至MYSQL數(shù)據(jù)庫中。若Web服務(wù)器在設(shè)定的時間內(nèi)未獲取到推薦結(jié)果，則返回空數(shù)組，并通過頁面顯示無推薦項的提示信息。例如將設(shè)定的時間設(shè)置為2s用來給消費者計算。如果2s內(nèi)獲得處理結(jié)果(如{"company":[{"id":"4871","name":"廣州數(shù)建信息科技有限公司"},…,{}]})，則會在頁面渲染出相應(yīng)的公司，超過2s則按計算超時處理，返回空數(shù)組。

需要注意的是，本發(fā)明實施例中的消息生產(chǎn)者和消費者構(gòu)建在java項目中，該項目依賴java語言編寫的ACTIVEMQ依賴包，這個java項目被封裝成jar文件形式，加入到了該系統(tǒng)(Icareer項目)的maven依賴庫中，啟動Icareer項目的同時要通過main函數(shù)的方式啟動公司個性化推薦模塊，啟動以后，消息消費者會通過監(jiān)聽的模式等待要處理的消息，消息來源于學(xué)生用戶個人引導(dǎo)的過程中。

在本發(fā)明實施例中，通過基于RESTful風(fēng)格的處理，把計算機密集型的推薦處理與系統(tǒng)平臺解耦，提高了系統(tǒng)的性能和穩(wěn)定性。把算法做成可熱插拔式的中間件，這樣不僅有利于系統(tǒng)的獨立完善也有利于算法的完善甚至更替。

另外，系統(tǒng)和算法引擎通過異步消息隊列鏈接，所以系統(tǒng)平臺和算法引擎可以獨立部署在不同的服務(wù)器上，算法的密集型計算所消耗的資源不會影響系統(tǒng)平臺的穩(wěn)定性。

RESTful風(fēng)格的API在安全性設(shè)計上還不夠完善，在對資源進行簡單的增刪改查操作時，它是簡單靈活的，但是在對訪問控制的限制上還有所欠缺，CXF框架也沒有給出完善的訪問控制的實現(xiàn)方案。為增加系統(tǒng)的安全性和穩(wěn)定性，本發(fā)明實施例的就業(yè)信息推薦系統(tǒng)采用訪問控制過濾器監(jiān)聽學(xué)生/企業(yè)用戶對該系統(tǒng)的訪問與操作。

基于推薦系統(tǒng)的所有的請求都要經(jīng)過訪問控制過濾器，訪問控制過濾器的驗證規(guī)則為：當(dāng)學(xué)生/企業(yè)用戶發(fā)出訪問或操作請求時，訪問控制過濾器首先判斷請求的類型。若請求屬于能夠被放行的類型，則允許學(xué)生/企業(yè)用戶對系統(tǒng)的訪問或操作請求。若請求不屬于能夠被放行的類型，則通過學(xué)生/企業(yè)用戶的認證信息獲取用戶的類型，并執(zhí)行相匹配的用戶類型權(quán)限驗證與登錄狀態(tài)更新。

進一步地，在權(quán)限驗證和狀態(tài)更新的過程中，首先要檢查請求是否是根路徑(如Icareer或Icareer/)，如果是根路徑分兩種情況，第一種情況是用戶已經(jīng)處于有效的登錄狀態(tài)中，這種情況屬于自動登錄，直接轉(zhuǎn)發(fā)到用戶主頁；第二種情況是用戶登錄狀態(tài)已經(jīng)失效，轉(zhuǎn)發(fā)到登錄頁面。如果不是根路徑而是一般的業(yè)務(wù)請求，檢查對應(yīng)用戶類型的登錄狀態(tài)并進行更新。

檢查對應(yīng)用戶類型的登錄狀態(tài)并進行更新的規(guī)則為，若該類型用戶的請求時間距離上一次請求時間小于等于第一時間閾值，則放行該請求。若該類型用戶的請求時間距離上一次請求時間大于第一時間閾值且小于等于第二時間閾值，則更新該用戶的登錄時間并放行該請求。若該類型用戶的請求時間距離上一次請求時間大于第二時間閾值，則刪除本次會話并轉(zhuǎn)發(fā)至用戶的登錄頁面。

舉例而言，如果該類型用戶的請求時間距離上次請求時間小于等于5分鐘，放行請求。如果該類型用戶的請求時間距離上次請求時間大于5分鐘并且小于等于30分鐘，更新該用戶的登錄時間并放行請求。如果該類型用戶的請求時間距離上次請求時間大于30分鐘，直接刪除該會話，轉(zhuǎn)發(fā)到登陸頁面重新登陸。

上述訪問控制過濾器的完整的工作流程如圖6所示。

在本發(fā)明的實施例中，由于客戶端不會保留用戶的會話狀態(tài)，這樣對系統(tǒng)的安全性有了很大的保證，服務(wù)端的無狀態(tài)性和客戶端的無狀態(tài)性同時得到了滿足。

本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。

雖然本發(fā)明所揭露的實施方式如上，但所述的內(nèi)容只是為了便于理解本發(fā)明而采用的實施方式，并非用以限定本發(fā)明。任何本發(fā)明所屬技術(shù)領(lǐng)域內(nèi)的技術(shù)人員，在不脫離本發(fā)明所揭露的精神和范圍的前提下，可以在實施的形式上及細節(jié)上作任何的修改與變化，但本發(fā)明的專利保護范圍，仍須以所附的權(quán)利要求書所界定的范圍為準。