大家好，我是Java烘焙師。後端程序員平時除了接觸業務代碼、中間件、存儲等，也難免會跟數倉有交集。下面結合筆者的經驗和思考，從後端程序員的視角看數倉、做個總結，後續再跟數倉/BI argue的時候就不虛了😃 分成兩部分介紹：離線數倉、實時數倉。 離線數倉 離線數倉是最典型的數倉應用場景。後端服務產生了業務數據、監控埋點、日誌等，如果要做統計分析，就要先離線採集到數倉，再通過SQL做聚合查詢。
大家好，我是Java烘焙師。上一篇文章介紹了限流方案的使用和選型，本文接着講限流算法的原理。 常見的限流算法有：令牌桶、窗口計數、漏桶，前兩種在實際使用中最常見，因此重點介紹。限流算法是通用的，既可以在單機上實現，也可以藉助redis來實現分佈式限流。 首先，定義一下限流算法需實現的基本功能： tryAquire嘗試獲取通行許可：立刻返回結果，true代表允許、false代表被限流 a
背景 在跨系統之間的數據寫入場景下，上下游系統極有可能因為網絡超時/抖動、或寫本地DB與調外部接口不能同時成功等原因，而出現數據不一致的問題，因此需要有及時發現不一致問題、並自動修復的能力。下面結合筆者的經驗，把對賬做個總結。 需要注意的是，這裏提的對賬不特指資金對賬，而是跨系統的字段對賬，如B端與C端系統之間的對賬。 對賬的指標 判斷對賬是否做得好，主要看這幾個指標： 完備性：確保所有字段都
大家好，我是Java烘焙師。如何更新緩存和DB、做到性能和一致性的取捨，是一個很常見的話題。下面結合筆者的經驗和思考，系統性地總結一下緩存更新模式，講透講明白。 1、旁路緩存（cache-aside） 實現方案 查詢：先查緩存，查不到緩存時再查DB，並把DB內容寫入緩存、設置合適的過期時間 更新：先更新DB，再刪緩存；做到極致則需引入延遲雙刪機制 之所以不是先刪緩存、再更新DB，是因為在這
大家好，我是Java烘焙師。為了避免突增流量引起服務雪崩，需要對接口、存儲資源做限流保護，根據系統負載情況設置合適的限流值。下面結合筆者的經驗和思考，對主要限流方案的選型做一下總結，本篇先看如何使用，下一篇再看背後的原理。 下面介紹幾種常見限流方案的使用方法、優缺點： 單機限流：Guava RateLimiter 同時支持單機限流、集羣限流：Sentinel 分佈式限流：Redisson
