不可否認，單個Redis實例已經(jīng)不能滿足實際生產(chǎn)中的需求了。為了解決由此帶來的問題，何不試試用專用實例代替邏輯數(shù)據(jù)庫呢？

一、邏輯數(shù)據(jù)庫可能已經(jīng)無法滿足需求的4個跡象
1．您有個“吵鬧的鄰居”
PS：“吵鬧的鄰居”指同一個Redis OSS實例中其它繁忙的邏輯數(shù)據(jù)庫。

場景：
假設你是一家游戲公司的開發(fā)人員，使用三個Redis邏輯數(shù)據(jù)庫：一個用于緩存和排行榜，一個用于匹配，一個作為消息代理。你的公司最近發(fā)布了一款非常成功的新游戲，每晚都有匹配請求的訪問高峰期。但是在這個時間段，你的排行榜顯示的數(shù)據(jù)可能不是實時的，并且消息代理的延遲正在增加。
問題的起源：
（1）這很可能是因為，**單個Redis實例，從命令執(zhí)行的角度來看是單線程的，并且按順序為每個請求提供服務。由于邏輯數(shù)據(jù)庫都共享同一實例，所以針對特定邏輯數(shù)據(jù)庫執(zhí)行的操作可能導致此該線程變慢甚至被阻塞，從而影響其他數(shù)據(jù)庫。**如果您有吞吐密集型用例或者您的應用程序使用 O(n) 復雜度的 Redis 命令，這可能會導致性能問題。

（2）在另一種情況下，您可能會遇到錯誤。例如，在微服務環(huán)境中，每個服務都會讀寫專用的邏輯數(shù)據(jù)庫，所有服務的數(shù)據(jù)庫可能會由于某個微服務中的錯誤而同時失效。將多個用例集中在一個 Redis 實例中是不具備容錯能力的。

如果您使用專用實例而不是邏輯數(shù)據(jù)庫會怎樣呢？
使用專用數(shù)據(jù)庫處理每個微服務的請求將為每個服務提供更好的性能，并使您的應用程序更具彈性。

2．您想要擴展規(guī)模
避免“吵鬧鄰居”問題的一種方法是擴展您的數(shù)據(jù)庫。為此，您可以使用Redis OSS Cluster，它允許您在多個節(jié)點上進行數(shù)據(jù)庫集群化。

存在的問題：
然而，這種方式僅支持位于索引0的邏輯數(shù)據(jù)庫，這意味著您只能擴展一個邏輯數(shù)據(jù)庫，這可能會導致您將與更重要的用例相關(guān)的數(shù)據(jù)存儲在同一邏輯空間中，從而否定了保留單獨名稱空間的初衷。

如果您使用專用實例而不是邏輯數(shù)據(jù)庫會怎樣呢？
您可以根據(jù)需要擴展每個數(shù)據(jù)庫，沒有限制。

3．您的用例多樣，需要量身定制的配置
場景：
想象一下您是一家電子商務公司的軟件開發(fā)人員，您使用一個邏輯數(shù)據(jù)庫進行緩存，使用另一個邏輯數(shù)據(jù)庫進行會話管理。您有以下要求：

• 當會話處于活動狀態(tài)時，會話存儲數(shù)據(jù)是唯一的事務數(shù)據(jù)源。因此，需要具備高可用和數(shù)據(jù)持久性以確保事務數(shù)據(jù)不會丟失。
• 如果您的緩存丟失，永久存儲中始終有一份副本。

盡管有這些要求，您的兩個邏輯數(shù)據(jù)庫必須共享相同的高可用性和持久性配置，因為它們都共享相同的redis.conf文件。

對于緩存用例而言，相同的情況也適用于驅(qū)逐策略和內(nèi)存限制，以及TLS證書、密碼，或是Redis OSS的redis.conf文件中的所有配置選項。

如果您使用專用實例而不是邏輯數(shù)據(jù)庫會怎樣呢？
不再需要妥協(xié)，您可以根據(jù)業(yè)務需求配置每個數(shù)據(jù)庫。

4．監(jiān)控和故障排除很痛苦
場景：
因為邏輯數(shù)據(jù)庫共享相同的Redis進程，您可能會發(fā)現(xiàn)監(jiān)控和故障排除變得很繁瑣。

案例1：
monitor命令。它會將Redis服務器處理的每個命令都返回，無論您從哪個邏輯數(shù)據(jù)庫運行它，它都會返回在服務器上運行的所有邏輯數(shù)據(jù)庫的命令，盡管它會顯示每個命令的數(shù)據(jù)庫索引。

案例2：
slowlog命令。在這里，沒有區(qū)分記錄的命令是在哪些邏輯數(shù)據(jù)庫中運行的。例如，為了人為地創(chuàng)建一些執(zhí)行緩慢的命令：

• 我在索引0上運行了兩次debug命令，并在索引1上運行了一次
• 然后我在索引1上運行了slowlog get命令

其他場景：
這同樣適用于日志、延遲子命令，或是您想要 grep 或從 Redis info命令獲取的任何值：連接的客戶端數(shù)量、已用內(nèi)存、當前 IOPS、逐出鍵的數(shù)量等。

其他解決方案：

• 使用第三方工具來監(jiān)視Redis，比如Grafana，您可以在定義Redis數(shù)據(jù)源時指定數(shù)據(jù)庫編號。然而，儀表板中顯示的數(shù)據(jù)不一定是您定義的數(shù)據(jù)庫索引所獨有的。
• 獲取keyspace中正確的鍵數(shù)，但命令統(tǒng)計、客戶端連接和IOPS并不基于所選的索引,這些值是整個Redis實例共享的。

設想一下，盡管閱讀儀表板和日志很復雜，但您發(fā)現(xiàn)緩存邏輯數(shù)據(jù)庫上的延遲來自于您在每次寫入時啟用 AOF，因為您的會話存儲數(shù)據(jù)庫需要它。

除了放寬會話數(shù)據(jù)庫的持久性要求之外，您還能做什么呢？這又回到了邏輯數(shù)據(jù)庫已經(jīng)無法滿足需求的早期跡象：“吵鬧的鄰居”和獨特的配置要求。

如果您使用專用實例而不是邏輯數(shù)據(jù)庫會怎樣呢？
您將更輕松、更快速地監(jiān)控每個數(shù)據(jù)庫的性能并識別問題，從而節(jié)省運維時間和精力。

二、解決方案：邏輯數(shù)據(jù)庫的遷移

• 使用單獨的Redis OSS實例來滿足不同的需求。
• 利用Redis Enterprise 的集群級多租戶能力，解決“吵鬧的鄰居”、容錯和通用配置方面的問題。

無論您選擇哪種選項，都需要將邏輯索引遷移到不同的專用數(shù)據(jù)庫實例中。

您需要怎么做？
由于所有邏輯數(shù)據(jù)庫都保存在同一個RDB文件中，這種遷移的第一步是手動將每個邏輯數(shù)據(jù)庫的數(shù)據(jù)提取到單獨的文件中。這是一個需要重復加載、刷新和重新啟動 Redis 服務器的繁瑣過程。為了省去您的麻煩，使用腳本會自動執(zhí)行該過程。它將數(shù)據(jù)加載到作為子進程啟動的輔助 Redis 服務器中，并使用該服務器為每個邏輯數(shù)據(jù)庫創(chuàng)建一個 RDB 文件：0.rdb、1.rdb 等。

聯(lián)系我們，進一步了解邏輯數(shù)據(jù)庫的遷移。文章來源地址http://www.zghlxwxcb.cn/news/detail-728219.html

到了這里，關(guān)于【虹科干貨】邏輯數(shù)據(jù)庫可能已經(jīng)無法滿足需求了！的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！