Redis压测脚本及恒久化机制

Redis压测脚本及恒久化机制

Redis性能压测脚本

Redis的所有数据是生存在内存当中的，得益于内存高效的读写性能，Redis的性能黑白常强悍的。但是，内存的缺点是断电即丢失，所以，在实际项目中，Redis一旦需要生存一些重要的数据，就不可能完全使用内存生存数据。因此，在真实项目中要使用Redis，一定需要针对应用场景，对Redis的性能进行估算，从而在数据安全性与读写性能之间找到一个平衡点。
Redis提供了压测脚本redis-benchmark，可以对Redis进行快速的基准测试。(redis-benchmark更多参数，使用redis-benchmark --help指令查看)

1. # 20个线程，100W个请求，测试redis的set指令(写数据)
2. redis-benchmark -a 123qweasd -t set -n 1000000 -c 20
3. ...
4. Summary:
5.   throughput summary: 116536.53 requests per second   ##平均每秒11W次写操作。
6.   latency summary (msec):
7.           avg       min       p50       p95       p99       max
8.         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
  
  
  
  • 优点：
    
  
  
  • AOF恒久化更安全。例如Redis默认每秒进行一次AOF写入，这样，即使服务瓦解，最多丧失一秒的操作。
    
  • AOF的记录方式是在之前基础上每次追加新的操作。因此AOF不会出现记录不完整的情况。即使因为一些特殊原因，造成一个操作没有记录完整，也可以使用redis-check-aof工具轻松恢复。
    
  • 当AOF文件太大时，Redis会自动切换新的日志文件。这样就可以防止单个文件太大的问题。
    
  • AOF记录操作的方式非常简朴易懂，你可以很轻松的自行调整日志。比如，如果你错误的执行了一次 FLUSHALL 操作，将数据误删除了。使用AOF，你可以简朴的将日志中最后一条FLUSHALL指令删掉，然后重启数据库，就可以恢复所有数据。
    
  
  
  
  
  • 缺点：
    
  
  
  • 针对同样的数据集，AOF文件通常比RDB文件更大。
    
  • 在写操作频繁的情况下，AOF备份的性能通常比RDB更慢。
    
  
  

总结

• 如果你只是把Redis当做一个缓存来用，可以直接关闭恒久化。
  
• 如果你更关注数据安全性，而且可以接受服务非常宕机时的小部门数据丧失，那么可以简朴的使用RDB计谋。这样性能是比较高的。
  
• 不建议单独使用AOF。RDB配合AOF，可以让数据恢复的过程更快。
  

RDB详解

RDB能干什么
RDB可以在指定的时间间隔，备份当前时间点的内存中的全部数据集，并生存到餐盘文件当中。通常是dump.rdb文件。在恢复时，再将磁盘中的快照文件直接都会到内存里。
由于RDB存的是全量数据，你乃至可以直接用RDB来通报数据。例如如果需要从一个Redis服务中将数据同步到另一个Redis服务(最好是同版本)，就可以直接复制最近的RDB文件。
何时触发RDB备份

• 到达配置文件中默认的快照配置时，会自动触发RDB快照
  
• 手动执行save或者bgsave指令时，会触发RDB快照。 此中save方法会在备份期间阻塞主线程。bgsve则不会阻塞主线程。但是他会fork一个子线程进行恒久化，这个过程中会要将数据复制一份，因此会占用更多内存和CPU。
  
• 主从复制时会触发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的恒久化计谋只能包管单机的数据安全。如果服务器的磁盘坏了，那么再好的恒久化计谋也无法包管数据安全。如果盼望进一步包管数据安全，那就需要增长以下几种集群化的方案了。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。