1 总述
入口
- 数据库
- 文件
- Socket通信
触发条件
- 时间
- 轮询
- 接口
- 手工
对于批量处理理论上要至少满足以下五个方面的考虑：
- 事务性
- 统计
- 监控
- 性能
- 错单处理
2 批量使用场景
2.1 批量操作同单笔操作比较
单笔操作：
- 一般是由客户端触发
- 更加实时；
- 开发相对比较简单
- 当业务处理复杂时，操作会比较慢，造成用户体验太好；
- 出错处理相对比较简单；
批量操作：
- 一般是在服务端触发
- 执行时间比较固定；或者在满足某些条件下触发；
- 开发和维护难度较大
- 比较合适处理大批量的数据；
- 出错处理相对比较麻烦
2.2 结论
在满足性能的条件下优先考虑使用单笔操作的方式去解决问题；对于一些有时间要求的业务，可以考虑增加eff_date/exp_date来进行自动判断，从而避免增加后台进程。为了良好的用户体验，将单笔业务操作移到后台批量进程去处理并不是一个很好的方案。单笔流程较长时，可以考虑增加调度方法来解决，例如事件（或者消息）驱动的方法来构造整体的框架。
如果单笔业务不好做了，那我们就考虑用批量进程来处理，下面就这个问题展开思考。
3 如何设计
3.1 事务性
3.1.1 入口为数据库的事务性
对于入口为数据库，一般每条数据为一个记录，则对于记录设置一个flag，一个remark（考虑合适的长度）。
? Flag：
0：未处理
1：正在处理
2：处理成功
3：处理异常
4：处理失败
说明一下3、4的区别，处理失败是指不满足业务条件的处理，既可以认为是正确的也可以认为是错误的，根据业务来确认；而处理异常，则是指程序问题、接口问题、系统、硬件等非业务原因引起的错误，是需要后期重新处理的业务；
另外，如果对于业务失败比较关注，则可以将其展开，分成部分的业务错误，以满足后期灵活的业务处理；
? Remark：
用来记录处理失败的详细信息；每处理完一条，则进行commit；
? 另外对于入参及关键参数，绝对不能去修改，如果业务需要则建议新增字段；
3.1.2 入口为文件的事务性
入口为文件的批量操作，一般文件的每条记录为一笔操作，每条记录中的以定长或者特殊分隔符（例如“|”，“，”）进行分割。也可以使用标准的传输文件协议为如何，例如xml或者json的方式，这种方式带来一定的灵活性比较合适业务有变动的情况，但是同时会增加网络的流量。
这种方式一般会有下载数据文件、数据文件解析、循环数据文件，单行业务处理，异常处理记录，异常工单处理这些操作。循环中要捕获单行处理的任何异常，防止因为一条记录的失败，导致处理整个文件的退出。
另外，要保证原始文件的完整性，不能对原始文件进行任何修改。处理完成后，将文件备份到一个单独的目录中。
处理成功的记录，由于文件方式的统计不是很方便，一般采用下面两种方式来记录。
方式1：将结果数据记录到数据库表中，此种方式简单不再啰嗦叙述。
方式2：记录一个汇总文件和一个明细文件。汇总文件记录每个文件或者每次触发条件下，处理的文件、成功的数目，失败的数目、开始时间和结束时间。明细文件记录处理成功的行记录信息，以便于以后进行核对。明细文件中，每一行代表一个记录的执行结果，里面能唯一识别该记录的来源，例如可以以下面方式组织：执行时间|文件名称|行数|关键数据（例如号码、订单号、流水号等）|处理结果。
处理失败的记录，同样可以以2中方式去组织，一种以数据库表的方式去组织，一种以文件方式组织，这里还是讲述文件的方式。这里组织2个文件，一个文件记录异常的处理记录及其错误原因；一个文件则是原始的数据，这样在处理完问题后，可以方便地进行重新处理。
3.2 统计
对于入口为数据库的方式来讲，可以通过时间、flag过滤筛选；
对于入口为文件的方式来讲，可以通过汇总文件进行统计；
3.3 监控
3.3.1 通用的监控
对于常驻进程，则通过类似于ps –fe|grep $(PROGRAM_NAME)|grep –v grep|wc，计算数量来分析；以及进程的状态来进一步处理；
对于处理时间很短的后台进程，则需要保证其与触发条件的一致性；
3.3.2 入口为数据库或者涉及数据库操作进程的监控
准实时监控处理的记录所占的及时性、正确率，例如处理比率、异常处理的比重；
或者操作记录的时间来监控（前提是能区分是前台在修改还是后台在修改）；
3.3.3 入库为文件的事务性
监控备份文件的变化；
监控汇总文件的变化、成功处理、异常处理数据的变化；
3.4 性能
3.4.1 入口为数据库的性能
以下情况适用于数据很大的情况，例如系统中的短信接口表处理。
如果数据量很大，则对数据库性能的影响会很大，特别是索引的建立不合适，会加剧这一问题；这也是数据表做接口表的缺点，当数据量非常巨大的时候，在分表、分区、分库都很难满足的情况下，则考虑采用其他方式。
一般会有至少3个表，分表为正表、处理成功表、处理失败表，处理失败表又可以根据业务进行拆分。
关于正表的处理有个处理策略问题，有点类似于系统调用策略。一般有先进先出、优先级争抢、超时处理等。索引的建立只满足于该策略即可，不建议再增加其他索引。因为正常来讲，数据在表中的时间会非常短暂。程序每次按照策略从表中取出数据，取出的同时从表中删除数据。
处理成功表，是用来存放正确处理的记录，供后续查看使用；这个表建议以时间进行分表，毕竟绝大多数是成功的数据。
错误处理表，是用来存放处理失败的记录，供后续处理使用；这里错误包括业务条件不满足等业务上的错误和非业务上的错误。
处理成功表和处理错误表相对来讲是比较静态的表，索引可以根据业务需要查询需要去建立合适数目的索引。
如何防止进程（或线程）竞争：
此类程序一般都是多个进程或者线程去处理的，这样的话就可能会有多个程序争到同一条记录，或者业务上有要求，同一个用户的数据必须按照顺序去执行。
解决方法：
方法1：例如如果启动10个进程的话（编号0、1….9），每个进程处理编号位数相同的记录，进程3处理订单号为xxxxxxx3的记录。
方法2：例如对用订单而言，一般用户的订单一定要先后顺序去执行，以满足业务上的限制；处理的时候，先做判断，将同一个用户的订单行构造成一个队列（可以是虚拟的），然后按照队列的方法去处理；
方法3：让其中一个线程专职做调度，让剩下的线程去干活；这个方法是最好的方法，如果系统策略变更，则只需要修改调用程序的流程即可，而不需要修改业务操作，做到了业务逻辑的透明性；但是相对而言开发难度更大些。
3.4.2 入口为文件方式的性能
文件方式性能问题并不大，更多的是其他角度处理相对困难。
3.5 错单处理
3.5.1 手工处理
对于入口为数据库表的方式，可以通过修改flag、将错误表数据导入正表去触发重新处理。
对于入口为文件的方式，可以手工指定错误数据数据文件去执行。
3.5.2 自动处理
自动处理的范围比较有限，且需要对异常处理有很好的细化，例如对于数据库故障、网络终端等错误，可以自动触发重新处理。