分类 : 818个相关结果 99次浏览

Elasticsearch
分布式搜索和分析引擎。具有高可伸缩、高可靠和易管理等特点。基于 Apache Lucene 构建,能对大容量的数据进行接近实时的存储、搜索和分析操作。

Logstash
日志收集器。搜集各种数据源,并对数据进行过滤、分析、格式化等操作,然后存储到 Elasticsearch。

Kibana
数据分析和可视化平台。与 Elasticsearch 配合使用,对其中数据进行搜索、分析、图表展示。

Filebeat
一个轻量级开源日志文件数据搜集器,Filebeat 读取文件内容,发送到 Logstash 进行解析后进入 Elasticsearch,或直接发送到 Elasticsearch 进行集中式存储和分析。

  01 style.css : CSS(样式表)文件 02 index.php : 主页模板 03 archive.php : Archive/Category模板 04 404.php : Not Found 错误页模板 05 comments.php : 留言/回复模板 06 footer.php : Footer模板 07 header.php : Header模板 08 sidebar.php : 侧栏模板 09 page.php : 内容页(Page)模板 10 single.php : 内容页(Post)模板 11 searchform.php : 搜索表单模板 12 search.php : 搜索结果模板   http://blog.csdn.net/sgdingye/article/details/51906320      

近日,杭州千岛湖环湖公路上发生一起交通事故,一货车超车时将前面轿车撞入湖中。阿里云存储团队的工程师刘新停等人恰好驾车路过,见状立刻下车开展援救。 此时已是初冬,寒流刚刚南下,面对冰冷的湖水,刘新停没有犹豫,衣服裤子也没脱就跳进水中,及时营救出一名孕妇及同车三人 http://mp.weixin.qq.com/s/wLqYk3YqwfZS4vKeeSsbtg

阿里巴巴于10月14日上午9:00在杭州云栖大会《研发效能峰会》上,正式发布《阿里巴巴Java开发手册》扫描插件。下面分享这个插件,希望更多的人使用,提高我们的代码/编码的规范! 阿里代码规约插件相关内容: 视频地址:https://yunqi.aliyun.com/#/video/detail1420 翘首期盼247天!《阿里巴巴Java开发手册》扫描插件正式发布: https://mp.weixin.qq.com/s/KcPtgFbnU6CS3L49EKcnDg 《阿里巴巴Java开发规约》IDEA插件与Eclipse插件使用指南【云栖社区】 http://mp.weixin.qq.com/s/GjrbDp6ZF_vPDoHyhImShw ​阿里巴巴代码规范扫描插件github地址: ​https://github.com/alibaba/p3c 阿里巴巴Java开发手册(终极版): https://github.com/alibaba/p3c/blob/master/阿里巴巴Java开发手册(终极版).pdf 下面是我在Eclipse安装插件的过程和具体测试代码的分析示例: 在github中已经具体说明了Eclipse和Idea的开发工具如何安装插件,下面就都进行简单的介绍和说明! 安装注意版本问题: 我在IDEA上安装这个插件的时候,报错 Plugin Alibaba Java Coding Guidelines was not installed: Cannot download ‘https://plugins.jetbrains.com/pluginManager/?action=download&;id=com.alibaba.p3c.smartfox&build=IU-172.4343.14&uuid=9f9fc264-a025-47ed-9bdc-c12871794d1c’: Read timed out 1 2 开始我以为是版本问题,我更新了IDEA最新版本,注意更新重新安装的时候,不要删除之前IDEA的配置信息。但是安装之后,发现还是不行,我真NC了,上面错误明显是 Read timed out !于是我马上断开我的wifi,用我手机开了个热点,一试之后,下载蹭蹭的!开心!【总结:如何报这个错误,请检查网络】 IDEA版的插件 : 我们发布到了IDEA官方仓库中(最低支持版本14.1.7,JDK1.7+) Eclipse版插件 : 支持4.2(Juno,JDK1.8+)及以上版本 注意代码一定要编译过后在进行 扫描,否则结果可能不完整! 1.Eclipse安装和使用介绍 第一步:安装插件 Help >> Install New Software 然后在框中输入URL: https://p3c.alibaba.com/plugin/eclipse/update 安装完成后,重启Eclipse! 然后右键可以看到,第一次显示 然后点击切换为中文: 第二步:简单使用插件 编写了一个不符合阿里代码规约的例子,进行测试,代码如下: /** * 测试阿里代码规约插件 * @author dufyun * */ //命名风格:3 — ALibabapluginTest,没有按照驼峰法 public class ALibabapluginTest { //命名风格:1 — _name ,不能以 下划线或美元符号 private String _name; //命名风格:2 — 严禁使用拼音与英文混合的方式 public void DaZhePromotion(){ System.out.println(“打折方法”); } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 右键,选择 阿里编码规约扫描,结果如下图 : 2.IDEA安装和使用介绍 安装和使用和Eclipse大同小异,具体安装也可以参考github介绍。 第一步:插件安装 Settings >> Plugins >> Browse repositories… 搜 Alibaba 就可以。 安装 然后重启; 就可以看见Tools 》》 阿里编码规约 第二步:简单使用插件 请看下图,注意代码一定要编译过后在进行 扫描,否则结果可能不完全! 附: 阿里云的代码检测 登录云效公有云官网(https://www.aliyun.com/product/yunxiao)(云效>公有云>设置->测试服务->阿里巴巴Java代码规约)。 阿里云界面:【因为我没有阿里云上的代码,没法进行测试!】 本次分享暂时就是这些,也欢迎和大家一起讨论,谢谢大家阅读! …

前言 一线程序员在工作中经常需要处理线上的问题或者故障,但工作几年下来发现,有些同事其实并不知道该如何去分析和解决这些问题,毫无章法的猜测和尝试,虽然在很多时候可以最终解决问题,但往往也会浪费大量的时间,时间就是金钱,对线上系统而言甚至是生命。 本文讲什么:本文尝试将本人工作过程中对线上问题的处理经验加以总结精炼,并给出一套相对有规律的问题定位处理模式,希望能够在排查问题的过程中可以帮助大家节省一些时间,尽快找出问题的关键点并修复。 本文不讲什么:1. 这不是一篇linux命令的教程,虽然文章里会提到一些命令,但只会简单介绍他们的作用和应用场景,详细使用说明请大家自行google。2. 本文不打算为所有问题寻找解决方案,事实上下面列出的方法只对大部分Java编写的web系统比较有意义,一些特别个性化的案例也不再讨论范围之内。 了解你的系统 什么样的现象应该列为“系统问题”?某个服务的QPS达到1000?对于一般系统或许算是,但是对大型电商网站,或许这只是常态。 很显然对于不同规模,不同功能的系统,这个问题无法一概而论。因此快速发现问题的前提是深入了解你的系统。 通常情况下,我们可以把系统简单的划分为下面三个层次: 系统层 也就是我们的部署软硬件环境。通常包含CPU、磁盘、内存、网络IO等。我们的系统是分布式的,还是单机应用?CPU是几核的?物理机还是虚机?内存、磁盘是多大?网卡的规格? 软件层 也是我们部署的软件环境。负载均衡服务器?JDK版本?web服务器(Tomcat等)以及JVM参数设置?数据库、缓存使用的是哪种产品? 应用层 也就是我们的系统本身。关键接口的平均响应时间(RT)是多少?服务的QPS是多少?某个接口的并发数能承受多少? 以上这些问题你是否能回答出来?这些问题的了解多寡,决定了你对系统的熟悉程度,也在很大程度上决定了你能否及时的发现问题,甚至在其真正造成影响之前就将问题解决。 现在你或许能回答:某个服务的QPS达到1000,究竟算不算是线上问题。 评估问题影响范围 一个问题究竟影响了多大范围的用户?在多大程度上影响用户的正常使用?如果是集群系统,那么这个问题是全局性的还是只在单台机器上出现?不同的问题范围会直接影响到问题处理的优先级,一些极端情况下的个案,甚至可以不急于处理(至少不用过于焦虑)。 问题信息的搜集来源,有如下途径: 系统、业务监控报警 一般稍微上规模的公司,都会有配套的监控系统,通常监控系统报警都意味着问题已经影响到系统的正常运行了,此时属于比较严重的生成事故,需要第一时间处理。此类问题由于可以重现,因此比较容易排查。 关联系统故障追溯 关联系统发现问题,通过追溯发现是由本系统的问题引发的,此时问题的触发的往往已经比较明确,需要根据关联系统的故障程度决定问题处理的优先级。但此类问题很容易牵扯出隐藏的其他问题(如系统改造时沟通不善造成的适配问题等),紧急修复后还需要进行进一步仔细排查。 生产事件上报(客服上报) 此类问题往往来自用户投诉,最重要的就是问题现象的复现。 主动发现 通过线上监控,或者日志,主动发现线上系异常的情况。需要确认是否是问题,可能只是偶发性的系统抖动。 快速恢复 说回问题本身,一旦确定是系统bug,该如何处理?立即去检查代码?且不说线上bug往往不那么容易检查出来,及时能够快速定位,修复又会耗费大量时间,这期间不知有多少用户受到影响。 线上问题处理的核心是快速修复。有以下两类处理方案: 1. 无法快速定位到问题根源   回滚:当最近有新版本上线时,多半首选这种方案 重启:CPU高,或者连接数飙升时,会采取这种方法 扩容:线上访问压力大,重启也无法解决时   2. 可以定位到问题点的   临时方案或者功能降级 无论哪种方式,目标都是以最快速度恢复服务。但这种方式是临时的,为了彻底解决问题,都需要保留事故现场。基本方式如下: a. 执行top命令,若CPU空闲程度较低:shift+p按CPU使用率倒排,记录最耗资源的进程信息。 b. 执行free –m命令,若内存使用量高:执行top,shift+m按内存使用率倒排,记录最耗资源的进程信息。 c. 对嫌疑进程执行ps xuf | grep java,打印进程详细信息并记录。 d. 使用jstack <PID> >jstack.log收集线程信息(反复多取几次)。 e. 使用jstat–gcutil <PID> 查看Old区占用率,对接近100%的进程执行jmap<PID> > jmap.log保留内存信息。 定位与修复 下图展示了常规情况下我们系统故障的原因:  图1-系统故障原因 由此可见,多数情况下,系统的故障都会反映为系统的一项或者多项指标异常。如最初所说,我们可以将整个系统抽象成为几个模块,那么对应的,每个模块也有一些工具供我们进行问题的分析与定位。 图2-Linux常用工具集 以下是常见的问题排查工具箱: CPU:top –Hp 系统内存:free –m IO:iostat 磁盘:df –h 网络链接:netstat gc:jstat –gcutil 线程:jstack Java内存:jmap 辅助工具:MAT,btrace,jprofile 具体的使用方法不再赘述 方法论 有了基本的系统模块划分,以及每个模块对应的分析工具,我们可以尝试将问题的排查抽象成一个相对固定的流程。大致的思路是: 先逐个模块排查,确认问题现象 再根据问题现象,定位问题进程 进一步分析线程以及内存情况 最终找到问题的触发点。 基本流程如下图所示: 图3-逐步排查,锁定问题进程 图4-详细分析目标进程 为故障与失败做设计 随着系统规模的逐渐扩大,更多的功能被引入,更多的代码被添加进来,从这个角度来看线上的问题几乎是无可避免的。以上说的都是问题发生后的消极应对措施。事实上,无论我们的设计多么的完善,故障仍然是无法避免的。而且大多数时候,失败、故障都会从一个我们无法预期的角度发生,令人猝不及防。 因此在系统架构时需要设计一种机制,使得失败、故障发生时能将系统的损失降到最低,在故障发生时尽可能维持核心功能的可用性。 1. 设置合理的超时机制   处理网络上第三方依赖时,需要对接口的响应时间有一个合理预期,当请求超时时能够主动断开连接,避免请求堆积。 本地服务相互调用时也需要合理的设置超时时间。 2. 服务降级   对于无法正常响应的应用程序应对可以自动切换到较低版本的实现。 对于一些次重要级的接口,可以考虑返回一个系统默认值。 3. 主动抛弃   对于响应过慢的第三方接口,如果非核心调用,也可以采取直接抛弃的方式。 无论是降级或者抛弃,系统都应当具备适当的重试机制,使得依赖在回复之后可以自动恢复正常调用。 作者简介 孙思,转转交易系统负责人,08年北航计算机系虚拟现实实验室研究生毕业。毕业后入职中国民航信息网络股份有限公司(TravelSky),负责机票发布平台(EasyFare)的研发和维护工作。2010年进入互联网行业,先后供职于网易(北京)、搜狐和去哪儿网,参与过网易电商基础平台建设,活动及促销运营平台的设计与实现;搜狐新闻客户端的开发、重构,以及去哪儿网旗下当地人产品的交易、支付系统的升级改造。2016年04月加入转转公司,担任中台技术部交易系统负责人,整体负责转转的交易系统、支付中心以及活动促销运营等系统的研发工作。对大规模电商平台、分布式系统的设计和实现有较深入的了解。 出处:https://mp.weixin.qq.com/s/4HTW3BmW1HfGyVmomO1Wrw   版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。

今天用git pull来更新代码,遇到了下面的问题: [html][/html] view plain copy error: Your local changes to the following files would be overwritten by merge:     xxx/xxx/xxx.java Please, commit your changes or stash them before you can merge. Aborting 提示已经很友好了,从网友处得到的答案直接帮我解决问题。 1.stash 通常遇到这个问题,你可以直接commit你的修改;但我这次不想这样。 看看git stash是如何做的。 git stash git pull git stash pop 接下来diff一下此文件看看自动合并的情况,并作出相应修改。 git stash: 备份当前的工作区的内容,从最近的一次提交中读取相关内容,让工作区保证和上次提交的内容一致。同时,将当前的工作区内容保存到Git栈中。 git stash pop: 从Git栈中读取最近一次保存的内容,恢复工作区的相关内容。由于可能存在多个Stash的内容,所以用栈来管理,pop会从最近的一个stash中读取内容并恢复。 git stash list: 显示Git栈内的所有备份,可以利用这个列表来决定从那个地方恢复。 git stash clear: 清空Git栈。此时使用gitg等图形化工具会发现,原来stash的哪些节点都消失了。 2.放弃本地修改,直接覆盖之 git reset –hard git pull  

自 Git@OSC 上线以来受到广大开源作者的喜爱。值此新年之际,开源中国整理出 Git@OSC 最热门开源项目 Top50,对 Git@OSC 的发展至今所取得的成绩进行总结。此榜单主要通过开源项目的 Watch、Star、Fork 数量来评定,项目类型不尽相同,难免有纰漏,如有遗漏或者不妥之处,希望大家批评指正。若您对 Git@OSC 未来的发展有何意见或者建议,也欢迎在评论区留言告诉我们。 下面是项目列表: 1、JFinal 项 目简介:JFinal 是基于 Java 语言的极速 WEB + ORM 框架,其核心设计目标是开发迅速、代码量少、学习简单、功能强大、轻量级、易扩展、Restful。在拥有Java语言所有优势的同时再拥有ruby、 python、php等动态语言的开发效率!为您节约更多时间,去陪恋人、家人和朋友 2、jeewx 项目简介:免费开源JAVA微信管家平台,实现了微信平台的基础功能,便于用户二次开发。JEEWX支持微信第三方平台全网发布、支持微信插件开发机制,可轻松集成微信H5插件。 3、tiny 项目简介:值得拥有的企业级j2ee应用开发框架套件,专业团队开发,完整的生态体系,活跃的社区氛围,无限的水平扩展能力,7*24不间断运维能力。 4、CMS 一款使用Java语言开发的CMS,使用了Spring MVC,Spring,MyBatis等流行框架,提供首页大图管理、目录管理、文章管理和管理员管理等功能。是学习和二次开发的首选。 5、jeecg 项 目推荐:JEECG是一款J2EE企业级快速智能开发平台,开源界“小普元”超越传统商业企业级开发平台。基于代码生成器,引领新的开发模式 (Online Coding模式(自定义表单)->代码生成器模式->手工MERGE智能开发), 可以帮助解决Java项目60%的重复工作,让开发更多关注业务逻辑。既能快速提高开发效率,帮助公司节省人力成本,同时又不失灵活性。 6、Mybatis_PageHelper 项目简介:Mybatis_PageHelper 是 Mybatis 分页插件,支持任何复杂的单表、多表分页。 7、JeeSite 项目简介:JeeSite 是一个企业信息化开发基础平台,Java EE(J2EE)快速开发框架,使用经典技术组合(Spring、Spring MVC、Apache Shiro、MyBatis、Bootstrap UI),包括核心模块如:组织机构、角色用户、权限授权、数据权限、内容管理、工作流等。 8、LigerUI 项目简介:基于jQuery的UI框架,包括表单、布局、表格等等常用UI控件,使用LigerUI可以快速轻松地创建风格统一的界面效果。 9、CrossApp 项目简介:一款完全开源、免费、跨平台的移动应用开发引擎,开发者可以完全免费、毫无顾虑的使用CrossApp开发任何项目。本引擎基于C++语言编写,OpenGl ES2.0图形渲染。拥有丰富的UI控件、丰富的第三方库、集成各种系统接口。 10、thinkphp 项目简介:ThinkPHP 是一个免费开源的,快速、简单的面向对象的 轻量级PHP开发框架 ,创立于2006年初,遵循Apache2开源协议发布,是为了敏捷WEB应用开发和简化企业应用开发而诞生的。ThinkPHP从诞生以来一直秉承简洁 实用的设计原则,在保持出色的性能和至简的代码的同时,也注重易用性。 11、KJFrameForAndroid 项目简介:KJFrameForAndroid的设计思想是通过封装Android原生SDK中复杂的复杂操作而达到简化Android应用级开发,最终实现快速而又安全高效的开发APP。我们的目标是用最少的代码,完成最多的操作,用最高的效率,完成最复杂的功能。 12、zbus 项目简介:ZBUS=MQ+RPC+PROXY 服务总线  1)支持消息队列, 发布订阅, RPC, 代理(TCP/DMZ)   2)亿级消息堆积能力、支持HA高可用  3)无依赖单个Jar包 ~300K   4)丰富的API–JAVA/C/C++/C#/Python/Node.JS多语言接入,支持HTTP/Thrift等协议接入 13、ECP 项目简介:ECP  是基于jfinal、avalon、bootstrap、jqGrid、snaker工作流开发的客户关系及进销存财务系统。支持多企业使用。 14、jfinal-weixin 项目简介:JFinal Weixin 是基于 JFinal 的微信公众号极速开发 SDK,只需浏览 Demo 代码即可进行极速开发,自 JFinal Weixin 1.2 版本开始已添加对多公众号支持。 15、cim 项目简介:基于apache  mina 的 java即时通讯服务端。与android 客户端完美结合,同时支持其他语言(ios,c,ActionScript,.net等)客户端的即时通信。 16、webmagic 项目简介:webmagic的是一个无须配置、便于二次开发的爬虫框架,它提供简单灵活的API,只需少量代码即可实现一个爬虫。 17、Mapper 项目简介:极其方便的使用Mybatis单表的增删改查。通用Mapper都可以极大的方便开发人员。可以随意的按照自己的需要选择通用方法,还可以很方便的开发自己的通用方法。 18、smart-framework 项目简介:轻量级 Java Web 开发框架,内置 IOC、AOP、ORM、DAO、MVC 等特性,基于 Servlet 3.0 规范,使用 Java 注解取代 XML 配置。 19、git-quick-start 项目简介:这是一个git的快速入门项目,使用一些gif图片来播放一些基础的git命令使用方法。 20、EasyPR 项目简介:EasyPR是一个中文的开源车牌识别系统,其目标是成为一个简单、高效、准确的车牌识别引擎。 相比于其他的车牌识别系统,EasyPR有如下特点: …

一、背景 1.1.什么是批量处理 维基百科给批量处理的定义是指在没有人工干预的情况下,由一个计算机程序基于一份批量的输入执行一系列的任务的一种处理模式。这句话可能有点拗口,简单来说,批量处理是一种处理模式,这种模式在进行数据处理时,输入数据一般包含多条,处理过程中一般没有人工交互。而另一种主流的处理模式,联机处理与批量处理的最主要区别就是,联机处理中一般一条输入数据就产生一次处理过程,然后直接将结果反馈给调用方。批量处理曾经在早期的计算机处理模式中占据统治地位。 1.2.批量处理拥有广泛的使用场景 我们先来看下批量处理的特点: 批量处理单次执行就可以处理大量数据,而联机处理中单次执行一般只能处理少量数据。 批量处理每次需要处理大量的数据,执行时间将较长,而联机系统需要实时、快速响应调用方的请求。 批量处理不需要维持与调用方的连接,执行结果一般通过报告等形式通知调用方,资源利用率比较高。 批量处理可以选择将处理时间放在计算资源不那么紧张的时间段,更好的利用系统资源。 从批量处理的特点我们可以看到,在实时性、交互性要求不高,同时待处理的数据量比较大的场景下,就可以考虑使用批量处理的模式。而实际各种业务系统中通常都会存在大量适合使用或者正在使用批量处理的场景,常见的如银行的对账、网银的批量待发工资、日志系统中批量备份日志等。我们大家可能都会有从支付宝里提现至银行卡的经历,通常提现并不是实时的,支付宝会给你一个deadline,这中间支付宝与银行之间数据对账就是采用批量处理完成的。 1.3.批量处理需要良好的架构设计 在最简单的批量处理场景下,我们可以通过编写脚本,在类Unix系统中通过cron程序定时启动执行。但是这种模式仅仅适合单机处理的情况,没有分布式处理的能力,同时也没有办法进行统一的监控管理。在实际使用时,可能同时存在数量巨大的批量任务,如何管理与调度这些任务将是个巨大的挑战。设计良好的批量处理框架可以简化批量任务开发过程,减少配置时间,提高整体稳定性。笔者曾经参与过某银行BPM系统批量处理框架的设计,一开始设计比较简单,在各个服务器部署批量脚本,基于cron执行,通过数据库进行结果统计,在项目上线初始阶段,由于批量任务比较少,所做的工作也比较简单,该设计能够基本满足需求,但是随着项目上线后,批量任务越来越多,场景越来越复杂(比如需要支持数据库服务器HA切换时批量任务不重复执行),原有设计已经越来越力不从心,最后只有推倒重新设计,费时又费力,由此可见一个好的批量处理框架设计是多么的重要。本文将通过分析批量处理中的两个关键环节,结合一些开源的批量处理框架,来聊一聊如何更好地进行批量处理型架构的设计。 二、批量处理中的关键设计 批量处理中两个关键环节是批量任务设计和任务调度设计: 批量任务设计:统一规定了作业的定义、编排、执行等过程,良好的作业模型可以隐藏了内部复杂性,简化具体作业开发难度,更好的支持调度过程。 任务调度设计:通俗的说调度就是控制作业在什么时候由那些资源(节点、线程等)去执行,同时还包含作业执行失败后的处理等内容。 2.1从SpringBatch看批量任务设计模式 2.1.1传统批量作业结构 我们首先来看一下过去几十年间已经被广泛使用的批量作业结构: 图1 批量作业结构 这个架构图非常简单,传递了批量作业中最重要的几个领域概念: JobLauncher:该领域对象是Job的启动器,其作用就是启动Job。 Job:定义,配置批处理任务的领域对象,该对象的作用,是做Step的容器,配置该批处理任务需要的Step,以及他们之间的逻辑关系。 Step:定义批处理任务中一个对立的逻辑任务处理单元。基本上的业务逻辑处理代码都是封装在Step中的,这种形式定义了一个Step的流程必须是“ItemReader- ItemProcessor(可选)-ItemWriter”。 JobRepository:该领域对象会为Job的运行数据提供一种持久化机制,为所有的Job提供CRUD的操作接口,并为所有的操作提供事务支持。 在这种设计模式下,任务的定义执行过程变得非常清晰,使用这只需要关注于每个Step中的具体业务实现即可,通过简单的配置就能完成任务的设计。 2.1.2. SpringBatch中的任务设计模式: 传统批量作业结构在好几代平台和编程语言中已经被证明为非常合理和有效。著名Java开源批处理框架SpringBatch就是实现了这种作业结构,不过除此之外,SpringBatch还加入了自身一些设计: 图2 SpringBatch作业模型 上图展现了SpringBatch中的几个概念模型: JobInstance:该领域概念和Job的关系与Java中实例和类的关系一样,Job定义了一个工作流程, JobInstance就是该工作流程的一个具体实例。一个Job可以有多个JobInstance,多个JobInstance之间的区分就要靠另外一个领域概念JobParameters了。 JobParameters:是一组可以贯穿整个Job的运行时配置参数。不同的配置将产生不同的JobInstance,如果你是使用相同的JobParameters运行同一个Job,那么这次运行会重用上一次创建的JobInstance。 JobExecution:该领域概念表示JobInstance的一次运行,JobInstance运行时可能会成功或者失败。每一次JobInstance的运行都会产生一个JobExecution。同一个JobInstance(JobParameters相同)可以多次运行,这样该JobInstance将对应多个Jobexecution。JobExecution记录了一个JobInstance在一次运行时的发生的所有事情,因此,一个JobExecution需要包含很多的属性,并且需要持久化,这样才能很好的支撑Restart等Spring Batch特性。 StepExecution: 类似于JobExecution,该领域对象表示Step的一次运行。Step是Job的一部分,因此一个StepExecution会关联到一个Jobexecution。另外,该对象还会存储很多与该次StepExecution运行相关的所有数据,因此该对象也有很多的属性,并且需要持久化以支持一些Spring Batch的特性。 同时,为了提高作业运行时效率, SpringBatch中还同时提供了几种并行处理方案: 多线程处理,一个Step的处理过程可以配置一个包含多个线程资源的线程池处理。 并行Step处理,根据任务的特点,可以将任务中的多个不同的Step进行分组,形成多个流,这多个流可以并行处理。 Step远程分片处理,下图为Step远程分片模型: 图3 远程分片模型 在远程分片模型中,某一个Step中由Master节点去读取数据,但是处理的过程,由Master分配给多个Slaves去处理,在这种模型中,Master节点的读取能力不能成为整个Step的瓶颈。 Step分区处理,这种模式跟远程分片处理过程很类似,不同是,分区处理中Master节点不负责读取数据,而是由该Step中的各个分区独立去读取和处理,当然这种模式下如何将数据进行合适的分区很重要,并不是所有Step都适合这种模式去处理。 2.1.3 SpringBatch的不足 可以看到SpringBatch中提供了一套非常完善的批量任务设计模式,但是SpringBatch也有不足的地方: SpringBatch本身不提供调度的能力,调度依赖于quartz,quartz虽然可以进行集群调度作业,一个节点挂了可以将任务漂移给其他节点执行从而避免单点故障,但是不支持分布式作业,一旦达到单机处理极限也会存在问题。 SpringBatch中虽然提供了一些并行处理方案,但是分片、多线程这些方案都非常依赖于任务配置,没有提供一种自动化的机制去灵活地进行资源的调度。 2.2任务调度设计 2.2.1两种调度模式 常见分布式调度系统在设计上主要有中心化和去中心化两种模式: 2.2.1.1. 中心化的调度模式 下图为中心化的调度模式结构图: 图4中心化的调度模型 如上图所示,在中心化的调度模式下,一般都有一个Leader节点用来负责拉取任务的调度信息,然后向各个Follower节点分派任务,由Follower节点完成任务的执行。同时为了保证整个系统的高可用,Leader节点一般会采取主备模式,当一个Leader节点失效时,备用节点会接管Leader节点工作。 2.2.1.2. 去中心化的调度模式 下面再来看一下去中心化模式: 图5去中心化的调度模型 在去中心化的调度模式下,没有调度中心节点这个概念,所有节点都是工作节点,节点之间通过注册中心进行分布式协调,但是在这种模式下,一般会有一个主节点用于处理一些集中式任务,如分片,清理运行时信息等,并无调度功能,定时调度都是由作业节点自己触发执行。 下面对比一下两种调度模式各自的优缺点: 表1 中心化和去中心化调度比较 2.2.2. TBSchedule中的调度设计 TBSchedule是由Taobao开源的一款非常优秀的高性能分布式调度框架,TBSchedule的使用非常广泛,目前被应用于淘宝、京东、国美、等很多互联网企业的调度系统。TBSchedule有如下特点: 支持集群、分布式 灵活的任务分片 动态的服务扩容和资源回收 任务监控支持 TBSchedule支持Cluster,可以宿主在多台服务器多个线程组并行进行任务调度,或者说可以将一个大的任务拆成多个小任务分配到不同的服务器。 TBSchedule的分布式机制是通过Sharding方式实现的,比如可以按所有数据的ID按10取模分片、按月份分片等等,根据不同的需求,不同的场景由客户端配置分片规则。TBSchedule的宿主服务器可以进行动态扩容和资源回收,这个特点主要是因为它后端依赖的ZooKeeper,这里的ZooKeeper对于TBSchedule来说是一个NoSQL,用于存储策略、任务、心跳信息数据,它的数据结构类似文件系统的目录结构,它的节点有临时节点、持久节点之分。调度引擎上线后,随着业务量数据量的增多,当前Cluster可能不能满足目前的处理需求,那么就需要增加服务器数量,一个新的服务器上线后会在ZooKeeper中创建一个代表当前服务器的一个唯一性路径(临时节点),并且新上线的服务器会和ZooKeeper保持长连接,当通信断开后,节点会自动摘除。下图为TBSchedule的基本结构图,从图上可以到,TBSchedule从整体上来说遵循的是去中心化的调度模式,每个节点都可以从ZooKeeper中拉取任务去执行。 图6 TBSchedule结构图 TBSchedule提供了两个核心组件ScheduleServer、TBScheduleManagerFactory。 ScheduleServer即任务处理器,的主要作用是任务和策略的管理、任务采集和执行,由一组工作线程组成,这组工作线程是基于队列实现的,进行任务抓取和任务处理。每个任务处理器和ZooKeeper有一个心跳通信连接,用于检测Server的状态和进行任务动态分配。 调度服务器TBScheduleManagerFactory的主要工作ZooKeeper连接参数配置和ZooKeeper的初始化、调度管理。 TBSchedule中的用户目标任务是通过实现任务接口实现的,任务接口中包含selectTasks和execute两个方法,分别对应任务的采集和执行过程。 2.2.3. TBSchedule的不足 尽管TBSchedule已经很优秀,尤其是资源调度这块,但是TBSchedule也有不足的地方: TBSchedule中对于批量任务开发的指导比较欠缺,这点SpringBatch中做的很好。 TBSchedule中任务执行是相互独立的,而在在实际使用场景中很多任务执行必须依赖于另一个任务,甚至可能多个任务之间都有相互关系,形成任务流这种形式,任务流需要以可视化的方式进行编排和执行时的管理,TBSchedule没有提供这种能力。 目前TBSchedule中如果上线一个新服务器,需要通过手动的方式去启动,没有结合这几年流行的容器技术,实现服务资源的动态伸缩。 四、总结 随着计算机技术的发展,在C/S和B/S软件体系结构中,联机处理模式已经慢慢成为最主要的数据处理模式,尽管如此,批量处理作为一种古老的处理模式,任然以其高吞吐、高性能的特性占据着一席之地。 本文从批量处理的概念出发,结合开源批量框架SpringBatch和TBSchedule,简要介绍了批处理型服务架构的设计。可以看到目前虽然有很多已经被广泛使用的批量处理框架,但是还是存在着很多不完善的地方。 冰冻三尺非一日之寒,任何事物的发展和完善都不是一朝一夕的事,对于批量处理框架设计而言也是如此。我们自己在设计时可以考虑站在巨人的肩膀上,借鉴成熟的框架设计,同时结合具体的业务场景,加入符合需求的功能特性,完善出功能强大、运行稳定和易于使用的批量处理框架。 本文仅仅是抛砖引玉,对于具体设计时的很多细节问题并没有进行深入讨论。希望本文对于正在设计批量处理框架的同学能有那么一点帮助和指导。 http://geek.csdn.net/news/detail/108890