1. 查詢(xún)模型的本質(zhì)

查詢(xún)模型的本質(zhì)就是：為不同的應(yīng)用場(chǎng)景選擇最合適的存儲(chǔ)引擎，充分發(fā)揮各個(gè)存儲(chǔ)引擎的優(yōu)勢(shì)。

在系統(tǒng)中，讀接口的數(shù)量遠(yuǎn)超寫(xiě)接口，但我深信：==再簡(jiǎn)單的寫(xiě)也是復(fù)雜，再?gòu)?fù)雜的讀也是簡(jiǎn)單。==

為什么呢？因?yàn)?，想做好查?xún)只需為不同的應(yīng)用場(chǎng)景選擇最合適的存儲(chǔ)引擎，從而充分發(fā)揮底層存儲(chǔ)引擎的優(yōu)勢(shì)，然后所面對(duì)的高性能、高并發(fā)等技術(shù)問(wèn)題就迎刃而解了。

如下圖所示：

面對(duì)一個(gè)查詢(xún)請(qǐng)求，我們需要：

接受并解析用戶(hù)請(qǐng)求；

從各個(gè)存儲(chǔ)引擎中獲取數(shù)據(jù)；

對(duì)數(shù)據(jù)進(jìn)行加工，包括數(shù)據(jù)聚合、數(shù)據(jù)關(guān)聯(lián)、數(shù)據(jù)轉(zhuǎn)換等；

將最終結(jié)果返回用戶(hù)；

1.1. 常見(jiàn)存儲(chǔ)引擎的特征

技術(shù)選型唯一原則：==僅僅使用它的成名之作，萬(wàn)萬(wàn)不可被花里胡哨的東西干擾你的判斷。==

簡(jiǎn)單列舉下常見(jiàn)的存儲(chǔ)引擎：

1.關(guān)系數(shù)據(jù)庫(kù)。

【特點(diǎn)】提供事務(wù)機(jī)制對(duì)數(shù)據(jù)強(qiáng)一致性進(jìn)行保障，其ACID四大特性更是建模利器；

【場(chǎng)景】適用于一致性要求高的金融或類(lèi)金融場(chǎng)景，比如銀行、支付、訂單等；

2.Redis。

【特點(diǎn)】基于內(nèi)存的鍵值存儲(chǔ)引擎，具有高性能和低延遲；支持豐富的數(shù)據(jù)結(jié)構(gòu)（字符串、哈希、列表、集合、有序集合等）和功能（發(fā)布訂閱、事務(wù)等），提供豐富的持久化選項(xiàng)；

【場(chǎng)景】：緩存、會(huì)話存儲(chǔ)、計(jì)數(shù)器、排行榜、分布式鎖等對(duì)性能和實(shí)時(shí)性要求較高的場(chǎng)景；

3.Elasticsearch。

【特點(diǎn)】全文搜索和分析引擎，建立在Lucene庫(kù)之上。擅長(zhǎng)水平擴(kuò)展、近實(shí)時(shí)搜索、全文搜索和復(fù)雜查詢(xún)等功能；支持分布式架構(gòu)、自動(dòng)分片和數(shù)據(jù)冗余；

【場(chǎng)景】日志分析、實(shí)時(shí)監(jiān)控、商業(yè)智能、搜索引擎、推薦系統(tǒng)等需要高效的實(shí)時(shí)全文搜索和分析功能的場(chǎng)景；

4.MongoDB。

【特點(diǎn)】面向文檔的NoSQL數(shù)據(jù)庫(kù)，以JSON風(fēng)格的文檔格式存儲(chǔ)數(shù)據(jù)；支持動(dòng)態(tài)模式、靈活的索引和復(fù)制集、分片等特性，可擴(kuò)展性好，支持水平擴(kuò)展；

【場(chǎng)景】大數(shù)據(jù)量、高寫(xiě)入頻率、動(dòng)態(tài)模式和靈活查詢(xún)的場(chǎng)景，如內(nèi)容管理系統(tǒng)、用戶(hù)個(gè)性化數(shù)據(jù)存儲(chǔ)、實(shí)時(shí)分析等；

1.2. 讀接口三把利器

對(duì)于查詢(xún)請(qǐng)求，主要有三種模式：

1.Query Object 模式?；?Query Object 建模，完成對(duì)單引擎的快速查詢(xún)；

通過(guò)對(duì) Query Object 對(duì)象建模，便可以對(duì)查詢(xún)條件進(jìn)行靈活管理；

無(wú)需寫(xiě) SQL，只需在 Query Object 上聲明好各種過(guò)濾條件，便能完成查詢(xún)。包括單條查詢(xún)、批量查詢(xún)、數(shù)量查詢(xún)、分頁(yè)查詢(xún)等

2.內(nèi)存 Join 模式?；?View Object 建模，完成對(duì)結(jié)果數(shù)據(jù)的聚合操作；

通過(guò)對(duì) View Object 對(duì)象建模，便可以對(duì)返回結(jié)果進(jìn)行靈活控制；

無(wú)需手寫(xiě)關(guān)聯(lián)代碼，只需在 View Object 上聲明關(guān)聯(lián)關(guān)系，自動(dòng)完成關(guān)聯(lián)數(shù)據(jù)的聚合；

3.異構(gòu)&冗余模式。

CQRS 思想的體現(xiàn)，徹底的將寫(xiě)模型和讀模型拆分開(kāi)，從而最大限度的發(fā)揮存儲(chǔ)引擎優(yōu)勢(shì)；

異構(gòu)意味著冗余，冗余意味著數(shù)據(jù)不一致，該模式通過(guò)準(zhǔn)實(shí)時(shí)巡檢、天級(jí)對(duì)賬來(lái)保障數(shù)據(jù)的最終一致性；

三大模式綜合使用如下：

內(nèi)存 Join 模式，從遠(yuǎn)程服務(wù)、存儲(chǔ)引擎中獲取數(shù)據(jù)，完成數(shù)據(jù)的聚合操作，然后對(duì)聚合數(shù)據(jù)進(jìn)行轉(zhuǎn)換，返回給用戶(hù)；

Query Object 模式，大大簡(jiǎn)化對(duì)單引擎的查詢(xún)，讓你從繁重的 SQL（底層API） 中解放出來(lái)，大大提升開(kāi)發(fā)效率；

異構(gòu)&冗余模式，方便構(gòu)建多副本異構(gòu)數(shù)據(jù)模型，完成最繁瑣的數(shù)據(jù)同步和數(shù)據(jù)一致性保障；

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

2. Query Object 模式

這是最常見(jiàn)，也是應(yīng)用最多的模型，主要用于解決單引擎的數(shù)據(jù)查詢(xún)。讓開(kāi)發(fā)聚焦于查詢(xún)建模，而不再是繁雜易錯(cuò)的技術(shù)細(xì)節(jié)。

我們以簡(jiǎn)單的 MySQL 查詢(xún)?yōu)槔?，假如使?MyBatis 作為系統(tǒng)的 ORM 框架，其核心流程如下：

首先，我們會(huì)定義一組查詢(xún)對(duì)象；

當(dāng)我們接收到參數(shù)后，把有效參數(shù)填充到 Example 對(duì)象；

然后，將 Example 對(duì)象傳入 MyBatis API 進(jìn)行查詢(xún)；

MyBatis 根據(jù) Mapper 配置，將 Example 對(duì)象轉(zhuǎn)換為對(duì)應(yīng)的 SQL 和參數(shù)，并提交給 MySQL；

最終，MySQL 執(zhí)行 SQL 獲取并返回查詢(xún)結(jié)果；

仔細(xì)思考下，這里面是不是存在很多“固定邏輯”，而我們每天寫(xiě)的代碼是不是有很強(qiáng)的“重復(fù)性”？

接下來(lái)看下面這張圖：

內(nèi)核和核心流程沒(méi)有變化，但上層 API 出現(xiàn)巨大變化：

1.首先，引入了 Query Object：

將分散的查詢(xún)參數(shù)封裝到一個(gè)類(lèi)中；

在查詢(xún)對(duì)象的屬性上多了一組注解，用于聲明該屬性與數(shù)據(jù)庫(kù)查詢(xún)條件的關(guān)系；

2.然后，多了一個(gè)核心組件 MyBatisQueryRepository：

從 Query Object 上讀取屬性和注解信息，并完成對(duì) Example 對(duì)象的填充；

使用填充好的 Example 對(duì)象調(diào)用 MyBatis API，從而完成數(shù)據(jù)查詢(xún)；

在該模式下，開(kāi)發(fā) MyBatis 的單表查詢(xún)，只有一件事要做：按照業(yè)務(wù)要求對(duì) Query Object 進(jìn)行建模。

當(dāng)然為了方便使用，QueryRepository 提供多種接口：

get：查詢(xún)單個(gè)對(duì)象；

listOf：查詢(xún)多個(gè)對(duì)象；

countOf：查詢(xún)數(shù)量；

pageOf：分頁(yè)查詢(xún)；

如對(duì)該部分感興趣，可研讀稍后文章。

該玩法支持復(fù)雜查詢(xún)嗎？

首先，不支持。對(duì)于復(fù)雜查詢(xún)，只能回歸到 MyBatis 底層 API。

【注】不要奢求一個(gè)框架或一個(gè)方案解決所有問(wèn)題。使用 20% 的精力來(lái)解決 80% 的問(wèn)題，那開(kāi)發(fā)效率已經(jīng)得到極大提升。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

3. 內(nèi)存 Join 模式

內(nèi)存 Join 等同于關(guān)系數(shù)據(jù)庫(kù)的 Join 語(yǔ)句，只是將 Join 動(dòng)作從數(shù)據(jù)層提升到了應(yīng)用層。

其實(shí)我們每天都在寫(xiě)這樣的重復(fù)代碼?。?！

假如有一個(gè)需求，實(shí)現(xiàn)我的訂單接口，返回值里面需要包括 用戶(hù)信息（User）、收獲地址信息（Address）、商品信息（Product）等。而這些信息沒(méi)有在一個(gè)數(shù)據(jù)庫(kù)，甚至分散在不同的服務(wù)，需要調(diào)用遠(yuǎn)程接口才能獲取到。由于無(wú)法使用數(shù)據(jù)庫(kù)的 join 語(yǔ)句，所以就出現(xiàn)了如下接口：

查詢(xún)我的訂單并將其轉(zhuǎn)換為 OrderDetail 集合：

獲取 User 信息，并填充到 OrderDetail 對(duì)象：

獲取 Address 信息，并填充到 OrderDetail 對(duì)象：

獲取 Product 信息，并填充到 OrderDetail 對(duì)象：

最后，返回填充好的 OrderDetail 集合；

仔細(xì)觀察上面的代碼，你是找到了“重復(fù)邏輯”？

如果，又要開(kāi)發(fā)一個(gè)購(gòu)物車(chē)列表呢？購(gòu)物車(chē)列表和我的訂單是否存在重復(fù)邏輯？

思考完之后，請(qǐng)看 內(nèi)存 Join 模式：

可以看到：

大量繁雜冗余代碼被簡(jiǎn)單的 @Join注解 取代

還可以開(kāi)啟并發(fā)模型，使用多線程技術(shù)加快接口響應(yīng)速度

整體流程如下：

我們通過(guò)對(duì) View Object 建模便能對(duì)返回?cái)?shù)據(jù)進(jìn)行控制，從而大大簡(jiǎn)化對(duì)返回結(jié)果的開(kāi)發(fā)成本。

如對(duì)該部分感興趣，可研讀稍后文章。

4. 異構(gòu)&冗余模式

異構(gòu)冗余模式，主要用于多存儲(chǔ)引擎的場(chǎng)景，旨在保障多存儲(chǔ)引擎間數(shù)據(jù)的一致性。

比如，在一個(gè)復(fù)雜的系統(tǒng)中，核心數(shù)據(jù)存儲(chǔ)于 MySQL，使用 Redis 進(jìn)行緩存加速，使用 ES 完成全文檢索。如何設(shè)計(jì)系統(tǒng)，才能保障 MySQL 中的數(shù)據(jù)與 Redis、ES 的數(shù)據(jù)始終保持同步，從而實(shí)現(xiàn)最終一致性。

看似很簡(jiǎn)單，但真正實(shí)現(xiàn)起來(lái)卻到處是坑，在深入思索后得出兩個(gè)特征：

存在決策節(jié)點(diǎn)并具備強(qiáng)順序性。按照決策節(jié)點(diǎn)給出的變更順序，依次在異構(gòu)引擎上進(jìn)行回放，便能實(shí)現(xiàn)兩者的最終一致性；

存在權(quán)威的“源信息”，發(fā)現(xiàn)不一致時(shí)可以使用源頭信息對(duì)數(shù)據(jù)進(jìn)行自動(dòng)修復(fù)；

從而，推導(dǎo)出該場(chǎng)景下的最佳實(shí)踐：

整體架構(gòu)分為如下幾部分：

索引：主要完成數(shù)據(jù)的構(gòu)建，從多個(gè)系統(tǒng)中拉取數(shù)據(jù)完成數(shù)據(jù)的裝配，并按所需結(jié)構(gòu)對(duì)數(shù)據(jù)進(jìn)行轉(zhuǎn)化；

巡檢：對(duì)系統(tǒng)中的數(shù)據(jù)進(jìn)行實(shí)時(shí)巡檢或定時(shí)對(duì)賬，發(fā)現(xiàn)系統(tǒng)中不一致的數(shù)據(jù)并完成數(shù)據(jù)的自動(dòng)修復(fù)。如遇數(shù)據(jù)無(wú)法修復(fù)的場(chǎng)景，自動(dòng)進(jìn)行報(bào)警，人工介入進(jìn)行處理；

查詢(xún)：充分發(fā)揮存儲(chǔ)引擎的優(yōu)勢(shì)，提供業(yè)務(wù)查詢(xún)能力，常與 Query Object 模式 和 內(nèi)存 Join 模式 結(jié)合使用；

通過(guò)對(duì)最佳實(shí)踐的封裝，可以在同一套組件、同一個(gè)數(shù)據(jù)模型基礎(chǔ)上，完成對(duì) 索引&更新、巡檢&修復(fù) 兩大流程的融合，大大降低研發(fā)工作量。

如對(duì)該部分感興趣，可研讀稍后文章。

5. 小結(jié)

查詢(xún)模型的本質(zhì)就是：為不同的應(yīng)用場(chǎng)景選擇最合適的存儲(chǔ)引擎，然后充分發(fā)揮各個(gè)存儲(chǔ)引擎的優(yōu)勢(shì)。

基于此提出三個(gè)模式：

Query Object 模式。通過(guò) Query Object 建模，實(shí)現(xiàn)對(duì)查詢(xún)條件的靈活管理。無(wú)需寫(xiě) SQL，只需在 Query Object 上聲明好各種過(guò)濾條件，便能完成常規(guī)查詢(xún)。包括單條查詢(xún)、批量查詢(xún)、數(shù)量查詢(xún)、分頁(yè)查詢(xún)等；

內(nèi)存 Join 模式?；?View Object 建模，實(shí)現(xiàn)對(duì)返回結(jié)果的靈活控制。無(wú)需手寫(xiě)關(guān)聯(lián)代碼，只需在 View Object 上聲明關(guān)聯(lián)關(guān)系，自動(dòng)完成關(guān)聯(lián)數(shù)據(jù)的聚合；

異構(gòu)&冗余模式。CQRS 思想的體現(xiàn)，徹底的將寫(xiě)模型和讀模型拆分開(kāi)，通過(guò)準(zhǔn)實(shí)時(shí)巡檢、天級(jí)對(duì)賬來(lái)保障數(shù)據(jù)的最終一致性，從而最大限度的發(fā)揮存儲(chǔ)引擎優(yōu)勢(shì)；