⑴ 京東hotkey源碼解析
京東hotkey是一個經過京東大促驗證的hotkey防禦中間件，大概原理是通過上報key訪問數到統計伺服器集群，統計伺服器集群將hotkey通知到客戶端，讓hotkey能緩存到本地內存中，做到毫秒級的Scale-Out。處理方式有點像美團cat實時收集數據進行統計，只不過美團cat沒有反向通知邏輯而已。非常貼近工作實踐，值得一看。
首先看一下緩存入口Cache的get方法，JdHotKeyStore.getValue是獲取hotkey的方法，並且會進行訪問次數的統計上報，如果獲取到hotkey不為空，則直接返回，否則從redis獲取並調用JdHotKeyStore.smartSet判斷是否有hotkey，有則設置值，最後返回。
JdHotKeyStore.getValue會先調用inRule校驗此key是否有對應規則，如果沒有對應規則則不處理，然後調用getValueSimple從本地內存中獲取hotkey的存儲對象ValueModel，如果沒有獲取到，則調用HotKeyPusher.push開始計數；如果獲取到，會調用isNearExpire判斷是否快過期了，如果是也計數，然後取出ValueModel里的value是否有設置對應值，有才返回。最後調用KeyHandlerFactory.getCounter().collect進行對應規則的計數。下面來一步步分析此流程。
inRule會去KeyRule緩存中獲取對應的規則，經過層層調用會到KeyRuleHolder的findByKey方法，然後繼續調用其findRule方法選擇對應的KeyRule，如果沒有KeyRule就直接返回了，否則會拿到它的ration(hotkey緩存時間)，拿到對應ration的本地緩存。實際上這里為了方法的通用性，用了get來代替contain的判斷。
findRule的邏輯比較特別，作者已經留下了注釋，優先全匹配->prefix匹配-> * 通配，這樣做是為了更精確選擇對應的規則。比如配置了sku_的前綴規則，但是茅台sku的流量突升，需要針對茅台sku的本地緩存再長一點時間讓系統平穩渡過高峰期，那就配置一個sku_moutai_sku_id的全匹配規則，這樣不會干擾到其他sku的緩存規則。
那麼KEY_RULES的規則是怎麼來的呢？這就要說到etcd了，其實可以把etcd當做zookeeper，也有對配置crud，然後通知客戶端的功能。這里是做了定時拉取+監聽變化的雙重保證，這里跟攜程apollo的處理非常像：不要把雞蛋放在一個籃子，兜底功能真的很重要。每5秒定時從etcd拉取規則，開啟監聽器有變化就去etcd拉取規則。fetchRuleFromEtcd從ectd的rule_path獲取rules，然後轉化成ruleList繼續調用notifyRuleChange進行本地處理。
notifyRuleChange會往EventBus發送KeyRuleInfoChangeEvent的通知，進而進入KeyRuleHolder的putRules方法，這里可以看到維護了KEY_RULES和RULE_CACHE_MAP。
回到原有流程，getValueSimple方法的鏈路比較長，主要是通過key的規則，獲取到對應的ration，然後從對應ration的本地緩存中獲取ValueModel。
接下來是HotKeyPusher.push，如果是remove則在etcd創建一個節點然後再刪除，達到集群刪除的效果。如果是探測並且key在規則內，則調用KeyHandlerFactory.getCollector().collect進行統計。
KeyHandlerFactory.getCollector().collect方法交替使用兩個map，對count進行累加，這樣清理map的時候就不需要停頓了，交替使用是避免停頓的有效方式。
接回上文，還有一個 KeyHandlerFactory.getCounter().collect收集的是規則的訪問次數，也是取到對應的規則，然後對規則的訪問總數、熱次數進行累加。
兩個指標的收集已經分析完畢，那怎麼發送到worker呢？來到PushSchelerStarter，這里會啟動對兩個指標的定時線程池，分別會定時調用NettyKeyPusher的send和sendCount方法。
NettyKeyPusher的send和sendCount方法都是為統計數據選擇對應的worker然後進行請求，chooseChannel就是根據key哈希到其中一個worker上，然後發送請求即可。
最後當worker統計到hotkey時，client需要接收worker推送過來的hotkey進行存儲，可以看到NettyClientHandler會向EventBus發送ReceiveNewKeyEvent事件，ReceiveNewKeyListener收到此事件後將調用receiveNewKeyListener.newKey，將hotkey放到本地緩存，client端的處理流程就結束了。
由上文可知，client與worker的交互只有推送統計數據到worker，worker接收處理，最後推送hotkey到client。因此worker端只需要分析兩個部分：統計數據匯總、推送hotkey。
首先看到HotKey的處理邏輯是在HotKeyFilter中，首先會對totalReceiveKeyCount進行累加，然後調用publishMsg，如果統計信息超時1秒或者在白名單中就不處理，否則繼續調用keyProcer.push。
keyProcer.push將未過時的統計信息丟進queue中。
worker端會開啟指定數量的KeyConsumer，不斷消費queue中的統計數據。根據統計數據的類型調用KeyListener的removeKey和newKey。
KeyListener的removeKey和newKey方法對Cache中的滑動窗口SlidingWindow進行刪除或者累加，刪除或者達到一定訪問數就會推送到根據appname選出所有client進行推送。
京東的hotkey處理是通過計數來動態判斷是否為hotkey，然後緩存再本地內存中，做到毫秒級的scale out。那還有沒有其他解決方案？下面是我的觀點：
1.如果面對一些緩存key很少的場景，比如活動頁信息（同時進行的活動頁不可能超過1000），完全就可以直接將緩存放在本地內存中，到了刷新時間就從redis拉取最新緩存即可，不需要動態計算hotkey。也就是常見的多級緩存。
2.同樣是動態判斷hotkey，但會將hotkey遷移到專門的、更多節點、更高性能的hotkey redis集群中，集群中每個節點都有同一個hotkey緩存，這樣就可以做到請求的分散，避免流量都流向同一個redis節點，判斷是hotkey就去hotkey集群中取，不需要存在本地內存中了，維護起來會比較簡單。
⑵ 關於Spring Cloud Alibaba，看這篇文章就夠了！（附教程資料）
首先我們需要了解一下Spring Cloud，然後再來了解Spring Cloud Alibaba；
源自官方描述：
Spring Cloud為開發人員提供了一些工具用來快速構建分布式系統中的一些常見模式和解決一些常見問題（例如配置管理、服務發現、斷路器、智能路由、微代理、控制匯流排、一次性令牌、全局鎖、領導選舉、分布式會話、群集狀態）。分布式系統的協調導致了很多樣板式的代碼（很多固定套路的代碼），使用Spring Cloud開發人員可以快速建立實現這些模式的服務和應用程序。它們在任何分布式環境中都能很好地運行，包括開發人員自己的筆記本電腦、裸機數據中心和雲計算等託管平台；
Spring Cloud為分布式系統開發的典型應用場景提供良好的開箱即用的功能:
Spring Cloud Alibaba是Spring Cloud下的一個子項目，Spring Cloud Alibaba為分布式應用程序開發提供了一站式解決方案，它包含開發分布式應用程序所需的所有組件，使您可以輕松地使用Spring Cloud開發應用程序，使用Spring Cloud Alibaba，您只需要添加一些註解和少量配置即可將Spring Cloud應用程序連接到Alibaba的分布式解決方案，並使用Alibaba中間件構建分布式應用程序系統；
Spring Cloud Alibaba 是阿里巴巴開源中間件跟 Spring Cloud 體系的融合:
動力節點的Spring Cloud Alibaba學習教程，將帶你深入掌握基於Spring Cloud Alibaba技術棧的微服務開發技術，包括nacos、sentinel、seata、gateway、skywalking等，培養獨立進行企業微服務項目架構的能力;
Spring Cloud Alibaba視頻教程
https://www.bilibili.com/video/BV1nK4y
Spring Cloud Alibaba資料下載
http://www.bjpowernode.com/?toutiao
•001.視頻導讀
•002.Spring家族產品梳理
•003.What is Spring-Cloud-Alibaba？
•004.Nacos運行環境部署
•005.向Nacos注冊中心注冊服務
•006.從Nacos發現服務並負載均衡調用
•007.從Nacos發現服務並負載均衡調用
•008.Nacos客戶端信息緩存
•009.Nacos客戶端信息緩存
•010.Nacos Config配置中心啟動讀取外部配置
•011.Nacos Config配置中心自動刷新
•012.Nacos Config配置中心yaml配置
•013.Nacos Config配置中心多環境配置
•014.問答交流
•015.內容回顧-配置中心數據模型
•016.配置中心三層結構數據配置隔離
•017.配置中心三層結構數據配置隔離
•018.配置版本回滾-服務注冊分組
•019.Nacos管控台用戶許可權管理
•020.Nacos數據持久化
•021.Nacos數據持久化
•022.Nacos集群環境部署
•023.Nacos集群環境測試
•024.Nacos集群統一入口Nginx
•025.快速回顧
•026.RestTemplate無參數Get調用返回String
•027.RestTemplate無參數Get調用返回User
•028.RestTemplate有參數Get調用返回User
•029.RestTemplate有參數Get調用返回User
•030.RestTemplate有參數Post調用返回User
•031.RestTemplate有參數Post調用返回User
•032.RestTemplate傳輸User對象參數Post調用返回User
•033.RestTemplate傳輸JSON參數Post調用返回User
•034.RestTemplate有參數Put調用
•035.RestTemplate有參數Delete調用
•036.RestTemplate方法調用梳理總結
•037.RestTemplate結合Ribbon實現負載均衡
•038.RestTemplate結合Ribbon實現負載均衡
•039.Ribbon負載均衡實現策略
•040.自定義Ribbon負載均衡實現策略
•041.更改Ribbon負載均衡實現策略
•042.Ribbon的核心介面組成
•043.Ribbon負載均衡策略個性化配置
•044.Ribbon結合Nacos實現權重負載均衡策略
•045.Ribbon結合Nacos負載均衡策優先調用同名集群
•046.Ribbon結合Nacos基於版本負載均衡策略
•047.Ribbon結合Nacos基於命名空間負載均衡策略
•048.What is Feign？
•049.Spring Cloud Alibaba基於Feign的遠程調用
•050.Spring Cloud Alibaba基於Feign+Ribbon負載均衡遠程調用
•051.Spring Cloud Alibaba基於Feign的相關配置
•052.脫離Ribbon的Feign的遠程調用
•054.微服務的級聯故障服務雪崩
•055.Spring Cloud Alibaba集成Sentinel
•056.Spring Cloud Alibaba基於Sentinel管理後台數據測試
•057.Spring Cloud Alibaba基於Sentinel實現限流
•058.Spring Cloud Alibaba基於Sentinel實現限流自定義返回結果
•059.Spring Cloud Alibaba基於Sentinel實現限流自定義跳轉頁面
•060.Spring Cloud Alibaba基於Sentinel線程數限流
•061.Spring Cloud Alibaba基於Sentinel資源關聯限流
•062.Spring Cloud Alibaba基於Sentinel流控規則和流控效果
•063.問答交流
•064.快速回顧和演示環境預備
•065.Spring Cloud Alibaba Sentinel 服務降級RT
•066.Spring Cloud Alibaba Sentinel 服務降級異常比例和異常數
•067.Spring Cloud Alibaba Sentinel 熱點參數規則
•068.Spring Cloud Alibaba Sentinel 熱點參數規則小細節
•069.Spring Cloud Alibaba Sentinel 系統保護規則
•070.Spring Cloud Alibaba Sentinel 授權規則
•071.Spring Cloud Alibaba Sentinel Dashboard控制台通信原理
•072.Spring Cloud Alibaba Sentinel 對Controller請求url埋點
•073.Spring Cloud Alibaba Sentinel 手寫代碼實現埋點
•074.Spring Cloud Alibaba Sentinel 採用註解實現埋點
•075.Spring Cloud Alibaba Sentinel 對RestTemplate流控和熔斷
•076.Spring Cloud Alibaba Sentinel 對Feign流控和熔斷
•077.問答交流
•078.Sentinel規則持久化-拉模式持久化到本地文件
•079.Sentinel規則持久化-拉模式持久化到本地文件
•080.Sentinel規則持久化-推模式持久化到Nacos
•081.Sentinel規則持久化-推模式持久化到Nacos
•082.Spring Cloud Gateway 網關功能特性
•083.Spring Cloud Gateway 網關搭建
•084.Spring Cloud Gateway 網關服務調用
•085.Spring Cloud Gateway 網關謂詞
•086.Spring Cloud Gateway 網關謂詞
•087.Spring Cloud Gateway 網關謂詞
•088.Spring Cloud Gateway 網關過濾器
•089.Spring Cloud Gateway 問答交流
•090.Spring Cloud Gateway自定義謂詞
•091.Spring Cloud Gateway自定義謂詞
•092.Spring Cloud Gateway自定義謂詞不匹配404頁面
•093.Spring Cloud Gateway自定義過濾器
•094.Spring Cloud Gateway全局過濾器
•095.Spring Cloud Gateway自定義全局過濾器
•096.Spring Cloud Gateway集成Ribbon實現負載均衡
•097.Spring Cloud Gateway集成Sentinel限流
•098.Spring Cloud Gateway集成Sentinel限流自定義錯誤頁
•099.Spring Cloud Gateway集成Sentinel規則持久化到文件
•100.Spring Cloud Gateway集成Sentinel規則持久化到Nacos
•101.Spring Cloud Gateway內部執行流程源碼分析
•102.Spring Cloud Gateway小結
•103.快速回顧
•104.Spring Cloud Gateway跨域CORS請求
•105.Spring Cloud Gateway跨域CORS請求
•106.What is SkyWalking？
•107.Skywalking運行環境部署
•108.SkyWalking Agent對微服務的鏈路追蹤
•109.SkyWalking Agent對微服務鏈路追蹤
•110.SkyWalking Agent加入IDEA中對微服務鏈路追蹤
•111.SkyWalking 監控告警通知
•112.SkyWalking 監控告警通知
•113.SkyWalking 微服務鏈路追蹤數據持久化MySQL
•114.SkyWalking 問答交流
•115.Skywalking持久化跟蹤數據elasticsearch
•116.Skywalking持久化跟蹤數據elasticsearch
•117.Skywalking對多個跨服務的鏈路跟蹤
•118.Skywalking對多個跨服務的鏈路跟蹤
•119.Skywalking自定義鏈路跟蹤
•120.Skywalking集成logback輸出traceId日誌
•121.Skywalking UI界面-儀表盤
•122.Skywalking UI界面-拓撲圖-追蹤-性能剖析-告警
•123.Skywalking 基於nacos集群
•124.Skywalking 基於nacos集群
•125.Skywalking 基於nacos集群
•126.Skywalking 問答交流
•127.What is Seata？
•128.Seata分布式事務生命周期
•129.Seata TC Server運行環境部署
•130.Seata基於AT事務模式單體應用多數據源分布式事務
•131.Seata基於AT事務模式單體應用多數據源分布式事務
•132.Seata基於AT事務模式單體應用多數據源分布式事務
•133.Seata基於AT事務模式多個微服務分布式事務
•134.Seata基於AT事務模式多個微服務分布式事務
•135.Seata基於AT事務模式多個微服務分布式事務
•136.Seata基於AT事務模式執行機制
•137.Seata AT事務模式
•138.Seata AT事務模式寫數據隔離
•139.Seata AT事務模式寫數據隔離
•140.Seata AT事務模式讀數據隔離
•141.Seata AT事務模式讀數據隔離
•142.Seata TC Server集群環境部署
•143.Seata TC Server集群環境部署
•144.Seata TC Server集群環境集成測試
•145.Seata TC Server集群環境集成測試
•146.Seata TCC事務模式的運行機制
•147.Seata TCC事務模式SpringBoot單體應用案例
•148.Seata TCC事務模式SpringBoot單體應用案例
•149.Seata TCC事務模式SpringCloudAlibab微服務應用案例
•150.Seata TCC事務模式SpringCloudAlibab微服務應用案例
•151.What is Spring Cloud Stream
•152.Spring Cloud Stream的核心概念
•153.Spring Cloud Stream集成RocketMQ配置
•154.Spring Cloud Stream集成RocketMQ發送消息
•155.Spring Cloud Stream集成RocketMQ接收消息
•156.Spring Cloud Stream集成RocketMQ監聽接收消息
•157.Spring Cloud Stream集成RocketMQ多種發送消息方式
•158.Spring Cloud Stream Starter代碼分析
•159.Spring Cloud Stream集成RocketMQ發送事務消息
•160.Spring Cloud Stream集成RocketMQ對象標簽消息
•161.Spring Cloud Stream問答交流
⑶ 最好的python視頻教程誰有
你看看這個教程適不適合你，如果適合的話，可以找我要一下視頻！
階段一：Python開發基礎
Python全棧開發與人工智慧之Python開發基礎知識學習內容包括：Python基礎語法、數據類型、字元編碼、文件操作、函數、裝飾器、迭代器、內置方法、常用模塊等。
階段二：Python高級編程和資料庫開發
Python全棧開發與人工智慧之Python高級編程和資料庫開發知識學習內容包括：面向對象開發、Socket網路編程、線程、進程、隊列、IO多路模型、Mysql資料庫開發等。
階段三：前端開發
Python全棧開發與人工智慧之前端開發知識學習內容包括：Html、CSS、JavaScript開發、Jquery&bootstrap開發、前端框架VUE開發等。
階段四：WEB框架開發
Python全棧開發與人工智慧之WEB框架開發學習內容包括：Django框架基礎、Django框架進階、BBS+Blog實戰項目開發、緩存和隊列中間件、Flask框架學習、Tornado框架學習、Restful API等。
階段五：爬蟲開發
Python全棧開發與人工智慧之爬蟲開發學習內容包括：爬蟲開發實戰。
階段六：全棧項目實戰
Python全棧開發與人工智慧之全棧項目實戰學習內容包括：企業應用工具學習、CRM客戶關系管理系統開發、路飛學城在線教育平台開發等。
階段七：數據分析
Python全棧開發與人工智慧之數據分析學習內容包括：金融量化分析。
階段八：人工智慧
Python全棧開發與人工智慧之人工智慧學習內容包括：機器學習、數據分析 、圖像識別、自然語言翻譯等。
階段九：自動化運維&開發
Python全棧開發與人工智慧之自動化運維&開發學習內容包括：CMDB資產管理系統開發、IT審計+主機管理系統開發、分布式主機監控系統開發等。
階段十：高並發語言GO開發
Python全棧開發與人工智慧之高並發語言GO開發學習內容包括：GO語言基礎、數據類型與文件IO操作、函數和面向對象、並發編程等。
⑷ Pandora Bootstrap源碼分析
在我的認知里，是沒有辦法改變當前的classloder的，當前的 SpringApplication.run的時候，肯定是系統的classloder啊，就讓我們來揭開迷霧吧。
參數mainClass就是HSFProviderApplication這個有main方法的入口類
參數args就是main方法的參數
參數的classLoader是我們自己創建的classloader
由於我們創建的classloder是系統classloder的子類，我們就可以做文章了，中間件的類用新創建的classloder來載入，業務的類用系統的classloder來載入。是不是非常巧妙啊。孫改高
如何保證不會執行多次載入邏輯，甚至死循環的呢？第一遍是系統的classloder，第二遍雖然看上去是我們自己創建的classloder，但我們我們創建的classloder是委託給系統則尺的classloder的，所以其實還是相同的classloder。這就很簡單了，PandoraBootstrap執行第一遍之後就改一個bool變數，第二遍讀到這個變數改了就直接跳過殲或了。