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：本文只用来学习时，整理的笔记记录。