Day 23：把併發控制手段實際裝進訂單服務 結尾講得很直白：Semaphore 與 withTimeout 這兩道防護都裝上了，但真正動到庫存數量本身的那個操...
Day 22：收斂進一個具名專案，訂單服務實戰整合版啟動 結尾說得很坦白：骨架能動，不代表它已經具備任何高併發防護。OrderService.getOrderD...
Day 21：小結，高併發控制的工具箱總覽，準備進實戰 把併發深化期七天累積的節流、逾時取消、背壓、連線池搭配與 k6 量測方法論收攏成一份完整的工具箱，也提前...
Day 20：實測結果解讀，協程贏在哪裡、代價又是什麼 結尾說得很直接，七天下來累積了節流、逾時取消、背壓、連線池搭配，再加上一套完整的效能量測方法論，五樣工具...
Day 19：幫協程模型量身打造一場效能比較 把該準備的都準備好了：公平比較的規則講清楚了，k6 定案為全系列壓測工具，模擬促銷流量爬升的測試情境也設計完成。昨...
Day 18：協程遇上 R2DBC 連線池，小心連線被偷偷耗盡 結尾留下一個問題：協程模型相對於 Thread-per-Request 模型，實際上能帶來多少效...
Day 17：背壓是什麼，生產太快時該怎麼踩煞車 結尾留下一個問題：背壓機制確實能避免資料無限制堆積，但消費端實際處理這些資料時，往往需要依賴某項數量有限的資源...
Day 16：逾時與取消，讓卡住的協程別拖垮整個系統 結尾留下一個問題：withTimeout 解決的是某個協程異常卡住太久的狀況，但如果問題根本不是卡住，而是...
Day 14：小結：三種技術選型的判斷依據，MVC、WebFlux 各用在哪 結尾留下一個尖銳的問題：即使底層是 WebFlux 搭配 R2DBC 這種從骨子裡...
Day 13：協程搭配訊息佇列與外部 API 呼叫的常見模式 結尾把問題攤開來了：這幾天累積的技術選型各自看起來都理解了，但實務上該根據什麼判斷依據去選擇，還沒...
Day 11：WebFlux 是什麼，協程與反應式模型的分工 停在一個尚未回答的風險上：即使應用程式用 WebFlux 搭配協程，整條請求處理鏈路理論上可以是非...
在上一篇文章 Day 10：在 Spring MVC 裡寫 suspend function，能動但有代價 最後留下一個問題：如果限制的源頭是底層容器骨架，有沒...
Day 09：小結：四個核心觀念如何在一次請求中協同運作 結尾留下一個還沒正面回答的問題：協程終究要活在一個真實的 Spring Boot 應用程式裡，它要接...
Day 08：Coroutine Context 與例外處理，協程出錯了誰負責 結尾把 Coroutine Scope、Structured Concurren...
《Day 07：Dispatchers，協程實際跑在哪條執行緒上》 結尾留下一個問題：Dispatcher 其實只是協程隨身攜帶的其中一項設定，那協程執行時還帶...
Day 06：Structured Concurrency，為什麼協程不能亂長亂放 結尾留下一個問題：確立了協程之間誰該對誰負責之後，這些協程實際上到底是在哪一...
Day 05：Coroutine Scope，協程住在哪裡、活多久 結尾留下一個問題：同一個 Scope 裡如果同時養著好幾個協程，其中一個先執行完，或者其中一...
《Day 04：小結：把 Thread 模型與協程模型放在一起比一次》 結尾留下一個疑問：訂單查詢與扣庫存服務裡，有些步驟適合同時發起，一旦一個請求裡需要同時或...
《Day 03：第一個 suspend function，協程到底暫停了什麼》結尾留下一個疑問：一個函式暫停了，那一整串呼叫呢。今天先不回答這個疑問，而是往回看...
《Day 02：Thread-per-Request 模型的極限，搞懂你原本在用什麼》 結尾停在一個問句上：如果執行緒能在等待的時候先被借走，去處理別的請求，等...
《Day 01：為什麼高併發後端需要協程，從一個會卡住的 API 說起》結尾留下一個看似簡單卻很少人真正答得出來的問題：你的 Spring Boot 應用程式收...
昨天我們深入剖析了 Timeout 設定與容量規劃的數學公式，證明了盲目放寬 Timeout 只會讓連線池乾涸。 今天，我們要將壓力測試的視角從PUT上傳轉向l...
昨天在 Day 00 的地圖裡，我們先按下不表那個會卡住的 API，只留下一句預告：今天要把它攤開來看清楚，它到底卡在哪裡。現在就從這個畫面開始。 開場，一個會...
如果你是一個習慣寫 Java 後端的工程師，大概對這個畫面不陌生。系統上線初期流量還小，每個 API 都反應飛快，Controller 收到請求，Service...
昨天我們成功在 JMeter 上傳併發測試中，證明了前面寫的保護api的功能將 3 秒超時引發的錯誤率從 53% 降至 0%，並透過 Grafana 發現真正的...
我們從一開始的三高指標與同步/非同步引擎對決，一路升級到分散式環境下的防禦機制（Semaphore 背壓限流、Double-Check 、uploadId 冪等...
在前幾天的文章中，我們在微服務中建構了多道盾牌，從透過headObject 探針解決網路超時問題的 Double-Check Pattern，實作 Idempo...
昨天我們完成了 Double-Check Pattern 的實作，當 putObject 發生 timeout 時，後端不再直接回傳失敗，而是使用 headOb...
在前兩篇中，我們在本地開發環境裡，利用了 simulateScenario 在代碼內部模擬超時，驗證了自我修復確實可以起死回生，手把手完成了微服務的三層防禦盾牌...
昨天我們說明了網路世界最殘酷的一面。當微服務呼叫 AWS S3 上傳檔案時，如果發生 TimeoutException時不能直接斷言上傳一定失敗，也有可能是上傳...
ReccaChao
emmmma
iThome鐵人賽
看影片追技術