redis配置⽂件f讲解，哨兵，主从
1.Redis备份(持久化)
在 Redis 中存在两种⽅式的备份: ⼀种是快照(snapshotting)，它是备份当前瞬间 Redis 在内存中的数据记录；另⼀种是只追加⽂件(Append-OnlyFile, AOF)， 其作⽤就是当 Redis 执⾏写命令后，在⼀定的条件下将执⾏过的写命令依次保存在 Redis 的⽂件中， 将来就可以依次执⾏那些保存的命令恢复 Redis 的数据了。对于快照备份⽽⾔， 如 果当前 Redis 的数据量⼤，备份可能造成 Redis 卡顿，但是恢复重启是 ⽐较’快速的 ；对于 AOF 备份⽽⾔，它只是追加写⼊命令，所以备份⼀般不会造成Redis卡顿， 但是恢复重启要执⾏更多的命令，备份⽂件可能也很⼤ ， 使⽤者使⽤的时候要注意。在 Redis 中允许使⽤其中的 ⼀种、同时使⽤两种，或者两种都不⽤，所以具体使⽤何种⽅式进⾏备份和持久化是⽤户可以通过配置决定的。 对于Redis⽽⾔，它的默认配置(在f⽂件中)为:
>>>>>>## SNAPSHOTTING >>>>>>##
# Save the DB on disk:
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
>>>>>> APPEND ONLY MODE >>>>>>#
appendonly no
appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
快照模式的配置项：
save 900 1
save 300 10
save 60 10000
这 3 个配置项的含义分别为 :
当 900 秒执⾏ 1 个 写命令时，启⽤快照备份。
当 300 秒执⾏ 10 个写命令时，启⽤快照备份 。
当 60 秒内执⾏ 10000 个写命令时，启⽤快照备份。
Redis 执⾏ save 命令的时候，将禁⽌写⼊命令 。
stop-writes-on-bgsave-error yes
bgsave是⼀个异步保存命令，也就是系统将启动另外⼀条进程，把 Redis 的数据保存到对应的数据⽂件中 。它和 save 命令最⼤的不同是它不会阻塞客户端的写⼊，也就是在执⾏ bgsave 的时候，允许客户端继续读/写 Redis。在默认情况下，如果Redis 执⾏bgsave 失败后， Redis 将停⽌接受写操作，这样以⼀种强硬的⽅式让⽤户知道数据不能正确的持久化到磁盘 ， 否则就会没⼈注意到灾难的发⽣，如果后台保存进程重新启动⼯作了， Redis 也将⾃动允许写操作。然⽽如果安装了靠谱的监控，可能不希望 Redis 这样做，那么你可以将其修改为 no。
rdbchecksum yes
这个命令意思是是否对 rbd ⽂件进⾏检验，如果是将对 rdb ⽂件检验。从 dbfilename的配置可 以知道， rdb ⽂件实际是 Redis 持久化的数据⽂件 。
dbfilename dump.rdb
它是数据⽂件。当采⽤快照模式备份(持久化)时， Redis 将使⽤它保存数据，将来可以使⽤它恢复数据 。
appendonly no
空调制冷不好如果 appendonly配置为 no，则不启⽤ AOF⽅式进⾏备份。如果 appendonly配置为 yes，则以 AOF ⽅式备份 Redis 数据，那么此时Redis 会按照配置，在特定的时候执⾏追加命令，⽤以备份数据。
appendfilename ”appendonly.aof”
这⾥定义追加的写⼊⽂件为 appendonly.aof， 采⽤ AOF 追加⽂件备份的时候命令都会写到这⾥。
# appendfsync always
文档打不开怎么办appendfsync everysec
# appendfsync no
AOF ⽂件和 Redis 命令是同步频率的 ， 假设配置为 always， 其含义为当 Redis 执⾏命令的时候，则同时同步到 AOF ⽂件， 这样会使得 Redis 同步刷新 AOF ⽂件， 造成缓慢。⽽采⽤ everysec 则代
表每秒同步⼀次命令到 AOF ⽂件。采⽤ no 的时候 ，则 由客户端调⽤命令执⾏备份， Redis 本⾝不备份⽂件。对于采⽤ always 配置的时候， 每次命令都会持久化，它的好处在于安全，坏处在于每次都持久化性能较差。采⽤ everysec 则每秒同步 ， 安全性不如 always， 备份可能会丢失 l 秒 以内的命令 ， 但是隐患 也不⼤ ， 安全度 尚可 ，性能可以得到保障。采⽤ no， 则性能有所保障 ， 但是由于失去备份， 所以安全性⽐较差。⼀般建议使⽤everysec。
no-appendfsync-on-rewrite no
它指定是否在后台 AOF ⽂件 rewrite (重写)期间调⽤ fsync， 默认 为 no， 表⽰要调⽤fsync (⽆论后台是否有⼦进程在刷新)。Redis在后台写 RDB⽂件或重写 AOF⽂件期间会存在⼤量磁盘1/0， 此时， 在某些Linux系统中，调⽤fsync可能会阻塞。
auto-aof-rewrite-percentage 100
它指定 Redis 重写 AOF ⽂件的条件 ， 默认为 100，表⽰与上次 rewrite 的 AOF ⽂件⼤⼩相⽐，当前 AOF ⽂件增长量超过上次 AOF ⽂件⼤⼩的 100%时，就会触发 background rewrite。若配置为0， 则会禁⽤⾃动 rewrite。
auto-aof-rewrite-min-size 64mb
它指定触发 rewrite 的 AOF⽂件⼤⼩。若 AOF⽂件⼩于该值，即使当前⽂件的增量⽐例达到 auto-aof-rewrite-percentage 的配置值 ，也不会触发⾃动 rewrite。 即这两个配置项同时满⾜时，才会触发 rewrite。
aof-load-truncated yes
Redis在恢复时会忽略最后⼀条可能存在问题的指令， 默认为yes。 即在AOF写⼊时，可能存在指令写错的问题(突然断电、写了⼀半)，这种情况下 yes 会 log 并继续，⽽no会直接恢复失败 。
2.Redis 内存回收策略
Redis 也会因为内存不⾜⽽产⽣错误，也可能因为回收过久⽽导致系统长期的停顿，因此掌握执⾏回收策略⼗分有必要。在 Redis 的配置⽂件中，当 Redis 的内存达到规定的最⼤值时，允许配置 6 种策略中的⼀种进⾏淘汰键值，并且将⼀些键值对进⾏回收。
在f中，Redis 对其中的⼀个配置项⼀maxmemory-policy：
# volatile-lru -> remove the key with an expire set using an LRU algorithm
# allkeys-lru -> remove any key according to the LRU algorithm
# volatile-random -> remove a random key with an expire set
# allkeys-random -> remove a random key, any key
# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
牛肉和什么不能一起吃# noeviction -> don't expire at all, just return an error on write operations
volatile-lru: 采⽤最近使⽤最少的淘汰策略， Redis 将回收那些超时的(仅仅是超时的)键值对 ，也就是它只淘汰那些超时的键值对。
allkeys-lru: 采⽤淘汰最少使⽤的策略， Redis将对所有的(不仅仅是超时的)键值对采⽤最近使⽤最少的淘汰策略。
volatile-random：采⽤随机淘汰策略删除超时的(仅仅是超时的)键值对 。
allkeys-random: 采⽤随机、淘汰策略删除所有的(不仅仅是超时的)键值对，这个策略不常⽤ 。
volatile-ttl: 采⽤删除存活时间最短的键值对策略 。
noeviction: 根本就不淘汰任何键值对，当内存已满时， 如果做读操作，例如get命令，它将正常⼯作，
⽽做写操作，它将返回错误 。
也就是说 ，当 Redis 采⽤这个策略内存达到最⼤的时候， 它就只能读⽽不能了。
Redis 在默认情况下会采⽤ noeviction 策略。换句话说，如果内存⼰满 ， 则不再提供写⼊操作 ，⽽只提供读取操作 。显然这往往并不能满⾜我们的要求，因为对于互联⽹系统⽽ ⾔ ， 常常会涉及数以百万甚⾄更多的⽤户 ， 所以往往需要设置回收策略。
这⾥需要指出的是 : LRU 算法或者 TTL 算法都是不是很精确算法，⽽是⼀个近似的算法。 Redis不会通过对全部的键值对进⾏⽐较来确定最精确的时间值，从⽽确定删除哪个键值对，因为这将消耗太多的时间，导致回收垃圾执⾏的时间太长，造成服务停顿。⽽在Redis 的默认配置⽂件中，存在着参数 maxmemo-samples，它的默认值为 3，假设采取了 volatile-ttl算法，让我们去了解这样的⼀个回收的过程，假设当前有 5 个即将超时的键值对， 如表所⽰ 。
由于配置 maxmemory-samples 的值为 3，如果 Redis 是按表中的顺序探测，那么它只会取到样本 Al、 A2, A3，然后进⾏⽐较，因为 A2 过期剩余秒数最少，所以决定淘汰 A2，因此 A2是最先被删除的。注意，此时即将过期且剩余超时秒数最短的 A4却还在内存中，因为它不属于探测样本。这就是 Redis 中采⽤的近似算法。当设置 maxmemory-samples 越⼤，则 Redis 删除的就越精确，但是与此同时带来不利的是，Redis 也就需要花更多的时间去计算和l匹配更为精确的值 。
回收超时策略的缺点是必须指明超时的键值对 ，这会给程序开发带来⼀些设置超时的代码，⽆疑增加了开发者的⼯作量。对所有的键值对进⾏回收 ，有可能把正在使⽤的键值对删掉 ，增加了存储的不稳定性 。对于垃圾回 收的策略，还需要注意的是回收的时间，因为在Redis 对垃圾的回收期间， 会造成系统缓慢。因 此，控制其回收时间有 ⼀定好 处，只是这个时间不能过短或过长。过短则会造成回收次数过于频繁 ，过长则导致系统单次垃圾回收停顿时间过长 ，都不利于系统的稳定性，这些都 需要设计者在实际 的⼯作中进⾏思考 。
3.复制
3.1 主从同步基础概念
互联⽹系统⼀般是以主从架构为基础的，所谓主从架构设计的思路⼤概是:
119消防日是几月几号
在多台数据服务器中，只有⼀台主服务器，⽽主服务器只负责写⼊数据，不负责让外部程序读取数据。
存在多台从服务器，从服务器不写⼊数据，只负责同步主服务器的数据，并让外部程序读取数据。
主服务器在写⼊数据后，即刻将写⼊数据的命令发送给从服务器，从⽽使得主从数 据同步。
应⽤程序可以随机读取某⼀台从服务器的数据， 这样就分摊了读数据的压⼒。
影响食品安全的因素当从服务器不能⼯作的时候，整个系统将不受影响；当主服务器不能⼯作的时候，可以⽅便地从从服务器中选举⼀ 台来当主服务器 。
多乐士油漆3.2 Redis 主从同步配置
对Redis进⾏主从同步的配置分为主机与从机，主机是⼀台，⽽从机可以是多台。
⾸先，明确主机。当你能确定哪台机⼦是主机的时候，关键的两个配置是 dir 和 dbfilename 选项， 当然必须保证这两个⽂件是可写的。对于 Redis 的默认配置⽽⾔， dir 的 默认值为“./”，⽽对于 dbfilename 的默认值为“ dump.rbd”。换句话说，默认采⽤ Redis 当 前⽬录的 dump.rbd ⽂件进⾏同步。对于主机⽽⾔，只要了解这多信息，很简单。其次，在明确了从机之后，进⾏进⼀步配置所要关注的只有slaveof这个配置选项 ，它的配置格式是 :
slaveof server port
server代表主机， port 此代表端⼝。当从机Redis服务重启时，就会同步对应主机的数据了。当不想让从机继续复制主机的数据时，可以在从机的 Redis 命令客户端发送 slaveof no one命令，这样从机就不会再接收主服务器的数据更新了。⼜或者原来主服务器已经⽆法⼯作了，⽽你可能需要去复制新的主机，这个时候执⾏ slaveof sever port就能让从机复制另外⼀台主机的数据了。
3.3 Redis 主从同步的过程
Redis主从同步过程图如下：
(1) ⽆论如何要先保证开启主服务器，开启主服务器后，从服务器通过命令或者重启配置项可以同步到主服务器。
(2)当从服务器启动时，读取同步的配置，根据配置决定是否使⽤当前数据响应客户端，然后发送 SYNC 命令。当主服务器接收到同步命令的时候，就会执⾏bgsave命令备份数据，但是主服务器并不会拒绝客户端的读/写，⽽是将来⾃客户端的写命令写⼊缓冲区。从服务器未收到主服务器备份的快照⽂件的时候，会根据其配置决定使⽤现有数据响应客户端或者拒绝。
(3)当bgsave命令被主服务器执⾏完后，开始向从服务器发送备份⽂件，这个时候从服务器就会丢弃所有现有的数据，开始载⼊发送的快照⽂件。
(4)当主服务器发送完备份⽂件后，从服务器就会执⾏这些写⼊命令。此时就会把bgsave 执⾏之后的缓存区内的写命令也发送给从服务器，从服务完成备份⽂件解析，就开始像往常⼀样，接收命令，等待命令写⼊。
(5)缓冲区的命令发送完成后，当主服务器执⾏⼀条写命令后，就同时往从服务器发送同步写⼊命令，从服务器就和主服务器保持⼀致了。⽽此时当从服务器完成主服务器发送的缓冲区命令后，就开始等待主服务器的命令了。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
Hive配置文件中配置项的含义详解
下一篇 »
发表评论