"已知的東西； 有些事情我們知道我們知道。 我們也知道有未知的事物。 就是說我們知道有些事情我們不知道。 但是，還有未知的未知數(shù)-我們不知道的我們不知道的……后一類往往是困難的。"

唐納德·拉姆斯菲爾德

> Redis Wikipedia Page Logo

我與Redis在一起已經(jīng)有好幾年了，從來沒有真正遇到過任何問題。 我已經(jīng)使用Redis計劃和部署了大規(guī)模的Web服務(wù)，并使用了數(shù)十億條日常讀寫命令(使用可上下伸縮的主從復(fù)制)，并且可以"正常工作"。 從開發(fā)人員的角度來看，這導(dǎo)致了我一個錯誤的假設(shè)，即我了解關(guān)于Redis所需的全部知識(而且，正如一位偉大的詩人所說，假設(shè)是所有問題的源頭)。

當(dāng)然，我不是DevOps工程師，也不知道Redis的所有細(xì)節(jié)(但我仍然不知道)，但是我覺得使用Redis被"發(fā)現(xiàn)"了。 其他服務(wù)(例如MySQL)迫使我對它們的概念有扎實的了解，以便編寫快速高效的代碼(再次，無需像DBA一樣掌握MySQL，但至少您需要了解索引或JOIN才能快速編寫代碼 和高效的查詢)。 但是使用Redis，我可以將其"即插即用"到我的代碼中。

幾周前，我被分配來解決在我們的一項舊服務(wù)中從Redis提取數(shù)據(jù)時的性能問題。 該服務(wù)的業(yè)務(wù)邏輯并不那么重要，但是對該服務(wù)的工作方式以及Redis的使用方式的總體概述將有助于我們理解問題所在以及最終如何解決。

我們擁有一個大型系統(tǒng)，可以存儲由不同實體產(chǎn)生的數(shù)十億每日事件。 查詢實體事件可能很慢，并且在許多情況下是多余的，因為我們不需要所有數(shù)據(jù)。 這就是我們提供服務(wù)的地方-它提供了一個API，可以快速查詢最近30天的實體唯一事件。

例如，假設(shè)有一個系統(tǒng)監(jiān)視著帶有傳感器的空調(diào)，該傳感器在每次AC狀態(tài)發(fā)生變化(打開/關(guān)閉會更改AC狀態(tài)以及改變溫度)時發(fā)送事件。 一個AC狀態(tài)每天可能會更改很多次，并且我們的系統(tǒng)將為每次更改存儲一個事件，但是我們的服務(wù)僅會為過去30天內(nèi)所做的每個更改返回一個事件(無論AC被翻轉(zhuǎn)了多少次) ，我們的服務(wù)將返回單個"打開"事件)。

Redis快速，支持?jǐn)?shù)據(jù)過期(我們只需要最近30天的事件，還記得嗎？)，并且具有Set數(shù)據(jù)結(jié)構(gòu)，是我們服務(wù)的理想存儲：將同一項目多次添加到Set中將導(dǎo)致只有一個副本 此商品在套裝中。 可以將存儲在我們系統(tǒng)中的每個實體(AC)的數(shù)百萬個不同事件轉(zhuǎn)換為幾十個唯一項(事件)的小集合。 我們的服務(wù)僅需要"偵聽"傳入的事件，并使用AC ID和日期作為鍵將它們存儲到Redis中，并將到期時間設(shè)置為30天。 當(dāng)查詢AC事件時，我們的服務(wù)將計算所有此AC密鑰并返回存儲在這些密鑰中的所有事件的并集。

Redis中存儲的數(shù)據(jù)的一覽視圖如下所示：

: #{on, off, 24°, 28° ...}, expires 2019-10-30
: #{on, off, 25°, 27° ...}, expires 2019-10-29
: #{on, 26°, humidity 32° ...}, expires 2019-10-28
...
...
...
: #{off, humidity 35° ...}, expires 2019-10-01
: #{on, off, 23°, 27° ...}, expires 2019-10-30
: #{on, off, 25°, 28° ...}, expires 2019-10-29
...
...
...
: #{24°, 26°, humidity 42° ...}, expires 2019-10-01
: #{on, off, 23°, 27° ...}, expires 2019-10-30
...
...
...

密鑰是具有事件收集日期的實體的ID。 ac1-2019-09-30代表id = ac1的實體，其值是該日期收集的一組事件。 該密鑰將于2019–10–30到期。

在Redis內(nèi)部，我們的服務(wù)使用SUNION命令來獲取特定實體在不同日期存儲的所有事件的聯(lián)合集：

SUNION
...
...

這個簡單的邏輯可以處理99.6％的查詢。 但是，有時從Redis獲取數(shù)據(jù)花費(fèi)的時間很長(在某些情況下可能需要30秒)，這在產(chǎn)品上并不被接受。

我已經(jīng)開始解決因搜索通用規(guī)則而導(dǎo)致的響應(yīng)緩慢的問題，這并不奇怪，這通常發(fā)生在SUNION處理大型Set時(也并非總是如此)。 Redis中存儲的大多數(shù)Set(基本代表元素數(shù))的基數(shù)小于100。 但是對于少量的Set，大小可能會很大。 如您在下表中所見，有85％的組合有0–50個項目，少于0.5％的組合有1,000個或更多項目)

我在閱讀服務(wù)代碼時注意到的另一件事是，為了避免產(chǎn)生較大的響應(yīng)負(fù)載，無論對服務(wù)進(jìn)行編碼的是誰，都對API返回的事件數(shù)量進(jìn)行了限制(我們將在后面看到為什么這與 解決方案)。

了解我對Redis的了解后，使用SUNION命令似乎是一個合理的解決方案。 如果我是首先編寫此服務(wù)的人，那么我可能會做同樣的事情。 但是，您不知道的內(nèi)容有時會造成很多痛苦……谷歌搜索很快發(fā)現(xiàn)了兩個我對Redis不了解或不完全了解的事實：

· SUNION是一個緩慢的命令，采用兩個大集合的交集可能會花費(fèi)大量時間。 實際上，我在Redis官方文檔中閱讀它感到很驚訝，因為我一直認(rèn)為Redis會一直保持快速。

· 從命令執(zhí)行的角度來看，Redis主要是單線程服務(wù)器，這意味著當(dāng)請求緩慢時，所有其他客戶端將等待該請求得到處理。

了解問題是找到正確解決方案的一半。 我意識到SUNION并不是我需要的命令，但是有哪些替代方案？ 好吧，感謝Google和Redis.io文檔，我遇到了SSCAN命令。 SSCAN命令(實際上，Redis中有針對不同數(shù)據(jù)類型的一堆不同的SCAN命令)允許在Set上進(jìn)行增量迭代，每次調(diào)用僅返回少量元素。 可以使用它而不會受到諸如SMEMBERS或SUNION之類的命令的負(fù)面影響，這些命令在針對大型集合進(jìn)行調(diào)用時可能會長時間阻塞服務(wù)器。

請注意，SSCAN在一個集合上完全迭代的時間復(fù)雜度為O(N)，其中N是集合基數(shù)。 對于SMEMBERS來說，這也是命令的復(fù)雜性，但是如果您還記得，我還說過我們的服務(wù)對從其API返回的商品數(shù)量有一定的限制。 由于一旦達(dá)到此限制就可以中斷SSCAN迭代，因此我們的時間復(fù)雜度實際上將是O(Min(N，Limit))，這是SUNION的要求，它將始終從Redis(和我們的服務(wù)邏輯)中提取數(shù)據(jù) 將對整個項目集合中返回的項目數(shù)設(shè)置限制)

到目前為止，一切都很好，但是在SUNION上使用SSCAN可能會有不利的一面嗎？ 好吧，可能存在—盡管像SUNION這樣的阻塞命令可以保證在給定的時間內(nèi)提供集合中的所有元素，但是SSCAN命令只能提供有限的保證，因為集合可以在迭代過程中進(jìn)行更改。 在完整的SSCAN迭代過程中，集合中不存在的元素可能會返回，也可能不會返回：它是未定義的。 但是，考慮到我們不會從Redis中刪除項目(只是添加新項目)，因此這并不是我們服務(wù)中的真正問題。

確實運(yùn)行了一些基準(zhǔn)測試可以測試SSCAN(僅提取有限數(shù)量的項目)與SUNION提取所有數(shù)據(jù)，并且它們以編程方式僅從中提取第一個有限的項目，這顯示出明顯的改進(jìn)。 對于小型Set，時間大致相同，但是對于具有1,000多個項目的大型Set，時間要好得多

繁榮！ 問題解決了。 從這個過程中我得出什么結(jié)論？ -可以說我們需要更好地了解我們的知識，但是在現(xiàn)實生活中，我們在日常工作中使用許多不同的服務(wù)和程序包(數(shù)據(jù)庫，云服務(wù)，開源程序包等)，而這幾乎是不可能的 掌握所有這些知識(不僅僅是性能，請考慮其中一些軟件包可能存在的安全性問題)。

但是，我們至少應(yīng)該嘗試掌握我們所依賴的服務(wù)，這些軟件包會對我們的服務(wù)產(chǎn)生巨大影響。

(本文翻譯自Tzafrir Ben Ami的文章《What I didn't know I didn't know about Redis》，參考：https://medium.com/swlh/what-i-didnt-know-i-didn-t-know-about-redis-6ad3729f29ed)

總結(jié)

以上是生活随笔為你收集整理的程序包android.support.annotation不存在_我不知道我不了解的Redis知识的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。