绿色门业宽屏网站模板 破解移动端网站建设方案

当前位置： 首页 > news >正文

绿色门业宽屏网站模板 破解,移动端网站建设方案,做vip的网站好做吗,wordpress保存为模板基于社区电商的Redis缓存架构 首先来讲一下 Feed 流的含义#xff1a; Feed 流指的是当我们进入 APP 之后#xff0c;APP 要做一个 Feed 行为#xff0c;即主动的在 APP 内提供各种各样的内容给我们 在电商 APP 首页#xff0c;不停在首页向下拉#xff0c;那么每次拉的…基于社区电商的Redis缓存架构 首先来讲一下 Feed 流的含义 Feed 流指的是当我们进入 APP 之后APP 要做一个 Feed 行为即主动的在 APP 内提供各种各样的内容给我们 在电商 APP 首页不停在首页向下拉那么每次拉的时候APP 就会根据你的喜好、算法来不停地展示新的内容给你看这就是电商 APP 的 Feed 流了 那么接下来呢就基于首页 Feed 流以及社区电商 APP 中的一些业务场景来实现一套基于 Redis 的企业级缓存架构MySQL 为基础RocketMQ 为辅助 那么在缓存中常见的问题有 热 key 问题大 key 问题缓存雪崩穿透数据库和缓存数据一致性问题 在 Redis 生产环境中也存在一些问题如下 Redis 集群部署需要进行高并发压测监控 Redis 集群每个节点数据存储情况、接口 QPS、机器负载情况、缓存命中率Redis 节点故障的主从切换、Redis 集群扩容 下边我们来逐个剖析在缓存架构中常见的一些问题 首先热 key 举个例子就是微博突然某个明星出现新闻那么会有大量请求去访问这个数据这个 key 就是热 key 大 key 指的是某个 key 所存储的 value 很大value 多大 10 mb那么如果读取这个大 key 过于频繁就会对网络带宽造成影响阻塞其他请求 缓存雪崩是因为大量缓存数据同时过期或者 Redis 集群故障如果因为缓存雪崩导致 Redis 集群都崩掉了那么此时只有数据库可以访问我们的系统需要可以识别出来缓存故障立马对各个接口进行限流、降级错误来保护数据库避免数据库崩掉可以在 jvm 内存缓存中存储少量缓存数据用于在 Redis 崩了之后提供降级备用数据那么流程为限流 – 降级 – jvm 缓存数据 读多写少数据缓存 那么我们先来分析一下在社区电商中用户去分享一个内容时如何操作缓存 用户分享内容加锁针对用户 id 上分布式锁避免同一用户重复请求导致数据重复灌入将用户分享内容写入数据库将用户的个人信息在缓存写一份用户信息在注册后一般不会变化读多写少因此用户信息非常适合放入缓存中这样在后续高并发访问用户的数据时就可以在缓存中进行查询根据用户前缀 用户 id 作为 key并设置缓存过期时间过期时间可以设置为 2 天加上随机几小时添加随机几小时的原因是避免同一时间大量缓存同时过期释放锁 缓存自动延期以及缓存穿透 那么上边我们已经对用户的个人信息进行了缓存那么某些热门的用户是经常被很多人看到的而有些冷门用户的内容没多少人看因此将用户信息的缓存过期时间设置为 2天随机几小时 因此我们针对热门的用户信息数据要做一个缓存自动延期因此只要访问用户数据那么就对该缓存数据进行一个延期流程如下 获取用户个人信息根据 用户前缀 用户id 作为 key 去缓存中查询用户信息 public UserInfo getUserInfo(Integer userId) {// 读缓存String userInfoJson redisCache.get(user_info_lock: userId);if (!StringUtils.isEmpty(userInfoJson)) {// 取到的是空缓存 避免一致访问数据库不存在的数据导致缓存穿透if ({}.equals(userInfoJson)) {// 延期缓存redisCache.expire(user_info_lock: userId, expireSecond);return null;} else {// 延期缓存redisCache.expire(user_info_lock: userId, expireSecond);UserInfo userInfo JSON.parseObject(productStr, UserInfo.class);}}// 如果缓存中没有取到数据则在数据库中查并放入缓存lock(user_lock_prefix userId); // 上分布式锁 伪代码try {// 读数据库UserInfo userInfo userInfoService.get(userId);if(userInfo ! null) {// 如果用户信息不为空就将用户数据写入缓存redisCache.set(user_info_lock: userId, JSON.toJSONString(userInfo), expireSecond);} else {// 如果数据库为空写入一个空字符串即可redisCache.set(user_info_lock: userId, {}, expireSecond);}} finally {unlock(user_lock_lock: userId); // 解锁} }缓存数据库双写不一致 在上边存储用户个人信息时使用的是 缓存数据库双写这样可能造成数据不一致性如下 有两个线程并发一个读线程一个写线程假设执行流程如下会造成双写不一致 当读线程去缓存中读取数据此时缓存中数据正好过期那么该线程就去读数据库中的数据此时写线程开始执行修改用户信息并且写入数据库再写入缓存此时读线程再接着执行将之前在数据库中读取的旧数据写入缓存覆盖了写线程更新后的数据 造成这种情况的原因是在读的时候加的是读锁key 为 user_info_lock:在写的时候加的是写锁key 为 user_update_lock:那么读写就可以并发 想要解决的话可以让读和写操作加同一把锁让读写串行化就可以了如下 让读和写都加同一把锁user_update_lock 针对先读后写的情况就不会出现双写不一致了读的时候先加上锁user_update_lock此时缓存假设正好过期去数据库中读取数据此时写线程开始执行阻塞等待锁user_update_lock此时读线程再去数据库读取数据放入缓存结束后释放锁那么写线程再拿到锁操作数据库再将数据写入缓存那么缓存中的数据是新数据针对先写后读的情况也不会出现双写不一致在写的时候加上锁 user_update_lock那么在并发读的时候先获取缓存内容如果获取不到尝试去 DB 中获取此时就会阻塞等待锁 user_update_lock在写线程写完之后更新了缓存释放锁此时读线程就拿到了锁此时在去数据库中查数据之前再加一个 double check双端检锁 的操作也就是再尝试去缓存中取一次数据如果取到了就返回如果没有取到就去数据库中查询 那么完整的写和读操作流程如下图 高并发场景下优化 在上边我们已经使用读写加同一把锁来实现缓存数据库双写一致了 但是还存在一种极端情况某一个用户的信息并不在缓存中但是突然火了大量用户来访问发现缓存中没有那么大量用户线程就阻塞在了获取锁的这一步操作上导致大量线程串行化的来获取锁然后再到缓存中获取数据下一个线程再获取锁取数据 这种情况的解决方案就是给获取锁加一个超时时间如果在 200ms 内没有拿到锁就算获取锁失败这样大量用户线程获取锁失败就会从串行再转为并发从缓存中取数据了避免大量线程阻塞获取锁 完整流程图如下粉色部分为优化 代码如下 private UserInfo getUserInfo(Long userId) {String userLockKey user_update_lock: userId;boolean lock false;try {// 尝试加锁并设置超时时间为 200 mslock redisLock.tryLock(user_update_lock:, 200);} catch(InterruptedException e) {UserInfo user getFromCache(userId);if(user ! null) {return user;}log.error(e.getMessage(), e);throw new BaseBizException(查询失败);}// 如果加锁超时就再次去缓存中查询if (!lock) {UserInfo user getFromCache(userId);if(user ! null) {return user;}// 缓存数据为空查询用户信息失败因为用户没有拿到锁因此也无法取 DB 中查询throw new BaseBizException(查询失败);}// 双端检锁如果拿到锁再去缓存中查询try {UserInfo user getFromCache(userId);if(user ! null) {return user;}String userInfoKey user_info: userId;// 数据库中查询user userService.getById(userId);if (Objects.isNull(user)) {redisCache.set(userInfoKey, {}, RandomUtil.genRandomInt(30, 100));return null;}// 缓存时间设置为 2 天 随机几小时redisCache.set(userInfoKey, JSON.toJSONString(user), 2 * 24 * 60 * 60RandomUtil.genRandomInt(0, 10) * 60 * 60);return user;} finally {redisLock.unlock(userLockKey);}