背景

目前手上有一個微信優惠券搶購系統，由於在初期限於客戶的工期、使用者規模不夠大、併發量小等情況下，除了搶購、銷售資料利用了 Redis外，其他的均是直連資料庫進行操作。

系統使用的技術：spring boot全家桶、mybatis，spring data jpa、Redis、MySQL等。spring data jpa只用於後臺管理系統，主要是為了和mybatis進行對比，看哪個更利於當前系統的開發工作及維護。

1 商品詳情展示

　　商品這塊的設計，分為商品表、商品版本表。設計目的：

　　　　1）利用版本表達到商品資訊快照目的，避免訂單上存放購買時的商品相關資訊；

　　　　2）因有版本概念，所以每次編輯後，會生成一個未釋出版本，為未來的效能優化留下空間，這也是本次優化的一個地方。

　　優化方案：

　　　　利用版本釋出功能，將MP前端展示的商品詳情資料，快取到Redis中，應對商品詳情的頻繁展示。

　　　　快取過期時間，則設定為商品銷售結束後，因商品一旦銷售結束後，就不是非高頻訪問的商品資料了。

2 首頁輪播商品資訊展示

　　首頁輪播商品展示最新推薦的5條商品資訊，在上一個版本中，也是直接從資料庫讀取。該資料讀取頻繁。

　　優化方案：

　　　　1）使用快取機制，將商品載入到Redis快取中，提升資料載入速度。

　　　　2）快取更新方案，更新方案：

　　　　　　a）Redis加鎖，如果多個請求都檢查到需要更新快取，已優先加鎖的更新請求為準，其餘更新直接忽略，然後直接讀取舊資料進行展示。

　　　　　　b）使用訊息佇列解耦，檢查到需要更新，直接向訊息佇列中put一個更新訊息。然後更新程式消費該訊息，執行快取更新操作。

　　　　　　c）使用job定時檢查快取是否到達更新時間，更新步驟和 a中一樣。

　　　如果用b方案，則需要增加訊息服務例項，所以綜合考慮技術、穩定性和時間成本，使用a方案。

3 商品列表查詢

 　　目前商品列表的查詢，在上一個版本中，也是直接從資料庫讀取。但是商品列表是一個比較頻繁的資料，也需要優化。

　　優化方案：

　　　　1）Redis快取方案。

　　　　2）Elasticsearch方案

　　鑑於方案2涉及到的技術比方案1複雜，本次經過權衡時間及技術成本後，選用方案1。

　　大體方案仍然和 2中的a方案一樣。只是列表快取資料有過期時間，在多個更新請求的檢查到鎖的情況下，暫時考慮使用自旋鎖保證請求能有資料，自旋頻率暫定100ms一次。也可尋找成熟的框架方案來解決該問題。

4 前端展示優化

　　目前頁面渲染使用的框架是thymeleaf，在進行上述改造後，將考慮使用前端框架優化頁面渲染。減少頁面響應白屏時間。