平屋慢生活

容器 Container為什麼要「輕量化隔離Deploy（部署方式的演進）cgroup (Control Group) 「資源控制」rootfs (Root File System)「容器的根檔案系統」如何建立容器化應用summary容器是一種「輕量化的應用執行環境」，讓你的應用程式能在任何地方執行，而且不會受到作業系統或環境差異的影響，本質上，是把「應用能不能跑」這件事，從環境問題，變成一個已經被打包解決的事!你不需要再賭「這台機器剛好跟你的一樣」，因為容器已經把所有必要條件一起帶著走 像錄影帶，裡面不只是程式碼，而是一段已經被錄好的「執行過程」：什麼時候啟動、用哪些資源、環境長什麼樣、第一秒該做什麼，只要你有能播放它的播放器（Docker），不管是在你的電腦、同事的機器、測試環境還是正式環境，播出來的結果都會一樣。 我們所需要做的事情是，應用程式本身要準備好，也就是你的程式碼，可能是一個 API、後端服務或指令工具 接著我們把應用需要的東西一起裝進來，包含語言執行環境（例如 Node、Python）、函式庫、系統套件，這一步是在解決「我電腦可以跑，你電腦不行」的問題 形成一個獨 ...

關於訂餐LEFT JOIN 事後過濾📜 SQL 執行順序LEFT JOIN 前置過濾INNER JOINsummary午休前的辦公室接近午休時間。Team leader 桌子一拍：「各位肥宅！麥當勞開團囉！」 Jacky 抬頭：「請客嗎？」Leader 停了一秒：「呃…好，可以。」 話才剛落音，幾個原本裝忙的同事像被觸發開關似地站起來，開始熱烈點餐： 「大薯 + 可樂，搭配麥脆雞腿堡。」 「大麥克加一份生菜，再配玉米濃湯。」 「精緻牛排。」 「鱈魚堡微糖少冰，搭配雪碧。」 ……………… Leader 看著訊息流越滾越誇張，只能扶額：「靠…我是不是講太大聲了？剛剛是不是還混進奇怪的東西？」 外送到後，大家開始大快朵頤，享受難得的免費午餐，而辦公室的一角，Allen 才剛把耳機拿下，看著眾人吃得開心，因為工作太專注，他完全錯過開團訊息 另一邊，也有同事沒發聲，只因為不喜歡炸物，於是默默提著自己的 Subway 回到座位 以資料表的角度來看，這裡會有兩張表 Employee（員工資料） Order（訂餐資料） 現在我們想查的是哪些員工有參與「活動」（例如平常都跟團），但沒有參與 ...

板著一張臉IsolationLevelIsolationLevel = SnapShotSnapShot - 一步步來資料庫設定使用 TempDB 儲存「行版本（Row Versions）」寫入衝突（Update Conflict）什麼情況下用 SNAPSHOT 最適合？什麼情況下用 SNAPSHOT 不適合？一個真實的 DirtyRead 案件結語 他的聲音低沉，又總是板著一張臉，走在路上連大人都會不自覺讓開，更別說孩子了。小孩一靠近他，他眉頭一皺，小朋友就嚇得跑掉。 久而久之，村裡流傳的故事越變越誇張，有人說他脾氣壞、有人說他討厭小孩、有人說他從不關心別人這些話像一堆未經查證的資訊在村裡亂流，就像大家用著 ReadUncommitted 的方式在認識他，還沒看清就急著下結論。 一個人的真心，不是聽來的，而是他在困境裡做出的選擇，謠言說的都是 Uncommitted 的版本，唯有親眼看見的 Snapshot，才是真實的他 在同一段交易裡，你接受看到「哪一種樣子的世界」？ 在多人同時查資料、改資料的世界裡，不可能做到「既快、又完全正確、又不互相干擾」。資料庫永遠在做取捨，而 Isol ...

GitLab Self-Managed公司網路怎麼建起來的DNS內網每台機器實際拿哪個 IP一步步summaryGitLab Self-Managed 是公司自己安裝、自己維運的一套 GitLab，可以部署在公司內部網路、私有雲，甚至做成完全離線的環境。和 GitLab.com（SaaS 版）最大的差別在於：這套 instance 完全由公司掌控，主機、網路、權限、備份、存取規則全都是自己管。 核心元件 元件 負責的事 Web / API 服務 你平常打開網頁、呼叫 API 的入口 PostgreSQL 儲存帳號、專案、issue、pipeline 等資料 Redis 快取與背景工作協調 Gitaly / Git 儲存 真正存放 repository 的地方 Sidekiq 背景工作，例如寄通知、執行非同步任務 Registry / Runner 延伸元件，視公司是否啟用 把整套 GitLab 比做一間公司： 前台（使用者介面）→ Web / API 服務 倉庫（放程式碼）→ Gitaly / rep ...

不安全的轉導（Open Redirect）白名單（Whitelist）驗證Relative Path加簽驗證（Signature）限制參數長度與格式— 防止繞過技巧增加跳轉提示頁（中介頁)攻擊手法summary🔆🔆 「🇯🇵 日本電商客服 月薪 8 萬｜包吃住｜合法公司詳情私我」 🔆🔆 他心想，「哇，日本耶！而且朋友的朋友介紹，應該很穩吧。」 於是他私訊、面試、簽約，一切流程超順，順到像自動登入了光明人生。後來對方說了：「先飛曼谷，再有人帶你過去。」 他當下沒有多想，就像看到網址是 https://trusted-company.com，沒去看後面的參數 下飛機後，接他的人說：「等等換一台車。」 換著換著，風景從市區 → 郊外 → 鐵門 → ❌ 404：你以為的人生不在這裡 Open Redirect 本質是，「把跳轉控制權交給使用者，卻沒有驗證對方要帶你去哪裡」，這會讓原本可信的網站，變成幫攻擊者背書的跳板 https://nice.com/redirect?target=https://phishing-site.com 因此，若應用程式提供 redir ...

🧱 多租戶系統的核心：Tenant Boundary（租戶邊界）不論是「店」或「會員」，都必須有一個一致的「租戶識別」，且整個系統要從上到下都尊重這邊界 1使用者 → Token → Context → DbContext / Repository → SQL 只要其中一層沒守好，就可能造成資料外洩想像你有「很多間分店」都使用同一套後台系統 A 店的會員不能看到 B 店的訂單 B 店的商品不能被 A 店誤改 C 店的營收絕不能被其他店家查到 👉 ShopId 就像房間鑰匙，沒有鑰匙就不能進別人的房間 🧱 後端層面防範策略（最重要的三層）這三層是「後端防呆」的核心，只要其中一層沒做好，就可能讓使用者查到不是自己的資料 1️⃣ Token / 身分驗證層：登入時就綁 ShopId（第一道鎖）當會員登入後，你發 JWT 時，「必須」把該會員的 ShopId 寫進 Token 12345{ "MemberId": "M123", "ShopId": "A001", ...

在 Entity Framework Core 開發中，看似簡單的 LINQ 查詢可能隱藏著巨大的效能陷阱。今天我們來深入分析兩個經典的效能問題，以及它們背後的根本原因。 🚨 案例一：SearchProducts 的效能災難💥 問題程式碼1234567public IEnumerable<Product> SearchProducts(string[] keywords){ return _context.Products.Where(p => keywords.All(k => p.Name.Contains(k)));}// 呼叫方式var results = SearchProducts(new[] { "red", "shoes" }); 乍看之下這段程式碼很合理：搜尋包含所有關鍵字的產品。但實際上，這是一個效能炸彈！ � 問題分析核心問題：keywords.All(...) 無法轉換成 SQL 讓我們拆解這個表達式： 1keywords.All(k =&g ...

ConsoleApp 的啟動流程Host - 是整個 App 的根hostingContext - 目前應用程式主機 (Host) 的執行環境上下文, 帶著關於目前執行環境的所有資訊 hostContext.Configuration - 拿出目前 config hostingContext.HostingEnvironment - 拿出目前環境 ConfigureAppConfiguration - 讀設定檔 config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true); ConfigureServices - 註冊服務 hostContext, IServiceCollection services.AddDbContext<WebStoreDbContext>(options options = DbContextOptionsBuilder, EF Core 啟動時用來決定連線方式、行為設定的物件 configuration.Ge ...

牽涉到三個核心風險： 超賣（Overselling） 鎖競爭（Lock Contention） 效能瓶頸（Performance Bottleneck） 庫存扣減要即時又要安全，但越嚴格的隔離會越慢，要怎麼平衡？ 在扣庫存的交易中，最怕的不是「讀到舊資料」，而是「兩個人同時看到同一個庫存，然後都扣成功」。這其實不是 read 的問題，而是 concurrent update 的問題 關鍵是交易期間必須鎖定庫存那一筆資料，確保扣減是序列化的（serial） 通常在電商系統，我們會選擇交易層級用 READ COMMITTED 或 REPEATABLE READ，配合「明確加鎖查詢」 模式 隔離級別 特性 是否會鎖住那筆庫存 備註 (1) READ COMMITTED + UPDLOCK 預設 防髒讀 ✅ 是 最常用、安全 (2) SERIALIZABLE 最嚴格 防髒讀 + 幻讀 ✅ 是 (範圍鎖) 太重，僅用於財務對帳 (3) SNAPSHOT / RCSI 基於版本 不會 block，但需要行版本控制 ❌ 否 不適合庫存扣減（可能超賣） 範例一： ...

它允許「髒讀 (dirty read)」，即能讀到尚未 commit 的資料，讀取過程也不會對任何資料加 lock（不會阻塞其他 transaction）。在高併發的電商場景中，這確實可以用來提升查詢效能，但只能用在「對準確性要求不高」的情境 查詢只讀、不影響交易邏輯 查詢結果可容忍暫時誤差 若使用 ORM可在 connection 層設定 transaction isolation WITH (NOLOCK) 1️⃣ 商品瀏覽頁（商品列表、搜尋結果）使用者瀏覽商品時，看到的價格或庫存即使延遲幾秒、甚至略有偏差，也不影響體驗。 範例： 12SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;SELECT id, name, price, stock FROM products WHERE category_id = 10 LIMIT 50; 使用者只是在「逛」，非購買瞬間，資料一致性不必嚴格 → 減少 shared lock，提升商品列表查詢速 2️⃣ 熱門商品排行榜（依銷量或瀏覽量排序）排行榜本身是近似實時資料，但不需要精確到 ...