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外，还有就是有性能更好，使用更方便的框架出现，而这些都是靠底层代码实现来决定的。