https://github.com/redisson
Redis常用數(shù)據(jù)結構：
String、List、Hash、set、sortedset
Redis數(shù)據(jù)持久化：
一、RDB【對內存中的數(shù)據(jù)庫狀態(tài)進行快照】建議開啟：fork出一個子進程（ 一個進程，包括代碼、數(shù)據(jù)和分配給進程的資源。fork（）函數(shù)通過系統(tǒng)調用創(chuàng)建一個與原來進程幾乎完全相同的進程），所有持久化工作都由子進程完成，Redis會定期保存數(shù)據(jù)快照至一個rbd文件中，并在啟動時自動加載rdb文件，恢復之前保存的數(shù)成[通過save指令 默認900秒1次，300秒10次，60秒10000次]
RDB的優(yōu)點：
①對性能影響最小。如前文所述，Redis在保存RDB快照時會fork出子進程進行，幾乎不影響Redis處理客戶端請求的效率。
②每次快照會生成一個完整的數(shù)據(jù)快照文件，所以可以輔以其他手段保存多個時間點的快照（例如把每天0點的快照備份至其他存儲媒介中），作為非?？煽康臑碾y恢復手段。
③使用RDB文件進行數(shù)據(jù)恢復比使用AOF要快很多。
RDB的缺點：
①快照是定期生成的，所以在Redis crash時或多或少會丟失一部分數(shù)據(jù)。
②如果數(shù)據(jù)集非常大且CPU不夠強（比如單核CPU），Redis在fork子進程時可能會消耗相對較長的時間（長至1秒），影響這期間的客戶端請求。

二、 AOF redis將每個寫請求寫入到日志中，在redis重啟時，會把AOF寫操作的順序執(zhí)行一遍，確保數(shù)據(jù)恢復到最新
AOF的優(yōu)點：
①最安全，在啟用appendfsync always時，任何已寫入的數(shù)據(jù)都不會丟失，使用在啟用appendfsync everysec也至多只會丟失1秒的數(shù)據(jù)。
AOF文件在發(fā)生斷電等問題時也不會損壞，即使出現(xiàn)了某條日志只寫入了一半的情況，也可以使用redis-check-aof工具輕松修復。
②AOF文件易讀，可修改，在進行了某些錯誤的數(shù)據(jù)清除操作后，只要AOF文件沒有rewrite，就可以把③AOF文件備份出來，把錯誤的命令刪除，然后恢復數(shù)據(jù)。
AOF的缺點：
①AOF文件通常比RDB文件更大
②性能消耗比RDB高
③數(shù)據(jù)恢復速度比RDB慢

三、Redis內存設置
在內存占用達到了maxmemory后，再向Redis寫入數(shù)據(jù)時，Redis會：
①根據(jù)配置的數(shù)據(jù)淘汰策略嘗試淘汰數(shù)據(jù)，釋放空間
②如果沒有數(shù)據(jù)可以淘汰，或者沒有配置數(shù)據(jù)淘汰策略，那么Redis會對所有寫請求返回錯誤，但讀請求仍然可以正常執(zhí)行
【注意在為Redis設置maxmemory時，如果采用了Redis的主從同步，主節(jié)點向從節(jié)點同步數(shù)據(jù)時，會占用掉一部分內存空間，如果maxmemory過于接近主機的可用內存，導致數(shù)據(jù)同步時內存不足。所以設置的maxmemory不要過于接近主機可用的內存，留出一部分預留用作主從同步。

四、緩存淘汰策略
數(shù)據(jù)淘汰機制

Redis提供了5種數(shù)據(jù)淘汰策略：
volatile-lru：使用LRU算法進行數(shù)據(jù)淘汰（淘汰上次使用時間最早的，且使用次數(shù)最少的key），只淘汰設定了有效期的key
allkeys-lru：使用LRU算法進行數(shù)據(jù)淘汰，所有的key都可以被淘汰
volatile-random：隨機淘汰數(shù)據(jù)，只淘汰設定了有效期的key
allkeys-random：隨機淘汰數(shù)據(jù)，所有的key都可以被淘汰
volatile-ttl：淘汰剩余有效期最短的key