记录一下redis常用运维命令

一、命令集

auth passwd 认证登录
TIME 查看时间戳与微秒数
DBSIZE 查看当前库中的key数量
BGREWRITEAOF 后台进程重写AOF
BGSAVE 后台保存rdb快照
SAVE 保存rdb快照
LASTSAVE 上次保存时间
SLAVEOF 设为slave服务器
FLUSHALL 清空所有db
FLUSHDB 清空当前db
SHUTDOWN[""|save|nosave] 断开连接,关闭服务器
SLOWLOG 显示慢查询
INFO 显示服务器信息
CONFIG GET 获取配置信息
CONFIG SET 设置配置信息
MONITOR 打开控制台
SYNC 主从同步
CLIENT LIST 客户端列表
CLIENT KILL 关闭某个客户端
CLIENT SETNAME 为客户端设置名字
CLIENT GETNAME 获取客户端名字

二、几个比较常用的命令

1. info命令(可以查看Redis 服务器的各种信息和统计数值)

# Server
redis_version:2.6.9
redis_git_sha1:00000000
redis_git_dirty:0
redis_mode:standalone
os:Linux 3.4.9-gentoo x86_64
arch_bits:64
multiplexing_api:epoll          # redis的事件循环机制
gcc_version:4.6.3
process_id:18926
run_id:df8ad7574f3ee5136e8be94aaa6602a0079704cc # 标识redis server的随机值
tcp_port:6379
uptime_in_seconds:120           # redis server启动的时间(单位s)
uptime_in_days:0                # redis server启动的时间(单位d)
lru_clock:321118                # Clock incrementing every minute, for LRU management TODO 不清楚是如何计算的

# Clients
connected_clients:3             # 连接的客户端数
client_longest_output_list:0    # 当前客户端连接的最大输出列表    TODO
client_biggest_input_buf:0      # 当前客户端连接的最大输入buffer TODO
blocked_clients:0               # 被阻塞的客户端数

# Memory
used_memory:573456              # 使用内存，单位B
used_memory_human:560.02K       # human read显示使用内存
used_memory_rss:1798144         # 系统给redis分配的内存（即常驻内存）
used_memory_peak:551744         # 内存使用的峰值大小
used_memory_peak_human:538.81K  # human read显示内存使用峰值
used_memory_lua:31744           # lua引擎使用的内存
mem_fragmentation_ratio:3.14    # used_memory_rss/used_memory比例，一般情况下，used_memory_rss略高于used_memory，当内存碎片较多时，则mem_fragmentation_ratio会较大，可以反映内存碎片是否很多
mem_allocator:jemalloc-3.3.1    # 内存分配器

# Persistence
##########################
# rdb和aof事redis的两种持久化机制
#
# rdb是通过配置文件设置save的时间的改动数量来操作
# 把上次改动后的数据达到设置的指标后保存到db
# 如果中间发生了crash，则数据会丢失
# 这种策略被叫做快照
#
# aof是持续的把写操作执行写入一个类似日志的文件
# 但是会影响应能
# 分为appendfsync always和appendfsync eversec
# 前者每次写操作都同步，数据安全性高，但是特别消耗性能
# 后者每秒同步一次，如果发生crash，则可能会丢失1s的数据
##########################
loading:0                       #
rdb_changes_since_last_save:0   # 自上次dump后rdb的改动
rdb_bgsave_in_progress:0        # 标识rdb save是否进行中
rdb_last_save_time:1366359865   # 上次save的时间戳
rdb_last_bgsave_status:ok       # 上次的save操作状态
rdb_last_bgsave_time_sec:-1     # 上次rdb save操作使用的时间(单位s)
rdb_current_bgsave_time_sec:-1  # 如果rdb save操作正在进行，则是所使用的时间
----------------------------
aof_enabled:0                   # 是否开启aof，默认没开启
aof_rewrite_in_progress:0       # 标识aof的rewrite操作是否在进行中
aof_rewrite_scheduled:0         # 标识是否将要在rdb save操作结束后执行
aof_last_rewrite_time_sec:-1    # 上次rewrite操作使用的时间(单位s)
aof_current_rewrite_time_sec:-1 # 如果rewrite操作正在进行，则记录所使用的时间
aof_last_bgrewrite_status:ok    # 上次rewrite操作的状态
-----------------------------
# 开启aof后增加的一些info信息
aof_current_size:0              # aof当前大小
aof_base_size:0                 # aof上次启动或rewrite的大小
aof_pending_rewrite:0           # 同上面的aof_rewrite_scheduled
aof_buffer_length:0             # aof buffer的大小
aof_rewrite_buffer_length:0     # aof rewrite buffer的大小
aof_pending_bio_fsync:0         # 后台IO队列中等待fsync任务的个数
aof_delayed_fsync:0             # 延迟的fsync计数器 TODO
-----------------------------

# Stats
total_connections_received:7    # 自启动起连接过的总数
total_commands_processed:7      # 自启动起运行命令的总数
instantaneous_ops_per_sec:0     # 每秒执行的命令个数
rejected_connections:0          # 因为最大客户端连接书限制，而导致被拒绝连接的个数
expired_keys:0                  # 自启动起过期的key的总数
evicted_keys:0                  # 因为内存大小限制，而被驱逐出去的键的个数
keyspace_hits:0                 # 在main dictionary(todo)中成功查到的key个数
keyspace_misses:0               # 同上，未查到的key的个数
pubsub_channels:0               # 发布/订阅频道数
pubsub_patterns:0               # 发布/订阅模式数
latest_fork_usec:0              # 上次的fork操作使用的时间（单位ms）
##########################
# pubsub是一种消息传送的方式，分为频道和模式两种
# 消息不支持持久化，消息方中断后再连接，前面的消息就会没了
# 频道是指通过SUBSCRIBE指定一个固定的频道来订阅
# 模式是指通过PSUBSCRIBE模式匹配来订阅相关的匹配给定模式的频道
##########################

# Replication
role:master                     # 角色
connected_slaves:1              # 连接的从库数
slave0:127.0.0.1,7777,online
-----------------------------
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0       # 标识主redis正在同步到从redis
slave_priority:100
slave_read_only:1
connected_slaves:0

# CPU
used_cpu_sys:0.00           # redis server的sys cpu使用率
used_cpu_user:0.12          # redis server的user cpu使用率
used_cpu_sys_children:0.00  # 后台进程的sys cpu使用率
used_cpu_user_children:0.00 # 后台进程的user cpu使用率

# Keyspace
db0:keys=2,expires=0
db1:keys=1,expires=0

2. config(可以查看redis配置属性值)

语法:[config get xxx]
例如:

//查看timeout配置
127.0.0.1:6379> config get timeout
1) "timeout"
2) "600"
127.0.0.1:6379>

同样的还有config set [属性] [属性值] ,给指定属性值设置参数。

3. client list(实时查看已经建立的连接)

127.0.0.1:6379> client list
id=13636 addr=10.1.60.25:57398 fd=106 name= age=28543 idle=6274 flags=N db=1 sub=0 psub=3 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=psubscribe
id=14071 addr=10.1.60.25:36923 fd=150 name= age=6342 idle=6 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=14116 addr=127.0.0.1:37037 fd=6 name= age=28 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
127.0.0.1:6379>

列一下client list中对应的字段含义:

以下是域的含义：
addr ： 客户端的地址和端口
fd ： 套接字所使用的文件描述符
age ： 以秒计算的已连接时长
idle ： 【以秒计算的空闲时长】
flags ： 客户端 flag
db ： 该客户端正在使用的数据库 ID
sub ： 已订阅频道的数量
psub ： 已订阅模式的数量
multi ： 在事务中被执行的命令数量
qbuf ： 查询缓冲区的长度（字节为单位， 0 表示没有分配查询缓冲区）
qbuf-free ： 查询缓冲区剩余空间的长度（字节为单位， 0 表示没有剩余空间）
obl ： 输出缓冲区的长度（字节为单位， 0 表示没有分配输出缓冲区）
oll ： 输出列表包含的对象数量（当输出缓冲区没有剩余空间时，命令回复会以字符串对象的形式被入队到这个队列里）
omem ： 输出缓冲区和输出列表占用的内存总量
events ： 文件描述符事件
cmd ： 最近一次执行的命令
客户端 flag 可以由以下部分组成：
O ： 客户端是 MONITOR 模式下的附属节点（slave）
S ： 客户端是一般模式下（normal）的附属节点
M ： 客户端是主节点（master）
x ： 客户端正在执行事务
b ： 客户端正在等待阻塞事件
i ： 客户端正在等待 VM I/O 操作（已废弃）
d ： 一个受监视（watched）的键已被修改， EXEC 命令将失败
c : 在将回复完整地写出之后，关闭链接
u : 客户端未被阻塞（unblocked）
A : 尽可能快地关闭连接
N : 未设置任何 flag
文件描述符事件可以是：
r : 客户端套接字（在事件 loop 中）是可读的（readable）
w : 客户端套接字（在事件 loop 中）是可写的（writeable）

如果发现idle中对应的值比较高,说明redis的timeout属性设置有问题。结合config get timeout查看一下超时时间,如果timeout为0,说明已经禁用掉该功能,就有可能导致redis连接数不释放的问题。

4. client kill（杀掉某个连接）

CLIENT KILL 127.0.0.1:43501

5. slowlog（查看redis慢查询）

Slow log 的行为由两个配置参数(configuration parameter)指定，可以通过改写 redis.conf 文件或者用 CONFIG GET 和 CONFIG SET 命令对它们动态地进行修改。
第一个选项是 slowlog-log-slower-than ，它决定要对执行时间大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的查询进行记录。
比如执行以下命令将让 slow log 记录所有查询时间大于等于 100 微秒的查询：
CONFIG SET slowlog-log-slower-than 100
而以下命令记录所有查询时间大于 1000 微秒的查询：
CONFIG SET slowlog-log-slower-than 1000
另一个选项是 slowlog-max-len ，它决定 slow log 最多能保存多少条日志， slow log 本身是一个 FIFO 队列，当队列大小超过 slowlog-max-len 时，最旧的一条日志将被删除，而最新的一条日志加入到 slow log ，以此类推。
以下命令让 slow log 最多保存 1000 条日志：
CONFIG SET slowlog-max-len 1000
使用 CONFIG GET 命令可以查询两个选项的当前值：

redis> CONFIG GET slowlog-log-slower-than
1) "slowlog-log-slower-than"
2) "1000"

redis> CONFIG GET slowlog-max-len
1) "slowlog-max-len"
2) "1000"

查看 slow log
要查看 slow log ，可以使用 SLOWLOG GET 或者 SLOWLOG GET number 命令，前者打印所有 slow log ，最大长度取决于 slowlog-max-len 选项的值，而 SLOWLOG GET number 则只打印指定数量的日志。
最新的日志会最先被打印：

为测试需要，将 slowlog-log-slower-than 设成了 10 微秒

redis> SLOWLOG GET
1) 1) (integer) 12                      # 唯一性(unique)的日志标识符
   2) (integer) 1324097834              # 被记录命令的执行时间点，以 UNIX 时间戳格式表示
   3) (integer) 16                      # 查询执行时间，以微秒为单位
   4) 1) "CONFIG"                       # 执行的命令，以数组的形式排列
      2) "GET"                          # 这里完整的命令是 CONFIG GET slowlog-log-slower-than
      3) "slowlog-log-slower-than"

2) 1) (integer) 11
   2) (integer) 1324097825
   3) (integer) 42
   4) 1) "CONFIG"
      2) "GET"
      3) "*"

3) 1) (integer) 10
   2) (integer) 1324097820
   3) (integer) 11
   4) 1) "CONFIG"
      2) "GET"
      3) "slowlog-log-slower-than"

日志的唯一 id 只有在 Redis 服务器重启的时候才会重置，这样可以避免对日志的重复处理(比如你可能会想在每次发现新的慢查询时发邮件通知你)。
查看当前日志的数量
使用命令 SLOWLOG LEN 可以查看当前日志的数量。
请注意这个值和 slower-max-len 的区别，它们一个是当前日志的数量，一个是允许记录的最大日志的数量。

redis> SLOWLOG LEN
(integer) 14

清空日志
使用命令 SLOWLOG RESET 可以清空 slow log 。

redis> SLOWLOG LEN
(integer) 14
redis> SLOWLOG RESET
OK
redis> SLOWLOG LEN
(integer) 0

6. Redis-benchmark测试Redis性能

Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]

 -h <hostname>      Server hostname (default 127.0.0.1)
 -p <port>          Server port (default 6379)
 -s <socket>        Server socket (overrides host and port)
 -c <clients>       Number of parallel connections (default 50)
 -n <requests>      Total number of requests (default 10000)
 -d <size>          Data size of SET/GET value in bytes (default 2)
 -k <boolean>       1=keep alive 0=reconnect (default 1)
 -r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD
  Using this option the benchmark will get/set keys
  in the form mykey_rand:000000012456 instead of constant
  keys, the <keyspacelen> argument determines the max
  number of values for the random number. For instance
  if set to 10 only rand:000000000000 - rand:000000000009
  range will be allowed.
 -P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline).
 -q                 Quiet. Just show query/sec values
 --csv              Output in CSV format
 -l                 Loop. Run the tests forever
 -t <tests>         Only run the comma-separated list of tests. The test
                    names are the same as the ones produced as output.
 -I                 Idle mode. Just open N idle connections and wait.

测试命令事例：
1、redis-benchmark -h 192.168.1.201 -p 6379 -c 100 -n 100000
100个并发连接，100000个请求，检测host为localhost 端口为6379的redis服务器性能
2、redis-benchmark -h 192.168.1.201 -p 6379 -q -d 100
测试存取大小为100字节的数据包的性能
3、redis-benchmark -t set,lpush -n 100000 -q
只测试某些操作的性能
4、redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
只测试某些数值存取的性能

测试结果分析:

requests completed in 0.30 seconds
parallel clients
bytes payload
  keep alive: 1

0.11% <= 1 milliseconds
86.00% <= 2 milliseconds
90.12% <= 3 milliseconds
96.68% <= 4 milliseconds
99.27% <= 5 milliseconds
99.54% <= 6 milliseconds
99.69% <= 7 milliseconds
99.78% <= 8 milliseconds
99.89% <= 9 milliseconds
100.00% <= 9 milliseconds
33222.59 requests per second

====== PING_BULK ======
requests completed in 0.27 seconds
parallel clients
bytes payload
  keep alive: 1

0.93% <= 1 milliseconds
97.66% <= 2 milliseconds
100.00% <= 2 milliseconds
37174.72 requests per second

====== SET ======
requests completed in 0.32 seconds
parallel clients
bytes payload
  keep alive: 1

0.22% <= 1 milliseconds
91.68% <= 2 milliseconds
97.78% <= 3 milliseconds
98.80% <= 4 milliseconds
99.38% <= 5 milliseconds
99.61% <= 6 milliseconds
99.72% <= 7 milliseconds
99.83% <= 8 milliseconds
99.94% <= 9 milliseconds
100.00% <= 9 milliseconds
30959.75 requests per second

====== GET ======
requests completed in 0.28 seconds
parallel clients
bytes payload
  keep alive: 1

0.55% <= 1 milliseconds
98.86% <= 2 milliseconds
100.00% <= 2 milliseconds
35971.22 requests per second

====== INCR ======
requests completed in 0.14 seconds
parallel clients
bytes payload
  keep alive: 1

95.61% <= 1 milliseconds
100.00% <= 1 milliseconds
69444.45 requests per second

====== LPUSH ======
requests completed in 0.21 seconds
parallel clients
bytes payload
  keep alive: 1

18.33% <= 1 milliseconds
100.00% <= 1 milliseconds
48309.18 requests per second

====== LPOP ======
requests completed in 0.23 seconds
parallel clients
bytes payload
  keep alive: 1

0.29% <= 1 milliseconds
99.76% <= 2 milliseconds
100.00% <= 2 milliseconds
44052.86 requests per second

====== SADD ======
requests completed in 0.22 seconds
parallel clients
bytes payload
  keep alive: 1

2.37% <= 1 milliseconds
99.81% <= 2 milliseconds
100.00% <= 2 milliseconds
44444.45 requests per second

====== SPOP ======
requests completed in 0.22 seconds
parallel clients
bytes payload
  keep alive: 1

4.27% <= 1 milliseconds
99.84% <= 2 milliseconds
100.00% <= 2 milliseconds
44642.86 requests per second

====== LPUSH (needed to benchmark LRANGE) ======
requests completed in 0.22 seconds
parallel clients
bytes payload
  keep alive: 1

12.35% <= 1 milliseconds
99.62% <= 2 milliseconds
100.00% <= 2 milliseconds
46082.95 requests per second

====== LRANGE_100 (first 100 elements) ======
requests completed in 0.48 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 1 milliseconds
3.27% <= 2 milliseconds
98.71% <= 3 milliseconds
99.93% <= 4 milliseconds
100.00% <= 4 milliseconds
20964.36 requests per second

====== LRANGE_300 (first 300 elements) ======
requests completed in 1.26 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 2 milliseconds
0.14% <= 3 milliseconds
0.90% <= 4 milliseconds
7.03% <= 5 milliseconds
31.68% <= 6 milliseconds
78.93% <= 7 milliseconds
98.88% <= 8 milliseconds
99.56% <= 9 milliseconds
99.72% <= 10 milliseconds
99.95% <= 11 milliseconds
100.00% <= 11 milliseconds
7961.78 requests per second

====== LRANGE_500 (first 450 elements) ======
requests completed in 1.82 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 2 milliseconds
0.06% <= 3 milliseconds
0.14% <= 4 milliseconds
0.30% <= 5 milliseconds
0.99% <= 6 milliseconds
2.91% <= 7 milliseconds
8.11% <= 8 milliseconds
43.15% <= 9 milliseconds
88.38% <= 10 milliseconds
97.25% <= 11 milliseconds
98.61% <= 12 milliseconds
99.26% <= 13 milliseconds
99.30% <= 14 milliseconds
99.44% <= 15 milliseconds
99.48% <= 16 milliseconds
99.64% <= 17 milliseconds
99.85% <= 18 milliseconds
99.92% <= 19 milliseconds
99.95% <= 20 milliseconds
99.96% <= 21 milliseconds
99.97% <= 22 milliseconds
100.00% <= 23 milliseconds
5491.49 requests per second

====== LRANGE_600 (first 600 elements) ======
requests completed in 2.29 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 2 milliseconds
0.05% <= 3 milliseconds
0.10% <= 4 milliseconds
0.19% <= 5 milliseconds
0.34% <= 6 milliseconds
0.46% <= 7 milliseconds
0.58% <= 8 milliseconds
4.46% <= 9 milliseconds
21.80% <= 10 milliseconds
40.48% <= 11 milliseconds
60.14% <= 12 milliseconds
79.81% <= 13 milliseconds
93.77% <= 14 milliseconds
97.14% <= 15 milliseconds
98.67% <= 16 milliseconds
99.08% <= 17 milliseconds
99.30% <= 18 milliseconds
99.41% <= 19 milliseconds
99.52% <= 20 milliseconds
99.61% <= 21 milliseconds
99.79% <= 22 milliseconds
99.88% <= 23 milliseconds
99.89% <= 24 milliseconds
99.95% <= 26 milliseconds
99.96% <= 27 milliseconds
99.97% <= 28 milliseconds
99.98% <= 29 milliseconds
100.00% <= 29 milliseconds
4359.20 requests per second

====== MSET (10 keys) ======
requests completed in 0.37 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 1 milliseconds
2.00% <= 2 milliseconds
18.41% <= 3 milliseconds
88.55% <= 4 milliseconds
96.09% <= 5 milliseconds
99.50% <= 6 milliseconds
99.65% <= 7 milliseconds
99.75% <= 8 milliseconds
99.77% <= 9 milliseconds
99.78% <= 11 milliseconds
99.79% <= 12 milliseconds
99.80% <= 13 milliseconds
99.81% <= 15 milliseconds
99.82% <= 16 milliseconds
99.83% <= 17 milliseconds
99.84% <= 19 milliseconds
99.85% <= 21 milliseconds
99.86% <= 23 milliseconds
99.87% <= 24 milliseconds
99.88% <= 25 milliseconds
99.89% <= 27 milliseconds
99.90% <= 28 milliseconds
99.91% <= 30 milliseconds
99.92% <= 32 milliseconds
99.93% <= 34 milliseconds
99.95% <= 35 milliseconds
99.96% <= 36 milliseconds
99.97% <= 37 milliseconds
99.98% <= 39 milliseconds
99.99% <= 41 milliseconds
100.00% <= 41 milliseconds
27173.91 requests per second

参考文档:http://www.cnblogs.com/silent2012/p/4514901.html
http://www.runoob.com/redis/server-client-list.html
http://dba10g.blog.51cto.com/764602/1846068
http://blog.csdn.net/cxhgg/article/details/67640263

最后编辑于：2017.12.11 06:58:53

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 203,937评论 6赞 478
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 85,503评论 2赞 381
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 150,712评论 0赞 337
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 54,668评论 1赞 276
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 63,677评论 5赞 366
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 48,601评论 1赞 281
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 37,975评论 3赞 396
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 36,637评论 0赞 258
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 40,881评论 1赞 298
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 35,621评论 2赞 321
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 37,710评论 1赞 329
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 33,387评论 4赞 319
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 38,971评论 3赞 307
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 29,947评论 0赞 19
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 31,189评论 1赞 260
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 44,805评论 2赞 349
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 42,449评论 2赞 342