几个Redis的监控指令以及保护Redis安全

查看QPS指令

>redis-cli info stats |grep ops
instantaneous_ops_per_sec:78

可以查看Redis在1s内执行多少指令，如果QPS过高，可以用monitor指令监控指令。

>redis-cli monitor

查看连接了多少客户端：

> redis-cli info clients
# Clients
connected_clients:124   # 这个就是正在连接的客户端数量
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0 

查看因为超过最大连接数而拒绝了客户端连接次数：

> redis-cli info stats |grep reject
rejected_connections:0

查看Redis内存占据多大

> redis-cli info memory | grep used | grep human
used_memory_human:827.46K # 内存分配器 (jemalloc) 从操作系统分配的内存总量
used_memory_rss_human:3.61M   # 操作系统看到的内存占用 ,top 命令看到的内存
used_memory_peak_human:829.41K   # Redis 内存消耗的峰值
used_memory_lua_human:37.00K # lua 脚本引擎占用的内存大小

查看复制缓冲区大小

> redis-cli info replication |grep backlog
repl_backlog_active:0
repl_backlog_size:1048576   # 这个就是积压缓冲区大小
repl_backlog_first_byte_offset:0  
repl_backlog_histlen:0

复制缓冲区很重要，严重影响主从复制的效率。缓冲区是环形的，如果从库断开时间过长或者缓冲区设置过小，就会导致从库无法及时同步，导致数据被覆盖，此时就需要进行全量同步，十分耗费资源。

查看半同步失败次数

> redis-cli info stats | grep sync
sync_full:0
sync_partial_ok:0
sync_partial_err:0   # 半同步失败次数

安全保护

指令安全

Redis 有一些非常危险的指令，这些指令会对 Redis 的稳定以及数据安全造成非常严重
的影响。比如 keys 指令会导致 Redis 卡顿，flushdb 和 flushall 会让 Redis 的所有数据全部清空。如何避免人为操作失误导致这些灾难性的后果也是运维人员特别需要注意的风险点之一。
Redis 在配置文件中提供了 rename-command 指令用于将某些危险的指令修改成特别的
名称，用来避免人为误操作。比如在配置文件的 security 块增加下面的内容:
rename-command keys abckeysabc
如果还想执行 keys 方法，那就不能直接敲 keys 命令了，而需要键入 abckeysabc。 如果想完全封杀某条指令，可以将指令 rename 成空串，就无法通过任何字符串指令来执行这条指令了。
rename-command flushall “”

端口安全

Redis 默认会监听 *:6379，如果当前的服务器主机有外网地址，Redis 的服务将会直接
暴露在公网上，任何一个初级黑客使用适当的工具对 IP 地址进行端口扫描就可以探测出
来。
Redis 的服务地址一旦可以被外网直接访问，内部的数据就彻底丧失了安全性。高级一
点的黑客们可以通过 Redis 执行 Lua 脚本拿到服务器权限，恶意的竞争对手们甚至会直接清空你的 Redis 数据库。
bind 10.100.20.13
所以，运维人员务必在 Redis 的配置文件中指定监听的 IP 地址，避免这样的惨剧发
生。更进一步，还可以增加 Redis 的密码访问限制，客户端必须使用 auth 指令传入正确的密码才可以访问 Redis，这样即使地址暴露出去了，普通黑客也无法对 Redis 进行任何指令
操作。
requirepass yoursecurepasswordhereplease
密码控制也会影响到从库复制，从库必须在配置文件里使用 masterauth 指令配置相应的
密码才可以进行复制操作。
masterauth yoursecurepasswordhereplease

Lua 脚本安全

开发者必须禁止 Lua 脚本由用户输入的内容 (UGC) 生成，这可能会被黑客利用以植入
恶意的攻击代码来得到 Redis 的主机权限。
同时，我们应该让 Redis 以普通用户的身份启动，这样即使存在恶意代码黑客也无法拿
到 root 权限。

SSL 代理

Redis 并不支持 SSL 链接，意味着客户端和服务器之间交互的数据不应该直接暴露在公
网上传输，否则会有被窃听的风险。如果必须要用在公网上，可以考虑使用 SSL 代理。SSL 代理比较常见的有 ssh，不过 Redis 官方推荐使用 spiped 工具，可能是因为
spiped 的功能相对比较单一，使用也比较简单，易于理解。

左边的 spiped 进程 A 负责接受来自 Redis Client 发送过来的请求数据，加密后传送到
右边的 spiped 进程 B。spiped B 将接收到的数据解密后传递到 Redis Server。然后 Redis Server 再走一个反向的流程将响应回复给 Redis Client。
每一个 spiped 进程都会有一个监听端口 (server socket) 用来接收数据，同时还会作为一个客户端 (socket client) 将数据转发到目标地址。
spiped 进程需要成对出现，相互之间需要使用相同的共享密钥来加密消息.
spiped 可以同时支持多个客户端链接的数据转发工作，它还可以通过参数来限定允许的
最大客户端连接数。但是对于服务器 spiped，它不能同时支持多个服务器之间的转发。意味着在集群环境下，需要为每一个 server 节点启动一个 spiped 进程来代收消息，在运维实践上这可能会比较繁琐。

PS：
【JAVA核心知识】系列导航 [持续更新中…]
关联导航：Redis应用篇
关联导航：Redis基础篇
关联导航：Redis原理篇
关联导航：Redis集群篇
欢迎关注…

参考资料：
《Redis深度历险》