Redis 调优监控知识和具体应用难点

一、Redis数据库的优缺点及适用场景
Redis持久服务的特点，key-value键值类型存储系统，支持数据可靠存储，单进程单线程高性能服务器，恢复比较慢单机qps（秒并发）可以达到10W，适合小数据高速读写访问。

Redis存储系统优、缺点：可以持久化存储数据，支持每秒10W的读写频率，支持丰富的数据类型，所有操作都是原子性的，支持异机主从复制，内存管理开销大（低于物理内存的3/5），不同命令延迟差别大，网站：http://www.***

主要使用场景分为两大块：

1、缓存：热点数据放到缓存里，大部分情况命中缓存，不命中时，访问磁盘存储并更新缓存

2、键值存储，独立使用缓存作为数据提供方。依赖于缓存服务的可靠性不高，业务对事务和数据的一致性要求不高。具体的，一般由架构师和开发人员，根据业务的特性，设计出具体的使用方法。

二、Redis的调优参数
Redis的参数调优问题，根据场景不同，有不同的调优方法，以下列举踩过的一些坑的参数调优。我们的场景的海量数据，高并发。

（1）timeout参数，非常需要关注，对timeout的解释如下：该参数表示当某一个客户端连接上来并闲置timeout（单位秒）的时间后，Redis服务端就主动关闭这个客户端连接。我们发现如果客户端对连接处理比较差的时候，存在连接不释放的问题，导致连接池耗尽，单个redis默认的连接数是1000.所以需要在timeout参数做文章，强制释放无效连接，我们的参数调整为timeout 30000

（2）持久化参数，RDB和AOF究竟开哪个，很多人很纠结。其实选择很简单，两者的区别是持久化的颗粒度不一样，如果你关注数据的强一致性，选择AOF，如果你选择更好的性能，选型RDB。如果你选择的性能，又能容忍数据的丢失，那你可以完全不用开启持久化，当然了，集群是一定要开持久化的。

（3）tcp-backlog和maxclient，这两个参数可能大家也比较迷糊，maxclient模式10000，一般情况下是够了，但是在高并发海量访问的时候，还是会出现客户端缓慢的情况，那就是系统的限制，就是backlog参数，你可以理解为在三次握手时进入accept queue队列的大值，也就是send_Q，所以这个值设大点是没有坏处的，我们的设置是1024

（4）重点提一下安全的参数，requirepass foobared 个人认为，如果你们觉得你们hold住，那就不用开，如果在DMZ区，数据又比较重要，那就开。个人认为，密码的作用不是你想象中的带给你安全，redis一分钟可以访问你想象不到的次数，如果弱密码，分分钟破解，第二auth命令是明文的，破解也很容易。

（5）maxmemory，这个参数比较常见，但是也非常的坑。如果你选择用，有个原则，你是当数据库用还是当缓存用，如果当数据库用，就不要开，如果当缓存用，可以开。曾经有个BUG，多个salve的情况下，会导致擦除主节点的数据。如果你开启这个参数，记得预留一些空间给系统的buffer。

遵循你的使用场景和你对参数的了解。宁愿逐步踩坑逐步解决问题逐步深入了解，也不要盲从的调整参数。

三、Redis 的监控指标
内存使用。如果 Redis 使用的内存超出了可用的物理内存大小，那么 Redis 很可能系统会被杀掉。针对这一点，你可以通过 info 命令对 used_memory 和 used_memory_peak 进行监控，为使用内存量设定阀值，并设定相应的报警机制。当然，报警只是手段，重要的是你得预先计划好，当内存使用量过大后，你应该做些什么，是一些没用的冷数据，还是把 Redis 迁移到更强大的机器上去。

持久化。如果因为你的机器或 Redis 本身的问题导致 Redis 崩溃了，那么你的救命稻草可能就是 dump 出来的rdb文件了，所以，对 Redis dump 文件进行监控也是很重要的。可以通过对rdb_last_save_time 进行监控，了解近一次 dump 数据操作的时间，还可以通过对rdb_changes_since_last_save进行监控来获得如果这时候出现故障，会丢失（即已改变）多少数据。

Keys。通过获取Keyspace中的结果得到各个数据库中key的数量

QPS。即每分钟执行的命令个数，即：(total_commands_processed2-total_commands_processed1)/span，为了实时得到QPS，可以设定脚本在后台运行，记录过去几分钟的total_commands_processed。在计算QPS时，利用过去的信息和当前的信息得出QPS的估计值。