一個簡單的Redis結合Spring MVC架構以及實現過程

爲了加快開發人員對公司項目的理解、更加容易入手和對公司項目的總體把控。

總體框架

首先介紹公司項目的總體框架，閒話少說，直接上圖

 

總體性能分析

這就是公司的一個總體的架構，爲了開發人員對架構的側重點的把控，接下來先分析一下架構的總體性能並暢談一下架構的功能擴展分面。

前臺項目

仍是從前臺項目提及吧。畢竟作這麼多工做，最終的目的是把公司的產品展現給客戶看，給客戶更高的用戶體驗

用了提升前面頁面的讀取速度，因此設計者採用具備「內存數據庫」美譽的Redis數據庫，可是Redis的缺點就在於事務的處理和檢索。所用設計

者又採用了第三方全文檢索來進行彌補。並且這個第三方全文檢索的檢索速度絕對不是MySQL的檢索速度所能比的，至少檢索速度在MySQL

檢索的數千倍甚至上萬倍。

頁面緩存

用戶訪問首先會通過一個頁面緩存OSCache若是緩存中已有該頁面內容，則直接返回內容給用戶，這樣極大的減小了服務器的壓力。建議接手者

儘可能在該塊的擴展，這樣能極大的減小服務器的壓力，並提供很是之高的用戶體驗。

全文檢索&Redis

若是用戶的訪問訪問的內容在OSCache中不存在，也就是訪問穿透了頁面的緩存，這裏首先會走全文檢索去檢索服務條件的內容再從Redis中取出

相應的內容，經過freemarker靜態渲染以後返回給用戶。

發佈項目

該項目具備極大的擴展性，如今主要是作數據資源的同步，後期能夠考慮作靜態頁面的發佈，主要處理運算和IO這一塊的功能，最後若是訪問量

暴增，能夠在這裏作MySQL的主從庫的同步，真正的實現讀寫分離。

技術實現分析

該項目主要採用了線程池的技術，主線程不斷去掃描gt_template這個數據的表，由於公司員工對後臺數據的更新的數據都會被mysql中的觸發器給觸發到gt_template這個表中，gt_template的數據庫的字段以下：

其中的source_id是資源的id，如線路的id或酒店的id，source_type爲資源的類型，

主線程一旦掃描到數據就會根據這個資源的類型從線程池中開闢新的線程並選擇對應的發佈程序進行發佈。

發佈程序會根據source_id也就是資源的id去MySQL數據庫中提取相應的產品，若是產品不存在，則說明該數據被刪除不存在了，爲了減小髒數據

的存在，因此發佈程序也作一次清理的過程，無論該條產品是否在全文檢索Solr和非關係性數據庫Redis中存在，都作一次清理該產品；若是產品

存在，則應該根據產品的當前狀態作及時的處理，若是是發佈狀態則作以下的操做：1、清理髒數據，直接從全文檢索Solr和非關係性數據庫Redis

中把該條產品清理掉；2、把最新的數據更新到全文檢索Solr和非關係性數據庫Redis中。3、從gt_template中刪除該條記錄。

後臺項目

該項目相對比較簡單，主要就是採用Spring MVC模式加上mybatis實現的，相信開發人員對此種架構已是至關的熟悉了，我就不在這裏賣弄了，

省得被扔鞋子、臭雞蛋等。

 

關於架構的性能就寫這麼多了，省得大牛們看得不下去了。因爲本身知識淺薄，就寫到這吧，大牛們輕拍。