tag 限流

標籤
貢獻22
90
11:14 AM · Nov 03 ,2025

@限流 / 博客 RSS 訂閱

卷福同學 - 分佈式系統架構5:限流設計模式

分佈式系統架構5:限流設計模式 這是小卷對分佈式系統架構學習的第5篇文章,今天來學習限流器和限流設計模式 1.為什麼要限流? 任何一個系統的運算、存儲、網絡資源都不是無限的,當系統資源不足以支撐外部超過預期的突發流量時,就應該要有取捨,建立面對超額流量自我保護的機制,而這個機制就是微服務中常説的“限流” 2.四種限流設計模式 説到限流,大家直接的想法就是Sentinel,但是Sentinel限流的

限流 , 設計模式 , 分佈式系統 , JAVA , 分佈式

收藏 評論

lenglingx - Guava之RateLimiter

RateLimiter概述 RateLimiter是Guava提供的的限流器。它基於令牌桶算法實現,預先設定一個速率,然後按照這個速率生成令牌,每次請求消耗一個令牌。限流是保護高併發系統的三把利器之一,另外兩個是緩存和降級,在秒殺搶購等場景中用來限制併發和請求量,保護自身系統和下游系統不被巨型流量沖垮。 核心原理 RateLimiter的核心是"令牌桶算法"。想

限流 , System , 後端開發 , JAVA

收藏 評論

Java烘焙師 - 架構師必備:限流方案選型(使用篇)

大家好,我是Java烘焙師。為了避免突增流量引起服務雪崩,需要對接口、存儲資源做限流保護,根據系統負載情況設置合適的限流值。下面結合筆者的經驗和思考,對主要限流方案的選型做一下總結,本篇先看如何使用,下一篇再看背後的原理。 下面介紹幾種常見限流方案的使用方法、優缺點: 單機限流:Guava RateLimiter 同時支持單機限流、集羣限流:Sentinel 分佈式限流:Redisson

redis , 限流 , sentinel , 架構 , 分佈式

收藏 評論

今夜有點兒涼 - 高併發問題解決方案

高併發問題是指系統需要處理大量用户請求或大量併發操作時所面臨的挑戰,通常表現為請求量大、處理時間長、響應速度慢、資源耗盡等問題。為了應對高併發場景,系統需要設計成能夠高效地處理併發請求,並確保系統的穩定性和可擴展性。以下是一些常見的解決高併發問題的方法和技術: 1. 負載均衡 目的:分擔單個服務器的壓力,提高系統處理能力。 實現方式: 應用層負載均衡:使用負載均衡器(如 N

限流 , 微服務 , 異步處理 , 負載均衡 , 緩存

收藏 評論

jian - Sentinel進化指南:dashbaord改造,集羣流控,監控持久化

前言 我們的項目為了方便移植,所以選擇了阿里雲來進行部署,脱離的公司自己的技術能力平台。項目中使用sentinel做 限流,單原本的sentinel只有基於的內存存儲的單機限流攻擊,無法滿足線上軟件的要求。我們需要在sentinel的基礎上,改造dashboard完成如下能力。 接入Sentinel-Dashboard提供更靈活的限流配置管理和更直觀的查看系統資源的入口。 接入nacos 提

限流 , sentinel , 源碼分析 , springboot

收藏 評論

龐然大悟 - 限流與熔斷機制:ngx_http_limit_conn/limit_req 模塊實現與自適應策略

在高併發場景下,限流與熔斷是保障服務穩定性的核心手段。NGINX 作為流量入口,通過 ngx_http_limit_conn 和 ngx_http_limit_req 模塊可快速實現基礎限流能力,而結合自適應策略則能進一步提升機制的靈活性與適配性。本文將拆解兩大核心模塊的實現邏輯、配置要點,並探討自適應限流熔斷策略的設計思路,為高可用服務架構提供可落地的流量管控方案。 一、

自適應 , 限流 , 服務器 , Nginx , 後端服務

收藏 評論

colddawn - 業務服務網關

  一般來説,API網關有四大職能: 請求接入:作為所有API接口服務請求的接入點,管理所有的接入請求 業務聚合:作為所有後端業務服務的聚合點,所有業務服務都可以在這裏被調用 中介策略:實現安全、驗證、路由、過濾、流控、緩存等策略,進行一些必要的中介處理 統一管理:提供配置管理工具,對所有API服務的調用生命週期和相應的中介策略進行統一管理

業務服務網關 , 限流 , lua , 雲計算 , 雲原生 , 可維護性

收藏 評論

u_13778063 - 一步到位!阿里云云原生 API 網關,助力 Nginx Ingress 用户實現高效、安全遷移

作者:澄潭 編者按: Ingress NGINX 退役引發開發者們的強烈關注,《遺憾,Ingress NGINX 要退役了》。 官方已經提供了完備的應對措施,遷移到 Gateway API,以及20+ Ingress 控制器。但實施遷移的時候,企業還會希望瞭解新的 Ingress 控制器是否兼容 Ingress NGINX 的註解,遷移過程中如何進行灰度切

限流 , 雲計算 , API , 雲服務 , Nginx

收藏 評論

u_15714439 - 寶劍鋒從磨礪出——零售數據庫內核,為大促鑄劍!

癸卯七月風雨大作 京東零售·袁博文 僵卧雙九不自哀,尚思為東戍輪台。 夜闌卧聽珊瑚雨,鐵馬內核入夢來。 前言略長,只關心技術的同學可直接跳過看第二章 一、前言:技術的底色是什麼? 這個問題在技術人心中其實沒有標準答案,每個人都有每個人的見解。架構師眼裏大抵是高屋建瓴,統領全局;技術大牛的視角可能是剖根溯源,精刀

軟件研發 , 限流 , 數據庫 , SQL

收藏 評論

SarPro - 【C++11算法設計】限流器設計之固定窗口計數法

前言 在高併發系統或接口服務中,頻繁的請求可能導致系統資源被快速耗盡,甚至造成服務不可用。為了保證系統的穩定性和響應能力,我們需要對接口調用進行限流,即控制單位時間內的最大請求次數。 本文將以 C++ 實現的限流器為例,講解如何通過固定窗口計數法來實現高精度、易維護的限流機制。 核心目標 控制調用頻率:每單位時間

sed , 限流 , 限流器 , 算法 , c++ , Css , 前端開發 , HTML

收藏 評論

Java烘焙師 - 架構師必備:限流方案選型(原理篇)

大家好,我是Java烘焙師。上一篇文章介紹了限流方案的使用和選型,本文接着講限流算法的原理。 常見的限流算法有:令牌桶、窗口計數、漏桶,前兩種在實際使用中最常見,因此重點介紹。限流算法是通用的,既可以在單機上實現,也可以藉助redis來實現分佈式限流。 首先,定義一下限流算法需實現的基本功能: tryAquire嘗試獲取通行許可:立刻返回結果,true代表允許、false代表被限流 a

限流 , 算法 , 架構

收藏 評論

mob64ca14101b2f - Spring-cloud微服務實戰【七】:服務熔斷與降級hystrix

促銷活動開始10分鐘,商品服務掛了。 然後呢?訂單服務調商品服務超時,線程池打滿。用户服務調訂單服務超時,線程池也打滿。整個系統像多米諾骨牌一樣全倒了。 這就是經典的雪崩效應。 解決方案:熔斷和降級。 雪崩是怎麼發生的 用户請求 │ ▼ ┌─────────┐ 調用 ┌─────────┐ 調用 ┌─────────

限流 , 線程池 , 後端開發 , ci , Python

收藏 評論

stillfox - 使用 go kit進行微服務開發

go-kit的基本介紹 go-kit 介紹 go-kit 是一個 Golang 編寫的開發框架,可以幫助開發者更快捷地構建可伸縮的微服務架構。它提供了一系列模塊化的組件,可以幫助開發者更輕鬆地構建和維護微服務。go-kit的設計理念是可組合的,它可以與各種服務發現系統進行集成,如etcd、consul和zookeeper等,並且可以輕鬆實現服務熔斷和負載均衡。 另外,go-kit也提供了諸如監控、

限流 , 微服務 , microservice , go

收藏 評論

萌萌朵朵開 - 微服務熔斷降級:Sentinel 落地實踐

做微服務開發時,我踩過最頭疼的坑就是“服務雪崩”——一次下游支付服務響應超時,導致上游訂單服務大量請求阻塞,線程池被佔滿,最後整個調用鏈路癱瘓,影響了核心業務。後來瞭解到熔斷降級機制,而 Sentinel 作為阿里開源的流量控制工具,上手簡單、功能強大,能輕鬆搞定限流、熔斷、降級等問題,成為我們微服務架構的“安全衞士”。這篇就分享 Sentinel 的落地實踐,從核心概念到實際配

spring , 限流 , 微服務 , 雲計算 , 雲服務

收藏 評論

kevinwan - 微服務治理之如何優雅應對突發流量洪峯

為什麼需要降載 微服務集羣中,調用鏈路錯綜複雜,作為服務提供者需要有一種保護自己的機制,防止調用方無腦調用壓垮自己,保證自身服務的高可用。 最常見的保護機制莫過於限流機制,使用限流器的前提是必須知道自身的能夠處理的最大併發數,一般在上線前通過壓測來得到最大併發數,而且日常請求過程中每個接口的限流參數都不一樣,同時系統一直在不斷的迭代其處理能力往往也會隨之變化,每次上線前都需要進行壓測然後調整限流參

限流 , 服務器開發 , 微服務 , go-zero , go

收藏 評論

編程之翼 - 微服務技術棧整體架構

一、服務註冊與發現:Nacos 組件定位:微服務架構裏的“服務通訊錄+配置大管家”,是整個服務體系的基礎。 核心價值:主要解決兩個頭疼問題——一是服務間“找誰通話”的問題:服務提供方啓動後會自動把自己的地址信息登記到Nacos上,消費方不用死記硬背對方地址,隨時能查到可用的服務實例;二是配置“散養難管”的問題:把多個服務共用的配置集中放在這裏管,還能按開發、測試、生產

spring , 限流 , 連接池 , 前端開發 , Javascript

收藏 評論

萌萌朵朵開 - 微服務API網關:Kong網關的路由配置與流量控制

前陣子公司微服務集羣擴張到三十多個服務,客户端調用變得一團糟:每個服務都有獨立域名,認證邏輯重複開發,還經常因為某個服務突發流量拖垮整個集羣。後來引入Kong網關作為統一入口,不僅解決了域名混亂問題,還通過流量控制和認證攔截減輕了業務服務的負擔,運維效率提升了不少。 在微服務架構中,API網關扮演着"交通樞紐"的角色,負責請求路由、流量控制、認證授權等橫切關注點。Kong作

限流 , 雲計算 , 雲服務 , 流量控制 , 後端服務

收藏 評論

小波同學 - SpringBoot——Bucket4j:分佈式限流

1. 引言:限流背景與 Bucket4j 項目概述 在微服務與高併發系統中,合理地限制請求速率能夠保護後端服務不被洪水般的請求壓垮,平滑流量並保障系統可用性。Bucket4j 是一個基於 Java 的令牌桶(Token Bucket)限流庫,支持內存與多種分佈式存儲後端(如 Redis、Hazelcast、JCache 等),並且提供豐富的 API,讓開發者能靈活定義限流策略與集成方

Spring Boot , spring , 限流 , Bucket4j , Starter , 後端開發 , springboot

收藏 評論

萌萌朵朵開 - API網關選型與落地:基於Istio構建雲原生統一入口

在雲原生架構中,API網關作為流量入口的核心組件,承擔着路由轉發、認證授權、限流熔斷等關鍵職責。隨着微服務規模擴大,傳統API網關(如Spring Cloud Gateway)面臨與業務代碼耦合、跨語言支持弱等問題。本文將對比主流API網關方案,詳解如何基於Istio服務網格構建雲原生統一入口,並提供落地實踐代碼。 一、API網關選型對比:為何選擇Istio? 主流A

限流 , 多語言 , 雲計算 , API , 雲服務

收藏 評論

雲端小夢 - TikTok如何判定賬號是否限流?該怎麼解決?

做TikTok的人,最怕三件事——賬號沒流量、視頻零播放、內容突然掉權。 有時候你明明在按爆款邏輯做內容,卻發現: 視頻剛發就不推流 平常幾千播放,突然變成幾十甚至個位數 換內容也沒用,賬號像“死號” 甚至發一條限一條、換號又廢一個 這就是TikTok最常見的隱形風控機制:限流。本篇文章拆解Ti

音視頻 , 限流 , 風控 , 權重 , 前端開發 , Javascript

收藏 評論

雲端小仙童 - rpc傳輸限制大小16m

系統的運行過程中,需要對外部請求進行限流。限流有本地限流與分佈式限流,本文現在對項目實踐過程中使用的分佈式限流中間件進行介紹。 該分佈式限流中間件實現的原理是每次從遠端(遠端的redis)消費掉固定數量的配額,待消費完後,再從遠端申請。 // rate.go // 定義了限流的頻次 type Rate struct {

redis , 限流 , 中間件 , 雲計算 , 雲原生 , rpc傳輸限制大小16m

收藏 評論

京東雲開發者 - 【穩定性】穩定性建設之彈性設計 | 京東物流技術團隊

背景 隨着業務的快速變化和技術的不斷髮展,系統面臨着諸多挑戰,例如流量峯值、依賴服務故障、硬件故障、網絡中斷、軟件缺陷等,這些因素都可能影響到系統的正常運行。在這種背景下,彈性設計(Resilience Design)應運而生。彈性設計是一種系統的設計和構建方法,系統的設計原則應該本着不信任外部資源(外部API服務、網絡設備、存儲、消息等)100%可用的原則,在關鍵處理路徑上針對上述可能發生故障的

系統設計 , 限流 , 彈性伸縮 , 系統

收藏 評論

萌萌朵朵開 - 微服務 API 網關:Kong 配置與性能優化

微服務架構下,服務拆分後會面臨一堆麻煩:每個服務都要處理認證、限流、日誌,客户端要記一堆服務地址,跨服務調用還容易出現兼容性問題。直到引入 Kong 網關,這些問題才迎刃而解——它就像微服務的“統一入口”,所有請求先經過 Kong,再轉發到對應服務,集中處理認證、限流、監控等通用功能,讓業務服務專注於核心邏輯。Kong 基於 Nginx 開發,性能強悍,配置靈活,是微服務架構中

限流 , 雲計算 , API , Nginx , Docker

收藏 評論

上海拔俗網絡 - AI 大語言模型及服務平台:從“接模型”到“可治理能力中台”的工程實踐

在很多團隊的最初方案中,“大語言模型平台”往往被理解為一件很簡單的事情: 接入一個大模型 封裝成 API 提供給業務調用 Demo 很快能跑,但一旦進入多業務、多團隊、多場景使用,就會迅速暴露出問題: 不同業務對模型口徑要求完全不同 Prompt 分散在各個服務中,無法統一管理 模型版本更新後,線上行為不可控 成本、延遲、風

限流 , NLP , 語言模型 , 緩存 , 人工智能

收藏 評論