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(List<Long> orderIds)
     
     /** 運營控制臺訂單分頁查詢 */
     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基礎數據
        
        //然后補充查詢訂單變更數據
        List<OrderTrack> orderTracks = orderTrackRepository.getByOrderId(orderId)
        
        //然后整合，返回整個View
    }
}

所以，由于它只會存在于訂單View中的一部分，自然不需要單獨一個OrderDetailFinder。當然如果未來OrderDetail的代碼量陡增，那是可以考慮重構的。

“java架構規范中的讀寫隔離舉例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！