平屋慢生活

NodeAlwaysOn Availability GroupAWS RDS 的 Multi-AZ + Read Replica 架構RW / ROCPU 效能消耗來源CPU HIGH 原因分析檢查 Query Plain 方式搶券優化 - 關於 tempTable 濫用後台付款查詢 - 關於索引summary一個 Node = 一個獨立運作的資料庫執行單位，實務上 通常對應一台 Instance（VM / EC2 / RDS instance） 一個「節點」就是一台資料庫伺服器（Server），在分散式或高可用架構中會有多台，也就是多節點佈署 1234567891011121314 +-------------------------+ | App / API Server | +-----------+-------------+ | v┌─────────────────────────────┐│ DB Cluster │├────────── ...

DynamoDB 是怎麼把「高併發壓力」攤平的DynamoDB 是怎麼把「高併發壓力」攤平的流量真的變很大時，DynamoDB 會做什麼購物車回饋活動管庫存資料存取模式明確、可預期的系統「不適合」用 DynamoDB 不要硬撐，不要集中，讓壓力自然就是分流，是最溫柔也最有效的防禦 如果把所有時間自我認同都投入單一面向上，一旦單點開始延遲、停滯、壓力襲來，整個人不是失落而是直接瓦解，開始焦慮、開始失去存在感 把自己拆成很多 partition，工作只是其中一塊、關係只是其中一塊，興趣、休息、身體、學習，各自扛一點 某一塊出問題 ≠ 整個人生當機 人生若綁定特定的 hot key ，可能是只從某個人那裡獲得肯定、只用成績證明自己、只靠收入撐安全感、情緒只剩一個出口，那個地方一爆，你會覺得為什麼我明明很努力，卻撐不住？不是你不夠強，而是你把所有流量都導到同一個點 我不需要承受，只要分散DynamoDB 一開始就把資料切碎，讓很多台機器各自扛一小部分，DynamoDB 真正在做的是資料本來就分散在很多 partition，當流量來了會調整 partition 數量與吞吐，這會讓「請求平均打到不 ...

故事：圖書館的智慧📘 RCU & WCU：圖書館的服務能量☁️ Serverless：你不用管伺服器🚦 Throttling：被限流了怎麼辦🔑 Partition Key：資料的身分證 想像一座巨大的圖書館，每天有成千上萬的人來借還書。 傳統的圖書館只有一個櫃檯，所有人都要排隊等候同一個館員處理。高峰時段，隊伍排得很長，有人只是想借一本輕小說，卻要等前面的人處理完十幾本厚重的專業書籍。 聰明的館長決定改革： 把圖書館分成多個區域（Partition）：小說區、科技區、藝術區…每個區都有獨立的櫃檯 每本書都有明確的歸屬（Partition Key）：根據書的類別編號，自動知道該去哪個櫃檯 每個櫃檯都能獨立工作（分散式處理）：不會因為科技區很忙，就影響到小說區的借書速度 這就是 DynamoDB 的核心思想：不要讓所有人擠在同一個地方，把壓力分散開來，每個人都能快速得到服務。 當某個區域（partition）突然湧入大量讀者，館長不需要叫所有館員都跑去幫忙，只要在那個區域增加一個臨時櫃檯就好。這就是 Serverless 和 Auto Scaling 的概念。 但如果所有人都只想 ...

Middleware 的運作原理如何「交換 Middleware 的順序」如何「跳過」特定 Middleware（但不跳過整條）多層 Middleware 之間交換資訊ASP.NET Core 的請求流程是一條「洋蔥模型」 當一個 Request 進來，他進入 ASP.NET Core 的處理管線（Pipeline），依照註冊順序進入 Middleware，第一個 UseXXX 註冊的 Middleware 最先被執行，每個 Middleware 都「包住」後面所有的 Middleware 當你呼叫 UseMiddleware() ，Framework 會產生一個 RequestDelegate 並把「下一個 Middleware」當成 next 傳進來，而在 Middleware 執行自己的邏輯時，可以在這裡做任何事（Log、驗證、改 Header…）、決定要不要呼叫 await next(context)，若呼叫表示請求繼續往下一層走，選擇不呼叫，則流程在這一層就被「攔截」 此時 Response 從最內層往外回傳 ✅ 方法一：直接調整註冊順序在 Program.cs 或 ...

.NET DI 中的 Service Lifetime（Transient / Scoped / Singleton）為什麼「無 Request 專屬狀態」的服務通常用 Singleton？Singleton - EntityHelperTransient - RequestMessageLoggingDelegatingHandlerPromotionEngineService 為何用 ScopedScoped 存在的目的Interface 跟 DI 關聯Registering & Resolving靜態物件的問題在 .NET DI 裡，我們註冊服務時通常會用三種生命週期 生命週期 建立時機 何時被回收 常見用途 Transient 每次注入時都會 new 一個新的實例 呼叫結束後可回收 短期任務、Request 專屬狀態的物件 Scoped 每個 Request (或每個範圍) 共用同一個實例 Request 結束時回收 Web Request、需在同一 Request 內共享狀態 Singleton 第一次解析時建立一次，全程共用 應用程式結束時回收 共用服務 ...

Closure方法呼叫（傳參數）編譯器背後的轉換點擊次數 Counter事件計數器累積計算器狀態機模擬提供 RetryClosure，就像人生的記憶機制。它讓一段邏輯，不只記得「要做什麼」，也記得「曾經與誰有關」。在我們離開某個場景之後，它仍攜帶著當時的狀態、情緒與環境，就像一個攜帶回憶的函式，延續著那份未完的故事。Closure 使「lambda 可以用外部變數」，但它的本質遠不只是「抓外部變數來用」，而是一種讓函式擁有「記憶狀態」的機制 立刻執行 → 當下的值是什麼就拿什麼 123456789101112131415void Show(int n) { Console.WriteLine(n);}for (int i = 0; i < 5; i++){ Show(i); // 當下的 i 是多少就傳進去}//0//1//2//3//4 而 Lambda 並不是幫你把當下的值存起來，而是把「之後要用哪一個變數」記住，所以多個 Lambda 如果指向同一個變數，就一定會互相干擾，Lambda 的目的是「延後執行一段邏輯」，而 ...

behaviors設計核心原則：是否依賴物件狀態實例方法 : string.Substring()靜態方法 :　char.ToUpper()總結有些事，必須「由我親自完成」。像是「寄信給某個人」、「打開我家的門」、「改變自己的心情」。這些行為，都需要知道「我是誰」 ， 要有具體的對象，行為才有意義 在程式裡，這樣的行為就像 實例方法（Instance Method）。它依附在一個物件上，只有當那個物件存在（例如某個字串、某個人、某個訂單），方法才能運作，因為它需要用到那個物件的內部狀態 但有些事，誰都能做。像是「把字變成大寫」、「計算兩個數的和」、「取得目前時間」。它們不需要知道「我是誰」，只要照著規則執行，就能得到相同的結果 類型 是否依賴物件狀態 範例 設計意圖 實例方法 (Instance Method) ✅ 是 string.Substring() 方法的邏輯需要使用「該物件的資料」。 靜態方法 (Static Method) ❌ 否 char.ToUpper() 方法不依賴任何物件，只根據輸入參數運算。 因為它要「從這個字串」取出一部分，也就是它需要知道 ...

SaveChanges() 和 Transaction 的關係TransactionScope 的時間限制錯誤記錄在資料庫的世界裡，一次或多次資料修改（INSERT、UPDATE、DELETE）必須放在 交易（Transaction） 裡，這樣如果其中一步錯了，整個動作都可以 rollback 回去，確保資料不會半途修改一半 SaveChanges() 就是 EF Core 幫你「把所有變動打包起來執行」的動作。而 EF Core 為了確保這個過程的資料一致性，在執行時會自動幫你開一個 Transaction 狀況 EF Core 內部會自動開啟交易嗎？ SaveChanges() 會自動 Commit 嗎？ 備註 ✅ 你 沒有 手動開交易 ✅ 是 ✅ 是 SaveChanges() 自動包一個 transaction，執行完自動 commit ⚠️ 你 手動開了交易 (BeginTransaction()) ❌ 否（你已經開了） ❌ 否（尊重你控制的交易） SaveChanges() 只會執行 SQL，不會幫你 commit 當你呼叫 context.SaveCh ...

記憶之箱🌸 泛型與快取🔹 記憶之箱✨✨ 登入人生 online總結 我們的大腦，其實就像一個會自動學習的「快取系統」。有些經驗，一次就讓我們記得深刻；有些事情，卻需要多次重複才會留下印象。有些回憶被時間淘汰、過期了，就像舊的快取資料一樣，被默默清除；但也正因為如此，新的經驗才能被寫入，人生才不會停在原地 程式中的 泛型（Generic），讓我們能用同一套邏輯，處理不同型別的資料；人生中，我們也在學習如何用同樣的「思考模式」，面對不同的狀況。無論是人際關係、工作挑戰、或自我成長，我們都在建立一個「屬於自己的泛型快取」——那些經驗的抽象化、情緒的緩存、學習的積累，都讓我們在未來遇到類似情境時，不必從零開始 泛型不僅在計算和包裝上有用，在快取機制中也能發揮強大的作用。透過泛型快取類別，我們可以建立一個通用的快取解決方案，適用於任何型別的資料 🔹 SimpleCache1234567891011121314151617181920212223242526272829303132333435363738394041void Main(){ var cache = ne ...

靈魂與肉身想解決甚麼問題型別參數化「重複邏輯，只是型別不同」讓「資料結構或工具類別」可重複使用總結學習「靈魂，不屬於肉身；邏輯，也不該屬於型別。」 我們都知道，肉體只是外殼，靈魂才是本質。人如此，程式亦然。在軟體的世界裡，邏輯就像靈魂，它決定了一段程式「該怎麼思考」；而型別（Type）就像肉體，負責「具體地呈現」 在泛型出現以前，我們若想讓容器能「存放不同型別」的資料通常會用 object 來實作 1234567ArrayList list = new ArrayList();list.Add(123);list.Add("ABC");// 問題來了int n = (int)list[0]; // OKint m = (int)list[1]; // ❌ runtime error 這樣雖然「兼容」了所有型別，但有兩個致命缺點 你要手動轉型 (casting)，而且有風險（可能轉錯） 編譯器無法幫你檢查型別錯誤，只能等執行時爆掉 泛型 (Generics) 是一種「延後決定型別」的程式設計方法，它讓你寫出對型別沒有限制，但仍然安全可重用的 ...