關於寫操作，想了半天感覺和讀操作差不多，那麼這裏就模擬一下秒殺的情景，看下500的數量，搶購時訂單多久搶完，排隊的情景。
測試場景：請求進來以後進行redis鑑權，查詢商品是否存在（數據庫百萬級），獲取用戶詳細信息，落單減庫存（百萬級），訂單入庫，增加銷量（百萬級）。
在之前配置下，redis記錄商品信息，不參與讀寫操作：
還沒有售罄的狀態下：
售罄以後：
對於連續讀寫操作時，性能。。。
引入rocketmq+redis（應用等待mq返回後才返回）：
還有庫存的時候
而且從數據庫和redis顯示，二者差了1000多個。
沒有返回值的時候：
二者差別不大，至於秒殺令牌令牌桶之類的限流這裏就不測了。
總的來說對於寫操作來說，由於必須和數據庫產生交互，性能損耗是不可避免的，我們只能儘量通過中間件用異步的形式把這些損失轉化到後面，當然對於用戶體驗來說還是要看實際場景。
接下來會通過擴展數據庫和redis主從結構進行優化