Redis與Memcached區別：

兩者都是非關系型數據庫。主要有以下不同：

數據類型：

• Memcached僅支持字符串類型。
• redis支持：String,List,set,zset,hash 可以靈活的解決問題。

數據持久化：

• Memcached不支持持久化。
• Redis采用兩種持久化策略：RDB快照和AOF日志。

分布式：

• Mencached不支持分布式，只能在客戶端使用一致性hash來實現分布式存儲，這種方式在存儲和查詢時都需要在客戶端先計算一次數據所在的節點。
• redis cluster實現了分布式的支持。

內存管理機制：

• redis中，并不是所有數據都一直存儲在內存中，可以將一些很久沒用的value交換到磁盤，而memcached數據則候會一直在內存中。
• memcached將內存分割成特定的塊進行存儲，以完全解決內存碎片化的問題，但是這種方式使得內存利用率不高，如塊大小128bytes，只存儲了100bytes的數據，那么剩下的28bytes就浪費掉了。

鍵的過期時間：

redis可以為每個鍵設置過期時間，當鍵過期時，自動刪除該鍵。對于散列表這種容器，只能為整個鍵設置過期時間(整個散列表)，而不是為鍵里面的單個元素設置過期時間。

設置鍵的生存時間：

• expire: 指定秒
• pexpire: 指定毫秒

127.0.0.1:6379> set key hello OK 127.0.0.1:6379> expire key 1 (integer) 1 127.0.0.1:6379> get key (nil) 127.0.0.1:6379> hset hashkey key1 1 (integer) 0 127.0.0.1:6379> hget hashkey key1 "1" 127.0.0.1:6379> expire hashkey 1 (integer) 1 127.0.0.1:6379> hget hashkey key1 (nil) 127.0.0.1:6379> zadd zset 0 key1 1 key2 (integer) 0 127.0.0.1:6379> zrange zset 0 -1 1) "key1" 2) "key3" 3) "key2" 127.0.0.1:6379> expire zset 1 (integer) 1 127.0.0.1:6379> zrange zset 0 -1 (empty list or set) 設置過期時間：過期時間是一個unix時間戳

• expireat:秒精度
• pexpireat：毫秒精度

過期鍵的刪除策略：

定時刪除：

在設置鍵的過期時間的同時，創建一個定時器，讓定時器在鍵過期時間來臨時，立即執行對鍵的刪除操作。

• [ ] 優點：對內存是友好的，可以保證過期鍵會盡可能快被刪除，并釋放過期鍵所占用的內存。
• [ ] 缺點：對CPU不友好，在過期鍵較多的情況下，刪除鍵的操作會占用相當一部分的CPU時間，在內存不緊張但CPU緊張的情況下，將cpu時間用在刪除與當前任務無關的過期鍵上，無疑會對服務器的響應時間和吞吐量造成影響。
  此外，定時器需要使用redis服務器的時間事件，時間事件的實現方式為無序鏈表，查找一個事件的事件復雜度為O(N)，因此創建大量的定時器不現實。

惰性刪除:

僅在程序取出鍵時才進行過期檢查

• [ ] 優點: CPU友好，不會花費額外的時間。
• [ ] 缺點：對內存不友好，會造成內存泄漏。

定期刪除:

每隔一段時間執行一次刪除過期鍵操作，并通過限制刪除操作執行的時長和頻率來減少對CPU時間的影響。

數據淘汰策略：6種

可以設置內存最大使用量，當內存使用超出時，施行數據淘汰策略。

作為內存數據庫，出于對性能和內存消耗的考慮，redis的淘汰算法實際上并未針對所有key，而是抽樣一小部分并且從中選出被淘汰的key。使用reids緩存數據時，為提高緩存命中率，需要保證緩存都是熱點數據。可以將內存最大使用量設置為熱點數據占用的內存量，然后啟用allkeys-lru淘汰策略，將最近最少未使用的數據進行淘汰。redis4.0 版本后引入了volatile-lfu和allkeys-lfu淘汰策略，LFU策略通過統計訪問頻率，將訪問頻率最小的鍵值進行淘汰。

持久化：

redis是內存型數據庫，為了保證數據在斷電后不會丟失，需要將內存中的數據持久化到硬盤上。

RDB持久化：

• 將某個時間點的所有數據都存放到硬盤上。
• 可以將快照復制到其他服務器從而創建具有相同數據的服務器副本。
• 如果系統方法故障，將會丟失最后一次快照后的數據。
• 如果數據量很大，保存快照時間會很長。

手動觸發：

• [ ] redis命令
• save：生成RDB文件，會阻塞服務器進程，知直到RDB文件創建完畢。
• bgsave： 派生(fork)一個子進程，然后由子進程負責創建RDB文件，父進程繼續處理命令請求。

自動觸發：

• 使用save相關配置，如“save m n”。表示m秒中對數據集進行n次修改，就觸發bgsave。
• 如果從節點執行全量復制操作，主節點自動執行bgsave生成RDB文件發送給從文件。
• 執行debug reload 命令重新加載redis時，自動觸發save操作。
• 默認情況下執行shutdown命令時，若沒有開啟AOF持久化功能則自動執行bgsave。

優缺點：

• [ ] 優點: 適用于備份，全量復制等場景。恢復數據遠快于AOF方法。
• [ ] 缺點：沒辦法做到實時持久化/秒級持久化。 RDB使用特定二進制格式，redis演化中有多個RDB版本，存在版本不兼容情況。

AOF 持久化：

將寫命令添加到AOF文件的末尾(append Only File)使用AOF持久化需要設置同步選項，從而保證寫命令什么時候會被同步到磁盤文件上。這時因為對文件進行寫入并不會，馬上將內容同步到磁盤上，而是先存儲到緩沖區，然后由操作系統決定什么時候同步到磁盤。有以下同步方式：

• always：每個寫命令都同步。嚴重影響服務器性能
• everysec：每秒同步一次。可以保證系統崩潰時只丟失一秒左右的數據，每秒執行一次對性能幾乎沒影響。
• no：讓操作系統決定，最長30秒。不能帶來太多的性能提升，但是會增加系統崩潰時數據丟失的數量。
  隨著服務器寫請求的增多，AOF文件會越來越大。redis提供了一種將AOF重寫的特性，能夠去除AOF文件中冗余的寫命令。

為什么會變小：

進程中已經超時數據不再寫入文件。

舊的AOF文件含有無效命令。

多條命令合并(對同一鍵值的更新)。

==感覺文章不錯的同學麻煩動動小手點點關注訂閱唄,您的肯定是對我持續更新最大的支持!==

總結

以上是生活随笔為你收集整理的定时器取数据时实时进来的数据_Redis-数据淘汰策略amp;持久化方式(RDB/AOF)amp;Redis与Memcached区别...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。