redis 持久化

介紹

首先，我們應(yīng)該明確持久化的數(shù)據(jù)有什么用，答案是用于重啟后的數(shù)據(jù)恢復(fù)。
Redis是一個(gè)內(nèi)存數(shù)據(jù)庫(kù)，無(wú)論是RDB還是AOF，都只是其保證數(shù)據(jù)恢復(fù)的措施。
所以Redis在利用RDB和AOF進(jìn)行恢復(fù)的時(shí)候，都會(huì)讀取RDB或AOF文件，重新加載到內(nèi)存中。

Redis持久化的方式

RDB
AOF

RDB

RDB就是Snapshot快照存儲(chǔ)，是默認(rèn)的持久化方式。
可理解為半持久化模式，即按照一定的策略周期性的將數(shù)據(jù)保存到磁盤。
對(duì)應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb，通過(guò)配置文件中的save參數(shù)來(lái)定義快照的周期。
下面是默認(rèn)的快照設(shè)置：
- save 900 1 #當(dāng)有一條Keys數(shù)據(jù)被改變時(shí)，900秒刷新到Disk一次
- save 300 10 #當(dāng)有10條Keys數(shù)據(jù)被改變時(shí)，300秒刷新到Disk一次
- save 60 10000#當(dāng)有10000條Keys數(shù)據(jù)被改變時(shí)，60秒刷新到Disk一次

Redis的RDB文件不會(huì)壞掉，因?yàn)槠鋵?xiě)操作是在一個(gè)新進(jìn)程中進(jìn)行的。
當(dāng)生成一個(gè)新的RDB文件時(shí)，Redis生成的子進(jìn)程會(huì)先將數(shù)據(jù)寫(xiě)到一個(gè)臨時(shí)文件中，然后通過(guò)原子性rename系統(tǒng)調(diào)用將臨時(shí)文件重命名為RDB文件。
這樣在任何時(shí)候出現(xiàn)故障，Redis的RDB文件都總是可用的。
同時(shí)，Redis的RDB文件也是Redis主從同步內(nèi)部實(shí)現(xiàn)中的一環(huán)。

第一次Slave向Master同步的實(shí)現(xiàn)是：
* Slave向Master發(fā)出同步請(qǐng)求，Master先dump出rdb文件，然后將rdb文件全量傳輸給slave，然后Master把緩存的命令轉(zhuǎn)發(fā)給Slave，初次同步完成。

第二次以及以后的同步實(shí)現(xiàn)是：
* Master將變量的快照直接實(shí)時(shí)依次發(fā)送給各個(gè)Slave。但不管什么原因?qū)е耂lave和Master斷開(kāi)重連都會(huì)重復(fù)以上兩個(gè)步驟的過(guò)程。

Redis的主從復(fù)制是建立在內(nèi)存快照的持久化基礎(chǔ)上的，只要有Slave就一定會(huì)有內(nèi)存快照發(fā)生。

可以很明顯的看到，RDB有它的不足，就是一旦數(shù)據(jù)庫(kù)出現(xiàn)問(wèn)題，那么我們的RDB文件中保存的數(shù)據(jù)并不是全新的。

從上次RDB文件生成到Redis停機(jī)這段時(shí)間的數(shù)據(jù)全部丟掉了。

AOF

AOF(Append-Only File)比RDB方式有更好的持久化性。

由于在使用AOF持久化方式時(shí)，Redis會(huì)將每一個(gè)收到的寫(xiě)命令都通過(guò)Write函數(shù)追加到文件中，類似于MySQL的binlog。

當(dāng)Redis重啟是會(huì)通過(guò)重新執(zhí)行文件中保存的寫(xiě)命令來(lái)在內(nèi)存中重建整個(gè)數(shù)據(jù)庫(kù)的內(nèi)容。

對(duì)應(yīng)的設(shè)置參數(shù)為：
$ vim /opt/redis/etc/redis_6379.conf

appendonly yes 啟用AOF持久化方式
appendfilename appendonly.aof #AOF文件的名稱，默認(rèn)為appendonly.aof
appendfsync always 每次收到寫(xiě)命令就立即強(qiáng)制寫(xiě)入磁盤，是最有保證的完全的持久化，但速度也是最慢的，一般不推薦使用。
appendfsync everysec 每秒鐘強(qiáng)制寫(xiě)入磁盤一次，在性能和持久化方面做了很好的折中，是受推薦的方式。
appendfsync no #完全依賴OS的寫(xiě)入，一般為30秒左右一次，性能最好但是持久化最沒(méi)有保證，不被推薦。

AOF的完全持久化方式同時(shí)也帶來(lái)了另一個(gè)問(wèn)題，持久化文件會(huì)變得越來(lái)越大。

比如我們調(diào)用INCR test命令100次，文件中就必須保存全部的100條命令，但其實(shí)99條都是多余的。

因?yàn)橐謴?fù)數(shù)據(jù)庫(kù)的狀態(tài)其實(shí)文件中保存一條SET test 100就夠了。

為了壓縮AOF的持久化文件，Redis提供了bgrewriteaof命令。

收到此命令后Redis將使用與快照類似的方式將內(nèi)存中的數(shù)據(jù)以命令的方式保存到臨時(shí)文件中，最后替換原來(lái)的文件，以此來(lái)實(shí)現(xiàn)控制AOF文件的增長(zhǎng)。

由于是模擬快照的過(guò)程，因此在重寫(xiě)AOF文件時(shí)并沒(méi)有讀取舊的AOF文件，而是將整個(gè)內(nèi)存中的數(shù)據(jù)庫(kù)內(nèi)容用命令的方式重寫(xiě)了一個(gè)新的AOF文件。

對(duì)應(yīng)的設(shè)置參數(shù)為:
$vim /opt/redis/etc/redis_6379.conf

no-appendfsync-on-rewrite yes

在日志重寫(xiě)時(shí)，不進(jìn)行命令追加操作，而只是將其放在緩沖區(qū)里，避免與命令的追加造成DISK IO上的沖突。
auto-aof-rewrite-percentage 100

當(dāng)前AOF文件大小是上次日志重寫(xiě)得到AOF文件大小的二倍時(shí)，自動(dòng)啟動(dòng)新的日志重寫(xiě)過(guò)程。
auto-aof-rewrite-min-size 64mb #當(dāng)前AOF文件啟動(dòng)新的日志重寫(xiě)過(guò)程的最小值，避免剛剛啟動(dòng)Reids時(shí)由于文件尺寸較小導(dǎo)致頻繁的重寫(xiě)。

選擇

到底選擇什么呢？下面是來(lái)自官方的建議：

通常，如果你要想提供很高的數(shù)據(jù)保障性，那么建議你同時(shí)使用兩種持久化方式。
如果你可以接受災(zāi)難帶來(lái)的幾分鐘的數(shù)據(jù)丟失，那么你可以僅使用RDB。
很多用戶僅使用了AOF，但是我們建議，既然RDB可以時(shí)不時(shí)的給數(shù)據(jù)做個(gè)完整的快照，并且提供更快的重啟，所以最好還是也使用RDB。
因此，我們希望可以在未來(lái)（長(zhǎng)遠(yuǎn)計(jì)劃）統(tǒng)一AOF和RDB成一種持久化模式。

在數(shù)據(jù)恢復(fù)方面

RDB的啟動(dòng)時(shí)間會(huì)更短，原因有兩個(gè)：

是RDB文件中每一條數(shù)據(jù)只有一條記錄，不會(huì)像AOF日志那樣可能有一條數(shù)據(jù)的多次操作記錄。所以每條數(shù)據(jù)只需要寫(xiě)一次就行了。
另一個(gè)原因是RDB文件的存儲(chǔ)格式和Redis數(shù)據(jù)在內(nèi)存中的編碼格式是一致的，不需要再進(jìn)行數(shù)據(jù)編碼工作，所以在CPU消耗上要遠(yuǎn)小于AOF日志的加載。
災(zāi)難恢復(fù)模擬
既然持久化的數(shù)據(jù)的作用是用于重啟后的數(shù)據(jù)恢復(fù)，那么我們就非常有必要進(jìn)行一次這樣的災(zāi)難恢復(fù)模擬了。
據(jù)稱如果數(shù)據(jù)要做持久化又想保證穩(wěn)定性，則建議留空一半的物理內(nèi)存。因?yàn)樵谶M(jìn)行快照的時(shí)候，fork出來(lái)進(jìn)行dump操作的子進(jìn)程會(huì)占用與父進(jìn)程一樣的內(nèi)存，真正的copy-on-write，對(duì)性能的影響和內(nèi)存的耗用都是比較大的。
目前，通常的設(shè)計(jì)思路是利用Replication機(jī)制來(lái)彌補(bǔ)aof、snapshot性能上的不足，達(dá)到了數(shù)據(jù)可持久化。

即Master上Snapshot和AOF都不做，來(lái)保證Master的讀寫(xiě)性能，而Slave上則同時(shí)開(kāi)啟Snapshot和AOF來(lái)進(jìn)行持久化，保證數(shù)據(jù)的安全性。

首先，修改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 #每秒鐘強(qiáng)制寫(xiě)入磁盤一次

appendfsync no

no-appendfsync-on-rewrite yes #在日志重寫(xiě)時(shí)，不進(jìn)行命令追加操作

auto-aof-rewrite-percentage 100 #自動(dòng)啟動(dòng)新的日志重寫(xiě)過(guò)程

auto-aof-rewrite-min-size 64mb #啟動(dòng)新的日志重寫(xiě)過(guò)程的最小值

分別啟動(dòng)Master與Slave

$ /etc/init.d/redis start

啟動(dòng)完成后在Master中確認(rèn)未啟動(dòng)Snapshot參數(shù)

redis 127.0.0.1:6379> CONFIG GET save

"save"
""

然后通過(guò)以下腳本在Master中生成25萬(wàn)條數(shù)據(jù)：

dongguo@redis:/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

dongguo@redis:/opt/redis/data/6379$ ./redis-cli-generate.temp.sh

在數(shù)據(jù)的生成過(guò)程中，可以很清楚的看到Master上僅在第一次做Slave同步時(shí)創(chuàng)建了dump.rdb文件，之后就通過(guò)增量傳輸命令的方式給Slave了。
dump.rdb文件沒(méi)有再增大。

dongguo@redis:/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文件的增長(zhǎng)速度明顯大于dump.rdb文件。

dongguo@redis-slave:/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

等待數(shù)據(jù)插入完成以后，首先確認(rèn)當(dāng)前的數(shù)據(jù)量。

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

當(dāng)前的數(shù)據(jù)量為25萬(wàn)條key，占用內(nèi)存31.52M。

然后我們直接Kill掉Master的Redis進(jìn)程，模擬災(zāi)難。

dongguo@redis:/opt/redis/data/6379$ sudo killall -9 redis-server

我們到Slave中查看狀態(tài)：

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的狀態(tài)已經(jīng)是down了，Master已經(jīng)不可訪問(wèn)了。

而此時(shí)，Slave依然運(yùn)行良好，并且保留有AOF與RDB文件。

下面我們將通過(guò)Slave上保存好的AOF與RDB文件來(lái)恢復(fù)Master上的數(shù)據(jù)。

首先，將Slave上的同步狀態(tài)取消，避免主庫(kù)在未完成數(shù)據(jù)恢復(fù)前就重啟，進(jìn)而直接覆蓋掉從庫(kù)上的數(shù)據(jù)，導(dǎo)致所有的數(shù)據(jù)丟失。

redis 127.0.0.1:6379> SLAVEOF NO ONE

確認(rèn)一下已經(jīng)沒(méi)有了master相關(guān)的配置信息：

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上復(fù)制數(shù)據(jù)文件：

dongguo@redis-slave:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *

appendonly.aof

dump.rdb

將data.tar上傳到Master上，嘗試恢復(fù)數(shù)據(jù):

可以看到Master目錄下有一個(gè)初始化Slave的數(shù)據(jù)文件，很小，將其刪除。

dongguo@redis:/opt/redis/data/6379$ ls -l

total 4

-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb

dongguo@redis:/opt/redis/data/6379$ sudo rm -f dump.rdb

然后解壓縮數(shù)據(jù)文件：

dongguo@redis:/opt/redis/data/6379$ sudo tar xf /home/dongguo/data.tar

dongguo@redis:/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

啟動(dòng)Master上的Redis；

dongguo@redis:/opt/redis/data/6379$ sudo /etc/init.d/redis start

Starting Redis server...

查看數(shù)據(jù)是否恢復(fù)：

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萬(wàn)條數(shù)據(jù)已經(jīng)完整恢復(fù)到了Master上。

此時(shí)，可以放心的恢復(fù)Slave的同步設(shè)置了。

redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379

查看同步狀態(tài)：

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，同步狀態(tài)正常。

在此次恢復(fù)的過(guò)程中，我們同時(shí)復(fù)制了AOF與RDB文件，那么到底是哪一個(gè)文件完成了數(shù)據(jù)的恢復(fù)呢？

實(shí)際上，當(dāng)Redis服務(wù)器掛掉時(shí)，重啟時(shí)將按照以下優(yōu)先級(jí)恢復(fù)數(shù)據(jù)到內(nèi)存：

如果只配置AOF,重啟時(shí)加載AOF文件恢復(fù)數(shù)據(jù)；
如果同時(shí) 配置了RDB和AOF,啟動(dòng)是只加載AOF文件恢復(fù)數(shù)據(jù);
如果只配置RDB,啟動(dòng)是將加載dump文件恢復(fù)數(shù)據(jù)。

也就是說(shuō)，AOF的優(yōu)先級(jí)要高于RDB，這也很好理解，因?yàn)锳OF本身對(duì)數(shù)據(jù)的完整性保障要高于RDB。

在此次的案例中，我們通過(guò)在Slave上啟用了AOF與RDB來(lái)保障了數(shù)據(jù)，并恢復(fù)了Master。

但在我們目前的線上環(huán)境中，由于數(shù)據(jù)都設(shè)置有過(guò)期時(shí)間，采用AOF的方式會(huì)不太實(shí)用，過(guò)于頻繁的寫(xiě)操作會(huì)使AOF文件增長(zhǎng)到異常的龐大，大大超過(guò)了我們實(shí)際的數(shù)據(jù)量，這也會(huì)導(dǎo)致在進(jìn)行數(shù)據(jù)恢復(fù)時(shí)耗用大量的時(shí)間。
因此，可以在Slave上僅開(kāi)啟Snapshot來(lái)進(jìn)行本地化，同時(shí)可以考慮將save中的頻率調(diào)高一些或者調(diào)用一個(gè)計(jì)劃任務(wù)來(lái)進(jìn)行定期bgsave的快照存儲(chǔ)，來(lái)盡可能的保障本地化數(shù)據(jù)的完整性。

在這樣的架構(gòu)下，如果僅僅是Master掛掉，Slave完整，數(shù)據(jù)恢復(fù)可達(dá)到100%。
如果Master與Slave同時(shí)掛掉的話，數(shù)據(jù)的恢復(fù)也可以達(dá)到一個(gè)可接受的程度。

image

最后編輯于：2019.06.01 18:21:12

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

人面猴
序言：七十年代末，一起剝皮案震驚了整個(gè)濱河市，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
沈念sama閱讀 227,967評(píng)論 6贊 531
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場(chǎng)離奇詭異，居然都是意外死亡，警方通過(guò)查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 98,273評(píng)論 3贊 415
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)，“玉大人，你說(shuō)我怎么就攤上這事。” “怎么了？”我有些...
開(kāi)封第一講書(shū)人閱讀 175,870評(píng)論 0贊 373
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長(zhǎng)。經(jīng)常有香客問(wèn)我，道長(zhǎng)，這世上最難降的妖魔是什么？我笑而不...
開(kāi)封第一講書(shū)人閱讀 62,742評(píng)論 1贊 309
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當(dāng)我...
茶點(diǎn)故事閱讀 71,527評(píng)論 6贊 407
惡毒庶女頂嫁案：這布局不是一般人想出來(lái)的
文/花漫我一把揭開(kāi)白布。她就那樣靜靜地躺著，像睡著了一般。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發(fā)上，一...
開(kāi)封第一講書(shū)人閱讀 55,010評(píng)論 1贊 322
城市分裂傳說(shuō)
那天，我揣著相機(jī)與錄音，去河邊找鬼。笑死，一個(gè)胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的。我是一名探鬼主播，決...
沈念sama閱讀 43,108評(píng)論 3贊 440
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開(kāi)眼，長(zhǎng)吁一口氣：“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼！你這毒婦竟也來(lái)了？” 一聲冷哼從身側(cè)響起，我...
開(kāi)封第一講書(shū)人閱讀 42,250評(píng)論 0贊 288
萬(wàn)榮殺人案實(shí)錄
序言：老撾萬(wàn)榮一對(duì)情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒(méi)想到半個(gè)月后，有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體，經(jīng)...
沈念sama閱讀 48,769評(píng)論 1贊 333
?護(hù)林員之死
正文獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點(diǎn)故事閱讀 40,656評(píng)論 3贊 354
?白月光啟示錄
正文我和宋清朗相戀三年，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
茶點(diǎn)故事閱讀 42,853評(píng)論 1贊 369
活死人
序言：一個(gè)原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
沈念sama閱讀 38,371評(píng)論 5贊 358
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布，位于F島的核電站，受9級(jí)特大地震影響，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜，卻給世界環(huán)境...
茶點(diǎn)故事閱讀 44,103評(píng)論 3贊 347
男人毒藥：我在死后第九天來(lái)索命
文/蒙蒙一、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
開(kāi)封第一講書(shū)人閱讀 34,472評(píng)論 0贊 26
一樁弒父案，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽(yáng)。三九已至，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背。一陣腳步聲響...
開(kāi)封第一講書(shū)人閱讀 35,717評(píng)論 1贊 281
情欲美人皮
我被黑心中介騙來(lái)泰國(guó)打工，沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。一個(gè)月前我還...
沈念sama閱讀 51,487評(píng)論 3贊 390
代替公主和親
正文我出身青樓，卻偏偏與公主長(zhǎng)得像，于是被迫代替她去往敵國(guó)和親。傳聞我的和親對(duì)象是個(gè)殘疾皇子，可洞房花燭夜當(dāng)晚...
茶點(diǎn)故事閱讀 47,815評(píng)論 2贊 372

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

redis 持久化

redis 持久化

介紹

Redis持久化的方式

RDB

AOF

選擇

在數(shù)據(jù)恢復(fù)方面

推薦閱讀更多精彩內(nèi)容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

redis 持久化

介紹

Redis持久化的方式

RDB

AOF

選擇

在數(shù)據(jù)恢復(fù)方面

推薦閱讀更多精彩內(nèi)容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频