配置文件简介
- redis的配置文件在redis安装目录下的redis.config
参数说明
redis.conf 配置项说明如下：
-
Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
daemonize no -
当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
pidfile /var/run/redis.pid -
指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
port 6379 -
绑定的主机地址
bind 127.0.0.1
5.当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
timeout 300 -
指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
loglevel verbose -
日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
logfile stdout -
设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
databases 16 -
指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
save <seconds> <changes>
Redis默认配置文件中提供了三个条件：
save 900 1
save 300 10
save 60 10000
分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。 -
指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
rdbcompression yes -
指定本地数据库文件名，默认值为dump.rdb
dbfilename dump.rdb -
指定本地数据库存放目录,默认为当前目录下
dir ./ -
设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
slaveof <masterip> <masterport> -
当master服务设置了密码保护时，slav服务连接master的密码
masterauth <master-password> -
设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭
requirepass foobared -
设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
maxclients 128 -
指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
maxmemory <bytes> -
指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly no -
指定更新日志文件名，默认为appendonly.aof
appendfilename appendonly.aof -
指定更新日志条件，共有3个可选值：
no：表示等操作系统进行数据缓存同步到磁盘（快）
always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
everysec：表示每秒同步一次（折衷，默认值）
appendfsync everysec -
指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
vm-enabled no -
虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
vm-swap-file /tmp/redis.swap -
将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
vm-max-memory 0 -
Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
vm-page-size 32 -
设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
vm-pages 134217728 -
设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
vm-max-threads 4 -
设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
glueoutputbuf yes -
指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512 -
指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
activerehashing yes -
指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
include /path/to/local.conf
持久化之RDB
该笔记部分内容转自:https://www.cnblogs.com/itdragon/p/7906481.html
- rdb是什么?
- 在指定的时间间隔内将内存中的数据集快照写入磁盘，
也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里 - Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到
一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。 - 配置文件中的RDB的配置
################################ SNAPSHOTTING ################################
#
# Save the DB on disk:
#
# save <seconds> <changes>
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving completely by commenting out all "save" lines.
#
# It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
#
# save ""
save 900 1
save 300 10
save 60 10000
- 默认 当900秒内key有修改过一次,或者 300秒内被修改过10次,或者60秒内被修改过10000次则将内存中的数据快照写入磁盘。
- 如果不想用RDB可以设置
save ""
- 指定数据库文件名称,一般使用默认设置
dbfilename dump.rdb
- 设置rdb文件保存路径,一般使用默认设置
dir ./
- 默认开启数据压缩
rdbcompression yes
-
配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。
-
触发RDB快照
- 在指定的时间间隔内，执行指定次数的写操作
- 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令
- 执行flushall 命令，清空数据库所有数据，意义不大。
- 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义…也不大。
-
通过RDB文件恢复数据
-
将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。
-
RDB 的优缺点
优点：
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
缺点：
1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
Redis持久化之AOF
-
AOF是什么?
-
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis
重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作. -
AOF的默认保存位置
-
在Redis的配置文件之中AOF所对应的配置位置为"APPEND ONLY MODE"对应位置
-
默认情况下aof是属于不开启状态的
############################## APPEND ONLY MODE ###############################
# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.
appendonly no
- AOF所使用的默认文件名为"appendonly.aof""
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
- AOF备份策略有三种
- no:只要让操作系统在需要的时候刷新数据即可。更快。
- always:每次操作之后进行备份,非常缓慢
- everysec:每秒执行一次,折中的方式(默认方式)
# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
- AOF数据恢复
- 开启AOF功能之后,当进行redis操作之后,对应的目录下会生成一个"appendonly.aof"文件,只需备份该文件,然后在需要恢复数据redis中,拷贝该文件,启动redis服务即可,(保证appendonly.aof文件没有损坏的情况下)
- 开启AOF
appendonly yes
- 进行一系列操作之后appendonly.conf之中会保存下对应的记录,只需拥有该文件,那么重启redis的时候就会再次执行所有操作,进行数据恢复
*2
$6
SELECT
$1
0
*3
$3
set
$6
maoshu
$5
nihao
- 当appendonly.cof文件出现错误时
*2
$6
SELECT
$1
0
*3
$3
set
$6
maoshu
$5
nihao
错误操作
- 就无法正确恢复数据
- 此时需要先恢复损坏的appendonly.conf文件,才可以恢复数据
- 如果是windows系统,redis安装目录下有对应的工具进行修复
- 如果是linux系统,可以使用以下命令修复
redis-check-aof --fix
总结:RDB于AOF相比较
-
优点:
- RDB的优点在于速度快,相比较AOF需要对每次操作进行记录,RDB的数据备份速度要快许多.
- AOF因为是忠实记录每次操作,所以AOF会完整的记录下来每一个数据,所以可以完美记录每一条数据,保证数据的完整性
-
缺点:
- RDB虽然速度占据优势,但是由于RDB备份数据机制(比如每3分钟进行10次操作时)的原因,有可能会遗漏最后一段的数据,.
- AOF需要对每个操作进行记录,所以可能出现无用的记录操作(例如添加一个数据,又删除了该数据),因此速度方面会大大降低.
-
所以RDB和AOF两个都有各自的优势,如果只是将Redis作为一个缓存来使用,那么可以对数据的完整性要求降低一点,也就只需要使用RDB即可.
Redis事务
-
Redis事务是什么?
-
可以一次执行多个命令，本质是一组命令的集合。一个事务中的
所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞 -
Redis能干什么?
-
一个队列中，一次性、顺序性、排他性的执行一系列命令
-
常用命令
| 命令 | 说明 |
|---|---|
| DISCARD | Redis Discard 命令用于取消事务，放弃执行事务块内的所有命令。 |
| Exec | Redis Exec 命令用于执行所有事务块内的命令。 |
| Multi | Redis Multi 命令用于标记一个事务块的开始。事务块内的多条命令会按照先后顺序被放进一个队列当中，最后由 EXEC 命令原子性(atomic)地执行。 |
| Unwatch | Redis Unwatch 命令用于取消 WATCH 命令对所有 key 的监视。 |
| Watch | 命令用于监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断 |
- 普通使用
- 使用Watch 监控"k1"时,另一个客户端修改了"k1"值,在另一个客户端提交事务时,并未执行
悲观锁/乐观锁/CAS(Check And Set)
-
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁
-
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，
-
乐观锁策略:提交版本必须大于记录当前版本才能执行更新
-
Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行
-
通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败
总结
-
Redis事务大致分为三个阶段
- 开启：以MULTI开始一个事务
- 入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
- 执行：由EXEC命令触发事务
-
Redis事务的三大特性
- 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
- 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，
也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
