博客 / 列表

poemyang - 流量洪峯下的交通指揮家：詳解負載均衡與限流實戰

負載均衡：聰明的交通指揮家 如果説水平擴容是為系統增加了更多的“工作車道”，那麼負載均衡就是站在車道入口處的交通指揮家。它的存在，是為了回答一個根本性問題：當成千上萬的請求同時涌來時，如何將它們高效、公平且智能地引導至後端的服務集羣，從而避免任何一條“車道”因擁堵而癱瘓？ 負載均衡的本質，是將單一的、巨大的訪問壓力，分解為多個可管理的、微小的壓力。負載均衡不僅需要在用户請求和Web服務

軟件設計

poemyang - 流量洪峯衝不垮的秘密：揭秘系統過載保護的核心防線

系統流量如潮汐般漲落，瞬時的洪峯可能將最堅固的系統沖垮。如何確保核心服務在極限壓力下依然穩如磐石？答案在於構建一套分層協同、動態彈性的過載保護機制。這並非單一技術的堆砌，而是一門融匯了預判、隔離、調度與自愈的系統工程藝術。 本文將深入剖析這套多層防護體系的構建之道：從最外層的流量調度（負載均衡），到精細化的請求管控（限流），再到保障核心業務的“丟車保帥”策略（降級與熔斷），最終邁向智能化的自

軟件設計

poemyang - 化整為零、分而治之、異步編排：一文讀懂現代併發的底層心法

LongAdder：化整為零，熱點分散 在Java多線程編程中，‌原子變量（如AtomicLong）‌通過CAS操作實現線程安全的累加。然而，在高併發場景下，大量線程爭搶同一原子變量會引發嚴重的‌緩存一致性問題‌。 ‌ 1）緩存行偽共享‌：多個線程頻繁更新同一緩存行，導致緩存失效和MESI協議頻繁觸發，處理器性能急劇下降。 ‌ 2）CAS衝突開銷‌：CAS操作需自旋重試，線程競爭

軟件設計

poemyang - 深入解析 Disruptor：從RingBuffer到緩存行填充的底層魔法

Disruptor，這一由英國金融巨頭LMAX匠心打造的高性能併發框架，自誕生之初便肩負着在處理生產者-消費者問題時，追求極致吞吐量與超低延遲的使命。令人矚目的是，LMAX公司憑藉Disruptor框架，成功將訂單處理速度飆升至每秒600萬次交易（Transactions Per Second，TPS）的驚人水平，這一成就無疑彰顯了Disruptor在併發處理領域的非凡實力。 然而，Disr

軟件設計

poemyang - 併發編程的三大基石：從底層邏輯聊透“同步、互斥與分工”

當單核性能的狂飆突進時代緩緩落幕，多核架構已成為算力增長的主旋律。然而，更多的核心並不天然等同於更強的性能。這就像將一條單行道拓寬為多車道高速公路，如果缺乏高效的交通調度系統，車輛（線程）間的搶道與擁堵（鎖競爭）反而會造成更嚴重的癱瘓。 Java，作為企業級應用的中流砥柱，其併發設計的智慧恰在於此：它提供的不僅是一系列工具，更是一種從“暴力爭搶”到“精巧協同”的思維躍遷。 本文將穿越這

軟件設計

poemyang - 像Git一樣管理數據：深入解析數據庫併發控制MVCC的實現

MVCC 多版本併發控制（Multi-version Concurrency Control， MVCC）是一種通過維護數據多個版本來實現併發控制的技術。其基本思想是為每次事務生成一個新版本的數據，在讀數據時選擇不同版本的數據即可以實現對事務結果的完整性讀取。在使用MVCC 時，每個事務都是基於一個已生效的基礎版本進行更新，事務可以並行進行，從而可以產生一種圖狀結構。 如圖所示，基礎

軟件設計

poemyang - 守護“真相之源”：深入理解數據庫的預寫日誌(WAL)與檢查點技術

如果説緩存和消息中間件處理的是流量的“流動”問題，那麼數據庫系統要解決的，則是數據的“存在”問題——即數據的最終正確性與持久性。它是整個系統的“真相之源”（Source of Truth）。 日誌技術 在考慮數據庫系統的持久性時，關鍵的考慮因素是如何在數據庫中實現數據的持久化。例如，在關係型數據庫中，數據被存儲在表中，而這些表是通過在文件系統或塊系統中的數據結構來實現的。如何保存和維護這些文

軟件設計

poemyang - 從硬盤I/O到網絡傳輸：Kafka與RocketMQ讀寫模型及零拷貝技術深度對比

消息寫讀 在Kafka的數據存儲架構中，一個主題由一個或多個分區組成。在物理存儲上，每個主題-分區都對應着硬盤上的一個獨立目錄，而消息數據則以日誌段文件（Log Segment）的形式存儲在這些目錄中。隨着數據的不斷寫入，當一個日誌段文件達到預設的大小（例如1GB）或時間閾值時，它會被關閉並變為只讀，同時一個新的可寫日誌段文件會被創建。這個過程稱為日誌滾動（Log Rolling）。

架構設計

poemyang - 從局部性原理到一致性模型：深入剖析緩存設計的核心權衡

緩存：高速存取數據的前哨站 緩存的根本思想，源於一個在計算機科學中被反覆驗證的黃金法則——局部性原理（Principle of Locality）。該原理包含兩個層面： 1）時間局部性（Temporal Locality）：如果一個數據項被訪問，那麼在不久的將來，它極有可能被再次訪問。例如，一篇熱門新聞的詳情頁、一個爆款商品的庫存信息。 2）空間局部性（Spatial Local

軟件設計

poemyang - “不要通過共享內存來通信”——深入理解Golang併發模型與CSP理論

Golang 在設計上另闢蹊徑，其併發哲學的核心信條是：“不要通過共享內存來通信，而要通過通信來共享內存。” (Do not communicate by sharing memory; instead, share memory by communicating.) 這一理念源自通信順序進程（Communicating Sequential Processes, CSP）理論。 共享消息模型

軟件設計

poemyang - Goroutine間的“靈魂管道”：Channel如何實現數據同步與因果傳遞？

Channel是連接Goroutine的“管道”，是CSP理念在Golang中的具象化實現。它不僅是數據傳遞的隊列，更是Goroutine間同步的天然工具，讓開發者無需訴諸顯式的鎖或條件變量。 func main() { ch := make(chan int, 1) // 創建一個int，緩衝區大小為1的Channel ch - 2 // 將2發送到ch

軟件設計

poemyang - “一切皆文件”：揭秘LINUX I/O與虛擬內存的底層設計哲學

RPC框架如同構建服務大廈的神經網絡，承擔着海量服務間通信的重任。它優雅地屏蔽了底層網絡通信的複雜性，使開發者能聚焦於業務邏輯的創造。然而，在這份優雅之下，RPC框架的網絡模型設計卻是決定系統吞吐量、延遲和資源利用率的命脈，其核心在於在有限的硬件資源與無限的數據洪流之間，建立一座高效、動態的橋樑。 當每秒數以萬計的請求涌入時，如何在有限的硬件上實現近乎無損的調度？事件驅動機制如何以“四兩撥千

軟件設計

poemyang - 你的程序為何卡頓？從LINUX I/O三大模式尋找答案

I/O交互流程 在LINUX中，內核空間和用户空間都位於虛擬內存中。LINUX採用兩級保護機制：0級供內核使用，3級供用户程序使用。每個進程都有獨立的用户空間（0~3G），對其他進程不可見，而最高的1G虛擬內核空間則由所有進程和內核共享。 操作系統和驅動程序運行在內核空間，應用程序運行在用户空間。由於LINUX使用虛擬內存機制，兩者之間不能直接通過指針傳遞數據。用户空間必須通過系統調用

軟件設計

poemyang - 單線程如何撐起百萬連接？I/O多路複用：現代網絡架構的基石

I/O多路複用（I/O Multiplexing）是一種允許單個線程同時監視多個文件描述符的I/O模型。其核心價值在於，它將應用程序從低效的I/O等待中解放出來，實現了“一次等待，響應多個事件”的高效併發模式。 要理解其優勢，需要對比非阻塞I/O的侷限性。雖然非阻塞I/O能避免線程在數據未就緒時阻塞，但它要求應用程序通過循環不斷地主動輪詢所有文件描述符，這會造成大量的處理器空轉，浪費計算資源

軟件設計

poemyang - 從C10K到Reactor：事件驅動，如何重塑高併發服務器的網絡架構

事件驅動 事件驅動（Event Driven）是一種核心的編程範式，其根本特徵是控制反轉（Inversion of Control，IoC）。在這種模型中，程序的執行流不再由代碼的順序調用決定，而是由一系列異步發生的事件來驅動。應用程序的角色從主動輪詢或等待，轉變為被動地對事件做出響應，這構成了現代高性能系統的基礎。 一個完整的事件驅動架構由四個基本部分組成，它們協同工作，構成了高效的

軟件設計

poemyang - 職責分離的藝術：剖析主從Reactor模型如何實現極致的併發性能

Reactor單線程模型 在Reactor單線程模型中，所謂的“單線程”主要針對I/O操作而言，即所有的I/O操作（如accept()、read()、write()和connect()）都在同一個線程上完成。然而，在當前的單線程Reactor模型中，不僅I/O操作由Reactor線程處理，非I/O的業務邏輯操作也在該線程上執行。這種設計可能導致I/O請求的響應被顯著延遲，因為耗時的業務邏輯會

軟件設計

poemyang - “化零為整”的智慧：內存池如何繞過系統調用和GC，構建性能的護城河

內存池：精打細算的內存管家 在高性能系統（如網絡服務器）的極致優化中，當處理器和I/O的瓶頸被逐一攻克後，內存管理便成為決定系統延遲和吞吐量的最後一道，也是最關鍵的一道關隘。傳統的內存分配方式在這種場景下顯得力不從心，催生了通過內存池（Memory Pool）作為管理策略。 在C/C++或Java等語言中，依賴系統默認的內存分配機制（如malloc或new）在高併發場景下會引發一系列性

軟件設計

poemyang - jemalloc思想的極致演繹：深度解構Netty內存池的精妙設計與實現

內存分配 Netty內存池的核心設計借鑑了jemalloc的設計思想。jemalloc是由Jason Evans在FreeBSD項目中實現的高性能內存分配器，其核心優勢在於通過細粒度內存塊劃分與多層級緩存機制，降低內存碎片率並優化高併發場景下的內存分配吞吐量。 Netty基於jemalloc的多Arena架構實現內存池化，每個運行實例維護固定數量的內存分配域（Arena），默認數量與處

軟件設計

poemyang - 為什麼Java/Python程序無需關心內存釋放？揭秘垃圾回收（GC）的核心概念

在Java的編程世界裏，開發者既無需也無法像C/C++那樣手動調用malloc/free來管理內存的分配與回收，這一核心任務完全由Java虛擬機在幕後自動完成。這種自動化設計極大地簡化了編碼，將開發者從繁瑣且極易出錯的內存管理中解放出來。然而，這種便利性的背後隱藏着一個經典且複雜的難題：一個動態運行的程序，其對象創建和消亡的模式千變萬化，Java虛擬機如何高效地追蹤這些對象的生命週期，在正確的時間

軟件設計

poemyang - 壓縮指針：64位系統下，Java虛擬機是如何“偷”回4字節內存的？

Java對象：在內存中的真面目 在Java中，通過new關鍵字創建一個Java類的實例對象時，該對象會通過碰撞指針方式存儲在內存的堆中，並被分配一個內存地址。在Java虛擬機中，一個Java對象由對象頭（Object Header）、實例數據（Instance Data）和對齊填充（Padding）三部分構成。 對象頭 對象頭由兩個字（計算機術語，表示計算機處理數據的最小單位）

軟件設計

poemyang - 誰生？誰死？從引用計數到可達性分析，洞悉GC的決策邏輯

引用計數與可達性分析：誰死了，誰還活着？ 垃圾回收，顧名思義，便是將已經分配出去的，但卻不再使用的內存回收回來，以便能夠再次分配。在Java虛擬機的語境下，垃圾指的是死亡的對象所佔據的堆空間。這裏便涉及了一個關鍵的問題：如何辨別一個對象是存是亡？ 引用計數 引用計數（Reference Counting）是一種古老的辨別方法，它的基本思想是給每個對象添加一個引用計數器，每當有一個引用指

軟件設計

poemyang - 為什麼我的應用會卡頓？垃圾回收中的STW難題與破解之道

垃圾回收算法：清除、壓縮、複製 可達性分析提供了一種有效的方式，來標記哪些對象死亡，哪些對象還存活。然而，確定哪些對象死亡可以被回收，只是垃圾回收的第一步， 這個過程通常被稱為標記（Mark）。接下來，需要一種方法來回收這些死亡對象佔用的內存，以便這些內存可以被重新使用。這就是垃圾回收算法的任務。 垃圾回收算法描述瞭如何有效地回收垃圾對象的內存，同時儘量減少對程序執行的影響。 清除

軟件設計

poemyang - 不止新生代與老年代：深入Java虛擬機堆內存佈局與TLAB、卡表等優化機制

Java虛擬機運行數據區域 在JDK 8及以上版本中，Java虛擬機運行時數據區域主要包括以下部分： 1）堆（Heap）：這是Java虛擬機中最大的內存區域，所有線程共享，主要用於存放對象實例和數組。這也是垃圾回收的主要區域，因此也被稱作GC堆（Garbage Collection Heap）。 2）方法區（Method Area）：在JDK 8之前，這被稱為永久代（PermGe

軟件設計

poemyang - 吞吐量、延遲、內存：深入理解垃圾回收的“三元悖論”

垃圾回收算法的評價標準：吞吐量、延遲、內存，孰輕孰重？ 評估和選擇垃圾回收器時，不存在一體通用的最優解。不同的應用場景對性能的要求截然不同，因此需要通過一套標準化的指標來衡量垃圾回收算法的特性。通常，關注三個主要的、且相互制約的評價指標：吞吐量（Throughput）、最大暫停時間（Max Pause Time / Latency）以及堆使用效率（Heap Usage Efficiency）

軟件設計