随笔分类 -  redis笔记

摘要:当我们关注了用户后,这个用户发了动态,那么我们应该把这些数据推送给用户,这个需求,其实我们又把他叫做Feed流,关注推送也叫做Feed流,直译为投喂。为用户持续的提供“沉浸式”的体验,通过无限下拉刷新获取新的信息。 对于传统的模式的内容解锁:我们是需要用户去通过搜索引擎或者是其他的方式去解锁想要看的 阅读全文
posted @ 2022-12-02 23:21 kisshappyboy 阅读(259) 评论(0) 推荐(0) 编辑
摘要:针对用户的操作:可以对用户进行关注和取消关注功能。 实现思路: 需求:基于该表数据结构,实现两个接口: 关注和取关接口 判断是否关注的接口 FollowService 取消关注service @Override public Result isFollow(Long followUserId) { 阅读全文
posted @ 2022-12-02 22:39 kisshappyboy 阅读(215) 评论(0) 推荐(0) 编辑
摘要:初始代码 @GetMapping("/likes/{id}") public Result queryBlogLikes(@PathVariable("id") Long id) { //修改点赞数量 blogService.update().setSql("liked = liked +1 "). 阅读全文
posted @ 2022-12-02 22:00 kisshappyboy 阅读(214) 评论(0) 推荐(0) 编辑
摘要:需求: 创建一个Stream类型的消息队列,名为stream.orders 修改之前的秒杀下单Lua脚本,在认定有抢购资格后,直接向stream.orders中添加消息,内容包含voucherId、userId、orderId 项目启动时,开启一个线程任务,尝试获取stream.orders中的消息 阅读全文
posted @ 2022-12-01 23:51 kisshappyboy 阅读(379) 评论(0) 推荐(0) 编辑
摘要:什么是消息队列:字面意思就是存放消息的队列。最简单的消息队列模型包括3个角色: 消息队列:存储和管理消息,也被称为消息代理(Message Broker) 生产者:发送消息到消息队列 消费者:从消息队列获取消息并处理消息 使用队列的好处在于 解耦:所谓解耦,举一个生活中的例子就是:快递员(生产者)把 阅读全文
posted @ 2022-12-01 23:27 kisshappyboy 阅读(195) 评论(0) 推荐(0) 编辑
摘要:当用户发起请求,此时会请求nginx,nginx会访问到tomcat,而tomcat中的程序,会进行串行操作,分成如下几个步骤 1、查询优惠卷 2、判断秒杀库存是否足够 3、查询订单 4、校验是否是一人一单 5、扣减库存 6、创建订单 在这六步操作中,又有很多操作是要去操作数据库的,而且还是一个线程 阅读全文
posted @ 2022-12-01 23:08 kisshappyboy 阅读(173) 评论(0) 推荐(0) 编辑
摘要:为了提高redis的可用性,我们会搭建集群或者主从,现在以主从为例 此时我们去写命令,写在主机上, 主机会将数据同步给从机,但是假设在主机还没有来得及把数据写入到从机去的时候,此时主机宕机,哨兵会发现主机宕机,并且选举一个slave变成master,而此时新的master中实际上并没有锁信息,此时锁 阅读全文
posted @ 2022-12-01 15:09 kisshappyboy 阅读(608) 评论(0) 推荐(0) 编辑
摘要:抢锁过程中,获得当前线程,通过tryAcquire进行抢锁,该抢锁逻辑和之前逻辑相同 1、先判断当前这把锁是否存在,如果不存在,插入一把锁,返回null 2、判断当前这把锁是否是属于当前线程,如果是,则返回null 所以如果返回是null,则代表着当前这哥们已经抢锁完毕,或者可重入完毕,但是如果以上 阅读全文
posted @ 2022-12-01 14:37 kisshappyboy 阅读(1005) 评论(0) 推荐(0) 编辑
摘要:在Lock锁中,他是借助于底层的一个voaltile的一个state变量来记录重入的状态的,比如当前没有人持有这把锁,那么state=0,假如有人持有这把锁,那么state=1,如果持有这把锁的人再次持有这把锁,那么state就会+1 ,如果是对于synchronized而言,他在c语言代码中会有一 阅读全文
posted @ 2022-12-01 11:46 kisshappyboy 阅读(900) 评论(0) 推荐(1) 编辑
摘要:之前的redis分布式锁已经结束了,实际上还有有些问题, 基于setnx实现的分布式锁存在下面的问题: 重入问题:重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中,可重入锁的意义在于防止死锁,比如HashTable这样的代码中,他的方法都是使用synchronized修饰的,假如他在一个方 阅读全文
posted @ 2022-12-01 11:42 kisshappyboy 阅读(245) 评论(0) 推荐(0) 编辑
摘要:辑说明: 持有锁的线程在锁的内部出现了阻塞,导致他的锁自动释放,这时其他线程,线程2来尝试获得锁,就拿到了这把锁,然后线程2在持有锁执行过程中,线程1反应过来,继续执行,而线程1执行过程中,走到了删除锁逻辑,此时就会把本应该属于线程2的锁进行删除,这就是误删别人锁的情况说明 解决方案:解决方案就是在 阅读全文
posted @ 2022-11-30 22:56 kisshappyboy 阅读(616) 评论(0) 推荐(0) 编辑
摘要:通过加锁可以解决在单机情况下的一人一单安全问题,但是在集群模式下就不行了。 有关锁失效原因分析 由于现在我们部署了多个tomcat,每个tomcat都有一个属于自己的jvm,那么假设在服务器A的tomcat内部,有两个线程,这两个线程由于使用的是同一份代码,那么他们的锁对象是同一个,是可以实现互斥的 阅读全文
posted @ 2022-11-29 23:06 kisshappyboy 阅读(209) 评论(0) 推荐(0) 编辑
摘要:需求:修改秒杀业务,要求同一个优惠券,一个用户只能下一单 现在的问题在于: 优惠卷是为了引流,但是目前的情况是,一个人可以无限制的抢这个优惠卷,所以我们应当增加一层逻辑,让一个用户只能下一个单,而不是让一个用户下多个单 具体操作逻辑如下:比如时间是否充足,如果时间充足,则进一步判断库存是否足够,然后 阅读全文
posted @ 2022-11-29 21:42 kisshappyboy 阅读(62) 评论(0) 推荐(0) 编辑
摘要:秒杀下单应该思考的内容: 下单时需要判断两点: 秒杀是否开始或结束,如果尚未开始或已经结束则无法下单 库存是否充足,不足则无法下单 下单核心逻辑分析: 当用户开始进行下单,我们应当去查询优惠卷信息,查询到优惠卷信息,判断是否满足秒杀条件 比如时间是否充足,如果时间充足,则进一步判断库存是否足够,如果 阅读全文
posted @ 2022-11-28 23:26 kisshappyboy 阅读(196) 评论(0) 推荐(0) 编辑
摘要:当用户抢购时,就会生成订单并保存到tb_voucher_order这张表中,而订单表如果使用数据库自增ID就存在一些问题: id的规律性太明显 受单表数据量的限制 场景分析:如果我们的id具有太明显的规则,用户或者说商业对手很容易猜测出来我们的一些敏感信息,比如商城在一天时间内,卖出了多少单,这明显 阅读全文
posted @ 2022-11-28 14:40 kisshappyboy 阅读(110) 评论(0) 推荐(0) 编辑
摘要:基于StringRedisTemplate封装一个缓存工具类,满足下列需求: 方法1:将任意Java对象序列化为json并存储在string类型的key中,并且可以设置TTL过期时间 方法2:将任意Java对象序列化为json并存储在string类型的key中,并且可以设置逻辑过期时间,用于处理缓 阅读全文
posted @ 2022-11-27 22:44 kisshappyboy 阅读(89) 评论(0) 推荐(0) 编辑
摘要:需求:修改根据id查询商铺的业务,基于逻辑过期方式来解决缓存击穿问题 思路分析:当用户开始查询redis时,判断是否命中,如果没有命中则直接返回空数据,不查询数据库,而一旦命中后,将value取出,判断value中的过期时间是否满足,如果没有过期,则直接返回redis中的数据,如果过期,则在开启独立 阅读全文
posted @ 2022-11-27 21:18 kisshappyboy 阅读(443) 评论(0) 推荐(0) 编辑
摘要:核心思路:相较于原来从缓存中查询不到数据后直接查询数据库而言,现在的方案是 进行查询之后,如果从缓存没有查询到数据,则进行互斥锁的获取,获取互斥锁后,判断是否获得到了锁,如果没有获得到,则休眠,过一会再进行尝试,直到获取到锁为止,才能进行查询 如果获取到了锁的线程,再去进行查询,查询后将数据写入re 阅读全文
posted @ 2022-11-27 11:59 kisshappyboy 阅读(230) 评论(0) 推荐(0) 编辑
摘要:缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力。 解决方案: 给不同的Key的TTL添加随机值 》在环境预热批量导入redis时发生 利用Redis集群提高服务的可用性 给缓存业务添加降级限流策略 给业务添加多级缓存 缓存击穿问题及解决思路 阅读全文
posted @ 2022-11-27 11:31 kisshappyboy 阅读(87) 评论(0) 推荐(0) 编辑
摘要:缓存穿透 :缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会打到数据库。 常见的解决方案有两种: 缓存空对象 优点:实现简单,维护方便 缺点: 额外的内存消耗 可能造成短期的不一致 布隆过滤 优点:内存占用较少,没有多余key 缺点: 实现复杂 存在误判可能 阅读全文
posted @ 2022-11-27 10:35 kisshappyboy 阅读(68) 评论(0) 推荐(0) 编辑

点击右上角即可分享
微信分享提示