1. 分頁查詢
依賴：PageHelper
新建一個分頁實體對象
Service中
startPage起到攔截作用，僅對其後的第一條查詢語句有效。
若依分頁原理：
通過
((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest().getParameter("pageNum")
得到pageNum=5，將其封裝到一個PageDomain實體中
然後調用PageHelper.startPage（page，size…）進行分頁。
注意：Request.getParameter只能獲取到url中的顯式參數
聯想：
- getParameter()獲取的是客戶端設置的數據。
- getAttribute()獲取的是服務器設置的數據。
- getParameter()永遠返回字符串
- getAttribute()返回值是任意類型
疑問：
HttpServletRequest好像可以通過Autowired注入直接使用，爲什麼若依要用這麼複雜的方式拿到request？
結論：
- HttpServletRequest可以注入使用，但只能在控制器中使用，service層等其他地方（以及靜態方法中）是不能使用的
- 可以通過線程上下文拿到當前的request，SpringMVC提供了RequestContextHolder保存當前的request，ruoyi就是使用這個在service拿到request
2. 條件查詢
依賴：通用mapper
1、service接口中提供條件查詢服務
2、實現查詢服務接口
Example是通用mapper中的對象，用於構造查詢條件。
3、控制器中
可以直接通過一個Map接收前端的查詢參數。
若依條件查詢原理：
前端直接傳遞查詢對象（比如查詢對象是user，則傳遞想要查詢的user字段），然後利用mybatis的if實現條件選擇。（詳情可進入任意一個mapper，進入註釋所標註的條件分頁查詢代碼）
優缺點：若依沒有使用通用mapper，條件構造是通過sql語句；利用通用mapper構造條件查詢利於移植。
3. 文件上傳
控制器中編寫以下代碼：
方法參數接收文件數據
（@RequestParam（“file”） MultipartFile file）
方法體中
創建本地目標文件desFile
方法體中將文件數據保存到本地文件中
file.transfTo(desFile);
若依文件上傳工具：FileUploadUtils
單點存儲可以使用本地存儲，但是一般來說都是用雲存儲（阿里雲OSS）
使用OSS存儲：
阿里雲OSS入門案例：https://www.bilibili.com/video/BV1Ft411c7P1?p=56
注意：同名文件在雲空間會被覆蓋，因此可以使用時間戳或者UUID來命名；此外，還可以加上OSS中自定義的文件夾名稱。
4. 緩存理論
緩存穿透：通過重複查詢不存在的數據，導致數據庫壓力過大。
例子：發起無數次查詢：查詢id爲-1的用戶 --> 先到緩存中查詢，不存在 --> 再到數據庫查詢 --> 使得數據庫承受無數次查詢壓力。
解決方案：查詢id爲-1的用戶 --> 如果緩存中不存在且數據庫中也不存在，則在緩存中加入key=查詢id，value=0的緩存 --> 第二次查詢id爲-1 --> 返回0；
緩存擊穿：緩存中沒有，但是數據庫有，當併發量較大的時候，瞬間大批量查詢數據庫，導致壓力較大。
解決方案：
1.高併發查詢通一個數據，一般是因爲該數據是熱點數據，因此設置熱點數據永不過期。
2.緩存預熱
緩存預熱：一開始就將數據庫的所有數據存爲緩存，用戶只允許查詢緩存；如果緩存中沒有，則說明沒有，不必查詢數據庫（也能防止緩存穿透）；當且僅當數據發生變更，再統一更新數據庫與緩存。
實現方法：
1.存：實現InitializingBean接口，會在啓動時調用（或者其他項目初始化方法），在其中查詢數據庫，並將數據加到緩存中。
2.取：查詢在緩存中查，若不存在，則返回爲空
3.改：修改數據後，更新對應緩存
緩存雪崩：“雪崩”，顧名思義即緩存崩潰；當緩存的過期時間接近導致同一時間大批量緩存過期，瞬間使得緩存類似失效的狀態，且數據庫在此時接收大批查詢，壓力大。
解決方案：
1.過期時間設置隨機（或其他方案），避免同一時間過多緩存過期。
2.熱點數據不過期
3.緩存預熱
5. 靜態渲染概念
概念：
對於長期不變動的頁面（或者只有部分信息會改變的頁面），服務端先生成靜態頁面，然後前端訪問的時候，直接訪問靜態頁面，這樣防止每次訪問頁面，都去數據庫查詢數據再渲染。
實現思路：
初始化時（或者專門調用靜態頁面創建接口），生成靜態頁面。
在靜態頁面中，對於會發生變動的數據，使用ajax進行動態查詢並渲染。
6. 數據表通用字段動態映射方法（如兩個必備時間）
必備時間：create_time、update_time
1.BaseEntity定義了兩個時間等多個通用字段（相當於每個實體都有這些字段），其他實體繼承BaseEntity
2.在哪裏使用？
a)在每個實體中的toString打印了這些通用字段
b)在數據庫中這些字段都是存在的
c)在mapper.xml中有這些字段的操作
3.在哪裏插值的？
在xml中調用sysdate()（數據庫函數，得到當前時間）進行設置
7. 定時任務調度
使用SpringTask：
Task只能用於簡單的定時，他是單線程的。
在SpringBoot中使用步驟：
1.啓動類上添加@EnableScheduling註解，開啓Spring的定時任務功能
2.創建定時任務類，用@Component標註類
3.創建定時任務方法，返回值必須爲void，不允許有參數、用@Scheduled標註
@Scheduled可以標註fixedRate和cron表達式，詳情百度。
Quartz
核心：
Job——任務，執行單元
Trigger——觸發器，什麼時候執行
Scheduler——任務調度，控制器
基本使用（JSEE）
使用步驟：
1.定義任務類JobDemo，繼承Job接口，實現execute方法。
2.在main方法（或其他執行處）
a)創建Job對象
JobDetail job = JobBuilder.newJob(JobDemo.class).build();
b)創建Trigger對象
Trigger trigger = TriggerBuilder.newTrigger().withSchedule(CronScheduleBuilder.cronSchedule(“corn表達式”));
c)創建Scheduler對象
Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();
d)組合Scheduler和Trigger
Scheduler.scheduleJob(job,trigger);
e)啓動
Scheduler.start();
整合SpringBoot：
通過一個Quartz配置類，注入三個核心組件，並關聯自定義的Job對象，然後在啓動類中開啓Quartz註解。
注意：Job對象在Quartz配置類中關聯的方式，是通過工廠反射注入的，而非Spring注入，因此，當我們在Job對象中使用Autowired注入service等IOC容器時會失敗。
解決方案：重寫AdaptableJobFactory中的createJobInstance，在返回Job之前，使用AutowireCapableBeanFactory將其加入到IOC容器中
(參考https://www.bilibili.com/video/BV1mE411F7NJ?p=6)
Quartz持久化：生成官方的12張表，這些表都不用管、然後完成配置類編寫；
若依是另外寫了一個sys_job表保存job的信息，並且所有的增刪查改都是在其上操作。Quartz的表都是框架自動使用。
若依quartz解析：
1.生成官方的10張表 （沒有qrtz_job_listeners、qrtz_paused_trigger_graps、qrtz_trigger_listeners）、完成QuartzConfig
2.創建自己的sys_job表，用於存儲任務，對應實體SysJob只是簡單的Javabean，沒有實現Job接口
3.在controller中都是對sys_job的增刪改查
4.自已有一套utils操作quartz
5.在service層調用mapper對SysJob操作，同時通過utils使sys_job與Quartz相關聯（這個工具包的具體操作我看不懂）
8. 支付
alipay
邏輯：
1.根據公鑰密鑰APPID等字段生成支付端口
2.用戶下單生成訂單（狀態：未支付）等一系列準備工作
3.將訂單信息發送到支付端口
4.支付端口返回支付頁面，用戶掃碼支付
5.支付端口回調支付成功頁面（狀態：完成支付）
6.訂單入庫等一系列收尾工作
注意事項：
1.將生成的公鑰填入RSA2（SHA256）應用密鑰即可，他會自動生成支付寶公鑰，對應我們生成的密鑰
2.在配置文件中，公鑰填寫網站自動生成的支付寶公鑰，密鑰填我們工具生成的密鑰
9. elasticSearch
提供RestFul接口服務，安裝運行之後，通過HTTP請求進行操縱。
協作包：IK分詞器、高級rest客戶端（在Java項目中通過代碼操縱，而不使用HTTP請求）
使用邏輯（以商城爲例）：
- 插入商品的同時，構建索引，插到elasticSearch中
- 發起搜索請求時，使用elasticSearch
未完待續