redis实战

分布式锁的实现

     关于锁，其实我们或多或少都有接触过一些，比如synchronized、 Lock这些，这类锁的目的很简单，在多线程环 境下，对共享资源的访问造成的线程安全问题，通过锁的机制来实现资源访问互斥。那么什么是分布式锁呢?或者 为什么我们需要通过Redis来构建分布式锁，其实最根本原因就是Score(范围)，因为在分布式架构中，所有的应 用都是进程隔离的，在多进程访问共享资源的时候我们需要满足互斥性，就需要设定一个所有进程都能看得到的范 围，而这个范围就是Redis本身。所以我们才需要把锁构建到Redis中。

     Redis里面提供了一些比较具有能够实现锁特性的命令，比如SETEX(在键不存在的情况下为键设置值)，那么我们可 以基于这个命令来去实现一些简单的锁的操作

Redisson实现分布式锁

      Redisson它除了常规的操作命令以外，还基于redis本身的特性去实现了很多功能的封装，比如分布式锁、原子操作、布隆过滤器、队列等等。我们可以直接利用这个api提供的功能去实现。

原理分析

trylock

tryAcquire

tryLockInnerAsync

通过lua脚本来实现加锁的操作

1. 判断lock键是否存在，不存在直接调用hset存储当前线程信息并且设置过期时间,返回nil，告诉客户端直接获取到锁。
2. 判断lock键是否存在，存在则将重入次数加1，并重新设置过期时间，返回nil，告诉客户端直接获取到锁。 
3. 被其它线程已经锁定，返回锁有效期的剩余时间，告诉客户端需要等待。

unlock

1. 如果lock键不存在，发消息说锁已经可用，发送一个消息 
2. 如果锁不是被当前线程锁定，则返回nil
3. 由于支持可重入，在解锁时将重入次数需要减1
4. 如果计算后的重入次数>0，则重新设置过期时间
5. 如果计算后的重入次数<=0，则发消息说锁已经可用

Redis的应用架构

      对于读多写少的高并发场景，我们会经常使用缓存来进行优化。比如说支付宝的余额展示功能，实际上99%的时候 都是查询，1%的请求是变更(除非是土豪，每秒钟都有收入在不断更改余额)，所以，我们在这样的场景下，可 以加入缓存，用户->余额

Redis缓存与数据一致性问题

那么基于上面的这个出发点，问题就来了，当用户的余额发生变化的时候，如何更新缓存中的数据，也就是说。 
1. 我是先更新缓存中的数据再更新数据库的数据;
2. 还是修改数据库中的数据再更新缓存中的数据
这就是我们经常会在面试遇到的问题，数据库的数据和缓存中的数据如何达到一致性?首先，可以肯定的是， redis中的数据和数据库中的数据不可能保证事务性达到统一的，这个是毫无疑问的，所以在实际应用中，我们都 是基于当前的场景进行权衡降低出现不一致问题的出现概率

更新缓存还是让缓存失效

     更新缓存表示数据不但会写入到数据库，还会同步更新缓存; 而让缓存失效是表示只更新数据库中的数据，然后删除缓存中对应的key。那么这两种方式怎么去选择?这块有一个衡量的指标。
1. 如果更新缓存的代价很小，那么可以先更新缓存，这个代价很小的意思是我不需要很复杂的计算去获得最新的余额数字。
2. 如果是更新缓存的代价很大，意味着需要通过多个接口调用和数据查询才能获得最新的结果，那么可以先淘汰 缓存。淘汰缓存以后后续的请求如果在缓存中找不到，自然去数据库中检索。

先操作数据库还是先操作缓存?

     当客户端发起事务类型请求时，假设我们以让缓存失效作为缓存的的处理方式，那么又会存在两个情况，
1. 先更新数据库再让缓存失效
2. 先让缓存失效，再更新数据库
      前面我们讲过，更新数据库和更新缓存这两个操作，是无法保证原子性的，所以我们需要根据当前业务的场景的容忍性来选择。也就是如果出现不一致的情况下，哪一种更新方式对业务的影响最小，就先执行影响最小的方案

最终一致性的解决方案

缓存雪崩

       缓存雪崩是指设置缓存时采用了相同的过期时间，导致缓存在某一个时刻同时失效，或者缓存服务器宕机宕机导致 缓存全面失效，请求全部转发到了DB层面，DB由于瞬间压力增大而导致崩溃。缓存失效导致的雪崩效应对底层系 统的冲击是很大的。

解决方式

      1. 对缓存的访问，如果发现从缓存中取不到值，那么通过加锁或者队列的方式保证缓存的单进程操作，从而避免 失效时并发请求全部落到底层的存储系统上;但是这种方式会带来性能上的损耗

      2. 将缓存失效的时间分散，降低每一个缓存过期时间的重复率

      3.如果是因为缓存服务器故障导致的问题，一方面需要保证缓存服务器的高可用、另一方面，应用程序中可以采用多级缓存

缓存穿透

       缓存穿透是指查询一个根本不存在的数据，缓存和数据源都不会命中。出于容错的考虑，如果从数据层查不到数据 则不写入缓存，即数据源返回值为 null 时，不缓存 null。缓存穿透问题可能会使后端数据源负载加大，由于很多后 端数据源不具备高并发性，甚至可能造成后端数据源宕掉

解决方式

    1. 如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。比如，”key” , “&&”。

     2. 根据缓存数据Key的设计规则，将不符合规则的key进行过滤 采用布隆过滤器（采用bit位判断，某样东西一定不存在或者可能存在），将所有可能存在的数据哈希到一个足够大的BitSet中，不存在的数据将会被拦截掉，从而避免了对底层存储系统的查询压力