填坑利器？Redis如何彌補傳統MySQL架構的不足

對於技術人來說，Redis最成功的一點就是可以補充和擴充套件生態系統中的其他資料庫。雖然使用新的後端資料庫來替換舊的後端資料庫，往往會被認為風險巨大、價格昂貴，但是原有的資料庫可能很難進行線性擴充套件以滿足使用者需求。

傳統MySQL架構難以滿足的現代應用程式需求包括：

1. 傳統資料庫的讀/寫速度對會話儲存等用例不友好;

2. 引入新表或修改現有模式非常複雜，這也導致了新增新功能和應用程式會有困難;

3. 傳統資料庫會受到每秒可執行操作的數量和併發連線數的限制，所以在資料庫例項增多的情況下，基礎架構和維護成本也會增加。

Redis和傳統資料庫結合會產生哪些化學反應呢?首先，如果應用程式的資料是儲存在MySQL或其它關係型資料庫中，那麼Redis可以作為前端資料庫處於應用程式和MySQL之間;其次，還可以利用Redis來設計旁路讀出式和寫通式快取解決方案、會話儲存和速率限制器，這樣可以提高效能、加速創新，以更少的資源擴充套件來獲得最佳的使用者體驗。

Redis作為“參與型系統”

Redis記憶體中鍵值資料儲存可為使用者提供低延遲響應，其內建的資料結構(例如Lists、Hashes、 Sets、Sorted Sets、Bitmaps、Hyperloglog和Geospatial Indices)，較於關係型資料庫能夠更有效地執行某些資料操作。

所以，我們建議在資料訪問層後使用Redis作為“參與型系統”來儲存熱資料，同時將MySQL指定為“記錄系統”。

另外，Redis如果應用於以下用例，那麼就可以規避掉很多可能在原有應用程式、資料庫或網路層中出現的瓶頸：

• 快取：為記憶體訪問提供一個分層模型，Redis中儲存應用程式中常用、重複讀取的資料。快取也可幫助應用程式快速檢索資料並限制資料庫伺服器上的負載。

• 會話儲存：在所有互動式應用程式中，伺服器為每個活動使用者維護一個唯一會話。相比於依賴MySQL等關係型資料庫來持久化會話資料，Redis在具有足夠RAM大小的伺服器上，單個叢集就可以管理數千個會話。

• 實時分析：透過排行榜、儀表板、民意測驗、訊息、計數器和其他實時聚合器進行的遊戲或操作需要與終端使用者進行持續的互動和通訊。而Redis強大、高效的資料結構可以收集和處理數百萬個同時進行的活動或物件，並將其傳送到活動使用者手中。

• 度量：Redis可以透過速率限制應用程式在一定時間內的呼叫次數，幫助開發人員在高峰使用時間內高效地管理傳統伺服器上的負載。

當然，除了上面的用例，Redis在訊息代理、資料結構儲存和臨時資料儲存等用例中表現也很突出。總結一下就是Redis能更快地收集和獲取資料並反饋給終端使用者。再進一步的話，Redis Enterprise提供高可用性、記憶體複製、自動伸縮和重新分片，以及基於前沿CRDT的分散式資料庫和內建Redis模組(如RediSearch、ReJSON、Rebloom和Redis Graph)。

藉助於Redis，我們在傳統解決方案中也可以享受到“即時體驗”，其在效能、靈活性和可擴充套件性方面的優勢值得我們嘗試!