架構
此處架構圖，後續有時間補上
方案設計要點
一、流量分發
Nginx : 分發層 + 應用層 流量分發策略
OpenResty + nginx + lua
二、多級緩存 + nginx本地渲染
Nginx 本地緩存 + Redis 緩存 + Tomcat堆緩存
三、時效性數據
-
針對庫存此類時效性要求高的數據，採用 緩存+數據庫 雙寫方案，實時更新緩存數據
緩存+數據庫雙寫 容易發生數據不一致問題，可採用內存隊列來保證數據一致
-
商品概覽數據時效性要求低，採用 商品服務+消息對列 異步更新緩存數據
分佈式緩存重建併發衝突：流量分發hash策略、消息隊列kafa策略不一致，數據變更的消息所到的緩存服務實例，跟我們的應用層nginx分發到的那個緩存服務實例也許就不在一臺機器上，可採用zookeeper分佈式鎖解決
四、緩存預熱
- 新系統第一次上線，此時在緩存裏可能是沒有數據的，來了大量的請求，命中到數據庫
- 系統在線上穩定運行着，但是突然間重要的redis緩存全盤崩潰了
方案：
- nginx+lua將訪問流量上報到kafka中
- storm從kafka中消費數據，實時統計出每個商品的訪問次數，訪問次數基於LRU內存數據結構的存儲方案
- 守護線程，每隔一段時間，比如1分鐘，都將排名前3的熱數據list，同步到zk中去
- 緩存服務，基於zk分佈式鎖，讀取熱點數據，更新到緩存
五、瞬間熱點/秒殺
- 在storm中，實時的計算出瞬間出現的熱點
- storm這裏，會直接發送http請求到nginx上，nginx上用lua腳本去處理這個請求
- storm會將熱點本身對應的productId，發送到流量分發的nginx上面去，放在本地緩存中
- storm會將熱點對應的完整的緩存數據，發送到所有的應用nginx服務器上去，直接放在本地緩存中
- 流量分發nginx的分發策略降級
- storm還需要保存下來上次識別出來的熱點list，diff差異，進行熱點取消