【Redis】核心理论&典型应用场景
https://www.cnblogs.com/wzh2010/p/17205505.html
Redis系列1：深刻理解高性能Redis的本质
Redis系列2：数据持久化提高可用性
Redis系列3：高可用之主从架构
Redis系列4：高可用之Sentinel(哨兵模式）
Redis系列5：深入分析Cluster 集群模式
追求性能极致：Redis6.0的多线程模型
追求性能极致：客户端缓存带来的革命
Redis系列8：Bitmap实现亿万级数据计算
Redis系列9：Geo 类型赋能亿级地图位置计算
Redis系列10：HyperLogLog实现海量数据基数统计
Redis系列11：内存淘汰策略
Redis系列12：Redis 的事务机制
Redis系列13：分布式锁实现
Redis系列14：使用List实现消息队列
Redis系列15：使用Stream实现消息队列
Redis系列16：聊聊布隆过滤器（原理篇）
Redis系列17：聊聊布隆过滤器（实践篇）
Redis系列18：过期数据的删除策略
Redis系列19：LRU内存淘汰算法分析
Redis系列20：LFU内存淘汰算法分析
Redis系列21：缓存与数据库的数据一致性讨论
Redis系列22：Redis 的Pub/Sub能力
Redis系列23：性能优化指南
强烈建议参考：https://mp.weixin.qq.com/s/7ct-mvSIaT3o4-tsMaKRWA 阿里 一文搞懂Redis（从数据结构、存储原理，事务，持久化都有涉及，简单精炼）
支持数据类型
Redis针对不同数据类型的命令梳理和演示：参考 https://www.cnblogs.com/xinhuaxuan/p/9250680.html
zset：默认ziplist存储，在数据量达到一定数量下（配置文件可定制），使用跳表skipList实现
持久化：
方案：RDB、AOF(记录每个操作）、RDB+AOF（混合持久化）
https://redis.io/docs/management/persistence/ 注意了解每种方式的不足
RDB: Fork新子线程进行处理，通过 call the SAVE or BGSAVE 命令
SAVE 保存是阻塞主进程，客户端无法连接redis，等SAVE完成后，主进程才开始工作，客户端可以连接
BGSAVE 是fork一个save的子进程，在执行save过程中，不影响主进程，客户端可以正常链接redis，等子进程fork执行save完成后，通知主进程，子进程关闭。很明显BGSAVE方式比较适合线上的维护操作，两种方式的使用一定要了解清楚在谨慎选择。
配置：save 60 1000
-
Redis forks. We now have a child and a parent process.
-
The child starts to write the dataset to a temporary RDB file.
-
When the child is done writing the new RDB file, it replaces the old one.
劣势：
- RDB is NOT good if you need to minimize the chance of data loss in case Redis stops working (for example after a power outage). You can configure different save points where an RDB is produced (for instance after at least five minutes and 100 writes against the data set, you can have multiple save points). However you'll usually create an RDB snapshot every five minutes or more, so in case of Redis stopping working without a correct shutdown for any reason you should be prepared to lose the latest minutes of data.
- RDB needs to fork() often in order to persist on disk using a child process. fork() can be time consuming if the dataset is big, and may result in Redis stopping serving clients for some milliseconds or even for one second if the dataset is very big and the CPU performance is not great. AOF also needs to fork() but less frequently and you can tune how often you want to rewrite your logs without any trade-off on durability.
RDB+AOF（混合持久化）： Redis 4.0新增
混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将aof_rewrite_buf重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。
简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据
二、应用场景
万亿级日访问量下，Redis在微博的9年优化历程 https://cloud.tencent.com/developer/news/462944 ~~干货满满
转载：https://blog.csdn.net/qq_42046105/article/details/95272836
首先介绍一下业务背景：总用户量大概是 5亿左右，月活 5kw，日活近 2kw 。服务端有 1000 多个 Redis 实例，100+ 集群，每个实例的内存控制在 20g 以下。
典型场景：
KV 缓存，分布式锁，延时队列，定时任务，频率控制，服务发现，位图，模糊计数，布隆过滤器
网站访问统计、分布式Session、应用排行榜、社交关系图
KV 缓存
基本使用：用 Redis 来缓存用户信息、会话信息、商品信息等等
当数据量不断增长时，就使用 Codis 或者 Redis-Cluster 集群来扩容。
除此之外 Redis 还提供了缓存模式，Set 指令不必设置过期时间，它也可以将这些键值对按照一定的策略进行淘汰。
打开缓存模式的指令是：config set maxmemory 20gb ，这样当内存达到 20gb 时，Redis 就会开始执行淘汰策略，给新来的键值对腾出空间。
这个策略 Redis 也是提供了很多种，总结起来这个策略分为两块：划定淘汰范围，选择淘汰算法。
比如我们线上使用的策略是 allkeys-lru。这个 allkeys 表示对 Redis 内部所有的 key 都有可能被淘汰，不管它有没有带过期时间，而volatile只淘汰带过期时间的。
当这个范围圈定之后，会从中选出若干个名额，怎么选择呢，这个就是淘汰算法。
最常用的就是 LRU 算法，它有一个弱点，那就是表面功夫做得好的人可以逃过优化。 Redis 4.0 里面引入了 LFU 算法，要对平时的成绩也进行考核，只做表面功夫就已经不够用了，还要看你平时勤不勤快。
最后还一种极不常用的算法 —— 随机摇号算法，这个算法有可能会把 CEO 也给淘汰了，所以一般不会使用它。
分布式锁
使用场景
给你一个亿的keys，Redis如何统计？ https://new.qq.com/omn/20210105/20210105A04VDK00.html
实践：
批量查询：字符串 MGET命令、哈希表 HMGET命令、管道技术、Lua 脚本
https://developer.aliyun.com/article/1432097?spm=a2c6h.12873639.article-detail.53.133d5f81QGQ6tr
