關於微服務分布式事務的一些思考，筆者沒有參與過復雜分布式事務的場景，各位大神路過可以分享一些遇到的案例，大家一起探討。 　　關於分布式事務，筆者推薦的處理方法是“盡量避免”，如果實在避免不了（這已經是高並發、用戶量比較多的網站了）則使用“最終一致性”處理（參照CAP理論base思想 ...

一、前言 最近系統上遇到一些問題，我又仔細去思考了一下CAP相關方面的東西，有點感悟想寫篇文章，來好好思索下CAP這個東西； 二、先聊聊一聊我遇到的問題? 簡單的說說我的場景，MQ推送消息過來以后寫入redis，然后多個進程去消費redis中的數據，最后處理完成進入ES ...

首先分布式鎖和我們平常講到的鎖原理基本一樣，目的就是確保，在多個線程並發時，只有一個線程在同一刻操作這個業務或者說方法、變量。 在一個進程中，也就是一個jvm 或者說應用中，我們很容易去處理控制，在jdk java.util 並發包中已經為我們提供了這些方法去加鎖 ...

前言 　　在一個分布式高並發的系統設計中，限流是一個不可忽視的功能點。如果不對系統進行有效的流量訪問限制，在雙十一和搶票這種流量洪峰的場景下，很容易就會把我們的系統打垮。而作為系統服務的衛兵的網關組件，作為系統服務的統一入口，更需要考慮流量的限制，直接在網關層阻斷流量比在各個系統中實現更合 ...

1.寫唯一ID生成器的原由 在閱讀工程源碼的時候，發現有一個工具職責生成一個消息ID，方便進行全鏈路的查詢，實現方式特別簡單，核心源碼不過兩行，根據時間戳以及隨機數生成一個ID，這種算法ID在分布式系統中重復的風險就很明顯了。本來以為只是日志打印功能，根據於此在不同系統調用間關聯業務日志 ...

前言 本文接着上文應用限流進行討論。 之前談到的限流方案只能針對於單個 JVM 有效，也就是單機應用。而對於現在普遍的分布式應用也得有一個分布式限流的方案。 基於此嘗試寫了這個組件： https://github.com/crossoverJie ...

分布式系統並不是什么新鮮詞，在上個世紀七八十年代就已經有各種分布式系統出現。只是在互聯網時代，分布式系統才大放異彩，尤其是Google更是把分布式系統運用到了極致。Google整個的軟件構架都是基於各種各樣的分布式系統，諸如Borg、MapReduce、BigTable等。正是這些分布式 ...

分布式測試是測試領域中的集大成者，要做好做精，需要做到三方面的准備，一是測試能力的儲備，包括功能，性能以及各種測試工具的開發的能力要到位；二是對於常用的分布式架構、技術、系統（如緩存，分布式數據庫，消息，降級、熔斷及限流等等）要有一定的理解，三是要對業務場景較為熟悉，因為每個分布式架構都有 ...