標籤:部分 rdp ESS pop 通訊 mit memory 失敗 常用
上期,小知和阿音在進行面試問答,可是呢,還沒問完小知就表示累了想休息一會,然後就休息去了,但是,以為這樣就完了嗎?
當然不是,還得繼續啊,嘿嘿嘿
註:對於第一種,需要應用程式自己處理資源的同步,可以使用的方法比較通俗,可以使用synchronized也可以使用lock;第二種需要用到Redis的setnx命令,但是需要注意一些問題。
Redis中事務的實現特徵:
在事務中的所有命令都將會被序列化的順序執行,事務執行期間,Redis不會再為其它用戶端的請求提供任何服務,從而保證了事物中的所有命令被原子的執行。
和關係型資料庫中的事務相比,在Redis事務中如果有某一條命令執行失敗,其後的命令仍然會被繼續執行。
我們可以通過MULTI命令開啟一個事務,有關係型資料庫開發經驗的人可以將其理解為"BEGIN TRANSACTION"語句。在該語句之後執行的命令都將被視為事務之內的操作,最後我們可以通過執行EXEC/DISCARD命令來提交/復原該事務內的所有操作。這兩個Redis命令可被視為等同於關係型資料庫中的COMMIT/ROLLBACK語句。
在事務開啟之前,如果用戶端與伺服器之間出現通訊故障並導致網路斷開,其後所有待執行的語句都將不會被伺服器執行。然而如果網路中斷事件是發生在用戶端執行EXEC命令之後,那麼該事務中的所有命令都會被伺服器執行。
當使用Append-Only模式時,Redis會通過調用系統函數write將該事務內的所有寫操作在本次調用中全部寫入磁碟。然而如果在寫入的過程中出現系統崩潰,如電源故障導致的宕機,那麼此時也許只有部分資料被寫入到磁碟,而另外一部分資料卻已經丟失。
Redis伺服器會在重新啟動時執行一系列必要的一致性檢測,一旦發現類似問題,就會立即退出並給出相應的錯誤提示。
此時,我們就要充分利用Redis工具包中提供的redis-check-aof工具,該工具可以協助我們定位到資料不一致的錯誤,並將已經寫入的部分資料進行復原。修複之後我們就可以再次重新啟動Redis伺服器了。
以上代碼只有在單串連的情況下才可以保證執行結果是正確的,因為如果在同一時刻有多個用戶端在同時執行該段代碼,那麼就會出現多線程程式中經常出現的一種錯誤情境--競態爭用(race condition)。
比如,用戶端A和B都在同一時刻讀取了mykey的原有值,假設該值為10,此後兩個用戶端又均將該值加一後set回Redis伺服器,這樣就會導致mykey的結果為11,而不是我們認為的12。為瞭解決類似的問題,我們需要藉助WATCH命令的協助,見如下代碼:
WATCH mykeyval = GET mykeyval = val + 1MULTISET mykey $valEXEC
和此前代碼不同的是,新代碼在擷取mykey的值之前先通過WATCH命令監控了該鍵,此後又將set命令包圍在事務中,這樣就可以有效保證每個串連在執行EXEC之前,如果當前串連擷取的mykey的值被其它串連的用戶端修改,那麼當前串連的EXEC命令將執行失敗。這樣調用者在判斷傳回值後就可以獲悉val是否被重新設定成功。
工作原理
vm-max-threads這個參數,可以設定訪問swap檔案的線程數,設定最好不要超過機器的核心數,如果設定為0,那麼所有對swap檔案的操作都是串列的.可能會造成比較長時間的延遲,但是對資料完整性有很好的保證.
自己測試的時候發現用虛擬記憶體效能也不錯。如果資料量很大,可以考慮分布式或者其他資料庫。
1、影響存留時間的一些操作
存留時間可以通過使用 DEL 命令來刪除整個 key 來移除,或者被 SET 和 GETSET 命令覆蓋原來的資料,也就是說,修改key對應的value和使用另外相同的key和value來覆蓋以後,當前資料的存留時間不同。
比如說,對一個 key 執行INCR命令,對一個列表進行LPUSH命令,或者對一個雜湊表執行HSET命令,這類操作都不會修改 key 本身的存留時間。另一方面,如果使用RENAME對一個 key 進行改名,那麼改名後的 key的存留時間和改名前一樣。
RENAME命令的另一種可能是,嘗試將一個帶存留時間的 key 改名成另一個帶存留時間的 another_key ,這時舊的 another_key (以及它的存留時間)會被刪除,然後舊的 key 會改名為 another_key ,因此,新的 another_key 的存留時間也和原本的 key 一樣。使用PERSIST命令可以在不刪除 key 的情況下,移除 key 的存留時間,讓 key 重新成為一個persistent key 。
2、如何更新存留時間
可以對一個已經帶有存留時間的 key 執行EXPIRE命令,新指定的存留時間會取代舊的存留時間。到期時間的精度已經被控制在1ms之內,主鍵失效的時間複雜度是O(1),EXPIRE和TTL命令搭配使用,TTL可以查看key的當前存留時間。設定成功返回 1;當 key 不存在或者不能為 key 設定存留時間時,返回 0 。
最大緩衝配置:
在 redis 中,允許使用者佈建最大使用記憶體大小,server.maxmemory預設為0,沒有指定最大緩衝,如果有新的資料添加,超過最大記憶體,則會使redis崩潰,所以一定要設定。redis 記憶體資料集大小上升到一定大小的時候,就會實行資料淘汰策略。
redis 提供 6種資料淘汰策略:
volatile-lru:從已設定到期時間的資料集(server.db[i].expires)中挑選最近最少使用的資料淘汰
volatile-ttl:從已設定到期時間的資料集(server.db[i].expires)中挑選將要到期的資料淘汰
volatile-random:從已設定到期時間的資料集(server.db[i].expires)中任意選擇資料淘汰
allkeys-lru:從資料集(server.db[i].dict)中挑選最近最少使用的資料淘汰
allkeys-random:從資料集(server.db[i].dict)中任意選擇資料淘汰
no-enviction(驅逐):禁止驅逐資料
注意這裡的6種機制,volatile和allkeys規定了是對已設定到期時間的資料集淘汰資料還是從全部資料集淘汰資料,後面的lru、ttl以及random是三種不同的淘汰策略,再加上一種no-enviction永不回收的策略。
使用原則規則:
如果資料呈現冪律分布,也就是一部分資料訪問頻率高,一部分資料訪問頻率低,則使用allkeys-lru
如果資料呈現平等分布,也就是所有的資料訪問頻率都相同,則使用allkeys-random
三種資料淘汰策略:
ttl和random比較容易理解,實現也會比較簡單。主要是Lru最近最少使用淘汰策略,設計上會對key 按失效時間排序,然後取最先失效的key進行淘汰
1、會話緩衝(Session Cache)
最常用的一種使用Redis的情景是會話緩衝(session cache)。用Redis緩衝會話比其他儲存(如Memcached)的優勢在於:Redis提供持久化。當維護一個不是嚴格要求一致性的緩衝時,如果使用者的購物車資訊全部丟失,大部分人都會不高興的,現在,他們還會這樣嗎?
幸運的是,隨著 Redis 這些年的改進,很容易找到怎麼恰當的使用Redis來緩衝會話的文檔。甚至廣為人知的商業平台Magento也提供Redis的外掛程式。
2、全頁緩衝(FPC)
除基本的會話token之外,Redis還提供很簡便的FPC平台。回到一致性問題,即使重啟了Redis執行個體,因為有磁碟的持久化,使用者也不會看到頁面載入速度的下降,這是一個極大改進,類似PHP本地FPC。
再次以Magento為例,Magento提供一個外掛程式來使用Redis作為全頁緩衝後端。
此外,對WordPress的使用者來說,Pantheon有一個非常好的外掛程式 wp-redis,這個外掛程式能協助你以最快速度載入你曾瀏覽過的頁面。
3、隊列
Reids在記憶體儲存引擎領域的一大優點是提供 list 和 set 操作,這使得Redis能作為一個很好的訊息佇列平台來使用。Redis作為隊列使用的操作,就類似於本地程式語言(如Python)對 list 的 push/pop 操作。
如果你快速的在Google中搜尋“Redis queues”,你馬上就能找到大量的開源項目,這些項目的目的就是利用Redis建立非常好的後端工具,以滿足各種隊列需求。例如,Celery有一個後台就是使用Redis作為broker,你可以從這裡去查看。
4、熱門排行榜/計數器
Redis在記憶體中對數字進行遞增或遞減的操作實現的非常好。集合(Set)和有序集合(Sorted Set)也使得我們在執行這些操作的時候變的非常簡單,Redis只是正好提供了這兩種資料結構。
所以,我們要從排序集合中擷取到排名最靠前的10個使用者–我們稱之為“user_scores”,我們只需要像下面一樣執行即可:
當然,這是假定你是根據你使用者的分數做遞增的排序。如果你想返回使用者及使用者的分數,你需要這樣執行:
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一個很好的例子,用Ruby實現的,它的熱門排行榜就是使用Redis來儲存資料的,你可以在這裡看到。
5、發布/訂閱
最後(但肯定不是最不重要的)是Redis的發布/訂閱功能。發布/訂閱的使用情境確實非常多。我已看見人們在社交網路串連中使用,還可作為基於發布/訂閱的指令碼觸發器,甚至用Redis的發布/訂閱功能來建立聊天系統!(不,這是真的,你可以去核實)。
Redis提供的所有特性中,我感覺這個是喜歡的人最少的一個,雖然它為使用者提供如果此多功能。
漫畫 | Redis常見面試問題(二)