model源碼分析圖

⑴ Netflix Conctor 源碼分析——系統任務

系統任務是 Conctor 內部執行的任務，不需要 Worker 來實行執行。本文介紹系統任務(HTTP,EVENT,INLINE,JQ)如何被執行。註：不包含系統操作符Switch,DoWhile,SetVariable

所有的系統任務都繼承 WorkflowSystemTask 。在 Conctor 系統啟動時 SystemTaskRegistry 所有 WorkflowSystemTask 載入進來，後續可以通過 SystemTaskRegistry#isSystemTask 方法判斷是否為系統任務從而執行系統任務邏輯。

WorkflowSystemTask#start

第一次執行任務時調用，且只調用一次

WorkflowSystemTask#execute

在start方法後執行，可以被執行多次

入口 WorkflowExecutor#decide 。在該方法里，根據workflowId獲取接下來要調度的任務。
第 1327行 stateChanged = scheleTask(workflow, tasksToBeScheled) || stateChanged;
scheleTask 方法時執行調度邏輯。
第 1715行 List<TaskModel> systemTasks = tasks.stream() .filter(task -> systemTaskRegistry.isSystemTask(task.getTaskType())) .collect(Collectors.toList());
把系統任務過濾出來，並在 1740行 執行workflowSystemTask.start(workflow, task, this);

⑵ 詳解Spring mvc工作原理及源碼分析

Model 模型層 (javaBean組件 = 領域模型(javaBean) + 業務層 + 持久層）

View 視圖層（ html、jsp…）

Controller 控制層（委託模型層進行數據處理）

springmvc是一個web層mvc框架，類似struts2。

springmvc是spring的部分，其實就是spring在原有基礎上，又提供了web應用的mvc模塊。

實現機制：

struts2是基於過濾器實現的。

springmvc是基於servlet實現的。

運行速度：

因為過濾器底層是servlet,所以springmvc的運行速度會稍微比structs2快。

struts2是多例的

springmvc單例的

參數封裝：

struts2參數封裝是基於屬性進行封裝。

springmvc是基於方法封裝。顆粒度更細。

⑴ 用戶發送請求至DispatcherServlet。

⑵ DispatcherServlet收到請求調用HandlerMapping查詢具體的Handler。

⑶ HandlerMapping找到具體的處理器(具體配置的是哪個處理器的實現類)，生成處理器對象及處理器攔截器(HandlerExcutorChain包含了Handler以及攔截器集合)返回給DispatcherServlet。

⑷ DispatcherServlet接收到HandlerMapping返回的HandlerExcutorChain後，調用HandlerAdapter請求執行具體的Handler(Controller)。

⑸ HandlerAdapter經過適配調用具體的Handler(Controller即後端控制器)。

⑹ Controller執行完成返回ModelAndView(其中包含邏輯視圖和數據)給HandlerAdaptor。

⑺ HandlerAdaptor再將ModelAndView返回給DispatcherServlet。

⑻ DispatcherServlet請求視圖解析器ViewReslover解析ModelAndView。

⑼ ViewReslover解析後返回具體View(物理視圖)到DispatcherServlet。

⑽ DispatcherServlet請求渲染視圖(即將模型數據填充至視圖中) 根據View進行渲染視圖。

⑾ 將渲染後的視圖返回給DispatcherServlet。

⑿ DispatcherServlet將響應結果返回給用戶。

(1)前端控制器DispatcherServlet（配置即可）

功能:中央處理器,接收請求,自己不做任何處理,而是將請求發送給其他組件進行處理。DispatcherServlet 是整個流程的控制中心。

(2)處理器映射器HandlerMapping(配置即可)

功能:根據DispatcherServlet發送的url請求路徑查找Handler

常見的處理器映射器:BeanNameUrlHandlerMapping,SimpleUrlHandlerMapping,

,(不建議使用)

(3)處理器適配器HandlerAdapter（配置即可）

功能:按照特定規則（HandlerAdapter要求的規則）去執行Handler。

通過HandlerAdapter對處理器進行執行，這是適配器模式的應用，通過擴展多個適配器對更多類型的處理器進行執行。

常見的處理器適配器:HttpRequestHandlerAdapter，，

(4)處理器Handler即Controller(程序猿編寫)

功能:編寫Handler時按照HandlerAdapter的要求去做，這樣適配器才可以去正確執行Handler。

(5)視圖解析器ViewReslover(配置即可)

功能:進行視圖解析，根據邏輯視圖名解析成真正的視圖。

ViewResolver負責將處理結果生成View視圖，ViewResolver首先根據邏輯視圖名解析成物理視圖名即具體的頁面地址，再生成View視圖對象，最後對View進行渲染將處理結果通過頁面展示給用戶。

springmvc框架提供了多種View視圖類型,如:jstlView、freemarkerView、pdfView...

(6)視圖View(程序猿編寫)

View是一個介面，實現類支持不同的View類型（jsp、freemarker、pdf...）

引入相關依賴：spring的基本包、springmvc需要的spring-webmvc，日誌相關的slf4j-log4j12，jsp相關的jstl、servlet-api、jsp-api。

因為DispatcherServlet本身就是一個Servlet，所以需要在web.xml配置。

一、使用默認載入springmvc配置文件的方式,必須按照以下規范：

①命名規則:-servlet.xml ====> springmvc-servlet.xml

②路徑規則:-servlet.xml必須放在WEB-INF下邊

二、如果要不按照默認載入位置,則需要在web.xml中通過標簽來指定springmvc配置文件的載入路徑,如上圖所示。

將自定義的 Controller 處理器配置到 spring 容器中交由 spring 容器來管理，因為這里的 springmvc.xml 配置文件中處理器映射器配置的是 BeanNameUrlHandlerMapping ，根據名字可知這個處理器映射器是根據 bean (自定義Controller) 的 name 屬性值url去尋找執行類 Handler(Controller) , 所以bean的name屬性值即是要和用戶發送的請求路徑匹配的 url 。

根據視圖解析路徑：WEB-INF/jsps/index.jsp

功能:根據bean(自定義Controller)的name屬性的url去尋找執行類Controller。

功能:自定義的處理器(Controller)實現了Controller介面時，適配器就會執行Controller的具體方法。

會自動判斷自定義的處理器(Controller)是否實現了Controller介面，如果是，它將會自動調用處理器的handleRequest方法。

Controller介面中有一個方法叫handleRequest，也就是處理器方法。

因此,自定義的Controller要想被調用就必須實現Controller介面,重寫Controller介面中的處理器方法。

⑶ iOS源碼解析—YYModel（NSObject+YYModel）

​ iOS源碼解析—YYModel（YYClassInfo） 分析了如何根據OC的Class對象構建YYClassInfo對象，為接下來的JSON數據和Model轉換作準備，這篇文章開始講解NSObject+YYModel。

​ 分析NSObject+YYModel.h文件，包括3個Category和一個protocol，分別是：

字典studentDic中的key對應原字典playerDic中的key，studentDic中的Model由playerDic中的value轉化得到。

首先定義了兩個類，_YYModelMeta和_YYModelPropertyMeta，分別封裝了Model的信息和Model中各屬性的信息。

_YYModelMeta維護了Class的相關信息，下面是注釋：

_YYModelMeta是通過YYClassInfo對象的信息構建得到的。首先調用metaWithClass:cls方法，該方法如下：

維護了一個鍵值對cache作為緩存，用cls作為key，調用CFDictionaryGetValue方法去緩存中查找，如果有，直接返回構建好的_____YYModelMeta對象，如果沒有找到或者needUpdate屬性標記為true，則根據cls創建一個新的_YYModelMeta對象，並且存入緩存。這樣不需要每次都創建，提高了性能。

接下來看一下initWithClass:方法，

下面分析幾個重要的方法：

YYModel的總體思想是以Model屬性的類型為准，如果JSON中對應名稱的value的類型和Model屬性類型不一致，會對value的類型進行轉化，保證和Model屬性的類型一致。如果兼容不了，不進行屬性賦值。下面分析一下ModelSetValueForProperty方法：

該方法上文中提到該方法是用來JSON轉成Model的過程中對Model中的屬性進行賦值的方法，該方法做了部分基本類型的兼容：

YYModel還提供了一些工具方法，下面簡單分析一下：

YYModel作為一個負責JSON數據和Model轉化的庫，十分易用和高效，特別是做了一些類型的兼容和轉化，避免了服務端介面數據類型和客戶端Model對象類型不兼容導致的問題，例如執行了不存在的方法而導致崩潰。另一方面，對YYModel的學習在一定程度也促進了對runtime機制的學習和了解。

關於YYModel的分析到這兒先告一段落，由於本人的iOS基礎有待提升，再加上表達能力有限，文中許多地方的分析和思路，表達的不是很准確和清楚，希望通過今後的學習和練習，提升自己的水平。

⑷ 京東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集群中取，不需要存在本地內存中了，維護起來會比較簡單。

⑸ 什麼叫底層代碼

底層代碼是指被封裝好的代碼，底層代碼寫的就是比較原始，比較基礎的代碼。底層代碼編寫是非常接近機器的編程，使用底層開發語言（如C或匯編）。這與使用高級語言（例如Python，Java）的程序員進行編程不同。

對於java來說，底層代碼一般是指框架的實現代碼，這些代碼一般都是一些常用代碼或比較接近於原始的代碼，這些代碼封裝好，可以方便復用和調用。而對一些操作系統來說，底層代碼可能就是c或者匯編，寫底層代碼就是做底層開發。比如java的Map類，底層代碼實現：

(5)model源碼分析圖擴展閱讀

編寫底層代碼一般要比較深厚的功底，對程序設計，代碼涉及的各個方面，性能，耦合度，復用性都要很深的掌握和考慮，熟練掌握設計模式,良好的編程習慣，代碼優雅，數據結構，精通各種演算法。

很多java框架被淘汰，除了本身有致命的bug外，還有就是有性能更好，使用更方便的框架出現，而這些都是靠底層代碼實現來決定的。