您好,登錄后才能下訂單哦!
這篇文章主要講解了“redis的下載及安裝配置”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“redis的下載及安裝配置”吧!
http://www.redis.cn/download.html
下載完成,使用rz命令上傳至linux 服務器 tar -xvf redis-5.0.5.tar.gz #解壓源碼包 mv redis-5.0.5 /usr/local/redis #將源碼包移動到/usr/local/目錄下,重命名為redis cd /usr/local/redis/ #cd 到源碼目錄里
make #編譯 中間有兩個報錯,解決
#沒有安裝gcc 包,yum install gcc -y 解決
#加個環境變量一起編譯 make MALLOC=libc 用這句命令能正常編譯
make install #安裝編譯完成的程序,也可以不用安裝,cd 到src目錄 執行也行 cd /usr/local/bin/ #這個目錄是安裝完成后 生成的腳本,打開關閉 客戶端工具都在里面
vim /usr/local/redis/redis.conf #配置 redis 配置文件,修改以下選項 bind 0.0.0.0 #監聽IP 0.0.0.0 表示此計算機所有IP都監聽 daemonize yes #是否后臺啟動redis,打開 protected-mode no # redis的安全機制,打開可能會報錯 #requirepass 123456 #設置密碼,默認注釋狀態。 redis-server /usr/local/redis/redis.conf #指定配置文件啟動 redis
netstat -nltp|grep 6379 #檢查6379 是否被監聽了,這個端口是redis默認端口
redis-cli #登陸客戶端,輸入幾個值,查看以下
redis-cli shutdown #關閉redis服務
RDB持久化方式是通過快照(snapshotting)完成的,當符合一定條件時,redis會自動將內存中所有數據以二進制方式生成一份副本并存儲在硬盤上。當redis重啟時,并且AOF持久化未開啟時,redis會讀取RDB持久化生成的二進制文件(默認名稱dump.rdb,可通過設置dbfilename修改)進行數據恢復,對于持久化信息可以用過命令“info Persistence”查看。
快照觸發條件
RDB生成快照可自動促發,也可以使用命令手動觸發,以下是redis觸發執行快照條件,后續會對每個條件詳細說明:
客戶端執行命令save和bgsave會生成快照; 根據配置文件save m n規則進行自動快照; 主從復制時,從庫全量復制同步主庫數據,此時主庫會執行bgsave命令進行快照; 客戶端執行數據庫清空命令FLUSHALL時候,觸發快照; 客戶端執行shutdown關閉redis時,觸發快照;
客戶端執行save命令,該命令強制redis執行快照,這時候redis處于阻塞狀態,不會響應任何其他客戶端發來的請求,直到RDB快照文件執行完畢,所以請慎用。 首先使用redis-cli info Persistence 查看最近一次持久化時間:
#可以看到數據是一組時間戳看的 不方便看,我們可以用AWK 配合date命令轉換下 date "+%Y-%m-%d %H:%M:%S" -d @`redis-cli info Persistence|awk -F":" 'NR==5{print$2}'`
#可以看到運行了 redis-cli save 命令,最后一次的保存時間已經發生了改變
#注意只有正常關閉才會觸發保存,直接kill是無法觸發的
basave 命令執行之后立即返回 OK ,然后 Redis fork 出一個新子進程(在此期間父進程不響應請求),原來的 Redis 進程(父進程)繼續處理客戶端請求,而子進程則負責將數據保存到磁盤,然后退出。
#用法和save 差不多,但是阻塞時間比save 大大減少了
這個配置在配置文件里 默認 save 900 1 #表示900秒內有1個鍵發生修改,觸發bgsave save 300 10 #表示300秒內有10個鍵發生修改,觸發bgsave save 60 10000 #表示60秒內有10000個鍵發生修改,觸發bgsave #上面關系式或的意思,滿足一個即可觸發bgsave
flushall命令用于清空數據庫,請慎用,當我們使用了則表明我們需要對數據進行清空,那redis當然需要對快照文件也進行清空,所以會觸發bgsave。 在redis主從復制中,從節點執行全量復制操作,主節點會執行bgsave命令,并將rdb文件發送給從節點。
save m n #配置快照(rdb)促發規則,格式:save <seconds> <changes> #save 900 1 900秒內至少有1個key被改變則做一次快照 #save 300 10 300秒內至少有300個key被改變則做一次快照 #save 60 10000 60秒內至少有10000個key被改變則做一次快照 #關閉該規則使用svae “” dbfilename dump.rdb #rdb持久化存儲數據庫文件名,默認為dump.rdb stop-write-on-bgsave-error yes #yes代表當使用bgsave命令持久化出錯時候停止寫RDB快照文件,no表明忽略錯誤繼續寫文件。 rdbchecksum yes #在寫入文件和讀取文件時是否開啟rdb文件檢查,檢查是否有無損壞,如果在啟動是檢查發現損壞,則停止啟動。 dir ./ #數據文件存放目錄,rdb快照文件和aof文件都會存放至該目錄,請確保有寫權限,編譯安裝的默認就在當前目錄。 rdbcompression yes #是否開啟RDB文件壓縮,該功能可以節約磁盤空間
AOF持久化和Mysql的二級制日志寫入原理一樣,AOF可以將Redis執行的每一條寫命令追加到磁盤文件(appendonly.aof)中,在redis啟動時候優先選擇從AOF文件恢復數據。由于每一次的寫操作,redis都會記錄到文件中,對磁盤I/O有以一定影響,與RDB持久化相比,AOF持久化數據(1秒左右的數據)丟失更少,其消耗內存更少(RDB方式執行bgsve會有內存拷貝)。
開啟AOF
#默認情況下,redis是關閉了AOF持久化,開啟AOF通過配置appendonly為yes開啟,我們修改配置文件或者在命令行直接使用config set修改,在用config rewrite同步到配置文件。通過客戶端修改好處是不用重啟redis,AOF持久化直接生效。
redisAOF持久化過程可分為以下階段:
1.追加寫入
redis將每一條寫命令以redis通訊協議添加至緩沖區aof_buf,這樣的好處在于在大量寫請求情況下,采用緩沖區暫存一部分命令隨后根據策略一次性寫入磁盤,這樣可以減少磁盤的I/O次數,提高性能。
2.同步命令到硬盤
當寫命令寫入aof_buf緩沖區后,redis會將緩沖區的命令寫入到文件,redis提供了三種同步策略,由配置參數appendfsync決定,下面是每個策略所對應的含義:
? no:不使用fsync方法同步,而是交給操作系統write函數去執行同步操作,在linux操作系統中大約每30秒刷一次緩沖。這種情況下,緩沖區數據同步不可控,并且在大量的寫操作下,aof_buf緩沖區會堆積會越來越嚴重,一旦redis出現故障,數據丟失嚴重。 ? always:表示每次有寫操作都調用fsync方法強制內核將數據寫入到aof文件。這種情況下由于每次寫命令都寫到了文件中, 雖然數據比較安全,但是因為每次寫操作都會同步到AOF文件中,所以在性能上會有影響,同時由于頻繁的IO操作,硬盤的使用壽命會降低。 ? everysec:數據將使用調用操作系統write寫入文件,并使用fsync每秒一次從 內核刷新到磁盤。 這是折中的方案,兼顧性能和數據安全,所以redis默認推薦使用該配置。
3.文件重寫(bgrewriteaof)
當開啟的AOF時,隨著時間推移,AOF文件會越來越大,當然redis也對AOF文件進行了優化,即觸發AOF文件重寫條件(后續會說明)時候,redis將使用bgrewriteaof對AOF文件進行重寫。這樣的好處在于減少AOF文件大小,同時有利于數據的恢復。
為什么重寫?比如先后執行了“set foo bar1 set foo bar2 set foo bar3” 此時AOF文件會記錄三條命令,這顯然不合理,因為文件中應只保留“set foo bar3”這個最后設置的值,前面的set命令都是多余的,下面是一些重寫時候策略:
? 重復或無效的命令不寫入文件 ? 過期的數據不再寫入文件 ? 多條命令合并寫入(當多個命令能合并一條命令時候會對其優化合并作為一個命令寫入,例如“RPUSH list1 a RPUSH list1 b" 合并為“RPUSH list1 a b” )
AOF文件觸發條件可分為手動觸發和自動觸發:
手動觸發:客戶端執行bgrewriteaof命令。
自動觸發:自動觸發通過以下兩個配置協作生效:
? auto-aof-rewrite-min-size: AOF文件最小重寫大小,只有當AOF文件大小大于該值時候才可能重寫,4.0默認配置64mb。 ? auto-aof-rewrite-percentage:當前AOF文件大小和最后一次重寫后的大小之間的比率等于或者等于指定的增長百分比,如100代表當前AOF文件是上次重寫的兩倍時候才重寫。
redis開啟在AOF功能開啟的情況下,會維持以下三個變量
? 記錄當前AOF文件大小的變量aof_current_size。 ? 記錄最后一次AOF重寫之后,AOF文件大小的變量aof_rewrite_base_size。 ? 增長百分比變量aof_rewrite_perc。
每次當serverCron(服務器周期性操作函數)函數執行時,它會檢查以下條件是否全部滿足,如果全部滿足的話,就觸發自動的AOF重寫操作:
? 沒有bgsave命令(RDB持久化)/AOF持久化在執行; ? 沒有bgrewriteaofF在進行; ? 當前AOF文件大小要大于server.aof_rewrite_min_size的值; ? 當前AOF文件大小和最后一次重寫后的大小之間的比率等于或者大于指定的增長百分比(auto-aof-rewrite-percentage參數)
auto-aof-rewrite-min-size 64mb #AOF文件最小重寫大小,只有當AOF文件大小大于該值時候才可能重寫,4.0默認配置64mb。 auto-aof-rewrite-percentage 100 #當前AOF文件大小和最后一次重寫后的大小之間的比率等于或者等于指定的增長百分比,如100代表當前AOF文件是上次重寫的兩倍時候才重寫。 appendfsync everysec #no:不使用fsync方法同步,而是交給操作系統write函數去執行同步操作,在linux操作系統中大約每30秒刷一次緩沖。這種情況下,緩沖區數據同步不可控,并且在大量的寫操作下,aof_buf緩沖區會堆積會越來越嚴重,一旦redis出現故障,數據 #always:表示每次有寫操作都調用fsync方法強制內核將數據寫入到aof文件。這種情況下由于每次寫命令都寫到了文件中, 雖然數據比較安全,但是因為每次寫操作都會同步到AOF文件中,所以在性能上會有影響,同時由于頻繁的IO操作,硬盤的使用壽命會降低。 #everysec:數據將使用調用操作系統write寫入文件,并使用fsync每秒一次從內核刷新到磁盤。 這是折中的方案,兼顧性能和數據安全,所以redis默認推薦使用該配置。 aof-load-truncated yes #當redis突然運行崩潰時,會出現aof文件被截斷的情況,Redis可以在發生這種情況時退出并加載錯誤,以下選項控制此行為。 #如果aof-load-truncated設置為yes,則加載截斷的AOF文件,Redis服務器啟動發出日志以通知用戶該事件。 #如果該選項設置為no,則服務將中止并顯示錯誤并停止啟動。當該選項設置為no時,用戶需要在重啟之前使用“redis-check-aof”實用程序修復AOF文件在進行啟動。 appendonly no #yes開啟AOF,no關閉AOF appendfilename appendonly.aof #指定AOF文件名,4.0無法通過config set 設置,只能通過修改配置文件設置。 dir ./ #RDB文件和AOF文件存放目錄
兩個保存文件檢查
redis-check-aof appendonly.aof #AOF redis-check-rdb dump.rdb #RDB
感謝各位的閱讀,以上就是“redis的下載及安裝配置”的內容了,經過本文的學習后,相信大家對redis的下載及安裝配置這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。