要在數(shù)據(jù)庫中獲取兩張表中具有相同ID的記錄，并獲取另一張表中的字段，您可以使用SQL中的JOIN操作來實現(xiàn)。下面是一個示例，展示如何通過JOIN獲取兩個表中相關(guān)記錄：

假設有兩張表：table1和table2，它們具有相同的ID字段。您想要獲取table1中的記錄，并獲取table2中的另一個字段。

SELECT t1.*, t2.fieldName
FROM table1 t1
JOIN table2 t2 ON t1.id = t2.id

我們使用JOIN操作連接table1和table2，并在ON子句中指定它們共享的ID字段。通過在SELECT語句中列出t1.*，我們選擇了table1中的所有字段。同時，我們使用t2.fieldName選擇了table2中的fieldName字段。這樣，查詢結(jié)果將包含來自兩個表的相關(guān)記錄。

Spring Boot 項目 一直運行在服務器上

ohup 的意思是即使登出也不會終止該進程

nohup java -jar jar包名 >  日志文件輸出路徑  2>&1  &

如：

nohup java -jar brain-deep-learn-server-0.0.1-SNAPSHOT.jar > /home/admin/logs/brain-deep-learn-server-0.0.1-SNAPSHOT.out 2>&1 &

日志文件輸出路徑 :  /home/admin/logs/brain-deep-learn-server-0.0.1-SNAPSHOT.out     

&表示這個程序在后臺運行

查看進程：

ps -ef | grep jar包名

如：

ps -ef | grep brain-deep-learn-server-0.0.1-SNAPSHOT.jar 

package com.br.file.config;
 
 
import java.io.File;
import javax.servlet.MultipartConfigElement;
 
import org.springframework.beans.factory.annotation.Value;
import org.springframework.boot.web.servlet.MultipartConfigFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
 
@Configuration
public class MultipartConfig {
    @Value("${server.tomcat.basedir}")
    private  String tempDir;
    @Bean
    MultipartConfigElement multipartConfigElement() {
        MultipartConfigFactory factory = new MultipartConfigFactory();
        String location = tempDir;
        File tmpFile = new File(location);
        if (!tmpFile.exists()) {
            tmpFile.mkdirs();
        }
        factory.setLocation(location);
        return factory.createMultipartConfig();
    }
}
 

Knife4j是一個集Swagger2 和 OpenAPI3 為一體的增強解決方案

• 提供基于K8S+Docker的云原生的聚合OpenAPI文檔的解決方案
• 簡化Knife4j的使用及學習成本，一鍵部署&集成&使用

/api/swagger-ui/index.html

<!--引入Knife4j的官方start包,該指南選擇Spring Boot版本<3.0,開發(fā)者需要注意-->
<dependency>
    <groupId>com.github.xiaoymin</groupId>
    <artifactId>knife4j-openapi2-spring-boot-starter</artifactId>
    <version>4.0.0</version>
</dependency>

api/druid/index.html

cd /usr/local/kibana/config/

1. 打開瀏覽器：打開你的瀏覽器，并輸入地址 http://localhost:5601。

2. 訪問登錄頁面：在瀏覽器中打開 http://localhost:5601 后，會跳轉(zhuǎn)到 Kibana 的登錄頁面。

3. 輸入用戶名和密碼：輸入你的用戶名和密碼以進行登錄。這些憑據(jù)通常是在安裝和配置 Kibana 時設置的。如果你沒有設置用戶名和密碼，可以嘗試使用默認的憑據(jù)進行登錄。

4. 開始使用 Kibana：成功登錄后，你將進入 Kibana 的主界面。從這里，你可以使用 Kibana 的各種功能來分析和可視化你的數(shù)據(jù)。

5. 獲取 Enrollment Token：從你的終端輸出中復制 Enrollment Token。這個 Token 通常是在配置 Elastic Stack 時生成的，用于進行安全認證和授權(quán)。

6. 訪問登錄頁面：在你的瀏覽器中打開 Elastic Stack 的登錄頁面。通常情況下，可以通過訪問 http://localhost:5601 來訪問 Kibana 登錄頁面。

7. 輸入 Enrollment Token：在登錄頁面中，選擇 "Enrollment Token" 或 "配置 Elastic" 選項。然后，粘貼你從終端復制的 Enrollment Token 到相應的輸入框中。

8. 登錄 Elastic Stack：完成輸入 Enrollment Token 后，點擊 "登錄" 或 "Continue" 進行登錄。

9. 開始使用 Elastic Stack：成功登錄后，你將進入 Elastic Stack 的主界面（通常是 Kibana）。從這里，你可以使用 Elastic Stack 的各種功能進行數(shù)據(jù)分析、搜索和可視化。

brew services start redis

brew services stop redis

https://www.elastic.co/cn/downloads/elasticsearch

https://www.elastic.co/cn/downloads/kibana

bin/elasticsearch-create-enrollment-token 命令用于在 Elastic Stack 中創(chuàng)建 Enrollment Token。在執(zhí)行該命令時，需要指定作用域（scope），如 kibana。

下面是獲取 Enrollment Token 的步驟：

1. 打開終端：打開終端或命令行界面。

2. 導航到 Elasticsearch 安裝目錄：使用 cd 命令導航到 Elasticsearch 的安裝目錄。例如，如果 Elasticsearch 安裝在 /usr/share/elasticsearch，則可以執(zhí)行以下命令：

   cd /usr/share/elasticsearch
   

3. 運行 elasticsearch-create-enrollment-token 命令：執(zhí)行以下命令來創(chuàng)建 Enrollment Token：

   bin/elasticsearch-create-enrollment-token --scope kibana
   

   這將生成一個 Enrollment Token，并將其顯示在終端輸出中。

4. 復制 Enrollment Token：復制終端中顯示的 Enrollment Token。你可以使用鼠標選中 Token，并使用右鍵點擊復制，或者手動選中并使用復制命令。

出現(xiàn)錯誤 [xpack.security.enrollment.enabled] must be set to 'true' to create an enrollment token 表示在創(chuàng)建 Enrollment Token 之前，需要將配置項 [xpack.security.enrollment.enabled] 設置為 true。

要解決這個問題，你可以按照以下步驟進行操作：

1. 打開 Elasticsearch 配置文件：找到并打開 Elasticsearch 的配置文件 elasticsearch.yml，該文件通常位于 Elasticsearch 安裝目錄的 config 文件夾下。

2. 搜索 [xpack.security.enrollment.enabled] 配置項：在配置文件中搜索 [xpack.security.enrollment.enabled]，確保該配置項存在。

3. 設置 [xpack.security.enrollment.enabled] 為 true：將 [xpack.security.enrollment.enabled] 的值設置為 true，即啟用 Enrollment 功能。如果該配置項不存在，請手動添加以下行到配置文件中：

   xpack.security.enrollment.enabled: true
   

4. 保存配置文件：保存對配置文件的修改。

5. 重新啟動 Elasticsearch：重啟 Elasticsearch 以使配置更改生效。

完成以上步驟后，再次嘗試執(zhí)行 bin/elasticsearch-create-enrollment-token --scope kibana 命令，應該就能夠成功創(chuàng)建 Enrollment Token。

ps aux|grep elasticsearch

當出現(xiàn) "Couldn't connect to cluster" 錯誤時，通常表示 Elasticsearch 客戶端無法連接到指定的集群。這可能是由于以下原因之一：

1. 集群地址錯誤：請確保你提供的集群地址是正確的，并且可以通過網(wǎng)絡訪問。檢查網(wǎng)絡連接、防火墻設置和主機可達性。
2. 集群健康狀態(tài)：如果集群處于紅色或黃色健康狀態(tài)，可能存在問題導致集群無法正常工作。請檢查 Elasticsearch 集群的健康狀態(tài)，并查看集群的日志文件以獲取更多信息。
3. 安全配置問題：如果你的 Elasticsearch 集群啟用了安全特性，例如身份驗證或 SSL/TLS 加密，你需要確?？蛻舳说倪B接配置與集群的安全設置相匹配。驗證證書、用戶名和密碼等安全配置是否正確。
4. 網(wǎng)絡代理問題：如果你的網(wǎng)絡環(huán)境使用了代理服務器，請確保客戶端的連接配置包括正確的代理設置。

為了解決此問題，你可以嘗試以下步驟：

• 驗證集群地址：確認你使用的集群地址是正確的，并且可以通過網(wǎng)絡訪問。嘗試使用 curl 或其他工具測試連接到 Elasticsearch 的端口。
• 檢查集群健康狀態(tài)：使用 Elasticsearch 的集群管理 API 或命令行工具來檢查集群的健康狀態(tài)。如果集群狀態(tài)不正常，查看集群的日志文件以獲取更多信息，并解決相關(guān)問題。
• 檢查安全配置：如果你的集群啟用了安全特性，請確保客戶端的連接配置正確，并具有適當?shù)纳矸蒡炞C憑據(jù)或證書。
• 確認網(wǎng)絡代理設置：如果你的網(wǎng)絡環(huán)境使用了代理服務器，請確?？蛻舳说倪B接配置包括正確的代理設置。

x86_64

@Data是Lombok提供的一個注解，用于自動生成Java類的常用方法，包括getter、setter、toString()、equals()、hashCode()等方法。

使用@Data注解可以簡化Java類的編寫，避免手動編寫大量的樣板代碼。當我們在一個類上添加了@Data注解時，Lombok會在編譯階段自動生成相關(guān)的方法。

具體而言，@Data注解會為類中的所有非靜態(tài)字段自動生成以下方法：

• Getter方法：為每個字段生成對應的getter方法，用于獲取字段的值。
• Setter方法：為每個字段生成對應的setter方法，用于設置字段的值。
• equals()方法：根據(jù)類中的字段生成相應的equals()方法，用于比較兩個對象的內(nèi)容是否相等。
• hashCode()方法：根據(jù)類中的字段生成相應的hashCode()方法，用于計算對象的哈希碼。
• toString()方法：生成一個包含類中所有字段及其值的字符串表示。

使用@Data注解可以大大簡化代碼，提高開發(fā)效率，特別是對于那些包含大量字段的POJO類。

例如，下面是一個使用@Data注解的示例：

@Data
public class Person {
    private String name;
    private int age;
    private String address;
}

上述代碼中，@Data注解標記在Person類上，Lombok會自動生成getName()、setName()、getAge()、setAge()、getAddress()、setAddress()、equals()、hashCode()和toString()等方法。

總之，@Data注解是一個方便的Lombok注解，用于自動生成常用方法，減少樣板代碼，提高開發(fā)效率。

在Spring Boot中，BO（Business Object）是一種常見的命名約定，表示業(yè)務對象。BO通常用于封裝業(yè)務邏輯和數(shù)據(jù)操作，代表業(yè)務領域中的概念或?qū)嶓w。架構(gòu)師在設計架構(gòu)時考慮到以下幾點：

1. 業(yè)務邏輯的封裝：BO用于封裝具體的業(yè)務邏輯，將業(yè)務處理的相關(guān)代碼集中在一起，實現(xiàn)業(yè)務邏輯的高內(nèi)聚性。這有助于代碼的組織和維護，并提高代碼的可讀性和可維護性。
2. 領域模型的表示：BO代表業(yè)務領域中的概念或?qū)嶓w，通過在BO中定義字段和方法，可以更好地描述和表達業(yè)務領域中的對象及其行為。BO可以與數(shù)據(jù)庫表、外部服務、用戶輸入等進行交互，處理和操作相關(guān)數(shù)據(jù)。
3. 業(yè)務規(guī)則和驗證：BO可以包含業(yè)務規(guī)則和驗證邏輯，用于確保業(yè)務操作的合法性和一致性。通過在BO中定義驗證方法，可以對數(shù)據(jù)進行校驗，并在業(yè)務操作之前或之后執(zhí)行相應的處理邏輯。
4. 與其他層的交互：BO可以作為業(yè)務邏輯層與其他層（如控制器、服務層、持久層）進行交互的中間對象。BO可以接收和傳遞數(shù)據(jù)，對數(shù)據(jù)進行處理和轉(zhuǎn)換，并與其他層進行協(xié)調(diào)和溝通，實現(xiàn)系統(tǒng)的整體功能。

通過將業(yè)務邏輯封裝在BO中，可以將關(guān)注點分離，提高代碼的可維護性和擴展性。同時，BO的設計應考慮領域模型的合理性和業(yè)務需求的變化，以便滿足系統(tǒng)的演進和擴展。

<!--引入Knife4j的官方start包,該指南選擇Spring Boot版本<3.0,開發(fā)者需要注意-->
<dependency>
    <groupId>com.github.xiaoymin</groupId>
    <artifactId>knife4j-openapi2-spring-boot-starter</artifactId>
    <version>4.0.0</version>
</dependency>

@Configuration
@EnableSwagger2WebMvc
public class Knife4jConfiguration {

    @Bean(value = "dockerBean")
    public Docket dockerBean() {
        //指定使用Swagger2規(guī)范
        Docket docket=new Docket(DocumentationType.SWAGGER_2)
                .apiInfo(new ApiInfoBuilder()
                //描述字段支持Markdown語法
                .description("# Knife4j RESTful APIs")
                .termsOfServiceUrl("https://doc.xiaominfo.com/")
                .contact("[email protected]")
                .version("1.0")
                .build())
                //分組名稱
                .groupName("用戶服務")
                .select()
                //這里指定Controller掃描包路徑
                .apis(RequestHandlerSelectors.basePackage("com.github.xiaoymin.knife4j.controller"))
                .paths(PathSelectors.any())
                .build();
        return docket;
    }
}

@Api(tags = "首頁模塊")
@RestController
public class IndexController {

    @ApiImplicitParam(name = "name",value = "姓名",required = true)
    @ApiOperation(value = "向客人問好")
    @GetMapping("/sayHi")
    public ResponseEntity<String> sayHi(@RequestParam(value = "name")String name){
        return ResponseEntity.ok("Hi:"+name);
    }
}

1440是表示Token的過期時間為1440分鐘，即24小時。這個設置在絕大多數(shù)情況下是合理的，因為一般來說，用戶的登錄狀態(tài)應該在一定時間后自動過期，需要用戶重新登錄以保障安全性。

設置Token的過期時間為24小時可以提供一定的用戶體驗和安全性。用戶在登錄后，可以在一天內(nèi)持續(xù)使用應用而不需要頻繁重新登錄。同時，較短的過期時間可以減少Token被盜用的風險，因為Token在短時間內(nèi)失效后，黑客無法持續(xù)使用被盜的Token訪問用戶的賬號。

然而，過期時間的設置還是要根據(jù)具體的應用場景和安全要求進行調(diào)整。如果你的應用對安全性要求非常高，可以考慮縮短Token的過期時間，比如設置為幾小時或者幾十分鐘，這樣可以進一步降低被盜用的風險。反之，如果應用對用戶的便利性要求較高，可以適當延長過期時間，以提供更好的用戶體驗。

總的來說，1440分鐘（即24小時）的Token過期時間在一般情況下是合理的，但具體的設置還需要根據(jù)應用的實際需求和安全性要求來決定。

在前端應用中，Token會在用戶登錄成功后由后端返回，并保存在前端的Cookie或者LocalStorage中。當用戶進行其他需要認證的請求時，前端會攜帶這個Token進行身份驗證。以下情況可能導致前端Token丟失或者無效，從而觸發(fā)認證失敗處理器：

1. Token過期：前端保存的Token可能有一個有效期，如果超過了有效期，就會失效，需要用戶重新登錄獲取新的Token。
2. Token被篡改：如果Token在傳輸過程中被非法篡改，或者前端保存的Token被惡意修改，后端會驗證失敗，認為Token無效。
3. 后端服務重啟或Token重新生成：當后端服務重啟時，原有的Token可能會失效，因為后端會重新生成新的Token，需要用戶重新登錄獲取新的Token。
4. 未正確攜帶Token：前端在發(fā)送需要認證的請求時，可能忘記在請求頭中攜帶Token或者攜帶的Token格式不正確，導致后端無法驗證身份。

關(guān)于你提供的代碼，AuthenticationEntryPointImpl 類的實現(xiàn)似乎沒有明顯的錯誤。它的功能是在認證失敗時，返回一個包含錯誤信息的JSON響應。如果前端攜帶的Token無效或者過期，后端會返回401狀態(tài)碼，以及一個提示信息告知用戶認證失敗，無法訪問系統(tǒng)資源。

可能的錯誤原因在于前端攜帶的Token無效，你可以在前端開發(fā)者工具中查看請求頭部，確保Token正確地攜帶在Authorization頭部或其他適當位置。另外，你也可以檢查后端生成Token的邏輯，確保Token的生成和驗證過程正確無誤。

加群聯(lián)系作者vx：xiaoda0423

倉庫地址：https://github.com/webVueBlog/JavaGuideInterview