缓存的6种常见的使用场景

缓存的使用场景

1.1、作为数据库的缓存,为数据库减压

通常情况下,数据是存储在数据库的,应用程序也是直接操作数据库。在访问量较小的时候几乎没有什么影响。

一旦读写请求量超过1w,数据库压力剧增,此时可以从数据库角度做处理,比如:

做读写分离,一主一从或者一主多从。

如果压力还持续增大,做分库分表,根据业务将数据库拆分为多个,根据需要,将数据库表拆分为多张表,分别放在多个库,又可以支撑一定的请求。再增大呢,我们继续增加分库分表吗?

当访问量超过10w, 100w, 1000w呢,其实这时候我们需要引入缓存,因为大多数的操作都是查询操作。

将访问过的数据存储起来,当再次访问时,先找到缓存,缓存命中就直接返回。找不到再查询数据库,并且回填缓存,下次访问就能直接命中缓存了。

1.2、提高系统响应速度

数据库的数据实际上是存储在文件里的,比如mysql,你可以在它的data目录下面看到,当数据需要迁移时,甚至可以直接拷贝磁盘文件,再稍作修改就可以实现数据迁移。与磁盘打交道,就需要与内存做交换,做swap操作。性能时比较差的。

当大量的并发请求,数据库可能因为太过频繁的IO操作导致无法正常返回结果。而将数据存储在缓存中(redis), 也就是存储在内存中。

而内存天然就支持高并发,可以处理瞬时大量的并发请求。

比如redis的单机qps能后达到11w/s读请求,8w/s写请求。可以说是甩开数据库无数倍。当然我们的响应速度也是得到了一个质的飞跃。

1.3、session共享

我们知道,当我们后台启动多台tomcat之后,上层再加了一层nginx做负载均衡的话,我们就会惊奇的发现,有时能够正常访问,,有时不能后正常访问。就是因为两个tomcat的session是不一样的。当然,可以做session复制等操作解决,但是性能比较低下。并且难以保证各个session之间完全同步。

如何解决呢?当然是使用redis来存储session,让他它们使用同一个session就ok了。这样就实现了session的共享。

登录成功之后,将session存储到redis,获取session时从redis查询。

1.4、存储token令牌,短信验证码等

session共享虽然解决了问题,但是这些都是基于pc端,或者存在session的内置浏览器中。但是比如app等没有session的,那就是基于token实现登录,登录前的验证码发送也都会存储在redis中。


1.5、做分布式锁

通常来说我们Java程序中的锁,是多线程的锁,是在一个JVM当众生效的,管不了其他JVM中的线程。

而多个进程(JVM)在并发时也会产生问题,也要控制时序性,此时就需要使用分布式锁。

1.5.1、使用Redis的setNX实现分布式锁

当然,这种方式存在并发问题,不值得讨论

1.5.2、使用redission实现分布式锁


public class DistributedRedisLock {

    //从配置类中获取redisson对象

    private static Redisson redisson = RedissonManager.getRedisson();

    private static final String LOCK_PREFIX = "RedisLock_";

    //加锁

    public static boolean acquire(String lockName) {

        //声明key对象

        String key = LOCK_PREFIX + lockName;

        //获取锁对象

        RLock mylock = redisson.getLock(key);

        //加锁,并且设置锁过期时间3秒,防止死锁的产生 uuid+threadId

        mylock.lock(2, 3, TimeUtil.SECOND);

        //加锁成功

        return true;

    }

    //锁的释放

    public static void release(String lockName) {

        //必须是和加锁时的同一个key

        String key = LOCK_PREFIX + lockName;

        //获取所对象

        RLock mylock = redisson.getLock(key);

        //释放锁(解锁)

        mylock.unlock();

    }

}


1.6、做乐观锁

Mysql中,同步锁和数据库中的行锁、表锁都是悲观锁

Java中 synchronized和可重入锁等都是悲观锁

悲观锁的性能是比较低的,响应性比较差,而高性能、高响应的锁一般都是使用乐观锁

Redis可以实现乐观锁 watch + incr


public static void main(String[] arg) {

    String redisKey = "lock";

    ExecutorService executorService = Executors.newFixedThreadPool(20);

    try {

        Jedis jedis = new Jedis("127.0.0.1", 6378);

        // 初始值

        jedis.set(redisKey, "0");

        jedis.close();

    } catch (Exception e) {

        e.printStackTrace();

    }

    for (int i = 0; i < 1000; i++) {

        executorService.execute(() -> {

            Jedis jedis1 = new Jedis("127.0.0.1", 6378);

            try {

                jedis1.watch(redisKey);

                String redisValue = jedis1.get(redisKey);

                int valInteger = Integer.valueOf(redisValue);

                String userInfo = UUID.randomUUID().toString();

                // 没有秒完

                if (valInteger < 20) {

                    Transaction tx = jedis1.multi();

                    tx.incr(redisKey);

                    List list = tx.exec();

                    // 秒成功 失败返回空list而不是空

                    if (list != null && list.size() > 0) {

                        System.out.println("用户:" + userInfo + ",秒杀成功!当前成功人数:" + (valInteger + 1));

                    }

                    // 版本变化,被别人抢了。

                    else {

                        System.out.println("用户:" + userInfo + ",秒杀失败");

                    }

                }

                // 秒完了

                else {

                    System.out.println("已经有20人秒杀成功,秒杀结束");

                }

            } catch (Exception e) {

                e.printStackTrace();

            } finally {

                jedis1.close();

            }

        });

    }

    executorService.shutdown();

}

©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

友情链接更多精彩内容