博客 / 列表

南城 - 從日誌到檢索的一站式方案——採集、清洗、入庫與可視化的組件協同關係圖

寫在前面，本人目前處於求職中，如有合適內推崗位，請加：lpshiyue 感謝。同時還望大家一鍵三連，賺點奶粉錢。 構建高效的日誌系統不是簡單堆砌組件，而是讓數據流在採集、緩衝、處理、存儲和可視化各環節無縫協同的藝術 在深入掌握Elasticsearch的分片、副本與聚合性能調優後，我們面臨一個更宏觀的挑戰：如何將這些單點技術整合成完整的日誌處理體系。本文將透過組件協同關係圖的視角，揭示從日誌產生到

elasticsearch

南城 - ES性能與可用性——分片、副本、路由與聚合的調度邏輯與成本

寫在前面，本人目前處於求職中，如有合適內推崗位，請加：lpshiyue 感謝。同時還望大家一鍵三連，賺點奶粉錢。 掌握Elasticsearch集羣調優的本質，是在數據分佈、冗餘備份與查詢效率之間找到最佳平衡點 在深入理解Elasticsearch的倒排索引、映射與分詞核心原理後，我們面臨下一個關鍵問題：如何讓這些單機能力在分佈式環境下協同工作，實現高性能與高可用性的統一。本文將聚焦分片策略、副本

elasticsearch

南城 - 重試、死信與補償策略——失敗處置流水線的設計，防雪崩的節流思路

寫在前面，本人目前處於求職中，如有合適內推崗位，請加：lpshiyue 感謝 構建彈性消息系統的核心不是避免失敗，而是優雅地處理失敗 在分佈式系統架構中，消息隊列承擔着解耦、削峯和異步處理的重要職責。然而，網絡波動、服務宕機、消息格式錯誤等異常情況難以完全避免。本文將從實踐角度出發，深入探討如何構建一套完整的失敗處置流水線，確保系統在面臨各種異常時仍能保持穩定可靠。 1 重試機制：失敗處理的第一道

隊列

南城 - 可靠性與順序性保障——冪等、事務與Exactly-once語義的適用邊界

寫在前面，本人目前處於求職中，如有合適內推崗位，請加：lpshiyue 感謝 在分佈式消息系統中，可靠性追求與性能代價總是相伴相生，理解不同保障機制的適用邊界是構建健壯系統的關鍵 在掌握 Kafka 核心概念的基礎上，我們面臨一個更深入的問題：如何在不同業務場景下選擇合適的可靠性保障機制。消息系統的可靠性不是一個非黑即白的選擇，而是一個需要權衡的連續譜系。本文將深入探討 Kafka 提供的三種消息

觀點 , 微服務

南城 - Kafka入門必知概念——Topic、分區、Offset、消費組的協作機制與影響

寫在前面，本人目前處於求職中，如有合適內推崗位，請加：lpshiyue 感謝 理解Kafka的核心概念如同掌握分佈式系統的通用語言，這些基礎組件的高效協作正是Kafka海量數據處理能力的源泉 在消息隊列選型框架中，Kafka以其高吞吐、可擴展架構成為大數據場景的首選。然而，要真正發揮Kafka的潛力，必須深入理解其核心概念之間的協作關係。本文將全面解析Topic、分區、Offset和消費組四大核心

kafka

南城 - 熱點 Key 與大 Key 治理——識別、拆分、預熱與降級的多手段組合策略

在 Redis 的運維實踐中，熱點 Key 與大 Key 如同系統中最隱蔽的性能陷阱，需要系統化的治理策略而非零散的解決方案 在高併發系統架構中，緩存承擔着流量緩衝與加速的核心職責。然而，熱點 Key（Hot Key）與大 Key（Big Key）問題如同緩存系統中的"隱形殺手"，隨時可能引發系統性能雪崩。本文將深入探討熱點 Key 與大 Key 的系統化治理方案，從識別、拆分到預熱與降級的全鏈路

redis

南城 - 延遲隊列的實現範式——ZSet與Stream方案對比、時間輪思想與使用邊界

寫在前面，本人目前處於求職中，如有合適內推崗位，請加微信：lpshiyue 感謝 在異步任務調度與時間觸發機制中，延遲隊列是平衡精度、可靠性與複雜度的藝術 在分佈式鎖與冪等性解決數據安全寫入的挑戰後，我們面臨另一個關鍵問題：如何可靠地調度未來事件。延遲隊列作為異步任務調度的核心組件，在訂單超時、定時提醒等場景中扮演着重要角色。本文將深入解析 Redis ZSet 與 Stream 兩種主流延遲隊列

redis , JAVA

南城 - 分佈式鎖與冪等的邊界——正確的鎖語義、過期與續約、業務層冪等配合

分佈式鎖管控併發時序，冪等性保障操作結果——二者協同而非替代，是構建可靠分佈式系統的關鍵 在多級緩存解決數據讀取性能瓶頸後，我們面臨另一個核心挑戰：如何在分佈式環境下保證數據寫入的安全性與一致性。分佈式鎖與冪等性作為分佈式系統中兩個常被混淆的概念，它們各自有着明確的職責邊界和適用場景。本文將深入探討分佈式鎖的正確語義、鎖過期與續約機制，以及如何與業務層冪等性協同工作，構建完整的數據安全防護體系。

redis

南城 - 多級緩存設計思路——本地 + 遠程的一致性策略、失效風暴與旁路緩存的取捨

在多級緩存的世界裏，性能與一致性從來不是朋友，而是一對需要精心調和的冤家 在高併發系統架構中，緩存是提升性能的利器，但單一緩存層往往難以兼顧極致性能與數據一致性。多級緩存通過分層設計，將數據冗餘存儲在距離應用不同層次的存儲介質中，實現了性能與成本的最佳平衡。本文將深入探討本地緩存與遠程緩存的協同策略，分析數據一致性保障機制，並提供應對緩存失效風暴的實用方案。 1 多級緩存架構的本質與價值 1.1

架構設計

南城 - 高可用架構速覽——主從、哨兵與 Cluster 的角色分工與故障轉移路徑

從數據備份到故障自動恢復，再到無限水平擴展，Redis 高可用架構的演進之路 在單機 Redis 面臨性能瓶頸和單點故障的風險下，構建高可用架構成為保障業務連續性的關鍵。本文將深入解析 Redis 的三種高可用架構方案——主從複製、哨兵模式和 Cluster 集羣，揭示它們各自的設計哲學、適用場景及故障轉移機制，幫助您在業務發展不同階段做出正確的技術選型。 1 高可用架構演進之路 1.1 高可用的

redis

南城 - 持久化與內存管理策略——RDB/AOF、淘汰策略與容量規劃的決策要點

Redis 的性能與可靠性平衡藝術，在於對持久化機制與內存管理的精準把控 在掌握 Redis 數據結構與業務場景映射後，我們面臨一個核心問題：如何保證內存數據的可靠性和管理有限內存資源。Redis 作為內存數據庫，其持久化策略和內存管理機制直接影響數據安全性和服務穩定性。本文將深入探討 RDB 與 AOF 持久化機制、內存淘汰策略以及容量規劃的關鍵決策點，幫助構建高可用的 Redis 架構。 1

redis

南城 - Redis 數據結構與典型業務映射——五大結構與 Bitmap/HyperLogLog 的適配場景地圖

在 Redis 的武器庫中，選擇合適的數據結構比優化算法更能直接提升系統性能，這是一場數據模型與業務場景的精準匹配遊戲 在分庫分表解決數據規模問題後，我們面臨一個新的挑戰：如何在高併發場景下實現極致性能。Redis 作為高性能內存數據存儲，其價值不僅在於速度快，更在於提供了豐富的數據結構，這些數據結構與業務場景的精準映射是構建高效系統的關鍵。本文將深入探討 Redis 各種數據結構的特點及其與典型

redis , JAVA

南城 - 分庫分表的門檻與代價——分片鍵、跨分片查詢與全鏈路一致性的挑戰清單

分庫分表不是性能銀彈，而是用架構複雜性換取擴展能力的艱難權衡 在數據量持續增長的現代系統中，分庫分表從可選項逐漸變為必選項。這一架構變革遠非簡單的數據分佈調整，而是涉及數據訪問路徑重構、事務邊界重新定義及一致性模型重塑的系統性工程。本文將全面剖析分庫分表的真實門檻與隱藏代價，為架構決策提供清晰的風險清單。 1 分庫分表：何時躍入的決策框架 分庫分表本質是通過數據分佈來突破單機存儲與性能極限，但這一

JAVA

南城 - 多數據源與讀寫分離的複雜度來源——路由、一致性與回放策略的思考框架

在多數據源架構中，技術的複雜度從單一的技術實現轉向了系統的協同治理，每一個決策都成為了權衡的藝術 在現代分佈式系統架構中，隨着業務規模不斷擴大，單一數據源已無法滿足高併發、高可用的需求。多數據源與讀寫分離架構通過數據分片、負載均衡等技術大幅提升系統處理能力，但同時也引入了路由複雜性、數據一致性挑戰和回放機制難度等新的複雜度來源。本文將深入剖析這些複雜度的根源，並提供系統的思考框架和應對策略。 1

數據庫 , JAVA

南城 - JPA/Hibernate 選擇指南——實體關係維護、懶加載與 N+1 問題的權衡

在面向對象與關係數據庫的鴻溝之間，JPA 與 Hibernate 提供了不同的過渡方案，而正確的選擇始於對數據訪問模式的深刻理解 在持久層架構設計中，JPA 與 Hibernate 的選擇遠非簡單的技術選型，而是對應用數據訪問模式、團隊技能棧和性能要求的綜合考量。本文將深入探討 JPA 與 Hibernate 的適用場景，分析實體關係維護的最佳實踐，並提供解決懶加載與 N+1 問題的完整方案。 1

JAVA

南城 - MyBatis 進階治理點——緩存、副作用、攔截與批處理的得失分析

深入 MyBatis 內核，在性能提升與數據一致性之間尋找精妙平衡 在掌握 MyBatis 基礎映射與動態 SQL 後，進階治理成為保證生產環境穩定性與性能的關鍵。本文將深入分析緩存機制、副作用控制、攔截器應用與批處理優化等高級主題，幫助開發者構建高可用、易維護的數據訪問層。 1 緩存機制深度治理 1.1 二級緩存的一致性挑戰 MyBatis 的二級緩存基於 Mapper 命名空間設計，多個 Sq

MySQL , JAVA

南城 - 從一個開發工程師的角度，聊聊“什麼是 K 線”

先把話挑明：K 線不是“畫出來”的，而是“算出來”的。它是對一段時間內價格與成交的壓縮表示：Open、High、Low、Close、Volume（常加 Turnover、交易筆數），按某種“窗口”聚合而成。聽起來像個普通的聚合任務，但真要把它在交易系統裏做穩、做快、做準，會踩很多坑。 K 線到底指什麼 時間維度：常見有 1s、1m、5m、15m、1h、日/周/月 K。不是自然時間，而是“交易所

JAVA

南城 - MyBatis 設計觀——映射思想、動態 SQL 的邊界與可維護性考量

在對象與關係的鴻溝之間，MyBatis 選擇了一條獨特的橋樑建設之路——不強求完全自動化，而是將控制權交還給開發者 在持久層框架的設計哲學中，MyBatis 採取了與全自動 ORM 框架截然不同的路徑。它不試圖完全隱藏數據庫細節，而是通過優雅的映射機制和動態 SQL 能力，在對象模型與關係模型之間建立了可控的轉換通道。本文將深入剖析 MyBatis 的核心設計思想，探討動態 SQL 的適用邊界，並

MySQL , JAVA

南城 - 連接池的價值與風險——池化提升與資源枯竭的雙刃劍，關鍵指標如何解讀

連接池是現代應用架構中的基礎設施，用好了是性能加速器，配置不當則成為系統崩潰的導火索 在數據庫應用系統中，連接管理是影響性能的關鍵因素之一。數據庫連接池通過池化技術將昂貴的數據庫連接進行復用，顯著提升了系統性能，但不當的配置和使用也會導致資源枯竭甚至系統崩潰。本文將深入探討連接池的工作機制、優化策略以及風險防範，幫助開發者掌握這一強大而危險的工具。 1 連接池的本質與演進歷程 1.1 連接池解決的

JAVA

南城 - SQL 性能的三要素——索引、執行計劃與數據分佈的協同影響

優秀的 SQL 性能不取決於單一組件的優化，而是索引設計、執行計劃選擇與數據分佈感知三者協同的結果 在數據庫系統中，SQL 查詢性能是衡量應用健康度的關鍵指標。許多開發者將性能優化簡單歸結為"添加索引"，但實際上，高效的查詢是索引策略、執行計劃優化和數據分佈理解三者協同作用的結果。本文將深入探討這三要素的相互作用機制，幫助您構建系統化的 SQL 性能優化思維。 1 SQL 執行的生命週期與性能瓶頸

MySQL

南城 - 撮合系統是什麼？把"買賣雙方配對成成交"的那台發動機到底做了什麼

前言 寫這篇文章的出發點很簡單：把"撮合系統（Matching Engine）"這件事講清楚，讓不熟交易所內部的人也能讀得懂。我做過撮合相關的開發和優化，下面用工程視角把它的職責、核心規則、常見實現思路和工程難點講明白，儘量用生活化的例子和實際場景來説明，方便直接拿去公眾號發佈。 一、一句話定義 撮合系統就是把市場上買單和賣單按照規則配對併產生成交記錄的核心引擎。它決定了誰以什麼價、什麼量成交，並

JAVA

南城 - 關係建模的底層邏輯——範式與反範式的收益成本對照，主鍵與外鍵的實踐取捨

良好的關係數據庫設計是在數據一致性、查詢性能和維護成本之間尋找精密平衡的藝術 在軟件系統架構中，數據模型設計是系統基石，直接影響着應用的性能、可擴展性和可維護性。本文將深入探討數據庫關係建模的核心問題——範式與反範式的權衡決策，以及主鍵與外鍵的實踐應用，幫助開發者在數據庫設計時做出更明智的架構選擇。 1 關係數據庫設計基礎 1.1 關係模型的核心概念 關係數據庫模型由 E.F. Codd 在 19

JAVA