Redis高并发缓存架构性能优化实战

场景1: 中小型公司Redis缓存架构以及线上问题实战

线程A在master获取锁之后，master在同步数据到slave时，master突然宕机(此时数据还没有同步到slave)，然后slave会自动选举成为新的master，此时线程B获取锁，结果成功了，这样会造成多个线程获取同一把锁

解决方案

• 网上说RedLock能解决分布式锁失效的问题。对于RedLock实现原理是: 超过半数Redis节点加锁成功之后才能算成功，否则返回false，和Zookeeper的"ZAB"原理很类似，而且与Redis Cluster集群中解决脑裂问题的方案类似，但是RedLock方案有很大的弊端，也就是会造成Redis可用性的延迟，众所周知，Redis的AP(可用性+分区容忍性)机制，假如把Redis变成CP(一致性+分区容忍性)，这样肯定会牺牲一定的可用性，与Redis初衷不符合，也就是说还不如使用Zookeeper。
• Zookeeper具备CP机制以及实现了ZAB，能够确保某一个节点宕机，也能保证数据一致性，而且效率会比Redis高很多，更适合做分布式锁

场景2: 大厂线上大规模商品缓存数据冷热分离实战

问题: 在高并发场景下，一定要把所有的缓存数据一直保存在缓存不让其失效吗？

虽然一直缓存所有数据没什么大问题，但是考虑到如果数据太多，就会一直占用缓存空间(内存资源非常宝贵)，并且数据的维护性也是需要耗时的.

解决方案

• 对缓存数据做冷热分离。在查询数据时，我们只需要在查询代码中再次更新过期时间，这样就能保证热点数据一直在缓存中，而不经常访问的数据过期了就自动从缓存中删除。

流程分析

• 假如一个热点数据每天访问特别高，不停的查询该数据，每次查询时再次更新过期时间，那么在这个过期时间之内只要有人访问就会一直存在缓存中，这样就保证热点商品数据不会因为过期时间而从缓存中移除；
• 而对于不经常访问的冷门数据到了过期时间就可以自动释放了，同时也释放除了一部分缓存空间，而且当再次访问冷门数据的时候，从数据库拿到的永远是最新的数据，也减少了维护成本。

场景3: 基于DCL机制解决热点缓存并发重建问题实战

DCL(双重检测锁)

问题: 冷门数据突然变成了热门数据，大量的请求突发性的对热点数据进行缓存重建导致系统压力暴增

解决方案

• 最容易想到的就是加锁
• DCL机制。先查一次，缓存有数据就直接返回，没有数据，就加锁，在锁的代码块中再次先查询缓存。这样锁的目的就是为了当第一次缓存从数据库查询更新到缓存中，代码块执行完，其他线程再次进来，此时缓存中就已经存在数据了，这样就减少了查询数据库的次数.在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

public Product get(Long productId) 
{    
Product product = null;    
String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;    
//DCL机制：第一次先从缓存里查数据    
product = getProductFromCache(prod