java架构规范中的读写隔离举例分析
本篇内容介绍了“java架构规范中的读写隔离举例分析”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
站在用户的角度思考问题,与客户深入沟通,找到定安网站设计与定安网站推广的解决方案,凭借多年的经验,让设计与互联网技术结合,创造个性化、用户体验好的作品,建站类型包括:成都网站设计、网站制作、企业官网、英文网站、手机端网站、网站推广、域名与空间、网页空间、企业邮箱。业务覆盖定安地区。
思想概述
读取操作必须是无害的,暂时不考虑大并发把服务器压垮这种极端场景,就一般而言,我们可以说,一个合格的查询接口所达到的效果应该是: 无论你执行多少次查询,系统的数据都是不会发生变化的
所以,对于一个陌生的系统,如果对方给了你【增删改查】四个接口,那么再没有深入了解业务的情况下,你首先进行测试的接口,一定是查询接口
为了达到一个合格的查询接口,对于系统的开发者的来说,必须保证所有的查询业务接口里,不能有任何对业务实体的修改操作,换句话说,所有的查询操作,只是对系统瞬时的一个快照,不对数据产生修改,自然对整个系统的业务运转也不产生任何变动。
实现策略
我们常说的读写分离,那是在应对性能问题时的一种解决方案。而我们这里特意换成了读写隔离,就是为了区分开两者。而这个隔离,是从更高层面来设计整个架构规范,是在项目设计刚开始的时候就考虑进去的。而且,实现难度小。
即使是基于现有的代码做重构,也只要挪代码块就行了,也没有什么业务风险,这个我们之后会再提到。
那么,很自然的,通过@Transactional(readOnly = true)
的控制,可以非常好的达到这个目的,这样,即使有开发人员不小心在其中做了修改操作,也会执行报错,给予很好的安全提示,这时,我们就需要重新审视这个需求,是否需要将修改操作分离出来。
import org.springframework.stereotype.Service; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.transaction.annotation.Transactional; /** * 以订单为主体的查询业务处理类 */ @Service @Transactional(readOnly = true) public class OrderFinder { @Autowired OrderRepository orderRepository; @Autowired UserRepository userRepository; /** 批量查询订单 */ List queryOrderByIds(ListorderIds) /** 运营控制台订单分页查询 */ List pagingOrdersOnConsole(int pageSize,int pageNumber) /** APP端用户订单分页查询 */ List pagingOrdersOnApp(Long userId,int pageSize,int pageNumber) // more methods and fields .. }
·
有一些问题直得探讨:
Finder就等同于将Repository里的查询方法挪过来吗?
并不是,首先,Finder
是一个查询业务的处理类。一个查询业务,意味着从调用端发起请求到结果返回,本次过程是进行一次完整的查询操作,更直观的来说,像是下面这样
//..在一个入口层中,比如SpringMVC中的@Controller @Autowired private OrderFinder orderFinder; @GetMapping("/paging/") public CustomPagingResponse pagingOrders(int pageSize,int pageNumber){ return orderFinder.paging(pageSize,pageNumber); }
而并非另外一种为了删改某一个实体而通过主键或其他特定查询SQL来做出的查询操作,这种操作,将会在一个命令业务中直接通过Repository去做,比如
//..假定是在订单删除业务OrderDeleteService中的一部分 public void deleteOrder(Long orderId){ //根据条件定位到需要进行操作的Entity,这个过程,是命令操作的一部分,所以,它不是一个完整的查询业务,这个时候,不会用到Finder Order order = orderRepository.getById(orderId); //...接下来对order进行操作,省略 }
而且,往往在一个较为复杂的查询业务中,不仅仅需要从数据库中获取数据,往往可能还需要通过各类协议的远程接口获取数据,进行整合,这就更加需要Finder来进行归纳处理了。
·
每个实体(Entity)类都需要有一个Finder吗?
并不一定,因为并不是每个实体都会有这种业务需求。比如我们很容易想到,对于订单,会有很多终端需要通过各类条件查询订单列表,也会有某一条订单的详细信息。但相比之下,订单变更记录,可能唯一会被查询到的地方只会是在订单详情中的一个小列表,那么,实现的写法更倾向于如下这种:
public void OrderFinder{ @Autowired private OrderTrackRepository orderTrackRepository; //它依旧出现在 OrderFinder 中 public OrderDetailView queryOrderDetail(Long orderId){ //首先查询order基础数据 //然后补充查询订单变更数据 ListorderTracks = orderTrackRepository.getByOrderId(orderId) //然后整合,返回整个View } }
所以,由于它只会存在于订单View中的一部分,自然不需要单独一个OrderDetailFinder
。当然如果未来OrderDetail
的代码量陡增,那是可以考虑重构的。
“java架构规范中的读写隔离举例分析”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!
分享题目:java架构规范中的读写隔离举例分析
文章URL:http://myzitong.com/article/pdgjji.html