SQL 資料庫滿載，Redis 力挽狂瀾

• 2019 年 12 月 25 日
• 筆記

為什麼你的 ERP/MES/CRM/HR/OA 系統訪問首頁都很慢，明明你確定打開頁面時沒有大量的寫入操作！

或許是時候了解下快取了。

一次實戰：在 SQL Server 前加層 Redis

步驟：

1 - Python 中啟動 5000 根執行緒同時訪問 SQL Server, 執行存儲過程，並記錄每次請求響應時間和 Windows Server 的伺服器狀態；

2 - 安裝 Redis, 並將步驟 1 中需要的數據載入到 Redis ；

3 - Python 中啟動 5000 根執行緒同時訪問 Redis 取數, 記錄每次請求響應時間與 Windows Server 伺服器以及 Redis 主機 CentOS 的伺服器狀態

直聯 SQL Server 時，5000 並發下的伺服器狀態：

注意：一個方格子為 10%. 這裡大約維持在 30% 的 CPU 使用率

直聯 SQL Server 時，5000 並發下的響應時間：

直聯 Redis 時，5000 並發下的伺服器狀態：

注意：Windows Server 的 CPU 使用率一直維持在了 10% 不到的基準線上。而 CentOS 除了網路使用率高之外，CPU, 記憶體其實都穩定。

直聯 Redis 時，5000 並發下的響應時間：

相較之前直聯 SQL Server ，在響應時間上並沒有優勢也沒有落後。

快取本質

分清楚 cache 和 buffer 很重要！

電商系統中所有的商品，加在一起將達到非常長的一份列表。購物頁面被打開的瞬間，顧客肯定希望商品列表分門別類的展示在眼前，而不是延遲 2,3 秒才逐個展現出來。因此在快取伺服器中，預先將資料庫中百萬甚至千萬商品讀取出來，然後分發給離顧客城市最近的二級快取伺服器上，便可給顧客一種快速從本地數據拉取商品列表的錯覺。這一過程，可以稱之為 cache.

顧客接著會挑選自己的商品下單。在挑選的過程中，先後會將挑好的商品存入快取，這層快取應當叫做 Buffer，而這份 Buffer 通常叫做購物車快取。傳統設計上將存入資料庫的顧客購物列表，現在放到了 Redis 快取中，大大減少了與資料庫的交互，提高了速度。為什麼不要直接與資料庫交互的原因，顧客的購物車不一定最後會成單，有可能顧客只是收藏，也有可能最後一刻反悔不買了。

用好快取

快取適用場景 - 寫少讀多

在大多數小規模應用中，採用一對一模式的快取加資料庫模式便足以滿足系統反應速度。過多過早的採用複雜的快取架構只能帶來負擔。很多數據寫入快取就失效，還沒被請求訪問。從適用角度來考慮，類似新浪微博大 V 的言論，做好快取設計就顯得十分有價值。寫一次就有數千萬次訪問，這類快取對系統來講就有意義的多。

快取適用場景 - 熱點數據

在購物場景中，熱點數據可以有：最受歡迎的商品，團購以及禮券等。而非熱點數據可以是：訂單歷史，用戶評論等。快取通常是用記憶體資源做數據存儲，而記憶體價格相比硬碟價格要貴很多，不分輕重把所有數據都放入記憶體，肯定加大硬體的成本。所以分清楚系統的熱點數據是哪一塊，再抽取這塊數據到快取伺服器記憶體中這一策略，肯定是在最佳。稍稍要記一筆的是，如何判斷熱點數據，以及非熱點數據如何做請退處理。