專案效能優化經驗 ZY（二）

1. hibernate 級聯問題

專案中，用了很多的lazy級聯，在頁面用到的時候再去load，這樣就使用open session in view的功能，在大併發且網路不好的情況下，會導致session遲遲不能釋放（session要等頁面request請求完全結束之後才close），即connection也沒法釋放。

之前專案都是使用eager，json資料傳遞的方式來處理，整個連線池太小不過100就能頂住1000+的併發下單

建議根據業務詳細區分：

1. 如果是前台需要的資料，直接eager，然後傳遞過去，反之lazy，不要去查了

2.盡量少用open session in view 會在大併發情況下，的確會導致很多問題，比如spring的事物管理（transcational注釋）和session的flush_mode之間，會導致頻繁的修改session的flush_mode，從auto到commit不停的切換

osiv的優缺點，見

2. 關於電商的一些業務建議：

專案中涉及了庫存，搶單，**等操作

庫存，在讀寫分離的情況下，大併發下庫存的讀寫庫同步會有延遲，導致庫存超賣

諮詢了一下**的人，發現即使**也不能完全避免超賣（只不過人家有錢賠）

**的處理：將下單和庫存的扣減分離（不是乙個事物），庫存非同步區扣減，人家機器多，效能好，速度快

本人建議：庫存應該非同步去減

具體：1. 根據庫存的量，來繼續乙個機率（每台tomcat），是否允許使用者區下單，比如庫存就剩10,4臺tomcat，那麼同一秒內，一台tomcat只允許2個請求的發生（根據乙個比率）

2. 然後訂單的提交其實分好幾步，在提交，確認的任何一步都可以去比庫存，然後丟擲

3. 超賣既然不能完全制止，就要減少發生概率，對於真的超賣，要麼協商處理

搶單：現在的電商很喜歡搞一些搶單，秒殺

一定要跟真正的下單流程分離，單獨機器，單獨tomcat，單獨資料庫（最少也要單獨的表），然後直接鎖死

掛了就掛了

**：現在很多電商，都有相關的**

一般分幾種：

1. 單獨商品的**資訊（這些可以綁在商品上）

2. **的策略，應該使用策略模式，或者模板模式，單獨的把**的複雜度分離開來

舉個例子，**可以有類似一號店的19,39,59多選三，可以有洗護類滿100-50，可以有樂事滿100-15，慢多少送什麼贈品等

分品牌，分型別，分**，分總額。。。

簡單的說，可以把商品的各個屬性都單獨拿出來作為策略的主體

應該可以根據屬性來定製策略，然後根據不同的策略來組成一次**，並把商品加入到這次**中

這些都要求，本身作為商品，相關的屬性是多對多的，同時如果簡單的多對多，會導致查詢商品的時候引出很多的級聯查詢，所以必要的冗餘也是必須的