深入理解MySQL索引底層數據結構
1 引言 在日常工作中，我們會遇見一些慢SQL，在分析這些慢SQL時，我們通常會看下SQL的執行計劃，驗證SQL執行過程中有沒有走索引。通常我們會調整一些查詢條件，增加必要的索引，SQL執行效率就會提升幾個數量級。我們有沒有思考過，為什麼加了索引就會能提高SQL的查詢效率，為什麼有時候加了索引SQL執行反而會沒有變化，本文就從MySQL索引的底層數據結構和算法來進行詳細分析。 2 索引數據結構對比
京東雲開發者 Blog
Stories
List
淺析MySQL代價模型：告別盲目使用EXPLAIN，提前預知索引優化策略 | 京東雲技術團隊
背景 在 MySQL 中，當我們為表創建了一個或多個索引後，通常需要在索引定義完成後，根據具體的數據情況執行 EXPLAIN 命令，才能觀察到數據庫實際使用哪個索引、是否使用索引。這使得我們在添加新索引之前，無法提前預知數據庫是否能使用期望的索引。更為糟糕的是，有時甚至在添加新的索引後，數據庫在某些查詢中會使用它，而在其他查詢中則不會使用，這種情況下，我們無法確定索引是否發揮了預期的作用，讓人感到
log4j2同步日誌引發的性能問題 | 京東物流技術團隊
1 問題回顧 1.1 問題描述 在項目的性能測試中，相關的接口的隨着併發數增加，接口的響應時間變長，接口吞吐不再增長，應用的CPU使用率較高。 1.2 分析思路 誰導致的CPU較高，阻塞接口TPS的增長？接口的響應時間的調用鏈分佈是什麼樣的，有沒有慢的點？ 1）使用火焰圖分析應用的CPU如下，其中log4j2日誌佔了40%左右CPU，初步懷疑是log4j2的問題。 2）調用鏈的分析 通過pfin
聊聊前端性能指標那些事兒
作者：京東科技 郝梁 前言：作為 C 端前端研發，除了攻克業務難點以外，也要有更深層的自我目標，那就是性能優化。這事兒説大不大，説小也不小，但難度絕對不一般，所涉及的範圍優化點深入工程每個細胞。做好前端性能優化絕非簡單之事！文章主要內容介紹前端性能考核指標及優化方案。 一、前端性能指標有哪些？ 根據 chrome Lighthouse 最新規則，前端性能指標考量主要有 FCP（First Cont
帶你揭開神秘的javascript AST面紗之AST 基礎與功能
作者：京東科技 周明亮 AST 基礎與功能 在前端裏面有一個很重要的概念，也是最原子化的內容，就是 AST ，幾乎所有的框架，都是基於 AST 進行改造運行，比如：React / Vue /Taro 等等。 多端的運行使用，都離不開 AST 這個概念。 在大家理解相關原理和背景後，我們可以通過手寫簡單的編譯器，簡單實現一個 Javascript 的代碼編譯器，編譯後在瀏覽器端正常運行。 創建數字小
React請求機制優化思路 | 京東雲技術團隊
説起數據加載的機制，有一個繞不開的話題就是前端性能，很多電商門户的首頁其實都會做一些垂直的定製優化，比如讓請求在頁面最早加載，或者在前一個頁面就進行預加載等等。隨着react18的發佈，請求機制這一塊也是被不斷談起，並且在後續其實也給出了明確的方向。 假如我們頁面中有三個組件C1、C2、C3依次嵌套，每個組件中有對應的請求F1、F2、F3，通常大多數人會使用useeffect和state變量來實現
極致性能優化：前端SSR渲染利器Qwik.js | 京東雲技術團隊
引言 前端性能已成為網站和應用成功的關鍵要素之一。用户期望快速加載的頁面和流暢的交互，而前端框架的選擇對於實現這些目標至關重要。然而，傳統的前端框架在某些情況下可能面臨性能挑戰且存在技術壁壘。 在這個充滿挑戰的背景下，我們引入了 Qwik.js 框架。Qwik.js 不僅是一個前端框架，更是一種前端性能的終極解決方案。它不僅提供了卓越的性能，還以其獨特的特點和優勢脱穎而出。 讓我們一起深入探索 Q
Python網絡爬蟲原理及實踐 | 京東雲技術團隊
作者：京東物流 田禹 1 網絡爬蟲 網絡爬蟲：是一種按照一定的規則，自動地抓取萬維網信息的程序或者腳本。 網絡爬蟲相關技術和框架繁多，針對場景的不同可以選擇不同的網絡爬蟲技術。 2 Scrapy框架（Python） 2.1. Scrapy架構 2.1.1. 系統架構 2.1.2. 執行流程 總結爬蟲開發過程，簡化爬蟲執行流程如下圖所示： 爬蟲運行主要流程如下： （1） Scrapy啓動Spid
Java模塊化應用實踐之精簡JRE | 京東雲技術團隊
導語 Java9及以後的版本引入了模塊化特性，但是直到今天JDK21都發布了，依然沒有被大量使用起來，那麼這個特性就真的沒啥意義了嗎？ 別忘了，Java本身可是把模塊化做到了極致的，所以可以利用這個特性對JRE本身進行定製化或者精簡化。 由於平時偶爾會開發一些Java的客户端應用，這時精簡JRE的需求就凸顯出來，讓自己的程序帶着最精簡的JRE到處運行。 實際實踐了一段時間之後發現“真香！” 現在把
Jmeter壓測實戰：Jmeter二次開發之自定義函數 | 京東雲技術團隊
1 前言 Jmeter是Apache基金會下的一款應用場景非常廣的壓力測試工具，具備輕量、高擴展性、分佈式等特性。Jmeter已支持實現隨機數、計數器、時間戳、大小寫轉換、屬性校驗等多種函數，方便使用人員使用。如果在使用過程中存在和業務強耦合的常用功能函數，在Jmeter不支持的情況下，那就需要單獨開發自定義函數實現特定功能。 本文介紹如何開發Jmeter自定義函數實現快速生成京東宙斯下單標準si
當我們在談論構造函數注入的時候我們在談論什麼 | 京東物流技術團隊
依賴注入 當涉及依賴注入（Dependency Injection，DI）時，首先推薦使用構造函數注入，因為構造函數注入有很多技術優點，而且還與面向對象的設計原則密切相關。在業界，構造函數注入作為依賴注入的一種最佳實踐得到了廣泛的認可，在Spring Framework的作者之一Rod Johnson的觀點中也得有體現。 下面是Spring官方文檔中對於依賴注入的描述： Since you c
前端部署新方案-技術篇（總體架構設計）
作者：京東科技 王光輝 1. 全流程自動化 打通 Jen/行雲/京東雲OSS/零售雲OSS/NP/CDN/R2M/JimDB/科技容器/零售容器/域名解析/鏡像適配/測試站發佈等全鏈路 實現資源免維護部署，提升部署效率 2. 高可用架構 支持高併發訪問，具備主備容災機制 系統穩定性與可維護性全面提升 3. 精細化部署策略 新增前端灰度發佈能力 支持按業務需求靈活選擇部署模
淺談冪等設計 | 京東雲技術團隊
1 冪等性 一句話，冪等就是一個執行操作，無論執行多少次，產生的效果和返回的結果都是一樣的。 2 為什麼要實現冪等性？ 如今隨着互聯網技術快速發展，業務越來越複雜，系統的高併發和關鍵數據的場景越來越多。 在分佈式系統中，機器宕機和消息丟失也是需要重點關注的問題，其中的一個典型就是冪等性問題。 想想看，一個對外暴露的接口會面領很多次請求，如果不能保證冪等性會帶來什麼樣的後果？ 微信進行一次扣款操作，
文盤Rust -- tokio綁定cpu實踐 | 京東雲技術團隊
tokio 是 rust 生態中流行的異步運行時框架。在實際生產中我們如果希望 tokio 應用程序與特定的 cpu core 綁定該怎麼處理呢？這次我們來聊聊這個話題。 首先我們先寫一段簡單的多任務程序。 use tokio::runtime; pub fn main() { let rt = runtime::Builder::new_multi_thread() .e
你真的瞭解@Async嗎？ | 京東雲技術團隊
使用場景： 開發中會碰到一些耗時較長或者不需要立即得到執行結果的邏輯，比如消息推送、商品同步等都可以使用異步方法，這時我們可以用到@Async。但是直接使用 @Async 會有風險，當我們沒有指定線程池時，他會默認使用其Spring自帶的 SimpleAsyncTaskExecutor 線程池，會不斷的創建線程，當併發大的時候會嚴重影響性能。所以可以將異步指定線程池使用 簡介： @Async是Sp
前端開發之函數式編程實踐 | 京東雲技術團隊
作者：京東科技牛志偉 函數式編程簡介 常見應用場景 1、ES6中的map、filter、reduce等函數 [1,2,3,4,5].map(x = x * 2).filter(x = x 5).reduce((p,n) = p + n); 2、React類組件 - 函數式組件+hooks、Vue3中的組合式API 3、RxJS、Lodash和Ramda等JS庫 4、中間件/插件，如Redux中的
Backbone前端框架解讀
作者: 京東零售 陳震 一、 什麼是Backbone 在前端的發展道路中，前端框架元老之一jQuery對繁瑣的DOM操作進行了封裝，提供了鏈式調用、各類選擇器，屏蔽了不同瀏覽器寫法的差異性，但是前端開發過程中依然存在作用域污染、代碼複用度低、冗餘度高、數據和事件綁定煩瑣等痛點。 5年後，Backbone橫空出世，通過與Underscore、Require、Handlebar的整合，提供了一個輕量和
實現動態表單的一種思路 | 京東雲技術團隊
一、動態表單是什麼 區別於傳統表單前後端配合聯調的開發實現方式，動態表單通過一種基於元數據管理的配置化方法來實現表單的動態生成，並能根據配置自由增改刪指定字段。實現特定需求的自助化。 圖1.1 傳統表單前後台協作模式 圖1.2 動態表單前後台協作模式 二、解決什麼問題 租户有個性化業務表單訴求的場景，千人千面系統 三、實現動態表單的一種思路 基於元數據管理的配置化表單技術共需三步來完成： 步驟
解析$nextTick魔力，為啥大家都愛它？
1.為什麼需要使用$nextTick? 首先我們來看看官方對於$nextTick的定義: 在下次 DOM 更新循環結束之後執行延遲迴調。在修改數據之後立即使用這個方法，獲取更新後的 DOM。 由於vue的試圖渲染是異步的，生命週期的created()鈎子函數進行的DOM操作一定要放在Vue.nextTick()的回調函數中，原因是在created()鈎子函數執行的時候DOM其實並未進行渲染，而此時
一種基於閉包函數實現自動化框架斷言組件的設計實踐 | 京東物流技術團隊
1 背景 目前測試組同學基本具備自動化腳本編寫能力，為了提高效率，如何靈活運用這些維護的腳本去替代部分手工的重複工作？為了達到測試過程中更多的去使用自動化方式，如何能夠保證通過腳本覆蓋更多的校驗點，提高自動化測試的精度和力度？那麼一定是不斷的豐富斷言，符合預期場景。緊接着棘手的問題就是，在前人維護的腳本不清楚如果在方法內部修改？擔心修改原來邏輯影響正向流程運行？一個斷言方法希望應用到更多的用例中？