1. 缓存(cache)
Redis最主要的用途，三个方面1.存储数据（内存数据库）；2.缓存[redis最常用的场景]；3.消息队列。
缓存(cache)是计算机中的⼀个经典的概念.核⼼思路就是把⼀些常⽤的数据放到触⼿可及(访问速度更快)的地⽅,⽅便随时读取.
对于硬件的访问速度来说,通常情况下: CPU寄存器>内存>硬盘>⽹络，速度快的设备，可以作为速度慢的设备的缓存。
1.1 使用redis作为缓存
为什么说关系型数据库性能不⾼?
1. 数据库把数据存储在硬盘上,硬盘的IO速度并不快.尤其是随机访问.
2. 如果查询不能命中索引,就需要进⾏表的遍历,这就会⼤⼤增加硬盘IO次数.
3. 关系型数据库对于SQL的执⾏会做⼀系列的解析,校验,优化⼯作.
4. 如果是⼀些复杂查询,⽐如联合查询,需要进⾏笛卡尔积操作,效率更是降低很多.
因为mysql等数据库，效率比较低，所以承担的并发量就有限一旦请求数量多了，数据库的压力就会很大，甚至很容易就宕机了
服务器每次处理一个请求，一定都要消耗一些硬件资源（cpu，内存，硬盘，网络...）任意一种资源的消耗超出了机器能提供的上限，机器就很容易出现故障了
如何提高mysl能承担的并发量？（客观需求）
1.开源：引入更多的机器.构成数据库集群
2.节流：引入缓存，就是典型的方案.把一些频繁读取的热点数据，保存到缓存上,后续在查询数据的时候，如果缓存中已经存在了，就不再访问mysal了.
数据访问流程逻辑：
1.2 缓存的更新策略
缓存的更新策略可以知道redis中应该存储哪些数据，依旧哪些数据是热点数据。
1.定期生成
会把访问的数据，给以日志的形式记录下来。日志记录和分析的过程如下所示：
此处的数据，就可以根据当前这里统计的维度，来定期更新，按照天级别统计，就每天更新一次或者按照月级别统计，就每个月更新一次。
写一套离线的流程（往往使用shell，python写脚本代码....），可以通过定时任务来触发
a）完成统计热词的过程
b）根据热词，找到搜索结果的数据
c）把得到缓存数据同步到缓存服务器上
d）控制这些缓存服务器自动重启
优点：上述过程，实际上实现起来比较简单的.过程更可控.（缓存中有啥是比较固定的），方便排查问题。
缺点：实时性不够.如果出现一些突发性事件，有一些本来不是热词的内容，成了热词了。新的热词就可能给后面的数据库带来较大的压力 。
2. 实时⽣成
如果在Redis查到了,就直接返回.
如果Redis中不存在,就从数据库查,把查到的结果同时也写⼊Redis.
这样不停的写redis，就会使redis的内存占用越来越多，逐渐达到内存上限.（不一定是机器内存上限.redis中也可以配置，最多使用多少内存），此时如果继续往里插入数据，就会触发问题
为了解决上述情况，redis就引入了“内存淘策略”。
redis里面，有一个配置项，就可以设置redis采取上述哪种策略淘汰内存数据：
1.3 缓存预热,缓存穿透,缓存雪崩 和缓存击穿
1. 关于缓存预热(Cachepreheating)
缓存预热，就是用来解决上述问题的：
定期生成和实时生成，结合一下。先通过离线的方式，通过一些统计的途径，先把热点数据找到一批，导入到redis中。此时导入的这批热点数据，就能帮mysal承担很大的压力了.随着时间的推移，逐渐就使用新的热点数据淘汰掉旧的数据。
2. 关于缓存穿透 (Cachepenetration)
查询的某个key，在redisS中没有，mysal中也没有，这个key肯定也不会被更新到redis中。这次查询，没有，下次查，仍然没有。如果像这样的数据，存在很多，并且还反复查询，一样也会给mysql带来很大的压力。
缓存穿透产生的原因：
• 业务设计不合理.⽐如缺少必要的参数校验环节,导致⾮法的key也被进⾏查询了.
• 开发/运维误操作.不⼩⼼把部分数据从数据库上误删了.
• ⿊客恶意攻击
解决方案：
通过改进业务/加强监控报警（不靠谱）
更靠谱的方案 （降低问题的严重性）：
1）如果发现这个key，在redis和mysal上都不存在，仍然写入redis中，value设成一个非法值（比如“”）
2）还可以引入布隆过滤器，每次查询redis/mysal之前都先判定一下key是否在布隆过滤器上存在（把所有的key都插入到布隆过滤器中）
布隆过滤器，本质上是结合了hash+bitmap，以比较小的空间开销和比较快的时间速度，实现针对key是否存在的判定
3.关于缓存雪崩(Cache avalanche)
由于在短时间内，redis上大规模的key失效，导致缓存命中率突然下降，并且mysql的压力迅速上升，甚至直接岩机，产生原因如下所示：
1）redis直接挂了。redis岩机/redis集群模式下大量节点容机....
2）redis好着呢，但是可能之前短时间内设置了很多key给redis，并且设置的过期时间是相同的。给redis里设置key作为缓存的时候，有的时候为了考虑缓存的时效性就会设置过期时间.（和redis内存淘汰机制，是配合使用的）
解决方案：
1）加强监控报警，加强redis集群可用性的保证
2）不给key设置过期时间/设置过期时间的时候添加随机的因子（避免同一时刻过期）
4. 关于缓存击穿(Cache breakdown)
其实这个意思类似于缓存瘫痪。缓存雪崩的特殊情况针对热点key，热点key突然过期了，导致大量的请求直接访问到数据库上，甚至引起数据库宕机。
解决方案：
2 分布式锁
2.1 认识分布式锁
在⼀个分布式的系统中,也会涉及到多个节点访问同⼀个公共资源的情况.此时就需要通过锁来做互斥 控制,避免出现类似于"线程安全"的问题.
⽽java的synchronized或者C++的std::mutex,这样的锁都是只能在当前进程中⽣效,在分布式的这 种多个进程多个主机的场景下就⽆能为⼒了.
此时就需要使⽤到分布式锁。
在分布式系统中，是有很多进程的（每个服务器，都是独立的进程）。因此，之前的锁就难以对现在分布式系统中的多个进程之间产生制约。分布式系统中，多个进程之间的执行顺序也是不确定的。由于进程随机执行，引入“分布式锁”来解决上述问题。
2.2 分布式锁的基础实现
上面这种情况就会出现超卖的情况。
所谓的分布式锁，也是一个/一组单独的服务器程序.给其他的服务器提供“加锁”这样的服务。
Redis是一种典型的可以用来实现分布式锁的方案，但是不是唯一的一种。业界可能也会使用mysl /zookeeper这样的组件来实现分布式锁的效果。
买票服务器，在进行买票操作的过程中，就需要先加锁。（往redis上设置一个特殊的key-value，完成上述买票操作，再把这个key-value删除掉.）其他服务器也想买票的时候，也去redis上尝试设置key-value，如果发现key-value已经存在，就认为“加锁失败”（是放弃/阻塞，就看具体的实现策略了），这样就可以保证第一个服务器执行“查询->更新”过程中，第二个服务器不会执行“查询”，也就解决了上述超卖”问题。
刚才买票场景，使用mysal的事务也可以批量执行查询+修改操作，但是分布式系统中，要访问的共享资源不一定是mysql。也可能是其他的存储介质，没有事务。也可能是执行一段特定的操作，是通过统一的服务器完成执行动作。
对于上面使用setnx在分布式系统上不能成功解锁，引入了过期时间。
可以给set的key设置过期时间，一旦时间到，key就会自动被删除掉了。set ex nx这样的命令来完成设置。
比如，设置key的过期时间，为1000ms，那么意味着即使出现极端情况，某个服务器挂了没有正确释放锁，这个锁最多保持1000ms也就会自动释放了。
redis上的多个命令之间，无法保证原子性的，此时就可能出现，这两个命令一个成功一个失败情况， 相比之下，使用一条命令设置更加稳妥。
所谓的加锁，就是给redis上设置一个key-value。所谓的解锁，就是给redis上这个key-value删除掉。所谓的锁，就是redis的普通键值对。
是否可能会出现服务器1执行了加锁，服务器2执行了解锁。
正常来说，肯定不是故意的，但是代码总会有bug。服务器2在服务器1进行加锁的同时，不小心就执行到了解锁操作.因此就可能进一步的给整个系统带来更严重的问题。
为了解决上述问题，就需要引入一点校验机制：
1.给服务器编号.每个服务器有一个自己的身份标识。
2.进行加锁的时候，设置key-value.key对应着要针对哪个资源加锁（比如车次），value就可以存储刚才服务器的编号，标识出当前这个锁是哪个服务器加上的。后续在解锁的时候，就可以进行校验了。
上述情况来说，看起来重复执行DEL好像问题不大，实则不然。
主要是引入一个新的服务器，执行加锁，就可能出现问题了在线程A执行完DEL之后，B执行DEL之前，服务器2的线程C正好要执行加锁（set），此时由于A已经把锁释放了，C的加锁是能够成功的。但是紧接着，线程BDEL就到来了.就把刚刚服务器2的加锁操作给解锁了
总的来说，就是因为get和set不是原子的。
使用redis事务，能解决上述问题.（redis事务虽然弱但是能够避免插队），但是实践中往往使用的更好的方案，即lua脚本。lua是一个编程语言，作为redis内嵌的脚本，lua语言特别轻量.（实现一个lua解释器，消耗的体积是非常小的）。
可以使用lua编写一些逻辑，把这个脚本上传到redis服务器上，然后就可以让客户端来控制redis执行上述脚本了。redis执行lua脚本的过程，也是原子的。相当于执行一条命令一样（实际上lua中可以写多个命令）redis官方文档，也明确说，lua就属于是事务替代方案。
2.3 引⼊过期时间
过期时间的续约问题，要在加锁的时候，给key设定过期时间。但是过期时间，设置多少合适？
如果设置的短，就可能在你的业务逻辑还没执行完，就释放锁了。
如果设置的太长，就也会导致“锁释放不及时”问题。
更好的方式，是“动态续约“，初始情况下，设置一个过期时间（比如设置1s）就提前在还剩300ms的时候（也不一定就是300ms，数值都灵活调整），如果当前任务还没执行完，就把过期时间再续上1s.等到时间又快到了，任务还没执行完，就再续.（无限续杯）
但是如果服务器中途崩溃了，自然就没人负责续约了。此时锁就能在较短的时间内被自动释放。
动态续约往往也需要服务器这边有一个专门的线程，负责续约这个事情。把这个负责的线程，叫做“看门狗（watch dog）。
2.4 引⼊Redlock算法
使用redis作为分布式锁，redis本身就有可能挂了。要想保证“高可用”就需要通过这样一系列的“预案演习”。
进行加锁，就是把key设置到主节点上，如果主节点挂了，有哨兵自动的把从节点升级成主节点，进一步的保证刚才的锁仍然可用。
主节点和从节点之间的数据同步，是存在延时的。可能主节点收到了set请求，还没来得及同步给从节点呢，主节点就先挂了即使从节点升级成了主节点，但是，刚才的加锁对应的数据，也是不存在的。
作为分布式系统，就需要随时考虑某个节点挂了的情况，需要保证某个节点挂不会影响到大局。
此处加锁，就是按照一定的顺序，针对这些组redis都进行加锁操作。如果某个节点挂了（某个节点加不上锁，没关系，可能是redis挂了）， 继续给下一个节点加锁即可。 如果写入key成功的节点个数超过总数的一半就视为加锁成功。同理，进行解锁的时候，也就会把上述节点都设置一遍解锁。
ps：本文只用来学习时，整理的笔记记录。