[大数据]Test 28

• Redis
  1. Key的过期淘汰机制
     1. Redis可以对存储在redis中的缓存数据设置过期时间，要注意并不是key过期时间到了就一定会被redis删除
  2. 定期删除
     1. Reids默认是没隔100ms就随机抽取一些设置了过期时间的key检查其是否过期，如果过期就删除。
  3. 惰性删除
     1. 定期删除由于是随机抽取可能会导致很多过期的key到了过期时间并没有被删除所以用户在从缓存获取数据的时候，redis会检查这个key是否过期了，如果过期就删除这个key。这个时候就会在查询的时候将过期key从缓存中清除
  4. 内存淘汰机制
     1. 仅仅使用定期删除+惰性删除会导致:如果定期删除留下了很多过期的key而用户又长时间不用导致过期数据一直堆积在内存中
     2. Redis提供了六种内存淘汰机制：
        • volatile-lru ：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。
        • volatile-ttl ：从已设置过期时间的数据集中挑选将要过期的数据淘汰。
        • volatile-random ：从已设置过期时间的数据集中任意选择数据淘汰。
        • allkeys-lru ：当内存不足以容纳新写入数据时移除最近最少使用的key。
        • allkeys-random ：从数据集中任意选择数据淘汰。
        • no-enviction（默认） ：当内存不足以容纳新写入数据时，新写入操作会报错
     3. ?一般情况下，推荐使用 volatile-lru 策略，对于配置信息等重要数据，不应该设置过期时间，这样Redis就永远不会淘汰这些重要数据。对于一般数据可以添加一个缓存时间，当数据失效则请求会从DB中获取并重新存入Redis中。
  5. 缓存击穿
     1. 高并发的情况下，某个热门key突然过期，导致大量请求在redis未找到缓存数据，进而全部去访问db请求数据，引起db压力瞬间增大
     2. 解决方案：缓存击穿的情况下一般不容易造成DB的宕机，只是会造成对DB的周期性压力
        • Redis中的数据不设置过期时间，然后在缓存的对象上添加一个属性标识过期时间，每次获取数据时校验对象中的过期时间属性，如果数据即将过期，则异步发起一个线程主动更新缓存中的数据。这种方案可能会导致有些请求会拿到过期的值。
        • 如果要求数据必须是新数据，最好是未热点数据设置未永不过期然后加一个互斥锁保证缓存的单线程写入。
  6. 缓存穿透
     1. 缓存穿透是指查询缓存和db都不存在的数据，由于缓存是不命中则从db中获取数据，这导致每次缓存都不命中数据导致每个请求都访问db，造成缓存穿透。
     2. 解决方案:
        • 利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试
        • 采用异步更新策略，无论key是否取到值，都直接返回。Value值值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存需要做缓存预热（项目启动前，先加载缓存）操作。
        • 提供一个能迅速判断请求是否有效的拦截机制，比如布隆过滤器内部维护一系列合法有效的key，迅速判断出，请求所携带的key是否合法有效。如果不合法则直接返回。
        • 如果从数据库查询的对象为空，也放入缓存，只是设定的缓存过期时间较短，比如设置为60s
  7. 缓存雪崩
     1. 缓存中如果大量缓存在一段时间内集中过期了，这时候会发生大量的缓存击穿现象，所有的请求都落在了db上，由于查询数据量巨大，引起db压力过大甚至导致db宕机。
     2. 解决方案：
        • 给缓存的失效时间，加上一个随机值，避免集体失效。如果redis是集群部署，将热点数据均匀分布在不同的redis库中也能避免全部失效的问题
        • 使用互斥锁，但是吞吐量明显下降
        • 设置热点数据永不过期
        • 双缓存。设置两个缓存A和B，缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几点
          1. 从缓存A读数据库，有则直接返回
          2. A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程
          3. 更新线程同时更新缓存A和缓存B
• rabbitMq
  1. 优点：解耦合、异步处理、流量削峰。缺点：系统可用性降低、系统复杂性增加
  2. 简单模式队列：简单队列-处理消息效率不高，吞吐量较低，不适合生成环境
  3. 工作模式队列
     1. 消息轮询分发：工作队列-消息轮询分发-消费者收到的消息数量平均分配，单位时间内消息处理速度加快，提高了吞吐量。
     2. 消息公平分发：消息分发采用的是默认轮询分发，消息应答采用的自动应答模
     3. 式，这是因为当消息进入队列，RabbitMQ就会分派消息。它不看消费者为应答的数目，只是盲目的将第n条消息发给第n个消费者。 为了解决这个问题，我们使用 basicQos(prefetchCount = 1) 方法，来限制RabbitMQ只发不超过1条的消息给同一个消费者。当消息处理完毕后，有了反馈，才会进行第二次发送。
     4. 工作队列-公平轮询分发-根据不同消费者机器硬件配置，消息处理速度不同，收到的消息数量也不同，通常速度快的处理的消息数量比较多，最大化使用计算机资源。适用于生成环境。
  4. 消息的发布与订阅模式（广播模式）
  5. 路由模式：生产者发送了多条设置了路由规则的消息，消费者可以根据具体的路由规则消费对应队列中的消息，而不是所有消费者都可以消费所有消息了。
  6. 主题模式：根据不同的路由匹配规则(主题)，可以将消息根据指定的routing key路由到匹配到的队列中，也是在生产中比较常见的一种消息处理方式。
  7. RPC-远程过程调用模式队列