Redis6 默认配置文件解读

+默认配置打开
- 默认配置关闭

network 网络

+ bind

# 绑定IP
bind 127.0.0.1

默认是127.0.0.1,修改的 IP 如果不为本机 IP 是无法启动的。可以直接注释 bind,这样所有机器可连,但会受 protected-mode 参数影响。

+ protected-mode

# 受保护的 默认开启
protected-mode yes

保护模式下,无论 bind 是否被注释都无法远程访问。想允许外网或局域网访问需要关闭保护模式,且注释 bind。

+ port

### 端口默认
port 6379

+ tcp-backlog

tcp-backlog 511

Linux内核为每个TCP服务器程序维护两条backlog队列,一条是TCP层的未连接队列,一条是应用层的已连接队列,分别对应net.ipv4.tcp_max_syn_backlog和net.core.somaxconn两个内核参数。

一个客户端连接在完成TCP 3次握手之前首先进入到未连接队列,完成握手之后正式建立连接,进入已连接队列,交付给应用程序处理。应用程序调用accept()函数从已连接队列取出连接进行处理。应用层在调用listen()函数时指定的backlog是已连接队列大小,如果大于somaxconn将被设为somaxconn。

如果应用层不调用accept()函数处理一个连接,或者处理不及时的话,将会导致已连接队列堆满。已连接队列已满的话会导致未连接队列在处理完3次握手之后无法进入已连接队列,最终也导致未连接队列堆满,在服务器看到处于未连接队列中的连接状态为SYN_RECV。 新进来的客户端连接将会一直处于SYN_SENT状态等待服务器的ACK应答,最终导致连接超时。

查看队列大小

查看未连接队列默认值:

cat /proc/sys/net/ipv4/tcp_max_syn_backlog

查看已连接队列默认值:

cat /proc/sys/net/core/somaxconn
修改队列大小

可以直接改写这两个文件的值。要永久修改这两个内核参数的话可以写到/etc/sysctl.conf

net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 1024

改完后执行sysctl -p 让修改立即生效。

timeout

timeout 0

客户端闲置N秒后关闭连接(0禁用)

tcp-keepalive

tcp-keepalive 300

向客户端发送 TCP ACK 检测连接是否断开,保证连接活跃。单位秒,默认300秒发送一次,如果等于0 就是禁用。

general 一般

daemonize

daemonize no

默认情况下,Redis不会作为守护程序运行。如果需要,请设置为 yes。请注意,Redis守护进程将在/var/run/redis.pid中写入一个pid文件。

supervised

supervised no

如果需要在机器启动(upstart模式 或systemd模式)时就启动Redis服务器,可以通过该选项来配置Redis。

  • supervised no - 不会与supervised tree进行交互
  • supervised upstart - 将Redis服务器添加到SIGSTOP 模式中
  • supervised systemd - 将READY=1 写入 $NOTIFY_SOCKET
  • supervised auto - 根据环境变量UPSTART_JOB 或 NOTIFY_SOCKET检测upstart 还是 systemd

上述 supervision 方法(upstart或systemd)仅发出“程序已就绪”信号,不会继续给supervisor返回ping回复。

pidfile

pidfile /var/run/redis_6379.pid

当Redis服务器已守护进程启动时,如果指定了配置文件,则直接使用,如果没有指定,则创建/var/run/redis.pid作为配置文件。

loglevel

loglevel notice

指定服务器的 verbosity 级别。Redis提供四种级别:

  • debug 包含大量信息,用于开发和测试
  • verbose 包含一些稀有的有用信息,但没有debug级别混乱
  • notice 适量提示信息,用于生产环境
  • warning 只包含非常重要和关键的信息

logfile

logfile ""

指定日志文件名称。指定为空时将输出到标准输出设备中。如果Redis以守护进程启动,当日志文件名称为空时,日志将会输出到 /dev/null。

databases

databases 16

设置数据库的数量。默认使用0号数据库。可以在每一个连接上使用SELECT <dbid> 来指定另外的数据库,但是这个值必须在 0到 ‘database' -1 之间。

always-show-logo

always-show-logo yes

redis 启动的时候显示 日志。

snapshotting 快照

save

save 900 1
save 300 10
save 60 10000

过了900秒并且有1个key发生了改变,触发save动作
过了300秒并且有10个key发生了改变,触发save动作
过了60秒并且至少有10000个key发生了改变,触发save动作

stop-writes-on-bgsave-error

stop-writes-on-bgsave-error yes

默认值为yes。当启用了RDB且最后一次后台保存数据失败,Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上,否则没有人会注意到灾难(disaster)发生了。如果Redis重启了,那么又可以重新开始接收数据了

rdbcompression

rdbcompression yes

默认值是yes。对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能,但是存储在磁盘上的快照会比较大。

rdbchecksum

rdbchecksum yes

在存储快照后,我们还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能。

dbfilename

dbfilename dump.rdb

rdb 文件得文件名称

rdb-del-sync-files

rdb-del-sync-files no

rdb文件是否删除同步锁

dir ./

设置 rdb 文件存放得路径

创建rdb文件机制

fork出一个子进程来处理,它和父进程共享内存里面的代码段和数据段。这时你可以把父子进程想象成一个连体婴儿,他们在共享身体。这就是Linux操作系统的机制,为了节约内存资源,所以尽可能让他们共享起来。在进程分离的一瞬间,内存的增长几乎没有明显变化。

子进程做数据持久化,不会修改现有的内存数据结构,它只是对数据结构进行遍历读取,然后序列化到磁盘中。但是父进程不一样,它必须持续服务客户请求,然后堆内存数据结构进行不间断的修改。

这个时候就会使用操作系统的 COW(copy on write) 机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成,当父进程对其中一个页面的数据进行修改时,会将被共享的页面复制一份分离出来,然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的,还是进程产生那一瞬间的数据。

随着父进程修改操作的持续进行,越来越多的共享页面被分离出来,内存就会持续增长,但是也不会超过原有数据内存的2倍大小。另外,Redis实例里冷数据占的比例往往是比较高的,所以很少会出现所有的页面都被分离的情况,被分离的往往只有其中一部分页面。每个页面的大小只有 4KB,一个Redis实例里面一般都会有成千上万个页面。

子进程因为数据没有变化,它能看到内存里的数据在进程产生的一瞬间就凝固了,再也不会改变,这也时为什么redis的持久化叫 快照 的原因。接下来子进程就可以非常安心地便利数据,进行序列化磁盘了。

replication 主从复制

replica-serve-stale-data

replica-serve-stale-data yes

当一个slave与master失去联系时,或者复制正在进行的时候,slave应对请求的行为:

  • 如果为 yes(默认值),slave仍然会应答客户端请求,但返回的数据可能是过时,或者数据可能是空的在第一次同步的时候
  • 如果为 no ,在你执行除了 info 和 salveof 之外的其他命令时,slave 都将返回一个 "SYNC with master in progress" 的错误。

replica-read-only

replica-read-only yes

设置slave是否是只读的。从2.6版起,slave默认是只读的

repl-diskless-sync

repl-diskless-sync no

主从数据复制是否使用无硬盘复制功能。

repl-diskless-sync-delay

repl-diskless-sync-delay 5

无磁盘(diskless)方式在进行数据传递之前会有一个时间的延迟,以便slave端能够进行到待传送的目标队列中,这个时间默认是5秒

repl-diskless-load

repl-diskless-load disabled

repl-disable-tcp-nodelay

repl-disable-tcp-nodelay no

是否启用TCP_NODELAY,如果启用则会使用少量的TCP包和带宽去进行数据传输到slave端,当然速度会比较慢;如果不启用则传输速度比较快,但是会占用比较多的带宽。

replica-priority

replica-priority 100

当 master 不能正常工作的时候,Redis Sentinel 会从 slaves 中选出一个新的 master,这个值越小,就越会被优先选中,但是如果是 0 , 那是意味着这个 slave 不可能被选中。 默认优先级为 100。

- keys tracking 键追踪

tracking-table-max-keys 1000000

security 安全

+ acllog-max-len

acllog-max-len 128

- aclfile

aclfile /etc/redis/users.acl

- requirepass

requirepass foobared

- rename-command

rename-command CONFIG ""

clients 客户

maxclients

maxclients 10000

设置最大连接客户端数。默认情况下,此限制设置为10000个客户端,但是,如果Redis服务器无法将进程文件限制配置为允许指定的限制,则允许的最大客户端数将设置为当前文件限制减去32(因为Redis保留了内部使用的文件描述符很少)

达到限制后,Redis将关闭所有新连接,并发送错误消息“已达到最大客户端数。

当使用Redis Cluster时,最大连接数也会与集群总线共享:集群中的每个节点将使用两个连接,一个进入,另一个向外。对于非常大的集群,重要的是相应地调整限制大小。

memory management 内存管理

maxmemory

maxmemory <bytes>

将内存使用限制设置为指定的字节数。当达到内存限制时,Redis将尝试根据所选的策略来删除key(请参见maxmemory-policy)。

如果Redis无法根据该策略删除key,或者如果该策略设置为'noeviction',则Redis将开始对将使用更多内存的命令(例如SET,LPUSH等)进行错误答复,并将继续答复诸如GET之类的只读命令。(不支持写,只支持读)

如果是主从复制,建议您为maxmemory设置一个下限,以便系统上有一些可用内存用于 ‘从’ 输出缓冲区(但是如果策略为'noeviction',则不需要这样做)。

maxmemory-policy

maxmemory-policy noeviction

maxmemory策略:达到maxmemory时,Redis将如何选择要删除的内容。您可以从以下行为中选择一种:

  • volatile-lru:利用LRU算法移除过期keys。
  • allkeys-lru:利用LRU算法移除keys。
  • volatile-random:随机移除过期keys。
  • allkeys-random:随机移除keys。
  • volatile-ttl:按照最近过期时间来删除(辅以TTL),移除即将过期的keys。
  • noeviction:不移除任何key,只是返回一个写错误。

maxmemory-samples

maxmemory-samples 5

Redis 中的 LRU 不是严格意义上的LRU算法实现,是一种近似的 LRU 实现,主要是为了节约内存占用以及提升性能。

Redis 的 LRU 是取出 配置的数目的key(5),然后从中选择一个最近最不经常使用的 key 进行置换。

对 LRU 来说 5 是比较合适的。10 已经很接近于真正的 LRU,但会消耗更多的 CPU。3 会更快但没有那么精确。

replica-ignore-maxmemory

replica-ignore-maxmemory yes

从 Redis 5 开始,默认情况下,replica 节点会忽略 maxmemory 设置(除非在发生 failover 后,此节点被提升为 master 节点)。 这意味着只有 master 才会执行过期删除策略,并且 master 在删除键之后会对 replica 发送 DEL 命令。

这个行为保证了 master 和 replicas 的一致性,并且这通常也是你需要的,但是若你的 replica 节点是可写的, 或者你希望 replica 节点有不同的内存配置,并且你确保所有到 replica 写操作都幂等的,那么你可以修改这个默认的行为 (请确保你明白你在做什么)。

需要注意的是默认情况下 replica 节点不会执行过期策略,它有可能使用了超过 maxmemory 设定的值的内存。 因此你需要监控 replicas 节点所在的机器并且确保在 master 节点到达配置的 maxmemory 大小时, replicas 节点不会超过物理内存的大小。

active-expire-effort

active-expire-effort 1

lazy freeing 懒惰释放

lazy free应用于被动删除中,目前有4种场景,每种场景对应一个配置参数; 默认都是关闭。

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no

lazyfree-lazy-eviction

针对redis内存使用达到maxmeory,并设置有淘汰策略时;在被动淘汰键时,是否采用lazy free机制;

因为此场景开启lazy free, 可能使用淘汰键的内存释放不及时,导致redis内存超用,超过maxmemory的限制。此场景使用时,请结合业务测试。

lazyfree-lazy-expire

针对设置有TTL的键,达到过期后,被redis清理删除时是否采用lazy free机制;

此场景建议开启,因TTL本身是自适应调整的速度。

lazyfree-lazy-server-del

针对有些指令在处理已存在的键时,会带有一个隐式的DEL键的操作。rename 命令当目标键已存在,redis会先删除目标键,如果这些目标键是一个big key,那就会引入阻塞删除的性能问题。 此参数设置就是解决这类问题,建议可开启。

slave-lazy-flush

针对slave进行全量数据同步,slave在加载master的RDB文件前,会运行flushall来清理自己的数据场景,参数设置决定是否采用异常flush机制。如果内存变动不大,建议可开启。可减少全量同步耗时,从而减少主库因输出缓冲区爆涨引起的内存使用增长。

lazyfree-lazy-user-del

对于不容易用 UNLINK 调用替换用户代码 DEL 调用的情况,也可以使用 lazyfree-lazy-user-del yes 配置指令将 DEL 命令的默认行为修改为与 UNLINK 完全相同。

threaded I/O 线程

默认情况下,线程是禁用的,我们建议仅在具有至少4个或更多内核的计算机上启用它,而至少保留一个备用内核。使用8个以上的线程不太可能有很大帮助。我们还建议在确实存在性能问题时再使用线程I / O,Redis实例会使用很大一部分CPU时间,否则就没有必要使用此功能。

io-threads 4

因此,如果您有四个核的,请尝试使用2或3个I / O线程,如果您有8个核,请尝试使用6个线程。

io-threads-do-reads

io-threads-do-reads no

通常,将io-threads设置为1只会使用主线程。启用I / O线程后,我们仅将线程用于写操作,即对 write 系统调用进行线程化,并将客户端缓冲区传输到套接字。但是,也可以通过 io-threads-do-reads yes 来启用读取线程和协议解析。通常,线程读取没有太大帮助。

无法在运行时通过CONFIG SET更改此配置指令。启用S​​SL时,Aso此功能当前不起作用。

kernel oom control 内核 oom 控制

这个 oom-score-adj 参数是用来 Linux 内核控制调优的,在 Linux 系统中,当内存溢出时,可以提示内核 OOM killer 应该首先杀死哪些进程。

oom-score-adj no

启用此功能可使Redis根据其进程主动控制其所有进程的 oom_score_adj值。默认分数将尝试使后台子进程在所有其他进程之前被杀死,而 replicas 在主数据库之前被杀死。

oom-score-adj-values 0 200 800

默认 oom-score-adj-values 不设置的情况下会优先杀死后台子进程,然后主从节点优先优先杀死从节点。

所以这 3 个值分别用来设置主、从、后台子进程的分值的,分值范围从 -1000 ~ 1000,分值越高越有可能被先杀死。

append only mode AOF 追加模式

Redis可以实现数据的持久化存储,即将数据保存到磁盘上。
Redis的持久化存储提供两种方式:RDB与AOF。RDB是默认配置。AOF需要手动开启。
现在Redis的配置中默认是关闭AOF模式的。

appendonly

appendonly no

是否开启AOF

appendfilename

appendfilename "appendonly.aof"

保存数据的AOF文件名称

appendfsync

# appendfsync always
appendfsync everysec
# appendfsync no

Redis支持3种不同的模式:

  • no:不即时同步,由操作系统控制何时刷写到磁盘上,这种模式速度最快;
  • always:每次只写日志,速度较慢,但最安全;
  • everysec:每秒钟同步一次,折中的方案。

no-appendfsync-on-rewrite

no-appendfsync-on-rewrite no

当使用AOF的 appendfsync 设置为 always 或 everysec 时,后台的存储进程会执行大量的磁盘I/O操作,在一些Linux架构中,Redis fsync() 调用时可能会阻塞很久。这个问题当前并没有修复,即使是在一个不同的线程执行 fsync 也会阻塞我们的同步写调用。

为了缓解这个问题,可以使用以下选项,它将会在有一个 BGSAVE 或 BGREWRITEAOF 正在运行时,阻止主进程调用 fsync()。

这意味着有另一个子进程在存储时,Redis的持久性等同于 appendfsync no。在实践中,意味着在最坏的情况下它可能丢失多达30秒的日志(默认的Linux设置)。

如果你有潜在的问题需要更改它为“yes”。否则从持久性的观点来看“no”是最安全的选择。

auto-aof-rewrite-percentage auto-aof-rewrite-min-size

auto-aof-rewrite-percentage 100

aof文件增长比例,指当前aof文件比上次重写的增长比例大小。aof重写即在aof文件在一定大小之后,重新将整个内存写到aof文件当中,以反映最新的状态(相当于bgsave)。这样就避免了,aof文件过大而实际内存数据小的问题(频繁修改数据问题).

auto-aof-rewrite-min-size

auto-aof-rewrite-min-size 64mb

aof文件重写最小的文件大小,即最开始aof文件必须要达到这个文件时才触发,后面的每次重写就不会根据这个变量了(根据上一次重写完成之后的大小).此变量仅初始化启动redis有效.如果是redis恢复时,则lastSize等于初始aof文件大小。

rewrite机制

其实Redis oaf机制包括了两件事,rewrite和AOF。rewrite类似于普通数据库管理系统日志恢复点,当AOF文件随着写命令的运行膨胀时,当文件大小触碰到临界时,rewrite会被运行。

rewrite会像复制一样,fork出一个子进程,创建一个临时文件,遍历数据库,将每个key、value对输出到临时文件。输出格式就是Redis的命令,但是为了减小文件大小,会将多个key、value对集合整理用一条命令表达。在rewrite期间的写操作会保存在内存的rewrite buffer中,rewrite成功后这些操作也会复制到临时文件中,在最后临时文件会代替AOF文件。

简单来说:aof里存放了所有的redis 操作指令,当aof文件达到一定条件或者手动 bgrewriteaof命令都可以触发rewrite。rewrite之后aof文件会保存keys的最后的状态,清除掉之前冗余的,来缩小这个文件。这里所谓的缩小就是 整理指令 ,比如客户端发送过三个命令:

lpush key 1 2 3
# 移出左边第一个元素,也就是把上面的元素 1 移出
lpop key 
lpush key 4 5 6

整理后的指令文件是

lpush key 4 5 6 2 3

aof-load-truncated

aof-load-truncated yes

指redis在恢复时,会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时,可能存在指令写错的问题(突然断电,写了一半),这种情况下,yes会log并继续,而no会直接恢复失败.

aof-use-rdb-preamble

aof-use-rdb-preamble yes

混合持久化同样也是通过 bgrewriteaof 完成的,不同的是当开启混合持久化时,fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件,然后在将重写缓冲区的增量命令以AOF方式写入到文件,写入完成后通知主进程更新统计信息,并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说:新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据。

lua scripting lua 脚本

Redis提供了Lua脚本功能来让用户实现自己的原子命令,但也存在着风险,编写不当的脚本可能阻塞线程导致整个Redis服务不可用。

lua-time-limit 5000

Redis的配置文件中提供了如下配置项来规定最大执行时长。

但这里有个坑,当一个脚本达到最大执行时长的时候,Redis并不会强制停止脚本的运行,仅仅在日志里打印个警告,告知有脚本超时。

因为 Redis 必须保证脚本执行的原子性,中途停止可能导致内存的数据集上只修改了部分数据。

如果时长达到 Lua-time-limit 规定的最大执行时间,Redis只会做这几件事情:

  • 日志记录有脚本运行超时
  • 开始允许接受其他客户端请求,但仅限于 SCRIPT KILL 和 SHUTDOWN NOSAVE 两个命令
  • 其他请求仍返回busy错误

- cluster 集群

cluster-enabled yes

开启集群模式

cluster-config-file nodes-6379.conf

1、这个配置文件不是要我们去配的,而是Redis运行时保存配置的文件,所以我们也不可以修改这个文件。

2、Redis集群节点每次发生更改时自动保留集群配置(基本上为状态)的文件,以便能够 在启动时重新读取它。

3、该文件列出了集群中其他节点,它们的状态,持久变量等等信息。 由于某些消息的接收,通常会将此文件重写并刷新到磁盘上。

4、生成的文件在dir指定路径下

cluster-node-timeout 15000

超时时间是集群中各节点相互通讯时,允许"失联"的最大毫秒数,上面的配置为15秒,如果超过15秒某个节点没向其它节点汇报成功,认为该节点挂了。

cluster-replica-validity-factor 10

1、如果设置为0,无论主节点和从节点之间的链路断开连接的时间长短,从节点都将尝试故障切换为主节点。

2、 如果该值为正值,则计算最大断开时间作为节点超时值乘以此选项提供的系数,如果该节点是从节点,则在主链路断开连接的时间超过指定的超时值时,它不会尝试启动故障切换。 例如,如果节点超时设置为5秒,并且有效因子设置为10,则与主节点断开连接超过50秒的从节点将不会尝试对其主节点进行故障切换。

3、请注意,如果没有从服务器节点能够对其进行故障转移,则任何非零值都可能导致Redis集群在主服务器出现故障后不可用。 在这种情况下,只有原始主节点重新加入集群时,集群才会返回可用。

cluster-migration-barrier 1

主节点将保持连接的最小从节点数量,以便另一个从节点迁移到不受任何从节点覆盖的主节点。

cluster-require-full-coverage yes

当cluster-require-full-coverage为no时,表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时,集群仍然可用。

当cluster-require-full-coverage为yes时,表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时,集群不可用。

cluster-replica-no-failover no

设置为yes时,此选项可防止从服务器在主服务器故障期间尝试对主服务器进行故障转移。但是,主服务器仍然可以执行手动故障转移(如果被迫执行)。

cluster-allow-reads-when-down no

默认为no, 表示当集群因主节点数量达不到最小值或有散列槽没有分配而被标记为失效时, 节点将停止所有的客户端通讯。 这样可以避免从一个不知道集群状态变化的节点读到不一致数据的危险。 设为yes则允许集群失效时仍可以由节点中读取数据。 这样既保证读操作的高可用性, 也避免不一致写操作,同时当 Redis Cluster 仅包含1至2个节点,而某个节点失效后无可用从节点替代,且因节点数量不足, 无法自动重新分配散列槽, 则该参数设为yes可保证节点仍然可执行读操作。

slow log慢日志

slowlog-log-slower-than 1000

其中slowlog-log-slower-than表示slowlog的划定界限,只有query执行时间大于slowlog-log-slower-than的才会定义成慢查询,才会被slowlog进行记录。slowlog-log-slower-than设置的单位是微妙,默认是10000微妙,也就是10ms

slowlog-max-len 128

slowlog-max-len 表示慢查询最大的条数,当slowlog超过设定的最大值后,会将最早的slowlog删除,是个FIFO队列

latency monitor 延迟监视器

latency-monitor-threshold 0

redis延时监控系统在运行时会采样一些操作,以便收集可能导致延时的数据根源。
通过 LATENCY命令 可以打印一些图样和获取一些报告,方便监控
这个系统仅仅记录那个执行时间大于或等于预定时间(毫秒)的操作,
这个预定时间是通过latency-monitor-threshold配置来指定的,
当设置为0时,这个监控系统处于停止状态

event notification 事件通知

notify-keyspace-events ""

advanced config 高级配置

当哈希条目只有少量条目且最大条目未超过给定阈值时,将使用内存高效的数据结构对其进行编码

hash-max-ziplist-entries 512

数据量小于等于hash-max-ziplist-entries的用ziplist,大于hash-max-ziplist-entries用hash

hash-max-ziplist-value 64

value大小小于等于hash-max-ziplist-value的用ziplist,大于hash-max-ziplist-value用hash。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,319评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,801评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,567评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,156评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,019评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,090评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,500评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,192评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,474评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,566评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,338评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,212评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,572评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,890评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,169评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,478评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,661评论 2 335