[Spring Cloud Task]6 Spring Batch批处理应用设计原则

概述

本文是Spring Cloud Task系列的第五篇文章，如果你尚未使用过Spring Cloud Task，请 移步spring cloud task1 简介与示例。
本文主要讲述的是Spring的另一个核心子项目 Spring Batch 批处理应用的一些设计技巧和原则。这些技巧分别涉及

原则与技巧

应用数据库设计原则

多分区批处理应用通常会用到数据库表分表。分表的设计是选取某个索引列作为分表的关键字，将有不同关键字的数据分别存储在不同物理数据库（表）。数据分表架构应有一个中心数据仓库（表），存储表分区参数等元数据。中心数据仓库（表）一般由单个表（非分区）组成，记录所有表分区的信息。有了中心数据仓库（表），数据分表架构才具有灵活性和可维护性。

中心数据仓库（表）的分区信息表所存储的数据通常是静态的，且只有DBA才有维护的权限。分区信息表的每行都包含一个表分区的信息（或者批处理应用实例的信息），分区信息表应该有代表应用编号的列(program_id )，分区逻辑编号( logical _id)以及要处理的数据分区主键最大值和分区主键最小值等信息。

在应用启动时，控制程序会把应用编号和分区编号传递给应用。如果使用关键列分表的方法，控制程序则会将要处理的数据范围传递给应用。另外下面两种处理还会用到分区编号：

1. 需要将多个数据处理应用的结果合并并输出到文件或数据库中。
2. 将分区应用的正常工作日志上报到控制器或将分区发生的错误上报到错误处理器。

极小死锁原则

在并行或分片批处理应用中，数据库资源可能会发生竞争或死锁。在设计数据库时请谨记下面这句话，减少数据竞争条件与完成业务需求同样重要。

死锁或访问热点常常发生在控制表或架构核心表中，如日志表，控制表，锁标识表。系统的瓶颈往往发生在这里，故而在架构设计时应该着重考虑这些表的性能需求。

为降低数据访问冲突所造成的影响，架构中应该设计类似 等待-重试 的周期服务，当访问数据库或发生死锁时，等待-重试 服务能减少数据冲突所造成的影响。这种机制对数据库的错误码并不立即响应，而是在经过预定时间和重试后，如果还发生错误，再向上层抛出错误。

参数解析与验证

分区应用架构应对开发人员相对透明，分区架构应确保下列3个与应用分区相关的任务能够执行：

1. 在应用启动前检索分区参数
2. 在应用启动前验证分区参数
3. 在应用启动时解析参数

验证任务确保参数能满足以下两点：

1. 确保应用有足够的分区示例覆盖到整个数据集区间
2. 分区与分区之间没有遗漏的数据

如果应用数据库也采用分表分库的方式来设计，那么还应该有一个表分区检测任务，确保一个应用分区不会跨越多个数据库分区。

分区架构还应该考虑分区的一致性问题，如：

1. 在进行下一步操作之前确认当前操作完全完成
2. 如何处理任务分区失败

关于

示例源码

Spring Cloud Task learning 的 task-demo-with-datasource 子项目

后记

Spring Cloud Task是一个优秀的项目，但是我找遍网络，也难以找出系统的、准确的中文相关文档。本系列文章以保证对Spring Cloud Task相关概念和设计理解的正确性为标准，尽量采用通俗易懂的语言，希望能给各位带来一些便捷。

本文内容主要是对 Spring Cloud Task 1.2.2-RELEASE 官方文档的翻译，不过作者水平有限，有不尽然的地方敬请指出。本项目和文档中所用的内容仅供学习和研究之用，转载或引用时请指明出处。如果你对文档有疑问或问题，请在项目中给我留言或发email到
[email protected] 我的github:
https://github.com/weiwei02/ 我相信技术能够改变世界 。

链接

• 上篇文章Spring Cloud Task 5 Spring Batch数据分片探究
• 下篇文章正在准备中