在我們分佈式架構中，分佈式任務，與drm是輔助業務系統的中間件必要存在的一部分 首先介紹一下分佈式任務的背景與出現解決的問題。 1：背景，分佈式架構中，你的業務系統部署了多臺，但是，大多業務系統中，都存在定時任務，如果在業務系統用
1：我想說下mybatis爲什麼會要優化，我們優化的點是什麼。 1.1mybatis是我們操作數據庫的一個框架，我們在業務中很多的加鎖，無非也是想控制我們的數據庫資源，併發量大了會帶來系統的資源壓力，數據庫的壓力。我們想要的優化點
博主上一篇文章介紹了sofa。 本張介紹sofa多模塊的使用。 1：模塊的拆分 這個層面需要使用者根據業務來定，SOFABoot 模塊一般用於封裝對外發布服務接口的具體實現。所以controller層建議放在root啓動模塊中。
1：關於sofa很多朋友都陌生，這個是支付寶開源的框架。大家很想知道，sofa框架的出現解決了什麼問題，個人理解是，從三個層面來說。 1：他提供的模塊化，解耦了項目各個模塊。其實就是把每個模塊獨立化上下文，每個模塊之間的開發互不影
1：博主最近接觸了支付寶開源的sofa框架，支付寶開源的項目地址在 在接觸當中，使用到我個人的項目中。本人項目中使用到sofa多模塊的方式，sofa的多模塊，與普通多模塊最大的區別是，sofa多模塊住提現每個每個模塊都是獨立的sp
1：java中自帶的鎖有系統所sychronized與應用層面的鎖lock，基於lock就介紹ReentrantLock。 基於這個層面的lock核心就是AQS，lock的底層原理實現還是依賴CAS，在jdk早期版本中，lock
這個框架主要有4個組成部分 1：fastmvc 關於 fastmvc的大體在微服務中的作用， 1.1 底層實現主要基於netty實現，主要負責接收與維護客戶端的鏈接。 2:AsynRpc 2.1關於AsynRpc的作用，主要用於消
背景：目前分庫分表是比較 熱門的話題，因爲考慮使用分佈式架構，一般屬於訪問量，數據量比較大系統，在這樣的系統中不可避免，爲了給系統的性能提高與高可用採用分庫分表的方式去解決數據層面的壓力。博主本次接受sharding的基礎使用。
1：底層技術對比 1.1webflux底層採用netty實現， 1.2rpc的底層採用netty實現 1.3netty的高性能體現在他的線程模型，零拷貝，高性能的序列化。 1.4個人認爲，在性能上，如果應用端採用webflux的情
對於web架構優化我們的最終方向有兩點 1：提高系統的吞吐量 2：提高系統的處理邏輯能力。 大體的流程圖如下 解釋下這個張流程圖 1：netty是維護客戶端連接負責把請求的內容拿到(是不能阻塞的) 2：disouptor是用來堆放
項目場景：對於定時任務發起的一些任務，由於某些客觀原因，導致任務失敗，希望能夠有一個監聽的定時器，定時輪訓任務狀態表，並重新發起任務調用。 核心思路： 1.定義一個定時器TaskARQCron.java，發起失敗任務掃描。
Redis中實現分佈式鎖機制 加鎖 使用setnx(商品ID,1)； 返回0，代表redis裏面有數據，即數據已經加鎖； 返回1，代表redis裏面沒有數據，即可以獲得鎖。 解鎖 使用redis的del 商品ID命令，刪除其中
Zookeeper中的數據存儲結構就像一棵樹，樹上的節點叫做Znode。這裏，Znode有四種類型： 持久節點； 持久節點順序節點 臨時節點 臨時節點順序節點 所謂的順序節點，即在創建節點時，Zookeeper會根據創建的時間
1.微服務架構要解決的問題 最大的問題：網絡是不可靠的。 1.1 客戶端如何訪問多個服務？ 解決方案：服務聚合到API網關，聚合服務 1.2 服務與服務之間如何通信？ 同步通信：Http（Apache Http Client）、R
Zookeeper可以幫我們實現服務的註冊與發現。然而，現在有一個問題是，如果只採用一個Zookeeper服務器，那麼當這個服務器宕機時，意味着整個分佈式服務無法正常工作。爲了解決這一問題，就需要Zookeeper集羣。 然而，在
