1. 為什麼需要複製 我們可以考慮如下問題： 當數據量、讀取或寫入負載已經超過了當前服務器的處理能力，如何實現負載均衡？ 希望在單台服務器出現故障時仍能繼續工作，這該如何實現？ 當服務的用户遍佈全球，並希望他們訪問服務時不會有較大的延遲，怎麼才能統一用户的交互體驗？ 這些問題其實都能通過“複製”來解決：複製，即在不同的節點上保存相同的副本，提供數據冗餘。如果一些節點不可用，剩餘的節點仍然
一、問題是怎麼發現的 最近有個新系統開發完成後要上線，由於系統調用量很大，所以先對核心接口進行了一次壓力測試，由於核心接口中基本上只有純內存運算，所以預估核心接口的壓測QPS能夠達到上千。 壓測容器配置：4C8G 先從10個併發開始進行發壓，結果cpu一下就飆升到了100%，但是核心接口的qps才200左右。於是觀察jvm的垃圾回收發現younggc很頻繁，但是fullGC數量為零。 二、排查問題
經常開發表格，是不是已經被手寫Ant-Design Table的Columns整煩了？ 尤其是ToB項目，表格經常動不動就幾十列。每次照着後端給的接口文檔一個個配置，太頭疼了，主要是有時還會粘錯就尷尬了。 那有沒有辦法能自動生成columns配置呢？ 當然可以。 目前後端的接口文檔一般是使用Swagger來生成的，Swagger是基於OpenAPI規範的一種實現。（OpenAPI規範是一種描述RE
1 WebAssembly是什麼？ 一種運行在現代網絡瀏覽器中的新型代碼，並且提供新的性能特性和效果 W3C WebAssembly Community Group開發的一項網絡標準，對於瀏覽器而言，WebAssembly 提供了一條途徑，讓各種語言編寫的代碼以接近原生的速度在 Web 中運行。在這種情況下，以前無法以此方式運行的客户端軟件等都將可以運行在 Web 中。 WebAssembl
前言 首先java語言的特性是不需像C和C++那樣自己手動釋放內存，因為java本身有垃圾回收機制（垃圾回收稱為GC），顧名思義就是釋放垃圾佔用的空間，防止內存泄露。JVM運行時佔用內存最大的空間就是堆內存，另外棧區和方法區也會佔用空間但是佔用有限本章就不探究了。那麼堆中的空間又分為年輕代和老年代，所以我們粗略的把垃圾回收分為兩種：年輕代的垃圾回收稱為Young GC，老年代的垃圾回收稱為Full
本文面向受眾可以是運營、可以是產品、也可以是研發、測試人員，作者希望通過如下思路（知歷史-清家底-明目標-定戰略-做戰術-促成長）幫助大家能夠了解電商大促系統的高可用保障，減少哪些高深莫測的黑話和高大尚的論調，而是希望有個體系化的知識讓讀者有所得。 一、【知歷史】電商大促的簡介 1.1、什麼是電商大促 電商大促是電商平台組織的一種大型銷售推廣活動，目的是通過提供各種優惠、折扣等方法，提高商品銷售額
前言 低代碼開發平台（LCDP），是低代碼或無代碼通過快速搭建配置的方式完成一個應用程序的開發與上線，可視化低代碼就是可視化的DSL，它的優點更多的是來源可視化，相對的，它的侷限性也還是來源於可視化，複雜的業務邏輯用低代碼可能會更加複雜。低代碼應該是特定領域問題的簡化和抽象，如果只是單純將原有的編碼工作轉換為 GUI 的模式，並沒有多大意義。 背景 隨着京東微信域業務與騰訊合作的加深，作為流量的載
一、需求開發修改代碼 一次需求開發時碰到如下所示方法代碼： private OrderShoudSettlementAmount getOrderShoudSettlementAmount(OrderDTO orderMain, ListSettlementDetail details) { OrderShoudSettlementAmount settlementAmount = new
本文旨在簡明扼要説明各回收器調優參數，如有疏漏歡迎指正。 1、JDK版本 以下所有優化全部基於JDK8版本，強烈建議低版本升級到JDK8，並儘可能使用update_191以後版本。 2、如何選擇垃圾回收器 響應優先應用：面向C端對響應時間敏感的應用，堆內存8G以上建議選擇G1，堆內存較小或低版本JDK選擇CMS； 吞吐量優先應用：對響應時間不敏感，以高吞吐量為目標的應用（如MQ、Worker），建
一 前言 架構設計按照實施過程可分為工程架構，業務架構，部署架構等多個維度，一個好的系統架構標準應該具備可擴展、可維護、可靠性、安全性和高性能等特點。儘管這些特點大家都熟知，但在實際落地時，我們更為迫切的想知道實現這些要求的關鍵路徑，以便在架構設計中融入這些特點。只有這樣，才能確保系統能夠適應未來的業務增長和交付效率。本文將重點圍繞如何進行工程架構設計展開探討。 二 價值為先 在方案出現歧義時，站
前言 瞭解清晰架構之前需要大家先熟悉以下常見架構方案： *EBI架構(Entity-Boundary-Interactor Architecture) 領域驅動設計(Domain-Driven Design) 端口與適配器架構(Ports Adapters Architecture,又稱為六邊形架構) 洋葱架構(Onion Architecture) 整潔架構(Cle
一：場景 20w的QPS的場景下，服務端架構應如何設計？ 二：常規解決方案 可使用分佈式緩存來抗，比如redis集羣，6主6從，主提供讀寫，從作為備，不提供讀寫服務。1台平均抗3w併發，還可以抗住，如果QPS達到100w,通過增加redis集羣中的機器數量，可以擴展緩存的容量和併發讀寫能力。同時，緩存數據對於應用來講都是共享的，主從架構，實現高可用。 三：如何解決緩存熱點（熱key）問題 但是如果
1 InnoDB存儲引擎 InnoDB存儲引擎最早由Innobase Oy公司開發（屬第三方存儲引擎）。從MySQL 5.5版本開始作為表的默認存儲引擎。該存儲引擎是第一個完整支持ACID事務的MySQL存儲引擎，特點是行鎖設計、支持MVCC、支持外鍵、提供一致性非鎖定讀，非常適合OLTP場景的應用使用。目前也是應用最廣泛的存儲引擎。 InnoDB存儲引擎架構包含內存結構和磁盤結構兩大部分，總體架
引言 現在全社會都在搞數字化轉型，從政府到企業，那麼為什麼要進行數字化轉型呢？本質上還是社會治理和企業經營難度變得更大了。 以企業來説，轉型的目標是為了實現有質量的活着，比如能賺更多的錢或者持續保持穩健運營，轉型的核心是期望藉助數字化技術構建一個管理體系，以應對外部環境動盪、企業競爭變化和技術更新發展帶來的不確定性。 數字化轉型會帶來大量的研發需求，如何更好更快的交付這些需求成為一個突出問題，該怎
背景 大促備戰，最大的隱患項之一就是慢sql，帶來的破壞性最大，也是日常工作中經常帶來整個應用抖動的最大隱患，而且對sql好壞的評估有一定的技術要求，有一些缺乏經驗或者因為不夠仔細造成一個壞的sql成功走到了線上，等發現的時候要麼是造成了線上影響、報警、或者後置的慢sql採集發現，這時候一般無法快速止損，需要修改代碼上線、或者調整數據庫索引。 核心痛點： 1、無法提前發現慢sql，可能惡化為慢sq
併發指同一時間內進行了多個線程。併發問題是多個線程對同一資源進行操作時產生的問題。通過加鎖可以解決併發問題，ReentrantLock是鎖的一種。 1 ReentrantLock 1.1 定義 ReentrantLock是Lock接口的實現類，可以手動的對某一段進行加鎖。ReentrantLock可重入鎖，具有可重入性，並且支持可中斷鎖。其內部對鎖的控制有兩種實現，一種為公平鎖，另一種為非公平鎖.
高可用指標與問題 高可用，英文單詞High Availability，縮寫HA，它是分佈式系統架構設計中一個重要的度量。業界通常用多個9來衡量系統的可用性，如下表： 既然有可用率，有一定會存在不可用的情況。系統宕機一般分為有計劃的和無計劃的，有計劃的如日常維護、系統升級等，無計劃的如設備故障、突發斷電等。我們對此作如下分類： 1.設備故障：機房斷電、硬盤損壞、交換機故障。 2.網絡故障：網絡帶寬
1. 背景 我方有一應用，偶爾會出現GC時間過長（間隔約4小時），導致性能波動的問題(接口最長需要耗時3秒以上)。經排查為G1垃圾回收器參數配置不當 疊加 MySQL 鏈接超過閒置時間回收，產生大量的虛引用，導致G1在執行老年代混合GC，標記階段耗時過長導致。以下為對此問題的分析及問題總結。 此外，此應用因為使用redis緩存為數據庫緩存一段時間的熱點數據，導致業務起量創建數據庫鏈接後，會很容易被
1、背景 到店商詳迭代過程中，需要提供的對外能力越來越多，如預約日曆、附近門店、為你推薦等。這其中不可避免會出現多個上層能力依賴同一個底層接口的場景。最初採用的方案是對外API入口進來後獲取對應的能力，併發調用多項能力，由能力層調用對應的數據鏈路，進行業務處理。然而，隨着接入功能的增多，這種情況導致了底層數據服務的重複調用，如商品配置信息，在一次API調用過程中重複調了3次，當流量增大或能力項愈多
前言 當我們在開發項目時，有時需要用到外部依賴組件，例如當我們需要Json序列化的時候需要用到FastJson組件，我們可以通過下載對應jar包加載到項目中。但當一個大的項目同時需要依賴各種各樣的外部服務，就存在着配置繁瑣、依賴衝突等問題，因此可以通過maven來完成對應的依賴管理功能。 一、Settings配置 settings.xml用來配置maven項目中的各種參數文件，包括本地倉庫、遠程倉
最近在讀《數據密集型應用系統設計》，其中談到了zookeeper對容錯共識算法的應用。這讓我想到之前參考的zookeeper學習資料中，誤將容錯共識算法寫成了2PC（兩階段提交協議），所以準備以此文對共識算法和2PC做梳理和區分，也希望它能幫助像我一樣對這兩者有誤解的同學。 1. 2PC（兩階段提交協議） 兩階段提交 (two-phase commit) 協議是一種用於實現跨多個節點的原子事務（分
1 引言 ClickHouse是一個用於聯機分析(OLAP)的列式數據庫管理系統(DBMS)。我們內部很多的報表、數據看板都基於它進行開發。今天為大家帶來remote方式的ClickHouse數據表遷移的完整過程介紹，如有錯誤，還請各位大佬指正。 以下sql語句為測試使用，如需使用請根據實際情況修改。 2 背景 我們使用的是京東雲提供的分佈式數據庫 JCHDB，原ClickHouse是兩個部門共用
前言 SpringAOP作為Spring最核心的能力之一，其重要性不言而喻。然後需要知道的是AOP並不只是Spring特有的功能，而是一種思想，一種通用的功能。而SpringAOP只是在AOP的基礎上將能力集成到SpringIOC中，使其作為bean的一種，從而我們能夠很方便的進行使用。 一、SpringAOP的使用方式 1.1 使用場景 當我們在日常業務開發中，例如有些功能模塊是通用的（日誌、權
1 目標 不在現有查詢代碼邏輯上做任何改動，實現dao維度的數據源切換（即表維度） 2 使用場景 節約bdp的集羣資源。接入新的寬表時，通常uat驗證後就會停止集羣釋放資源，在對應的查詢服務器uat環境時需要查詢的是生產庫的表數據（uat庫表因為bdp實時任務停止，沒有數據落入），只進行服務器配置文件的改動而無需進行代碼的修改變更，即可按需切換查詢的數據源。 2.1 實時任務對應的集羣資源 [](
