原创 字段權限控制之基於Java AOP方案 前言 核心代碼 使用示例

前言 有時業務需要對一些敏感字段處理,結合權限系統,對不同請求方的字段權限進行字段控制。本方案是基於AOP方案。 核心代碼 AuthorityField(需要權限校驗的字段標記) import java.lang.annotatio

原创 Rocketmq 封裝使用核心步驟

註解類配置 import com.aliyun.openservices.ons.api.PropertyKeyConst; import lombok.Data; import org.springframework.boot.aut

原创 k8s常用指令

1.查看存在的pods kubectl get pods 獲取的默認是namespace爲default的所有pods; kubectl get pods -n gos 加上-n的參數,就可以查看到具體的namespace下的pods信息

原创 Java 在K8s下實現優雅停機

前言 當我們實現滾動升級之前,務必要實現應用級別的優雅停機,否則滾動升級時,還是會影響到業務。所以,我們希望Java發版實現優雅停機。 1. Java 配置(開發側) 1.1 加入依賴 <dependency> <groupId

原创 DDD 概述

前言 爲什麼需要DDD 微服務拆分困境產生的根本原因就是不知道業務或者微服務的邊界到底在什麼地方。換句話說,確定了業務邊界和應用邊界,這個困境也就迎刃而解了。 如何確定,是否有相關理論或知識體系支持呢? 2004 年埃裏克·埃文斯(Eric

原创 RocketMQ 10.順序消息在高併發下的使用

前言 順序消息:指的是消息的消費順序和生產順序相同 全局順序:在某個topic下,所有的消息都要保證順序 局部順序:只要保證每一組消息被順序消費即可 Rocketmq順序消息屬於局部順序(分區順序) 1. 普通消息與順序消息 public

原创 Flink中的Time及Windows操作

Flink中的Time類型 Flink中的Windows編程 Flink的watermarks Event Time: Event Time 是事件發生的時間,一般就是數據本身攜帶的時間。這個時間通常是在事件到達 Flink 之前就

原创 7. 分佈式統一ID策略與Disruptor作用

1.業務ID生成方式與含義 使用帶有業務含義的ID生成策略,這種方式也在傳統應用系統、特定的場景下非常的好用。比如我們現在有一張商品貨架表,這張表的數據維度是這樣的,比如是按照城市和區域來劃分的。 •比如北京我們按照100000爲基本維度數

原创 6. Disruptor與Netty實現百萬級長連接接入

1. Disruptor與Netty 架構 與Netty網絡通信框架整合提升性能: 在使用Netty進行接收處理數據的時候,我們儘量都不要在工作線程(Handler)上編寫自己的代碼邏輯 我們需要利用異步的機制,比如使用線程池異

原创 5. Disruptor 高性能解析

1. 數據結構-內存預加載機制 數據結構層面:使用環形結構、數組、內存預加載 RingBuffer使用數組Object[] entries作爲存儲元素,如下圖所示 2. 內核-使用單線程寫 Disruptor的RingBuffer,之所

原创 4. Disruptor高級應用

核心鏈路 核心鏈路特點:至關重要且業務複雜。 實現方式: 傳統的完全解耦模式 模板模式 解決手段: 1 領域模型的高度抽象 2 尋找更好的框架幫助我們進行編碼 使用框架: 1 有限狀態機框架,例如Spring-StateMachine

原创 3. Disruptor核心組件

1.RingBuffer、Disruptor RingBuffer: 基於數組的緩存實現,也是創建Sequencer與定義WaitStrategy的入口 Disruptor: 持有RingBuffer、消費者線程池Executor、消費者

原创 2.Disruptor核心原理與使用

1. 急速入門-Disruptor,掌握編程模型 LAMX 它能夠在一線程裏每秒處理6百萬訂單 業務邏輯處理器完全是運行在內存中,使用事件源驅動方式 業務邏輯處理器的核心時Disruptor Disruptor Quick Start

原创 1.Disruptor 性能優勢

1. ArrayBlockingQueue public class ArrayBlockingQueue4Test { public static void main(String[] args) { final

原创 MySQL實戰14 慢查詢優化join、order by、group by

1.慢查詢的優化思路 1.1優化更需要優化的SQL 優化SQL是有成本的 高併發低消耗的比低併發高消耗影響更大 優化示例 併發形式 優化前 假設優化後 高併發低消耗 每小時10000次,每次20個IO 每小時節約20000次I