Batch设计注意点与奇怪现象调查

↑①SAMBA服务只是方便windows用户使用，Linux系统连接时，不使用此服务，还是正常的sftp连接。 ②有时，samba服务会对放入的文件进行限制，比如只保留七天之内的文件，此时，如果你放了一个【时间戳】是10天之前的文件上去。夜间Batch执行，取得文件之前，这个文件又肯已经被删除了，造成取不到文件的现象。（【坑！！！】）

　　　　（以上两种方式，都需要 ssh 公钥私钥相关的配置。）

※　使用 Samba时，windows的目录和Linux 和 Window 的目录有可能不同。

1.处理前ー数据来源

・从上流系统连携文件

・从自己系统数据库中读取数据（可以时通过WebAPI方式投入的数据）

2.处理后ー数据的去处ー与下流系统的通信方式

・直接放到指定目录，没有跨服务器的通信。（前提：其他下流系统和你的系统在同一台服务器上）（设计时，要确认一下，下流系统服务器的名字）

・SFTP（put）

・SFTP（get）

・共有文件目录（使用mount 命令，挂载一个目录，这个是其他系统的的）

・同一个服务器（直接使用cp命令，复制到对方目录下即可）（前提：对方660，并且同一个组）

・通过第三方软件通信

・下流系统保存（或读取时），约定的位置

3.连携文件的状态

・比如，SFTP（get）时，要设置文件已被读取的Flg

4.连携文件的备份

xxx

5.Batch启动的ー【执行周期】・【执行时点】

5.1.执行周期

・执行周期（実行サイクル）
・每天都运行。

　　・或者只在营业日运行，

　　・或者每月运行一次

※　注意！！！根据执行周期的不同，Batch对应的JOB的命名方式，也有可能不同

5.2.执行时点 ( 需要所有Batch 整体上考虑 )

・需要考虑现存Batch的启动时点，尽量叉开时间运行

・考虑运行的先后顺序

・指定时间执行1次或多次，或者从几点到几点每隔一定时间执行一次

（比如9：00-17：00，每隔1小时，执行一次）

5.3.执行时点 ( 【API 处理】和【Batch处理】结合使用同一个DB 的系统)

比如某个 Flg（状态），API 处理中要使用，作为查询・查询之后根据状态对这条数据进行不同的操作处理。

尽量避免在 API 业务时间段内，Batch 处理，对这个Flg（状态）进行更新处理。

尽量选择在API业务外时间， Batch 处理，更新此Flg（状态）。

===

比如：业务要求，状态是1，可以查询到，但是禁止对这条数据进行再次跟新处理。

7：55分：调用API①查询，一览中，状态是0，可以操作

8：00整：Batch执行，状态变为1

8：05分：选中一览中的数据，进行编辑，准备再次调用API②进行更新操作。

　　　　　※　但是，如果此时再进行一次查询，会发现这条数据已经是禁止编辑的状态了。。。

===

6.Batch启动的ー控制方式

・cron

・A-AUTO

※注意：AUTO是否有分类，比如 Online系， MF（Mainframe）（IBM大机）系

・SpringBatch的TaskLet等等

7.Batchー配置文件设定

・环境差异文件

・文件编码

・文件最后一行，一定要有换行符

8.BatchーLog设定

・Log信息要详细一点，要有能确认一条记录的标识信息，方便出错时调查

※　注意　:虽然希望Log详细，但有的时候，Log如果过于详细，也是一个问题。
比如在API处理中，使用Interceptor写了一个Log的共同处理，能让每个方法的【参数】和【返回值】都出Log，
当查询100条数据时，这100条数据的内容，作为返回值，都会出现在log中，这样就造成log过于肥大了。。。

・正常Log（一般一个Batch是一个），异常Log（一般使用同一个Log文件）

・Log备份

・日志轮替 Log rotation

9.Batchー处理状态的保存

・DB中要有字段，能记录每条数据的状态以及处理时间

（状态：0未处理，1正常处理，2发生异常）

通常，数据库中的每条记录，要和下流系统连携时，都要采用这种设计方式。

----

10.事务处理

・WebAPI处理：

如果一个处理里面，有两个更新操作，需要把这两个更新操作放到一个事务里面

・Batch处理（通常处理）：

如果是循环处理多条数据，通常不使用事务，
对应方式是：如果某一条数据出错，直接对应的记录的处理状态，标记为2即可

然后继续处理下一条数据。因为还要继续处理后面的数据，所以不需要考虑回滚。

但是，此时需要考虑被标记为2的数据，需要如何恢复（リカバリー処理）。

・Batch处理（特殊处理）：

・读取一个文件，把文件中所有的数据，投入数据库中，此时如果中途出错，需要回滚，重新读取数据文件。
・按照时间，删除数据库终端旧数据，如果途中出错，需要回滚。

11.并发处理

比如1：

=============

在Batch处理数据的时候，
是否会有别的处理（比如WebAPI被调用），对batch正在处理的数据进行更新操作。

解决方案：
使用乐观锁：Batch操作开始时，锁住处理对象记录

=============

xxx

12.DB设计

・主键设置

・是否要设置索引

・每个字段长度是否合适

・是否要保留一些预备字段，以备将来字段增加时使用（目的：不用每次都频繁的更新数据库表的结构）

・尽量对char或varchar项目，设定默认值‘’

xxx_Iteam_xxx CHARACTER(1) default ''

原因：
<>'1' 对于 null有【坑】，无法抽出值为null的项目

DB2常用命令、操作总结_ibm db2 的基本操作-CSDN博客

<> null的【坑】在这里有详细记述 ↑

===

13.数据的抽出条件

数据抽出条件，除了以下

・还没有被处理的数据【被标记为「已经处理完的数据」以外的数据】
・正常的数据【没有被标记为「伦理删除」的数据】

还有

・业务上的各种Flg（各种状态）是否满足

===

14.异常系

异常系是必须要考虑的问题

・错误的那一条跳过并标记，其他数据能正常处理

・是否需要考虑事务回滚，根据自己的业务决定

=====

二．额外的考虑

1.总处理时间

・指定时间内，Batch如何没有运行完了，是否要出警告

・效率

xxx

2.最大处理件数限制

・比如，总件数超过多少件之后，不再继续处理

xxxx

3.数据是否要加密

比如有图片数据保存，保存的图片数据是否要进行加密

4.异常后的恢复操作

xxx

5.数据库死锁问题

xxx

6.压力测试是否需要

考虑的点：

・Base数据量　（数据库中，最多一共有多少条数据）
・每次抽出多少数据
・查询条件的项目，有多少（比如说UserID，每个UserID有多条数据，有多少个UserID）
・同时多少个人进行查询操作

PT工具【SoapUI】

一些很好的工具软件~_capt_st-CSDN博客

xxx

7.启动时时，jvm参数指定

Java中的GC（垃圾回收）log ，以及 JVM 介绍_gc log-CSDN博客

比如设置堆内存最大值

8.循环处理时循环的最大件数

・比如有一个循环处理，从数据库中取得数据，编辑后，放入List中。
如果数据库中有70万条数据，最终List中就会有70万件数据。。。。
・List扩大容量，浪费性能。。。
・如果每一数据的内容比较大，最后很容易造成OutOfMemmoryException

xxx

9.设计的合理性

・备份数据的实现，为了不新规Batch，竟然在既有的删除Batch上用Java实现。。。。无语。
后果：数据库中有70万条数据时，直接OutOfMemmoryException。

xxx

10.设计的合理性（处理对象数据，应该有条件，尽量不要处理数据库中全量数据）

上面的【9.】

xxx

11.下流传递文件时，文件压缩成zip后传送

好处1：只传送一个文件

好处2：传送的大小减少

====

三．非机能要件的设计

1.数据库中数据的定期删除

比如，物理删除数据库中，超过1年的数据

（先伦理删除，再物理删除）

2.文件的定期备份与压缩

xxx

3.数据库中的数据的备份

如果需要备份数据，要按正规思路操作，
比如使用 shell，shell中，连接数据库，使用export命令导出数据。

（非正常思路，使用java处理，生成csv，导出数据。。。。

比如【二.9】设计合理性中的记述）

====

DB2常用命令、操作总结_ibm db2 的基本操作-CSDN博客

EXPORT TO filename.csv OF DEL SELECT * from schemaName.yourTableName ordey by xxx with cs;

===

4.日志轮替（ログローテーション）

log文件的删除，备份，轮替。（每天是每天的Log，不能把所有天的Log文件，都记录到一个文件中，即使有日期时间信息，记录到一个文件中也不好）

5.如果保存了一些个人信息的图片文件，定期删除。（这应该是机能要件）

因为信息安全，不能长期保留客户的数据。

6.某个目录下，只保留几日之内的文件（比如Samba服务器）

【坑】如果上传了一个时间戳旧的文件，可能在Batch读取处理之前，就被删除了。。。

7.服务的定时停止启动

Web服务器 Apache

App服务器，比如： Tamcat

DB服务，比如： Msql

业务处理，比如：SpringBatch 的 TaskLet

8.备份文件，再次归档（xxx.tar）

比如，每周日晚上，把过去7到14天之内的数据，压缩到 xxx.tar文件中

9.处理数据的上限

比如，最多处理10000件数据

比如，要连携的总文件大小，超过100M时，停止处理。本次处理只往下流传递当前生成的文件。

四．奇怪现象发生的原因调查

1.生成的文件，还没往下流连携，就莫名奇妙的被删除了

调查方向，在同一时间，是否还有别的Batch在运行，并且使用了相同的工作目录

（比如ST环境，如果使用一台服务器，搭建多个ST环境，下流只有一个工作目录时，会出现此问题）

2.batch运行时间超长

调查方向，尝试修改Batch的运行时间，比如延迟5分钟执行

（比如，夜间，在某个整点运行Batch，这时服务器还有别的进程在运行）

五．环境中常用的ミドルウェア（大部分是对日开发中使用）

1.服务器 IBM WebSphere

2.数据库 DB2

3.账票 SVF （SVF客户端， SVF服务器端（默认端口4141））

会社概要 | ウイングアーク１ｓｔコーポレートサイト

-------------功能概要

1.1. SVF Connect for Java APIの機能概要 (wingarc.com)

-----------------

===知识扩展

acrobat也可以生成张票（PDF）

acrobat 是什么软件

Acrobat 是由 Adobe 公司开发的一款用于创建、编辑和查看 PDF（Portable Document Format）文件的软件。Adobe Acrobat 主要用于处理电子文档，用户可以使用 Acrobat 创建 PDF 文件、编辑 PDF 内容、进行文档标记和注释、添加数字签名、以及进行文档安全设置等操作。Adobe Acrobat 被广泛用于办公室、教育、设计等领域，方便用户共享和管理电子文档

===

4.batch控制 A-AUTO

A-AUTOバッチ管理ツール（HOLD之后，如何再次启动）-CSDN博客

5.文件传输 HULFT // utladmin

【公式】HULFT管理画面を起動する

六．DevOps相关

DevOps使用到的工具・术语_devops veracode-CSDN博客

持续集成(Continuous Integration)（CI）

1.代码管理 GitHub

2.Jenkins リリース資材作成，保存，安全性check

　　└Maven

　└Artifactory　　// 　　jar管理的库 // 可以获取第三方jar，可以上传保存自己工程的jar

　└代码安全，脆弱性检查 Veracode // 自动或者手动

-----------------------------------------------------

持续交付(Continuous Delivery)（CD）

1.1.发布代码 Jenkins

1.2.发布代码 XLDeploy

1.3.Docker

上面三个，任意一种方式都可以。

==========

七．环境配置注意点（手动配置・手动执行）

■前言

虽然基本上环境发布，都已经使用Jenkins实现了。

但是，如果只是部分实现，或者没有实现时，

就需要我们手动发布。

■手动配置

・0．【自动发布正确性】不要认为，资源文件的时间是新的，资源就一定是新的。

（比如，Jenkins脚本错误，造成了实际运行目录下，发布的jar并不正确。。。）

（脚本中使用了 cp -rf 命令，从一个错误的目录下，复制了一个古老的jar过来。

因为想保留原来资源的属性，没有使用 p 参数，造成资源的时间显示为脚本的执行时间。

检查资源时，只检查了时间，没有查看内部。。。。其实这是一个错误的资源。）

・1．【环境差异文件】batch启动文件，指定了使用的conf目录的位置

・2．【环境差异文件】记录数据库 Schema 的配置文件

・3．【环境差异文件】记录文件 读写路径【/DATA/XXX_IT1】的配置文件

・4．【环境差异文件】记录log 出力路径 【/Logs/XXX_IT1】的配置文件。比如Log4j

■手动执行

・1．之前前，准备好的数据的【执行状态】字段，是否置为未执行【0】的状态

・2．之前前，准备好的数据的【条件XX】字段，是否置正确

・3．如果有文件，文件权限是否正确

・4．如果有文件，文件名和数据是否匹配

・5．如果有文件，文件的编码，文件的上传方式（binary）

・6．如果有文件，文件在本地环境能否被正常处理

・7．执行batch前，是否切换到batch执行的专用User下【sudo su -】不要使用root用户执行

■额外注意

你到底配置了几个环境，是否所有环境的上述注意点都检查了。

比如：

今天（2024/01/30）执行

画像的加密（Batch）处理，这是Batch系统

画像的解密（API）处理，这是Online系统。

忘了检查 Online系统的记录文件 读写路径 配置，造成代码一直得不到期待的结果。。。
・3．【环境差异文件】记录文件 读写路径【/DATA/XXX_IT1】的配置文件

==============

八．系统发布时的注意点（本番リリース）

本番リリースのフローの概要-CSDN博客

●環境

・環境数

　　（本番１～２，災対）

・環境差異ファイル

　　主に、本番と災対環境、差異がある。主に接続サーバーの先の配置

●マウント

・マウント
　　（/DATA　フォルダ通常マウント）

・マウントかどうか
　　（DBサーバーなら、通常、稼働している（SQL運行）DBサーバーとマウント）

　　（災対サーバーも、通常時/DATAはマウントされておらず）

・マウントのデバイスは同じか（本番と災対）

　　　確認必要、別のシステムは異なるです。

●同期化

・同期化有無

　　　主に、災対サーバーを指します。

・同期化対象フォルダ

・同期タイミング

・削除資材も同期できるか

●監視ログ

　新規Batchのログ、監視ログ対象になる必要か。

●バッチスケジュールの停止

　　※停止対象ジョブ

●バッチスケジュールの停止後の回復

●関連のシステムの閉局・停止　（例えば、onlineシステム）

　　そのシステム停止時、死活監視があれば、関連の監視除外考慮・連絡必要です。

＝＝＝＝＝＝＝

九.Batch整体设计时，有哪些注意点(AI回答)

设计Batch处理系统时需要考虑的注意点包括：

任务拆分：将大任务拆分成小任务，使得每个小任务可以独立运行，提高任务并行度和整体处理效率。

异常处理：设计健壮的异常处理机制，包括重试、错误日志记录、告警通知等，保证系统可以在异常情况下正确处理任务。

任务调度：确定任务触发的方式和调度策略，例如定时触发、事件触发或者手动触发，合理安排任务的执行顺序和时间。

配置管理：将系统的配置参数独立出来，支持动态调整参数，避免硬编码，提高系统的灵活性和可维护性。

日志记录：详细记录Batch任务的执行日志，包括任务执行结果、错误信息、运行时间等，便于监控和故障排查。

监控与性能优化：实时监控Batch任务的执行情况，处理性能瓶颈和资源利用率等问题，及时进行调优。

并发控制：合理控制并发量，避免系统资源过度占用或者产生冲突，保证任务执行的稳定性和可靠性。

数据完整性：确保数据处理过程中的数据完整性和一致性，避免脏数据或者数据丢失对系统造成影响。

自动化测试：编写充分的自动化测试用例，包括单元测试、集成测试和端到端测试，保证系统的稳定性和可靠性。

扩展性：设计灵活的架构和模块化的代码结构，支持系统的扩展和功能的快速迭代。