Redis压测脚本及持久化机制

合集 - Redis(2)

1.Redis压测脚本及持久化机制03-04

2.Redis缓存设计与性能优化03-05

收起

Redis压测脚本及持久化机制

Redis性能压测脚本

Redis的所有数据是保存在内存当中的，得益于内存高效的读写性能，Redis的性能是非常强悍的。但是，内存的缺点是断电即丢失，所以，在实际项目中，Redis一旦需要保存一些重要的数据，就不可能完全使用内存保存数据。因此，在真实项目中要使用Redis，一定需要针对应用场景，对Redis的性能进行估算，从而在数据安全性与读写性能之间找到一个平衡点。

Redis提供了压测脚本redis-benchmark，可以对Redis进行快速的基准测试。(redis-benchmark更多参数，使用redis-benchmark --help指令查看)

# 20个线程，100W个请求，测试redis的set指令(写数据)
redis-benchmark -a 123qweasd -t set -n 1000000 -c 20
 ...
Summary:
  throughput summary: 116536.53 requests per second   ##平均每秒11W次写操作。
  latency summary (msec):
          avg       min       p50       p95       p99       max
        0.111     0.032     0.111     0.167     0.215     3.199

Redis数据持久化机制详解

Redis提供了很多跟数据持久化相关的配置，大体上，可以组成以下几种策略：

• 无持久化：完全关闭数据持久化，不保证数据安全。相当于将Redis完全当做缓存来用
• RDB(RedisDatabase)：按照一定的时间间隔缓存Redis所有数据快照。
• AOF(Append Only File)：记录Redis收到的每一次写操作。这样可以通过操作重演的方式恢复Redis的数据
• RDB+AOF：同时保存Redis的数据和操作。

两种方式的优缺点：

• RDB

  • 优点：

    1.RDB文件非常紧凑，非常适合定期备份数据。

    2.RDB快照非常适合灾难恢复。

    3.RDB备份时性能非常快，对主线程的性能几乎没有影响。RDB备份时，主线程只需要启动一个负责数据备份的子线程即可。所有的备份工作都由子线程完成，这对主线程的IO性能几乎没有影响。

    4.与AOF相比，RDB在进行大数据量重启时会快很多。

  • 缺点：

    1.RDB不能对数据进行实时备份，所以，总会有数据丢失的可能。

    2.RDB需要fork化子线程的数据写入情况，在fork的过程中，需要将内存中的数据克隆一份。如果数据量太大，或者CPU性能不是很好，RDB方式就容易造成Redis短暂的服务停用。相比之下，AOF也需要进行持久化，但频率较低。并且你可以调整日志重写的频率。

• AOF

  • 优点：

  1. AOF持久化更安全。例如Redis默认每秒进行一次AOF写入，这样，即使服务崩溃，最多损失一秒的操作。

  2. AOF的记录方式是在之前基础上每次追加新的操作。因此AOF不会出现记录不完整的情况。即使因为一些特殊原因，造成一个操作没有记录完整，也可以使用redis-check-aof工具轻松恢复。

  3. 当AOF文件太大时，Redis会自动切换新的日志文件。这样就可以防止单个文件太大的问题。

  4. AOF记录操作的方式非常简单易懂，你可以很轻松的自行调整日志。比如，如果你错误的执行了一次 FLUSHALL 操作，将数据误删除了。使用AOF，你可以简单的将日志中最后一条FLUSHALL指令删掉，然后重启数据库，就可以恢复所有数据。

  • 缺点：

  1. 针对同样的数据集，AOF文件通常比RDB文件更大。

  2. 在写操作频繁的情况下，AOF备份的性能通常比RDB更慢。

总结

1. 如果你只是把Redis当做一个缓存来用，可以直接关闭持久化。

2. 如果你更关注数据安全性，并且可以接受服务异常宕机时的小部分数据损失，那么可以简单的使用RDB策略。这样性能是比较高的。

3. 不建议单独使用AOF。RDB配合AOF，可以让数据恢复的过程更快。

RDB详解

RDB能干什么

RDB可以在指定的时间间隔，备份当前时间点的内存中的全部数据集，并保存到餐盘文件当中。通常是dump.rdb文件。在恢复时，再将磁盘中的快照文件直接都会到内存里。

由于RDB存的是全量数据，你甚至可以直接用RDB来传递数据。例如如果需要从一个Redis服务中将数据同步到另一个Redis服务(最好是同版本)，就可以直接复制最近的RDB文件。

何时触发RDB备份

1. 到达配置文件中默认的快照配置时，会自动触发RDB快照

2. 手动执行save或者bgsave指令时，会触发RDB快照。 其中save方法会在备份期间阻塞主线程。bgsve则不会阻塞主线程。但是他会fork一个子线程进行持久化，这个过程中会要将数据复制一份，因此会占用更多内存和CPU。

3. 主从复制时会触发RDB备份。LASTSAVE指令查看最后一次成功执行快照的时间。时间是一个代表毫秒的LONG数字，在linux中可以使用date -d @{timestamp} 快速格式化。

AOF详解

AOF能干什么

以日志的形式记录每个写操作(读操作不记录)。只允许追加文件而不允许改写文件。

AOF日志恢复

如果Redis服务出现一些意外情况，就会造成AOF日志中指令记录不完整。例如，手动编辑appendonly.aof.1.incr.aof日志文件，在最后随便输入一段文字，就可以模拟指令记录不完整的情况。

混合持久化策略

RDB和AOF两种持久化策略各有优劣，所以在使用Redis时，是支持同时开启两种持久化策略的。在redis.conf配置文件中，有一个参数可以同时打开RDB和AOF两种持久化策略。

这也说明，如果同时开启RDB和AOF两种持久化策略，那么Redis在恢复数据时，其实还是会优先选择从AOF的持久化文件开始恢复。因为通常情况下，AOF的数据集比RDB更完整。而且AOF的持久化策略现在已经明确包含了RDB和AOF两种格式，所以AOF恢复数据的效率也还是比较高的。

但是要注意，既然服务重启时只找AOF文件，那是不是就不需要做RDB备份了呢？通常建议还是增加RDB备份。因为AOF数据通常在不断变化，这样其实不太利于定期做数据备份。所以通常建议保留RDB文件并定期进行备份，作为保证数据安全的后手。

最后要注意，Redis的持久化策略只能保证单机的数据安全。如果服务器的磁盘坏了，那么再好的持久化策略也无法保证数据安全。如果希望进一步保证数据安全，那就需要增加以下几种集群化的方案了。