info指令

• Info 指令显示的信息非常繁多，分为 9 大块，每个块都有非常多的参数，

 1、Server 服务器运行的环境参数
 2、Clients 客户端相关信息
 3、Memory 服务器运行内存统计数据
 4、Persistence 持久化信息
 5、Stats 通用统计数据
 6、Replication 主从复制相关信息
 7、CPU CPU 使用情况
 8、Cluster 集群信息
 9、KeySpace 键值对统计数量信息

• Redis 每秒执行多少次指令

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

• Redis 连接了多少客户端

> redis-cli info clients
# Clients
connected_clients:124 # 这个就是正在连接的客户端数量
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients: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集群时是有缺陷的。
• 比如在 Sentinel 集群中，主节点挂掉时，从节点会取而代之，客户端上却并没有明显感知。原先第一个客户端在主节点中申请成功了一把锁，但是这把锁还没有来得及同步到从节点，主节点突然挂掉了。然后从节点变成了主节点，这个新的节点内部没有这个锁，所以当另一个客户端过来请求加锁时，立即就批准了。这样就会导致系统中同样一把锁被两个客户端同时持有，不安全性由此产生。
• 为了解决这个问题，就有个Redlock算法。Redlock原理和大多数的分布式处理方式是类似的，都是采用的过半原则。加锁时，会向过半节点发送 set(key, value, nx=True, ex=xxx) 指令，只要过半节点 set 成功，那就认为加锁成功。释放锁时，需要向所有节点发送 del 指令。（既然是操作多个节点，性能上自然是要下降的）

过期策略

• redis 会将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定时遍历这个字典来删除到期的 key。除了定时遍历之外，它还会使用惰性策略来删除过期的 key，所谓惰性策略就是在客户端访问这个 key 的时候，redis 对 key 的过期时间进行检查，如果过期了就立即删除。定时删除是集中处理，惰性删除是零散处理。
• Redis 默认会每秒进行十次过期扫描，redis的定时扫描不是扫描全部，而是采取一种简单的贪心策略

 1、从过期字典中随机 20 个 key；
 2、删除这 20 个 key 中已经过期的 key；
 3、如果过期的 key 比率超过 1/4，那就重复步骤 1；

• 从库对过期数据的处理是被动，只能同步主库的处理，这期间是有延迟的，会出现主从数据不一致的情况。

LRU

• 当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)。交换会让 Redis 的性能急剧下降，对于访问量比较频繁的 Redis 来说，这样龟速的存取效率基本上等于不可用。
• 为了防止这种情况，redis有几种避免策略可供选择

noeviction 不会继续服务写请求 (DEL 请求可以继续服务)，读请求可以继续进行。这样可以保证不会丢失数据，但是会让线上的业务不能持续进行。这是默认的淘汰策略。
volatile-lru 尝试淘汰设置了过期时间的 key，最少使用的 key 优先被淘汰。没有设置过期时间的 key 不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。
volatile-ttl 跟上面一样，除了淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。
volatile-random 跟上面一样，不过淘汰的 key 是过期 key 集合中随机的 key。 
allkeys-lru 区别于 volatile-lru，这个策略要淘汰的 key 对象是全体的 key 集合，而不只是过期的 key 集合。这意味着没有设置过期时间的 key 也会被淘汰。
allkeys-random 跟上面一样，不过淘汰的策略是随机的 key。 
volatile-xxx 策略只会针对带过期时间的 key 进行淘汰，allkeys-xxx 策略会对所有的key 进行淘汰。如果你只是拿 Redis 做缓存，那应该使用 allkeys-xxx，客户端写缓存时不必携带过期时间。如果你还想同时使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，这样可以保留没有设置过期时间的 key，它们是永久的 key 不会被 LRU 算法淘汰。

• 实现 LRU 算法除了需要 key/value 字典外，还需要附加一个链表，链表中的元素按照一定的顺序进行排列。当空间满的时候，会踢掉链表尾部的元素。当字典的某个元素被访问时，它在链表中的位置会被移动到表头。所以链表的元素排列顺序就是元素最近被访问的时间顺序。
• 因为实现LRU要大额内存的支持，redis是使用的类似LRU的算法，随机取5个key淘汰这5各种最久没被使用的key。为了使淘汰的数据更准确，redis还加了个淘汰池，每次随机出来的数据先融入这个淘汰池然后再淘汰最久没被使用的key。

保护redis

• 指令安全：Redis 有一些非常危险的指令，这些指令会对 Redis 的稳定以及数据安全造成非常严重的影响。比如 keys 指令会导致 Redis 卡顿，flushdb 和 flushall 会让 Redis 的所有数据全部清空。为了避免这种情况可以在配置文件中将这些危险的指令重命名或屏蔽掉（rename-command keys abckeysabc，rename-command flushall ""）

• 端口安全：Redis 默认会监听 *:6379，如果当前的服务器主机有外网地址，Redis 的服务将会直接暴露在公网上，任何一个初级黑客使用适当的工具对 IP 地址进行端口扫描就可以探测出来。为了避免这种情况，有必要指定要监听的ip（bind 10.100.20.13）以及设置redis密码访问权限（requirepass yoursecurepasswordhereplease）

• SSL 代理：Redis 并不支持 SSL 链接，意味着客户端和服务器之间交互的数据不应该直接暴露在公网上传输，否则会有被窃听的风险。如果必须要用在公网上，可以考虑使用 SSL 代理。为了规避这种风险可以使用官方推荐的 spiped 工具