班级网站 建设目标维护网站的职位叫什么

班级网站 建设目标,维护网站的职位叫什么,浙江做网站套餐,山西网站建设服务公司先明确#xff1a;两种“修改数据”的场景#xff0c;结果完全不同场景1#xff1a;同一个SqlSession内执行增删改操作#xff08;修改对应数据#xff09;场景2#xff1a;外部修改了数据库数据#xff08;同一个SqlSession期间#xff0c;其他SqlSession/应用改了数据…先明确两种“修改数据”的场景结果完全不同场景1同一个SqlSession内执行增删改操作修改对应数据场景2外部修改了数据库数据同一个SqlSession期间其他SqlSession/应用改了数据怎么解决“外部修改数据导致缓存不一致”的问题1. 缩短SqlSession的生命周期最常用2. 手动清空一级缓存3. 对关键查询禁用一级缓存不推荐除非必要4. 结合二级缓存第三方分布式缓存适合分布式系统总结MyBatis缓存的“安全性”是相对的我最开始用MyBatis一级缓存的时候也有过一模一样的顾虑——要是同一个SqlSession里我先查了数据然后别的地方改了数据库里的这条数据我再查的时候会不会拿到缓存里的旧数据假数据后来实际测试看了MyBatis的源码逻辑才发现这个担心其实分两种情况MyBatis早就做了对应的处理只是我们需要搞清楚场景差异。先明确两种“修改数据”的场景结果完全不同首先要把“修改数据”的场景拆开来这是理解的关键——是在同一个SqlSession里执行增删改操作还是外部其他SqlSession、其他应用修改了数据库数据这两种情况MyBatis的处理方式不一样安全性也不同。场景1同一个SqlSession内执行增删改操作修改对应数据这种情况完全不用担心查到假数据因为MyBatis有个核心机制在同一个SqlSession中只要执行了insert、update、delete操作不管是修改哪条数据哪怕和你要查的无关MyBatis会立刻清空当前SqlSession的一级缓存。这样后续的查询就会重新去数据库取最新数据不会用到缓存里的旧数据。我给你写个代码示例一看就明白TestpublicvoidtestCrudClearCache(){SqlSessionsqlSessionMyBatisUtil.getSqlSession();UserMapperuserMappersqlSession.getMapper(UserMapper.class);// 第一步第一次查询数据存入一级缓存Useruser1userMapper.selectById(1);System.out.println(第一次查询user1);// 比如输出User{id1, name张三, age20}// 第二步同一个SqlSession里执行更新操作修改id1的用户数据UserupdateUsernewUser();updateUser.setId(1);updateUser.setName(张三修改后);updateUser.setAge(21);userMapper.updateById(updateUser);sqlSession.commit();// 增删改必须提交事务这一步会触发一级缓存清空// 第三步再次查询id1的用户Useruser2userMapper.selectById(1);System.out.println(第二次查询user2);// 输出User{id1, name张三修改后, age21}System.out.println(两个对象是否相同(user1user2));// false说明走了数据库sqlSession.close();}运行这段代码你会发现控制台打印了两次SQL执行日志第二次查询拿到的是修改后的最新数据。原因就是updateById操作执行并提交后MyBatis清空了一级缓存所以第二次查询只能去数据库查最新的。我认为这个设计特别贴心它优先保证了数据的一致性哪怕牺牲一点缓存的性能也不会让你拿到过期的假数据。场景2外部修改了数据库数据同一个SqlSession期间其他SqlSession/应用改了数据这种情况才是真正可能出现“查到假数据”的场景也是MyBatis一级缓存的局限性所在。举个例子我打开SqlSession A查询了id1的用户数据存入A的一级缓存这时候另一个用户打开SqlSession B修改了数据库里id1的用户数据并且提交了事务我在SqlSession A里再次查询id1的用户这时候拿到的还是缓存里的旧数据因为SqlSession A的一级缓存并没有被清空——MyBatis的一级缓存是本地的它感知不到外部数据库的变化。这种情况是不是就“不安全”了其实也不能完全这么说我们得结合实际的业务场景来看在我看来SqlSession的生命周期通常是“一个请求对应一个SqlSession”比如Spring整合MyBatis时默认SqlSession是和请求绑定的请求结束就关闭。这种情况下SqlSession的存活时间很短外部修改数据恰好发生在同一个SqlSession期间的概率其实不高。但如果你的SqlSession存活时间很长比如手动创建的SqlSession一直不关闭那这种数据不一致的问题就会很明显。怎么解决“外部修改数据导致缓存不一致”的问题既然存在这种潜在的风险我们在实际开发中就需要有应对的办法。我们的经验是主要有这几种思路1. 缩短SqlSession的生命周期最常用这是最简单也最有效的办法。比如在Spring项目中我们会让SqlSession和Spring的事务管理器绑定或者让SqlSession的生命周期对应一次HTTP请求——请求进来创建SqlSession请求结束关闭SqlSession一级缓存也就跟着销毁了。这样一来缓存的存活时间极短基本不会遇到外部修改数据的情况。2. 手动清空一级缓存如果确实需要长时间持有SqlSession可以在关键查询前手动调用sqlSession.clearCache()方法清空当前SqlSession的一级缓存这样查询就会去数据库取最新数据。// 在查询前手动清空缓存sqlSession.clearCache();UseruseruserMapper.selectById(1);3. 对关键查询禁用一级缓存不推荐除非必要MyBatis其实没有直接禁用一级缓存的配置但可以通过一些“小技巧”绕开比如在查询语句后加一个随机参数但这样会失去一级缓存的优化效果不建议常用。// 不推荐通过添加随机参数绕开一级缓存Select(SELECT id, name, age FROM user WHERE id #{id} AND random #{random})UserselectByIdWithRandom(Param(id)Integerid,Param(random)Doublerandom);// 调用时传入随机数userMapper.selectByIdWithRandom(1,Math.random());4. 结合二级缓存第三方分布式缓存适合分布式系统如果是分布式项目多个应用节点之间的数据一致性问题会更突出这时候可以用MyBatis的二级缓存配合Redis、Ehcache等第三方缓存。这些分布式缓存可以配置缓存刷新策略或者在数据修改时手动通知其他节点清空缓存从而保证数据一致性。不过这种方式配置起来更复杂需要权衡成本和收益。总结MyBatis缓存的“安全性”是相对的回到最开始的问题MyBatis的缓存是不是很不安全我认为答案是在合理使用的场景下它是安全的但如果使用方式不当比如长时间持有SqlSession就可能出现数据不一致的问题。MyBatis的一级缓存设计是偏向“性能优化”的但它优先通过“增删改清空缓存”的机制保证了同一个SqlSession内的数据一致性而对于外部修改数据的情况它并没有做自动处理也没法做因为本地缓存感知不到外部变化这就需要我们在开发中通过规范SqlSession的使用、手动清空缓存等方式来规避风险。说白了任何缓存都存在“缓存一致性”的问题不只是MyBatisRedis、Memcached这些缓存中间件也一样。我们不能因为有这个潜在问题就不用缓存而是要根据业务场景选择合适的缓存策略在性能和数据一致性之间找到平衡。