2. 程式人生 > >redis資料丟失及解決

redis資料丟失及解決

阿新 • • 發佈：2019-01-27

參考資料：
Redis Persistence http://redis.io/topics/persistence
Google Groups https://groups.google.com/forum/?fromgroups=#!forum/redis-db

一、對Redis持久化的探討與理解

目前Redis持久化的方式有兩種： RDB 和 AOF

首先，我們應該明確持久化的資料有什麼用，答案是用於重啟後的資料恢復。
Redis是一個記憶體資料庫，無論是RDB還是AOF，都只是其保證資料恢復的措施。
所以Redis在利用RDB和AOF進行恢復的時候，都會讀取RDB或AOF檔案，重新載入到記憶體中。

RDB就是Snapshot快照儲存，是預設的持久化方式。
可理解為半持久化模式，即按照一定的策略週期性的將資料儲存到磁碟。
對應產生的資料檔案為dump.rdb，通過配置檔案中的save引數來定義快照的週期。
下面是預設的快照設定：

save 900 1    #當有一條Keys資料被改變時，900秒重新整理到Disk一次
save 300 10   #當有10條Keys資料被改變時，300秒重新整理到Disk一次
save 60 10000 #當有10000條Keys資料被改變時，60秒重新整理到Disk一次

Redis的RDB檔案不會壞掉，因為其寫操作是在一個新程序中進行的。
當生成一個新的RDB檔案時，Redis生成的子程序會先將資料寫到一個臨時檔案中，然後通過原子性rename系統呼叫將臨時檔案重新命名為RDB檔案。
這樣在任何時候出現故障，Redis的RDB檔案都總是可用的。

同時，Redis的RDB檔案也是Redis主從同步內部實現中的一環。
第一次Slave向Master同步的實現是：
Slave向Master發出同步請求，Master先dump出rdb檔案，然後將rdb檔案全量傳輸給slave，然後Master把快取的命令轉發給Slave，初次同步完成。
第二次以及以後的同步實現是：
Master將變數的快照直接實時依次傳送給各個Slave。
但不管什麼原因導致Slave和Master斷開重連都會重複以上兩個步驟的過程。
Redis的主從複製是建立在記憶體快照的持久化基礎上的，只要有Slave就一定會有記憶體快照發生。

可以很明顯的看到，RDB有它的不足，就是一旦資料庫出現問題，那麼我們的RDB檔案中儲存的資料並不是全新的。
從上次RDB檔案生成到Redis停機這段時間的資料全部丟掉了。

AOF(Append-Only File)比RDB方式有更好的持久化性。
由於在使用AOF持久化方式時，Redis會將每一個收到的寫命令都通過Write函式追加到檔案中，類似於MySQL的binlog。
當Redis重啟是會通過重新執行檔案中儲存的寫命令來在記憶體中重建整個資料庫的內容。
對應的設定引數為：
$ vim /opt/redis/etc/redis_6379.conf

appendonly yes       #啟用AOF持久化方式
appendfilename appendonly.aof #AOF檔案的名稱，預設為appendonly.aof
# appendfsync always #每次收到寫命令就立即強制寫入磁碟，是最有保證的完全的持久化，但速度也是最慢的，一般不推薦使用。
appendfsync everysec #每秒鐘強制寫入磁碟一次，在效能和持久化方面做了很好的折中，是受推薦的方式。
# appendfsync no     #完全依賴OS的寫入，一般為30秒左右一次，效能最好但是持久化最沒有保證，不被推薦。

AOF的完全持久化方式同時也帶來了另一個問題，持久化檔案會變得越來越大。
比如我們呼叫INCR test命令100次，檔案中就必須儲存全部的100條命令，但其實99條都是多餘的。
因為要恢復資料庫的狀態其實檔案中儲存一條SET test 100就夠了。
為了壓縮AOF的持久化檔案，Redis提供了bgrewriteaof命令。
收到此命令後Redis將使用與快照類似的方式將記憶體中的資料以命令的方式儲存到臨時檔案中，最後替換原來的檔案，以此來實現控制AOF檔案的增長。
由於是模擬快照的過程，因此在重寫AOF檔案時並沒有讀取舊的AOF檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的AOF檔案。
對應的設定引數為:
$ vim /opt/redis/etc/redis_6379.conf

no-appendfsync-on-rewrite yes   #在日誌重寫時，不進行命令追加操作，而只是將其放在緩衝區裡，避免與命令的追加造成DISK IO上的衝突。
auto-aof-rewrite-percentage 100 #當前AOF檔案大小是上次日誌重寫得到AOF檔案大小的二倍時，自動啟動新的日誌重寫過程。
auto-aof-rewrite-min-size 64mb  #當前AOF檔案啟動新的日誌重寫過程的最小值，避免剛剛啟動Reids時由於檔案尺寸較小導致頻繁的重寫。

到底選擇什麼呢？下面是來自官方的建議：
通常，如果你要想提供很高的資料保障性，那麼建議你同時使用兩種持久化方式。
如果你可以接受災難帶來的幾分鐘的資料丟失，那麼你可以僅使用RDB。
很多使用者僅使用了AOF，但是我們建議，既然RDB可以時不時的給資料做個完整的快照，並且提供更快的重啟，所以最好還是也使用RDB。
因此，我們希望可以在未來（長遠計劃）統一AOF和RDB成一種持久化模式。

在資料恢復方面：
RDB的啟動時間會更短，原因有兩個：
一是RDB檔案中每一條資料只有一條記錄，不會像AOF日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。
另一個原因是RDB檔案的儲存格式和Redis資料在記憶體中的編碼格式是一致的，不需要再進行資料編碼工作，所以在CPU消耗上要遠小於AOF日誌的載入。

二、災難恢復模擬
既然持久化的資料的作用是用於重啟後的資料恢復，那麼我們就非常有必要進行一次這樣的災難恢復模擬了。
據稱如果資料要做持久化又想保證穩定性，則建議留空一半的實體記憶體。因為在進行快照的時候，fork出來進行dump操作的子程序會佔用與父程序一樣的記憶體，真正的copy-on-write，對效能的影響和記憶體的耗用都是比較大的。
目前，通常的設計思路是利用Replication機制來彌補aof、snapshot效能上的不足，達到了資料可持久化。
即Master上Snapshot和AOF都不做，來保證Master的讀寫效能，而Slave上則同時開啟Snapshot和AOF來進行持久化，保證資料的安全性。

首先，修改Master上的如下配置：
$ sudo vim /opt/redis/etc/redis_6379.conf

#save 900 1 #禁用Snapshot
#save 300 10
#save 60 10000

appendonly no #禁用AOF

接著，修改Slave上的如下配置：
$ sudo vim /opt/redis/etc/redis_6379.conf

save 900 1 #啟用Snapshot
save 300 10
save 60 10000

appendonly yes #啟用AOF
appendfilename appendonly.aof #AOF檔案的名稱
# appendfsync always
appendfsync everysec #每秒鐘強制寫入磁碟一次
# appendfsync no  

no-appendfsync-on-rewrite yes   #在日誌重寫時，不進行命令追加操作
auto-aof-rewrite-percentage 100 #自動啟動新的日誌重寫過程
auto-aof-rewrite-min-size 64mb  #啟動新的日誌重寫過程的最小值

分別啟動Master與Slave
$ /etc/init.d/redis start

啟動完成後在Master中確認未啟動Snapshot引數
redis 127.0.0.1:6379> CONFIG GET save
1) "save"
2) ""

然後通過以下指令碼在Master中生成25萬條資料：
[email protected]:/opt/redis/data/6379$ cat redis-cli-generate.temp.sh

#!/bin/bash

REDISCLI="redis-cli -a slavepass -n 1 SET"
ID=1

while(($ID<50001))
do
  INSTANCE_NAME="i-2-$ID-VM"
  UUID=`cat /proc/sys/kernel/random/uuid`
  PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`\
  CREATED=`date "+%Y-%m-%d %H:%M:%S"`

  $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME"
  $REDISCLI vm_instance:$ID:uuid "$UUID"
  $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS"
  $REDISCLI vm_instance:$ID:created "$CREATED"

  $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID"

  ID=$(($ID+1))
done

[email protected]:/opt/redis/data/6379$ ./redis-cli-generate.temp.sh

在資料的生成過程中，可以很清楚的看到Master上僅在第一次做Slave同步時建立了dump.rdb檔案，之後就通過增量傳輸命令的方式給Slave了。
dump.rdb檔案沒有再增大。
[email protected]:/opt/redis/data/6379$ ls -lh
total 4.0K
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb

而Slave上則可以看到dump.rdb檔案和AOF檔案在不斷的增大，並且AOF檔案的增長速度明顯大於dump.rdb檔案。
[email protected]:/opt/redis/data/6379$ ls -lh
total 24M
-rw-r--r-- 1 root root 15M Sep 27 12:06 appendonly.aof
-rw-r--r-- 1 root root 9.2M Sep 27 12:06 dump.rdb

等待資料插入完成以後，首先確認當前的資料量。
redis 127.0.0.1:6379> info

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:27623
run_id:e00757f7b2d6885fa9811540df9dfed39430b642
uptime_in_seconds:1541
uptime_in_days:0
lru_clock:650187
used_cpu_sys:69.28
used_cpu_user:7.67
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
connected_clients:1
connected_slaves:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33055824
used_memory_human:31.52M
used_memory_rss:34717696
used_memory_peak:33055800
used_memory_peak_human:31.52M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:0
changes_since_last_save:250000
bgsave_in_progress:0
last_save_time:1348677645
bgrewriteaof_in_progress:0
total_connections_received:250007
total_commands_processed:750019
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:246
vm_enabled:0
role:master
slave0:10.6.1.144,6379,online
db1:keys=250000,expires=0

當前的資料量為25萬條key，佔用記憶體31.52M。

然後我們直接Kill掉Master的Redis程序，模擬災難。
[email protected]:/opt/redis/data/6379$ sudo killall -9 redis-server

我們到Slave中檢視狀態：
redis 127.0.0.1:6379> info

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:13003
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
uptime_in_seconds:1627
uptime_in_days:0
lru_clock:654181
used_cpu_sys:29.69
used_cpu_user:1.21
used_cpu_sys_children:1.70
used_cpu_user_children:1.23
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33047696
used_memory_human:31.52M
used_memory_rss:34775040
used_memory_peak:33064400
used_memory_peak_human:31.53M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:1
changes_since_last_save:3308
bgsave_in_progress:0
last_save_time:1348718951
bgrewriteaof_in_progress:0
total_connections_received:4
total_commands_processed:250308
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:694
vm_enabled:0
role:slave
aof_current_size:17908619
aof_base_size:16787337
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
master_host:10.6.1.143
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
master_link_down_since_seconds:25
slave_priority:100
db1:keys=250000,expires=0

可以看到master_link_status的狀態已經是down了，Master已經不可訪問了。
而此時，Slave依然執行良好，並且保留有AOF與RDB檔案。

下面我們將通過Slave上儲存好的AOF與RDB檔案來恢復Master上的資料。

首先，將Slave上的同步狀態取消，避免主庫在未完成資料恢復前就重啟，進而直接覆蓋掉從庫上的資料，導致所有的資料丟失。
redis 127.0.0.1:6379> SLAVEOF NO ONE
OK

確認一下已經沒有了master相關的配置資訊：
redis 127.0.0.1:6379> INFO

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:13003
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
uptime_in_seconds:1961
uptime_in_days:0
lru_clock:654215
used_cpu_sys:29.98
used_cpu_user:1.22
used_cpu_sys_children:1.76
used_cpu_user_children:1.42
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33047696
used_memory_human:31.52M
used_memory_rss:34779136
used_memory_peak:33064400
used_memory_peak_human:31.53M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:1
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1348719252
bgrewriteaof_in_progress:0
total_connections_received:4
total_commands_processed:250311
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:1119
vm_enabled:0
role:master
aof_current_size:17908619
aof_base_size:16787337
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
db1:keys=250000,expires=0

在Slave上覆制資料檔案：
[email protected]:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *
appendonly.aof
dump.rdb

將data.tar上傳到Master上，嘗試恢復資料:
可以看到Master目錄下有一個初始化Slave的資料檔案，很小，將其刪除。
[email protected]:/opt/redis/data/6379$ ls -l
total 4
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
[email protected]:/opt/redis/data/6379$ sudo rm -f dump.rdb

然後解壓縮資料檔案：
[email protected]:/opt/redis/data/6379$ sudo tar xf /home/dongguo/data.tar
[email protected]:/opt/redis/data/6379$ ls -lh
total 29M
-rw-r--r-- 1 root root 18M Sep 27 01:22 appendonly.aof
-rw-r--r-- 1 root root 12M Sep 27 01:22 dump.rdb

啟動Master上的Redis；
[email protected]:/opt/redis/data/6379$ sudo /etc/init.d/redis start
Starting Redis server...

檢視資料是否恢復：
redis 127.0.0.1:6379> INFO

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:16959
run_id:6e5ba6c053583414e75353b283597ea404494926
uptime_in_seconds:22
uptime_in_days:0
lru_clock:650292
used_cpu_sys:0.18
used_cpu_user:0.20
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33047216
used_memory_human:31.52M
used_memory_rss:34623488
used_memory_peak:33047192
used_memory_peak_human:31.52M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:0
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1348680180
bgrewriteaof_in_progress:0
total_connections_received:1
total_commands_processed:1
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
vm_enabled:0
role:master
db1:keys=250000,expires=0

可以看到25萬條資料已經完整恢復到了Master上。

此時，可以放心的恢復Slave的同步設定了。
redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379
OK

檢視同步狀態：
redis 127.0.0.1:6379> INFO

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:13003
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
uptime_in_seconds:2652
uptime_in_days:0
lru_clock:654284
used_cpu_sys:30.01
used_cpu_user:2.12
used_cpu_sys_children:1.76
used_cpu_user_children:1.42
connected_clients:2
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33056288
used_memory_human:31.52M
used_memory_rss:34766848
used_memory_peak:33064400
used_memory_peak_human:31.53M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:1
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1348719252
bgrewriteaof_in_progress:1
total_connections_received:6
total_commands_processed:250313
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:12217
vm_enabled:0
role:slave
aof_current_size:17908619
aof_base_size:16787337
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
master_host:10.6.1.143
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_priority:100
db1:keys=250000,expires=0

master_link_status顯示為up，同步狀態正常。

在此次恢復的過程中，我們同時複製了AOF與RDB檔案，那麼到底是哪一個檔案完成了資料的恢復呢？
實際上，當Redis伺服器掛掉時，重啟時將按照以下優先順序恢復資料到記憶體：
1. 如果只配置AOF,重啟時載入AOF檔案恢復資料；
2. 如果同時 配置了RDB和AOF,啟動是隻載入AOF檔案恢復資料;
3. 如果只配置RDB,啟動是將載入dump檔案恢復資料。

也就是說，AOF的優先順序要高於RDB，這也很好理解，因為AOF本身對資料的完整性保障要高於RDB。

在此次的案例中，我們通過在Slave上啟用了AOF與RDB來保障了資料，並恢復了Master。

但在我們目前的線上環境中，由於資料都設定有過期時間，採用AOF的方式會不太實用，過於頻繁的寫操作會使AOF檔案增長到異常的龐大，大大超過了我們實際的資料量，這也會導致在進行資料恢復時耗用大量的時間。
因此，可以在Slave上僅開啟Snapshot來進行本地化，同時可以考慮將save中的頻率調高一些或者呼叫一個計劃任務來進行定期bgsave的快照儲存，來儘可能的保障本地化資料的完整性。
在這樣的架構下，如果僅僅是Master掛掉，Slave完整，資料恢復可達到100%。
如果Master與Slave同時掛掉的話，資料的恢復也可以達到一個可接受的程度。

相關推薦

redis資料丟失及解決

參考資料： Redis Persistence http://redis.io/topics/persistence Google Groups https://groups.google.com/forum/?fromgroups=#!forum/redis-db 一、對Redis持久化的探討與理解 目前

redis 叢集 資料丟失及解決方案 AOF RDB 資料恢復

參考資料： Redis Persistence http://redis.io/topics/persistence Google Groups https://groups.google.com/forum/?fromgroups=#!forum/redis-db 一、對Redis持久化的探討與理解

Redis持久化-資料丟失及解決

Redis的資料回寫機制Redis的資料回寫機制分同步和非同步兩種，同步回寫即SAVE命令，主程序直接向磁盤迴寫資料。在資料大的情況下會導致系統假死很長時間，所以一般不是推薦的。非同步回寫即BGSAVE命令，主程序fork後，複製自身並通過這個新的程序回寫磁碟，回寫結束後新程序自行關閉。由於這樣做不需要主程序

Redis資料"丟失"討論及規避和解決的幾點總結

Redis大部分應用場景是純快取服務，請求後端有Primary Storage的元件,如MySQL,HBase;請求Redis的鍵未命中，會從primary Storage中獲取資料返回，同時更新Redis快取。如果少量資料丟失，相當於請求"緩衝未命中"； 一般對業務的影響是

docker重啟redis、mysql資料丟失的解決方法

官方文件: 所以 mysql應如下啟動: docker run -p 3306:3306 -d -e MYSQL_ROOT

09.redis 哨兵主備切換時資料丟失的解決方案

## 一、兩種資料丟失的情況 * * * ### 1. 非同步複製導致的資料丟失   因為master->slave的複製是非同步的，所以可能有部分資料還沒複製到slave，master就宕機了，此時這些部分資料就丟失了 ### 2. 腦裂導致的資料丟失 **腦裂是什麼** &em

分布式Redis常見問題及解決方案精講

百萬 要求 軟件企業 參數 沒有 cpu redis 休眠 產生 前言考慮到絕大部分寫業務的程序員，在實際開發中使用 Redis 的時候，只會 Set Value 和 Get Value 兩個操作，對 Redis 整體缺乏一個認知。 所以我鬥膽以 Redis 為題材，對 R

redis資料型別及基本操作

Redis支援五種資料型別：string（字串），hash（雜湊），list（列表），set（集合）及zset(sorted set：有序集合) 一、string型別及基本操作 string 是 redis 最基本的型別，最大上限是1G 位元組。你可以理解成與 Memcached 一模一樣的型別，一個 k

Android Studio “Project Structure”選項目錄中的Android選項丟失及解決辦法

問題描述：從github中的專案匯入到Android Studio中時發現，缺少app資料夾，並且Project Structure中沒有了Android選線，急壞了，以為是匯入的專案有問題，就一直沿著這個方向查詢原因，github匯入工程的解決方案搜了一大堆，還是不行。然後

Uncaught DOMException: Blocked a frame with origin - 跨域資料問題及解決

遇到需要使用視窗的功能，是這樣的 ，A站點的a1頁面為主要顯示頁面，但是需要呼叫B站點的b1介面用來儲存資料到B站點上，然後再將b1頁面獲取的地址體現到a1頁面上，在呼叫頁面的關閉事件的時候遇到問題： Uncaught DOMException: Blocked a frame with

redis 資料結構及應用場景

1. String 常用命令： get、set、incr、decr、mget等 應用場景： String是最常用的資料型別，普通的key/value都可以歸為此類，value其實不僅是String，也可以是數字。 比如想知道什麼時候封鎖一個IP地址(訪問超過幾次)。INCRBY命令讓這些變得很容易，

history.back返回後資料丟失的解決辦法

‍js使用history.back返回表單資料丟失的主要原因就是使用了session_start();的原因，該函式會強制當前頁面不被快取。   解決辦法如下： 在你的 Session_start 函式後加入 header("Cache-control: private")

Redis 資料型別及常用操作指令

Redis 資料型別 redis支援五種資料型別：string（字串），hash（雜湊），list（列表），set（集合）及zset(sorted set：有序集合) **************************************************************

Spark資料傾斜及解決方案

一.場景 　　1.絕大多數task執行得都非常快，但個別task執行極慢。比如，總共有100個task，97個task都在1s之內執行完了，但是剩餘的task卻要一兩分鐘。這種情況很常見。 　　2.原本能夠正常執行的Spark作業，某天突然報出OOM(記憶體溢位)，觀察異常棧，是我們寫的業務程式碼造成的。

Redis資料型別及常用的操作命令——LIST操作

可以通過該網站檢視更多redis命令及資訊：http://redisdoc.com/ LPUSH key value [value …] 將一個或多個值 value 插入到列表 key 的表頭 如果有多個 value 值，那麼各個 value 值按從左到右的順序依次插入到表頭： 比如說，對空

Redis資料型別及常用的操作命令——String操作

可以通過該網站檢視更多redis命令及資訊：http://redisdoc.com/ set k v： 當set k1 v1後再次set k1 v2,則會覆蓋上一次的值； get key: 獲取key的value； del key： 刪除當前key； APPEND key value：

Redis資料型別及常用的操作命令——key操作

可以通過該網站檢視更多redis命令及資訊：http://redisdoc.com/ key： select：用於選擇redis的DB，redis的DB有0-16個數據庫。 keys /key：：遍歷該資料庫中的所有的key，key代表具體的key。 EXISTS key：代表是否存在

Redis資料型別及常用的操作命令——資料型別

Redis總共有5大資料型別,分列如下： String（字串）： string是redis最基本的型別，你可以理解成與Memcached一模一樣的型別，一個key對應一個value。 string型別是二進位制安全的。意思是redis的string可以包含任何資料。比如jpg圖片或者序列化的

Redis資料型別及常用的操作命令——hash操作

可以通過該網站檢視更多redis命令及資訊：http://redisdoc.com/ HSET key field value 將雜湊表 key 中的域 field 的值設為 value 。 如果 key 不存在，一個新的雜湊表被建立並進行 HSET 操作。 如果域 field 已經存在於雜

linux伺服器重啟後導致redis資料丟失

直接上解決方案： 1.找到 /etc/sysctl.conf vim /etc/sysctl.conf 2.在最後一行新增 vm.overcommit_memory = 1 3.wq儲存，用sysctl -p 使配置生效 sysctl -p 會返回新增的那一行，