# 面試題目
## 資料庫
### 遷移資料庫
1. 計劃和準備
評估需求：明確遷移的範圍、目標數據庫系統、遷移的窗口時間、預算及風險。
確定工具：選擇合適的遷移工具，如AWS Database Migration Service、Google Cloud Database Migration Service、Azure Database Migration Service、DMS、Data Pump、pg_dump/pg_restore等。
2. 備份和驗證
完整備份：在開始遷移之前，對現有數據庫進行完整備份，以防止數據丟失。
驗證備份：確保備份的完整性和可用性。
3. 設置目標數據庫
環境準備：在目標數據庫中準備好相應的基礎設施和配置。
模式設置：如果目標數據庫需要特定的模式，先在目標數據庫中創建好。
4. 遷移過程
**初始數據遷移**：使用選擇的工具將現有數據遷移到目標數據庫。可以考慮分批次遷移，以減少一次性遷移的大量數據所帶來的風險。
**增量數據遷移**：對於持續變更的數據，考慮使用增量遷移策略，即定期同步源數據庫和目標數據庫之間的變更。
5. 驗證和測試
數據驗證：檢查遷移後的數據完整性和一致性，確保所有數據都已正確遷移。
性能測試：在目標數據庫上進行性能測試，確保其能夠滿足業務需求。
6. 切換和優化
最終切換：在確保數據已完整且性能達標後，將應用程序切換到新的數據庫。
優化配置：對目標數據庫進行性能調優，確保其運行效率。
7. 監控和支持
持續監控：監控新數據庫的運行情況，及時發現和解決問題。
用戶支持：為用戶提供必要的支持和培訓，幫助其適應新的數據庫系統。
### Master Slave Replication

### 正規化
#### 1NF 規則
1.每一個欄位只能有一個基元值（Atomic Value）即單一值

2.沒有任何兩筆以上的資料是完全重複

3.資料表中有 Primary Key，而其他所有的欄位都相依於 Primary Key

### composite index
a,b,c

### sql transaction ACID
#### Atomic
> 每個tx，在交易過程當中只有完全成交或全部失敗
#### Consistency
> 在事務開始之前和事務結束以後，資料庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設約束
#### Isolation
##### 問題
1. Dirty Read
- 會讀到沒有commit的transaction資料
2. Non Repeatable read
- 同樣查詢但會有不同的資料
3. Phantom reads
- 同樣查詢條件卻有不同的筆數
##### Isolation level
1. 未提交讀（read uncommitted）
> 完全不鎖
2. 提交讀（read committed）
> 只會讀到tx commit後的資料
3. 可重複讀（repeatable read）
> 在Transaction內，只要條件相同讀出來的內容會相同
4. 串行化（Serializable）
> 在Transaction內，只要條件相同讀出來的內容筆數皆會相同
#### Durability
> 資料不會遺失且可以復原
## 資安
### 加密以及雜湊
### xss
cross-site，是因為這種攻擊方式，通常是從可信的來源發出，因此能夠繞過同源政策 (same origin policy)
1. REFLECTED
2. DOM
3. Stored
- 存在資料庫裏面的
- (e.g. 留言板:<script>doSthBad()</script>)
#### solution
1. CSP (content security policy)
用header限制來源
2. stored 跟 Reflected 需要後端資料庫去把任何有威脅的檢查並不允許儲存
3. 前端 dom 必須設規則嚴防
### CSRF(Cross-site request forgery)
- 利用session或驗證尚未過期時間幫你發送請求
- 如果請求不是get方法要再設計form給客戶輸入
#### solution
1. 驗證碼
2. 產生CSRF token做二次驗證
3. 檢查Referer
> Header的referer欄位記錄著來源的domain，只要是不同domain就擋，但有些瀏覽器不帶referer
### CORS
Access-Control-Allow-Origin：*
## Nginx
1. 反向代理 Reverse Proxy
2. 負載均衡 LoadBalancer
3. http 快取
## 程式架構設計
### RateLimiter
1. 令牌桶（Token Bucket）
2. 漏桶（Leaky Bucket）
3. 固定窗口（Fixed Window）
邊界高請求
4. 滑動窗口（Sliding Window）
### SOLID
#### Single Responsible Principle
> 一個class一個職責
例如: shoppingCart 和 receipt
#### Open-closed Principle
> 擁抱擴充，但盡量不要內部修改
例如: 結帳分成兩種結帳方式，不要直接繼承對方
ShoppingCartWithDiscount & ShoppingCart
#### Liskov Substitution Principle
> 子類別永遠可以取代父類別
例如: shape Square
#### Interface Segregation Principle
> 接口盡可能切得更小
例如 : 印刷 打字 掃描
#### Dependency Inversion Principle
> 依賴抽象或是介面，減少類別之間的直接耦合

### OOP
#### Encapsulation
#### Inheritance
#### Polymorphism

## 網路
### TCP/IP
將傳統的OSI七層架構變成四層
1. APPLICATION
> http, smtp ,pop3(收信),ssh ,ftp
2. TRANSPORT
> TCP UDP
3. NETWORK
> IP
4. LINK
> LAN WAN ARP

## 高併發

### 三大改善
#### 高擴張
#### 高效能
#### 高可用

### 垂直擴張
1、提升單機的硬件性能：通過增加內存、CPU核數、存儲容量、或者將磁盤升級成SSD等堆硬件的方式來提升。
2、提升單機的軟件性能：使用緩存減少IO次數，使用並發或者異步的方式增加吞吐量。

### 水平擴張

## 風險控制
- 風險識別：確定可能影響目標實現的各種潛在風險。

- 風險評估：評估每種風險發生的可能性和對組織的影響程度。

- 風險管理：制定和實施措施來減少或控制風險的影響，包括避免、轉移、減少或接受風險。

- 監控和回應：持續監控風險情況，並在必要時調整措施以應對新的或變化的風險。

### 需求變更風險：
風險描述：客戶或管理層可能會在開發過程中提出需求變更，影響開發進度和資源分配。
風險控制：確立清晰的需求管理流程，包括需求的評估、優先級設定和變更管理。定期與利益相關者溝通，確保共識和理解。
### 技術選擇和設計風險：
風險描述：選擇不適當的技術或設計方案可能導致後續開發和維護困難，以及性能問題。
風險控制：進行詳細的技術評估和原型開發，與團隊討論和確定最佳技術和設計方案。實施代碼審查和設計審查機制，確保符合最佳實踐和品質標準。
### 時間和進度風險：
風險描述：開發進度落後於計劃可能導致項目延期或增加成本。
風險控制：採用敏捷開發方法，實行迭代開發，定期進行進度跟蹤和風險評估。合理估計工作量，避免過度承諾。
### 質量控制風險：
風險描述：開發過程中出現軟體缺陷、安全漏洞或性能問題。
風險控制：實施全面的單元測試、集成測試和系統測試，使用自動化測試工具來確保程式碼質量。採用持續集成和持續交付（CI/CD）流程，確保代碼穩定性和一致性。

## Redis
### 1.DB Cache
### 2.Session
### 3.Distributed Lock
### 4.Rank
- Sorted Sets

## Cache
### Cache penetration
- 用戶端查詢不存在資料
### Cache Avalanche
- 過期時間一致
### Hotspot Invalid
- 某個資料太多人使用突然過期