Redis详解
Redis
为什么用Redis
速度快，完全基于内存，使用C语言实现，网络层使用epoll解决高并发问题，单线程模型避免了不必要的上下文切换及竞争条件；
注意：单线程仅仅是说在网络请求这一模块上用一个请求处理客户端的请求，像持久化它就会重开一个线程/进程去进行处理。
丰富的数据类型，Redis有8种数据类型，当然常用的主要是 String、Hash、List、Set、 SortSet 这5种类型
Redis 持久化
AOF
AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF 命令以 Redis 协议追加保存每次写的操作到文件末尾。
Redis 还能对 AOF 文件进行后台重写，使得 AOF 文件的体积不至于过大。
同时开启两种持久化方式，在这种情况下，当 Redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。
可以使用不同的 Fsync 策略：无 Fsync、每秒 Fsync 、每次写的时候 Fsync 使用默认的每秒 Fsync 策略。
一旦出现故障，你最多丢失 1 秒的数据。
RDB
在指定的时间间隔对你的数据进行快照存储。
RDB 是一个非常紧凑的单一文件,它保存了某个时间点的数据集，非常适用于数据集的备份，方便传输，非常使用于灾备。
RDB 在保存 RDB 文件时父进程唯一需要做的就是 Fork 出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他 IO 操作，所以 RDB 持久化方式可以最大化 Redis 的性能。
与 AOF 相比，在恢复大的数据集的时候，RDB 方式会更快一些。
用Redis去保存用户的基本信息，虽然它能够支持持久化，但是它的持久化方案并不能保证数据绝对的落地，并且还可能带来Redis性能下降，因为持久化太过频繁会增大Redis服务的压力。
为什么Redis 这么快
- 完全基于内存
- 数据结构简单，对数据操作也简单
- 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗
- 使用多路I/O复用模型，非阻塞IO
多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。
这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。
Redis是用”单线程-多路复用IO模型”来实现高性能的内存数据服务的，这种机制避免了使用锁，但是同时这种机制在进行sunion之类的比较耗时的命令时会使redis的并发下降。因为是单一线程，所以同一时刻只有一个操作在进行，所以，耗时的命令会导致并发的下降，不只是读并发，写并发也会下降。而单一线程也只能用到一个CPU核心，所以可以在同一个多核的服务器中，可以启动多个实例，组成master-master或者master-slave的形式，耗时的读命令可以完全在slave进行。
Redis指标
缓存命中率
keyspace_misses/keyspace_hits这两个指标用来统计缓存的命令率
连接数
连接的客户端数量，可通过命令src/redis-cli info Clients | grep connected_clients得到。
不能太大，建议不要超过5000，如果太大可能是redis处理太慢，那么需要排除问题找出原因。
另外还有一个拒绝连接数（rejected_connections）也需要关注，这个值理想状态是0。如果大于0，说明创建的连接数超过了maxclients，需要排查原因。是redis连接池配置不合理还是连接这个redis实例的服务过多等。
阻塞客户端数量
src/redis-cli info Clients | grep blocked_clients 最好应该为0
一般是执行了list数据类型的BLPOP或者BRPOP命令引起的
使用内存峰值
Redis可以通过命令config set maxmemory 10737418240设置允许使用的最大内存（强烈建议不要超过20G），为了防止发生swap导致Redis性能骤降，甚至由于使用内存超标导致被系统kill，建议used_memory_peak的值与maxmemory的值有个安全区间，例如1G，那么used_memory_peak的值不能超过9663676416（9G）
内存碎片率
redis4.0 碎片整理允许Redis压缩内存空间，从而回收内存
建议used_memory至少1G以上才考虑对内存碎片率进行监控。
OPS 每秒操作数
instantaneous_ops_per_sec这个指标表示缓存的OPS，如果业务比较平稳，那么这个值也不会波动很大
持久化
rdb_last_bgsave_status/aof_last_bgrewrite_status，即最近一次或者说最后一次RDB/AOF持久化是否有问题，这两个值都应该是"ok"。
失效KEY
如果把Redis当缓存使用，那么建议所有的key都设置了expire属性，通过命令src/redis-cli info Keyspace得到每个db中key的数量和设置了expire属性的key的属性，且expires需要等于keys
慢日志
通过命令slowlog get得到Redis执行的slowlog集合，理想情况下，slowlog集合应该为空，即没有任何慢日志，不过，有时候由于网络波动等原因造成set key value这种命令执行也需要几毫秒，在监控的时候我们需要注意，而不能看到slowlog就想着去优化，简单的set/get可能也会出现在slowlog中。
Redis List
Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现。
Lists 就是链表，相信略有数据结构知识的人都应该能理解其结构。使用Lists结构，我们可以轻松地实现最新消息排行等功能。
Lists的另一个应用就是消息队列，
可以利用Lists的PUSH操作，将任务存在Lists中，然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作Lists中某一段的api，你可以直接查询，删除Lists中某一段的元素。
用redis的list当作队列可能存在的问题
redis崩溃的时候队列功能失效
如果入队端一直在塞数据，而出队端没有消费数据，或者是入队的频率大而多，出队端的消费频率慢会导致内存暴涨
Redis的队列也可以像rabbitmq那样 即可以做消息的持久化，也可以不做消息的持久化。
当做持久话的时候，需要启动redis的dump数据的功能.暂时不建议开启持久化。
Redis其实只适合作为缓存，而不是数据库或是存储。它的持久化方式适用于救救急啥的，不太适合当作一个普通功能来用。应为dump时候，会影响性能，数据量小的时候还看不出来，当数据量达到百万级别，内存10g左右的时候，非常影响性能。
假如有多个消费者同时监听一个队列，其中一个出队了一个元素，另一个则获取不到该元素
Redis的队列应用场景是一对多或者一对一的关系，即有多个入队端，但是只有一个消费端(出队)
Redis缓存穿透、缓存雪崩和缓存击穿
缓存穿透
缓存穿透，是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。
如果传入的参数为-1，会是怎么样？这个-1，就是一定不存在的对象。就会每次都去查询数据库，而每次查询都是空，每次又都不会进行缓存。假如有恶意攻击，就可以利用这个漏洞，对数据库造成压力，甚至压垮数据库。
解决方法
如果从数据库查询的对象为空，也放入缓存，只是设定的缓存过期时间较短，比如设置为60秒。
缓存雪崩
在某一个时间段，缓存集中过期失效。对于数据库，就会产生周期性的压力波峰。
采取不同分类商品，缓存不同周期。在同一分类中的商品，加上一个随机因子。这样能尽可能分散缓存过期时间，而且，热门类目的商品缓存时间长一些，冷门类目的商品缓存时间短一些，也能节省缓存服务的资源。
其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，那么那个时候数据库能顶住压力，这个时候，数据库也是可以顶住压力的。
缓存击穿
是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
比如：爆款，让其永不过期
Redis 排行榜
sorted set
ZINCRBY rank:20150401 5 1
redis的sorted set去实现, 只能设定单一的排序分值score
https://blog.csdn.net/chaoluo001/article/details/77453848
更新缓存 VS 淘汰缓存
只是简单的把余额money设置成一个值，那么：
（1）淘汰缓存的操作为deleteCache(uid)
（2）更新缓存的操作为setCache(uid, money)
更新缓存的代价很小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率
如果余额是通过很复杂的数据计算得出来的，
更新缓存的代价很大，此时我们应该更倾向于淘汰缓存。
however，淘汰缓存操作简单，并且带来的副作用只是增加了一次cache miss，建议作为通用的处理方式。
先操作数据库 vs 先操作缓存
如果出现不一致，谁先做对业务的影响较小，就谁先执行。
假设先写数据库，再淘汰缓存：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致。
假设先淘汰缓存，再写数据库：第一步淘汰缓存成功，第二步写数据库失败，则只会引发一次Cache miss。
数据和缓存的操作时序，结论是清楚的：先淘汰缓存，再写数据库。
我的公众号
程序员进化之路，从一个简单的公众号开始
