weixin_62079735的博客

阻塞行为lock方法是阻塞的，如果锁不可用，调用线程会一直等待直到获得锁。tryLock方法是非阻塞的，如果锁不可用，它会立即返回一个布尔值，指示锁是否获取成功。灵活性lock方法适合在必须获取锁的情况下使用，不考虑获取锁的时间长短。tryLock方法提供了更大的灵活性，可以立即返回结果，也可以指定超时时间，适合在需要非阻塞获取锁的情况下使用。使用场景lock适用于需要确保访问共享资源，并且能够容忍阻塞的情况。tryLock。

签到是一个很常见的功能，如果使用数据库实现，那么用户一次签到，就是一条记录，假如有100万用户，平均每个用户每年签到次数为30次，则这张表一年的数据量为 3000 万条，一般签到记录字段不会太多一条数据按照30字节算，一年就是858.3MB左右，但是对于签到信息查询是比较频繁的，如查询当天是否签到、查询用户近7天签到记录、查询用户近30天签到记录、统计用户签到次数，如果这些查询都要去签到表查询那么数据库压力是非常大的，而且考虑到数据量会不断增长，这里使用Redis BitMap 实现高效的签到与统计。

缓存异常会面临的三个问题：缓存雪崩、击穿和穿透。

当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。

如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，这就是缓存击穿的问题。

当大量缓存数据在同一时间过期（失效）或者 Redis 故障宕机时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。

fsync策略

最近在复习自己的技术社区的源码时候发现了一个之前自己忽略的一个有趣的地方：就是在项目的Redis操作封装类RedisClient中（包含封装了redis的几种数据结构的使用姿势）对于redisTemplate.execute() 方法与 template.opsForValue() 的选择。

管道技术是一种优化 Redis 性能的方法，它允许客户端在一次网络往返中发送多个命令，而不是每个命令都进行一次网络通信。这种批量发送的方式可以减少网络延迟和通信开销，从而显著提高 Redis 的吞吐量和响应速度。

Redis 常见数据类型和应用场景(详解)

启动项目时，用到了Redis缓存数据库，但是却出现了报错信息：Caused by: io.lettuce.core.RedisCommandExecutionException: ERR Client sent AUTH, but no password is set