摘要：
需求：修改秒杀业务，要求同一个优惠券，一个用户只能下一单 现在的问题在于： 优惠卷是为了引流，但是目前的情况是，一个人可以无限制的抢这个优惠卷，所以我们应当增加一层逻辑，让一个用户只能下一个单，而不是让一个用户下多个单 具体操作逻辑如下：比如时间是否充足，如果时间充足，则进一步判断库存是否足够，然后 阅读全文
摘要：
秒杀下单应该思考的内容： 下单时需要判断两点： 秒杀是否开始或结束，如果尚未开始或已经结束则无法下单 库存是否充足，不足则无法下单 下单核心逻辑分析： 当用户开始进行下单，我们应当去查询优惠卷信息，查询到优惠卷信息，判断是否满足秒杀条件 比如时间是否充足，如果时间充足，则进一步判断库存是否足够，如果 阅读全文
摘要：
当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，而订单表如果使用数据库自增ID就存在一些问题： id的规律性太明显 受单表数据量的限制 场景分析：如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显 阅读全文
摘要：
基于StringRedisTemplate封装一个缓存工具类，满足下列需求： 方法1：将任意Java对象序列化为json并存储在string类型的key中，并且可以设置TTL过期时间 方法2：将任意Java对象序列化为json并存储在string类型的key中，并且可以设置逻辑过期时间，用于处理缓 阅读全文
摘要：
需求：修改根据id查询商铺的业务，基于逻辑过期方式来解决缓存击穿问题 思路分析：当用户开始查询redis时，判断是否命中，如果没有命中则直接返回空数据，不查询数据库，而一旦命中后，将value取出，判断value中的过期时间是否满足，如果没有过期，则直接返回redis中的数据，如果过期，则在开启独立 阅读全文
摘要：
核心思路：相较于原来从缓存中查询不到数据后直接查询数据库而言，现在的方案是 进行查询之后，如果从缓存没有查询到数据，则进行互斥锁的获取，获取互斥锁后，判断是否获得到了锁，如果没有获得到，则休眠，过一会再进行尝试，直到获取到锁为止，才能进行查询 如果获取到了锁的线程，再去进行查询，查询后将数据写入re 阅读全文
摘要：
缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。 解决方案： 给不同的Key的TTL添加随机值 》在环境预热批量导入redis时发生 利用Redis集群提高服务的可用性 给缓存业务添加降级限流策略 给业务添加多级缓存 缓存击穿问题及解决思路 阅读全文
摘要：
缓存穿透 ：缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。 常见的解决方案有两种： 缓存空对象 优点：实现简单，维护方便 缺点： 额外的内存消耗 可能造成短期的不一致 布隆过滤 优点：内存占用较少，没有多余key 缺点： 实现复杂 存在误判可能 阅读全文
摘要：
缓存更新是redis为了节约内存而设计出来的一个东西，主要是因为内存数据宝贵，当我们向redis插入太多数据，此时就可能会导致缓存中的数据过多，所以redis会对部分数据进行更新，或者把他叫为淘汰更合适。 内存淘汰：redis自动进行，当redis内存达到咱们设定的max-memery的时候，会自动 阅读全文
摘要：
缓存模型和思路 标准的操作方式就是查询数据库之前先查询缓存，如果缓存数据存在，则直接从缓存中返回，如果缓存数据不存在，再查询数据库，然后将数据存入redis。 代码如下： public Result queryById(Long id) { //从redis中查询商铺 String shopStr 阅读全文