首页 / 软件开发 / 数据结构与算法 / 通向架构师的道路 第二十七天 IBM网格计算与企业批处理任务架构

通向架构师的道路 第二十七天 IBM网格计算与企业批处理任务架构2013-02-23 csdn lifetragedy一、批处理

我们在一些项目中如：银行、保险、零商业门店系统中的对帐、结帐、核算、日结等操作中经常会碰到一 些"批处理“作业。

这些批处理经常会涉及到一些大数据处理，同时处理一批增、删、改、查等SQL，往往涉及到好 几张表，这边取点数据那边写点数据，运行一些存储过程等。

批处理往往耗时、耗资源，往往还会用到多线程去设计程 序代码，有时处理不好还会碰到内存泄漏、溢出、不够、CPU占用高达99%，服务器被严重堵塞等现象。

笔者曾经经历过 一个批处理的3次优化，该批处理笔者按照数据库连接池的原理实现了一个线程池，使得线程数可以动态设定，不用的线程还可 还回线程池，其过程经历了加入cache等操作，最后连负载截均衡都想到了。

最终虽然取得了较满意的结果，但是当中不 断的优化程序、算法上耗时彼多，尤其是想到了负截匀衡。大家知道，一个web或者是一个app容器当达到极限时可以通过加入集 群以及增加节点的手段来提高总体的处理能力，但是这个批处理往往是一个应用程序，要把应用程序做成集群通过增加节点的方 式来提高处理能力可不是一件简单的事，对吧？

当然我不是说不能实现，硬代码通过SOCKET通讯利用MQ机制加数据库队 列是一种比较通用的设计手段，可以做到应用程序在处理大数据大事务时的集群这样的能力。

但是对于一些较大型的商 业客户尤其是银行、保险、大型零售行业或者是电信等客户，他们都是有成品套件的，你自己设计的具有集群能力的批处理固然 有成就感，但是从另外一个方面来说，从稳定性、可用性、维护性来说相信同类的现成的成熟商业用品一定要超过你自己编写的 批处理程序吧？

因为我这套架构师的道路走的是企业级架构师路线，因此也不得不经常提到一些商业级解决方案，对于自 己设计这个具有集群扩展能力的批处理我会放到以后去讲，今天主要讲的就是使用商业成品来完成你的批处理的集成。

二、商业级解决方案

来看一个批处理的需求：

1.能够做批处理

2. 能够通过增加节点来提高批处理的能力 ，相当于集群

3. 具有错误重跑的能力

4. 断点处理能力，比如说5000批次作业，我跑了2000批后失败了，这时后 面3000批在我做了一些调整后会接着前面的2000批继续跑下去

5. 完善的日志、监督、暂停（挂起）、定时（嘿嘿，这个 夸张）跑批处理的能力

我们先用传统的自己手工来做批处理的设计思想来考虑这个需求，至少要用到下面几个技术：

1. 我们得写个线程池，就和我上面提到过的自己按照jdbc connection pool的原理去写这个线程池，快手的话2周至少 要得吧，对吧？

2. 集成JMS或者是MQ机制，使得该程序具有节点间通讯能力这样就能做到负载均衡了。

3. 将任 务做任务记录持久化到数据库，这样可以做到错误记录、断点、重跑等功能

4. 得要用Quartz类似的组件来实现这个”定 时，定期跑批”的功能吧

好了，上述这些需求就够你做一个工程了，不是吗？

我现在告诉你，这个批处理的需求 是一个最低层次的商业级批处理作业的需求，如果用我以前工程上涉及到的完整需求，这可写上10几页（仅需求部分）。

大家知道在做大型客户如：银行、保险等项目时，这些客户是怎么考虑的吗？

首先，你如果告诉他你需要1个月左 右来做这个批处理（包含测试，这个已经是非常快的速度了），它会告诉你它只给你1周或者2周时间（最多了）。

因为 客户认为，批处理无非就是输入->处理->输出就完了，怎么处理的，有这么复杂吗，嘿嘿，客户一般认为它的需求都是很 简单的，开发商往往都是喜欢多要时间这样可以多算人力成本。

但是看官们请注意，客户这些考虑也是没有错的，是的 ，批处理从大的方面来说就是read->handle->write是这样的，至于read数据库+read文件再+read socket对于客户来说， 它就认为只有一个read，这其中的苦处啊，只有我们程序员自己知道。