java架構(gòu)規(guī)范中的讀寫隔離舉例分析

本篇內(nèi)容介紹了“java架構(gòu)規(guī)范中的讀寫隔離舉例分析”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

思想概述

讀取操作必須是無害的，暫時(shí)不考慮大并發(fā)把服務(wù)器壓垮這種極端場景，就一般而言，我們可以說，一個(gè)合格的查詢接口所達(dá)到的效果應(yīng)該是： 無論你執(zhí)行多少次查詢，系統(tǒng)的數(shù)據(jù)都是不會(huì)發(fā)生變化的

所以，對(duì)于一個(gè)陌生的系統(tǒng)，如果對(duì)方給了你【增刪改查】四個(gè)接口，那么再?zèng)]有深入了解業(yè)務(wù)的情況下，你首先進(jìn)行測試的接口，一定是查詢接口

為了達(dá)到一個(gè)合格的查詢接口，對(duì)于系統(tǒng)的開發(fā)者的來說，必須保證所有的查詢業(yè)務(wù)接口里，不能有任何對(duì)業(yè)務(wù)實(shí)體的修改操作，換句話說，所有的查詢操作，只是對(duì)系統(tǒng)瞬時(shí)的一個(gè)快照，不對(duì)數(shù)據(jù)產(chǎn)生修改，自然對(duì)整個(gè)系統(tǒng)的業(yè)務(wù)運(yùn)轉(zhuǎn)也不產(chǎn)生任何變動(dòng)。

實(shí)現(xiàn)策略

我們常說的讀寫分離，那是在應(yīng)對(duì)性能問題時(shí)的一種解決方案。而我們這里特意換成了讀寫隔離，就是為了區(qū)分開兩者。而這個(gè)隔離，是從更高層面來設(shè)計(jì)整個(gè)架構(gòu)規(guī)范，是在項(xiàng)目設(shè)計(jì)剛開始的時(shí)候就考慮進(jìn)去的。而且，實(shí)現(xiàn)難度小。

即使是基于現(xiàn)有的代碼做重構(gòu)，也只要挪代碼塊就行了，也沒有什么業(yè)務(wù)風(fēng)險(xiǎn)，這個(gè)我們之后會(huì)再提到。

那么，很自然的，通過@Transactional(readOnly = true)的控制，可以非常好的達(dá)到這個(gè)目的，這樣，即使有開發(fā)人員不小心在其中做了修改操作，也會(huì)執(zhí)行報(bào)錯(cuò)，給予很好的安全提示，這時(shí)，我們就需要重新審視這個(gè)需求，是否需要將修改操作分離出來。

import org.springframework.stereotype.Service;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.transaction.annotation.Transactional;

/**
 * 以訂單為主體的查詢業(yè)務(wù)處理類
 */
@Service
@Transactional(readOnly = true)
public class OrderFinder {

    @Autowired
    OrderRepository orderRepository;
    @Autowired
    UserRepository userRepository;
     
     /** 批量查詢訂單 */
     List queryOrderByIds(List<Long> orderIds)
     
     /** 運(yùn)營控制臺(tái)訂單分頁查詢 */
     List pagingOrdersOnConsole(int pageSize,int pageNumber)
     
     /** APP端用戶訂單分頁查詢 */
     List pagingOrdersOnApp(Long userId,int pageSize,int pageNumber)
     
     // more methods and fields ..
}

·

有一些問題直得探討：

Finder就等同于將Repository里的查詢方法挪過來嗎？

并不是，首先，Finder是一個(gè)查詢業(yè)務(wù)的處理類。一個(gè)查詢業(yè)務(wù)，意味著從調(diào)用端發(fā)起請(qǐng)求到結(jié)果返回，本次過程是進(jìn)行一次完整的查詢操作，更直觀的來說，像是下面這樣

    //..在一個(gè)入口層中，比如SpringMVC中的@Controller
    
    @Autowired
    private OrderFinder orderFinder;

    @GetMapping("/paging/")
    public CustomPagingResponse pagingOrders(int pageSize,int pageNumber){
          return orderFinder.paging(pageSize,pageNumber);
    }

而并非另外一種為了刪改某一個(gè)實(shí)體而通過主鍵或其他特定查詢SQL來做出的查詢操作，這種操作，將會(huì)在一個(gè)命令業(yè)務(wù)中直接通過Repository去做，比如

    //..假定是在訂單刪除業(yè)務(wù)OrderDeleteService中的一部分
    
    public void deleteOrder(Long orderId){
    
        //根據(jù)條件定位到需要進(jìn)行操作的Entity，這個(gè)過程，是命令操作的一部分，所以，它不是一個(gè)完整的查詢業(yè)務(wù)，這個(gè)時(shí)候，不會(huì)用到Finder
        Order order = orderRepository.getById(orderId);
        
        //...接下來對(duì)order進(jìn)行操作，省略
    }

而且，往往在一個(gè)較為復(fù)雜的查詢業(yè)務(wù)中，不僅僅需要從數(shù)據(jù)庫中獲取數(shù)據(jù)，往往可能還需要通過各類協(xié)議的遠(yuǎn)程接口獲取數(shù)據(jù)，進(jìn)行整合，這就更加需要Finder來進(jìn)行歸納處理了。

·

每個(gè)實(shí)體（Entity）類都需要有一個(gè)Finder嗎？

并不一定，因?yàn)椴⒉皇敲總€(gè)實(shí)體都會(huì)有這種業(yè)務(wù)需求。比如我們很容易想到，對(duì)于訂單，會(huì)有很多終端需要通過各類條件查詢訂單列表，也會(huì)有某一條訂單的詳細(xì)信息。但相比之下，訂單變更記錄，可能唯一會(huì)被查詢到的地方只會(huì)是在訂單詳情中的一個(gè)小列表，那么，實(shí)現(xiàn)的寫法更傾向于如下這種：

public void OrderFinder{
    @Autowired
    private OrderTrackRepository orderTrackRepository;
    
	//它依舊出現(xiàn)在 OrderFinder 中
    public OrderDetailView queryOrderDetail(Long orderId){
    
        //首先查詢order基礎(chǔ)數(shù)據(jù)
        
        //然后補(bǔ)充查詢訂單變更數(shù)據(jù)
        List<OrderTrack> orderTracks = orderTrackRepository.getByOrderId(orderId)
        
        //然后整合，返回整個(gè)View
    }
}

所以，由于它只會(huì)存在于訂單View中的一部分，自然不需要單獨(dú)一個(gè)OrderDetailFinder。當(dāng)然如果未來OrderDetail的代碼量陡增，那是可以考慮重構(gòu)的。

“java架構(gòu)規(guī)范中的讀寫隔離舉例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！