目录
5.2.执行时点 ( 需要 所有Batch 整体上 考虑 )
5.3.执行时点 ( 【API 处理 】 和 【Batch处理】 结合使用同一个DB 的系统)
10.设计的合理性（处理对象数据，应该有条件，尽量不要处理数据库中全量数据）
持续集成(Continuous Integration)（CI）
=====
・上流系统（如何从上流系统取得数据的话）
・Batch的运行环境（AIX，Linux 命令略有不同，还有的Batch部署在Windows环境中）
・下流系统的环境（关系的文件的换行符）
・壳（bash、ksh）
・环境使用的文件编码
・是【日次，周次（每周运行一次），非营业日，周一到周五，月次。。。】中的哪一种
・先行・后续 batch 之间的关系配置有无
・文件夹创建（需要注意考虑权限等问题）
・SFTP（get） 这种方式，初次运行时，要提前准备一个结果文件
・资源配置后，当天运行，还是之后指定日期运行。
↑ 要根据情况考虑，如果你的Batch，当天不能运行，对业务是否会产生影响
・上下流通信时，
・SSH通信的用户
（新建用户时，umask相关设定考虑）
（用户拥有的权限，用户所属的组等信息）
・公钥私钥 （使用ssh put 或 get）
・防火墙等相关配置
・为了能直接使用文件夹，mount相关配置（可以直接copy cp）
・通信软件的安装 (第三方软件通信时), 比如 Hulft
・和Windowsサーバー通信時
・直接SFTP接続・通信は可能です。
※ 连接后，目录是，连接用的用户的目录
・中間サーバーで、Sambaサービス起動、Samba経由sftp接続・通信も可能です。
（以上两种方式，都需要 ssh 公钥 私钥 相关的配置。）
※ 使用 Samba时，windows的目录和Linux 和 Window 的目录有可能不同。
・从上流系统连携文件
・从自己系统数据库中读取数据（可以时通过WebAPI方式投入的数据）
・SFTP（put）
・SFTP（get）
・共有文件目录 （使用mount 命令，挂载一个目录，这个是其他系统的的）
・通过第三方软件通信
・下流系统保存（或读取时），约定的位置
・比如，SFTP（get）时，要设置文件已被读取的Flg
xxx
・执行周期 （実行サイクル）
・每天都运行。
・或者 只在营业日运行，
・或者 每月运行一次
※ 注意！！！ 根据执行周期的不同，Batch对应的JOB的命名方式，也有可能不同
・需要考虑现存Batch的启动时点，尽量叉开时间运行
・考虑运行的先后顺序
・指定时间执行1次或多次，或者从几点到几点每隔一定时间执行一次
（比如9：00-17：00， 每隔1小时，执行一次）
比如某个 Flg（状态），API 处理中要使用，作为查询・查询之后根据状态对这条数据进行不同的操作处理。
尽量避免 在 API 业务时间段内，Batch 处理，对这个Flg（状态）进行更新处理。
尽量选择 在API业务外时间， Batch 处理，更新此Flg（状态）。
===
比如：业务要求，状态是1，可以查询到，但是禁止对这条数据进行再次跟新处理。
7：55分：调用API①查询，一览中，状态是0，可以操作
8：00整：Batch执行，状态变为1
8：05分：选中一览中的数据，进行编辑，准备再次调用API②进行更新操作。
※ 但是，如果此时再进行一次查询，会发现这条数据已经是禁止编辑的状态了。。。
===
・cron
・A-AUTO
※注意：AUTO是否有分类，比如 Online系， MF（Mainframe）（IBM大机）系
・SpringBatch的TaskLet等等
・环境差异文件
・文件编码
・文件最后一行，一定要有换行符
・Log信息要详细一点，要有能确认一条记录的标识信息，方便出错时调查
※ 注意 :虽然希望Log详细，但有的时候，Log如果过于详细，也是一个问题。
比如在API处理中，使用Interceptor写了一个Log的共同处理，能让每个方法的【参数】和【返回值】都出Log，
当查询100条数据时，这100条数据的内容，作为返回值，都会出现在log中，这样就造成log过于肥大了。。。
・正常Log（一般一个Batch是一个），异常Log（一般使用同一个Log文件）
・Log备份
・日志轮替 Log rotation
・DB中要有字段，能记录每条数据的状态以及处理时间
（状态：0未处理，1正常处理，2发生异常）
通常，数据库中的每条记录，要和下流系统连携时，都要采用这种设计方式。
----
如果一个处理里面，有两个更新操作，需要把这两个更新操作放到一个事务里面
如果是循环处理多条数据，通常不使用事务，
对应方式是：如果某一条数据出错，直接对应的记录的处理状态，标记为2即可然后继续处理下一条数据。因为还要继续处理后面的数据，所以不需要考虑回滚。
但是，此时需要考虑被标记为2的数据，需要如何恢复（リカバリー処理）。
・读取一个文件，把文件中所有的数据，投入数据库中，此时如果中途出错，需要回滚，重新读取数据文件。
・按照时间，删除数据库终端旧数据，如果途中出错，需要回滚。
比如1：
=============
在Batch处理数据的时候，
是否会有别的处理（比如WebAPI被调用），对batch正在处理的数据进行更新操作。
解决方案：
使用乐观锁：Batch操作开始时，锁住处理对象记录
=============
xxx
・主键设置
・是否要设置索引
・每个字段长度是否合适
・是否要保留一些预备字段，以备将来字段增加时使用（目的：不用每次都频繁的更新数据库表的结构）
・尽量对char或varchar项目，设定默认值‘’
xxx_Iteam_xxx CHARACTER(1) default ''
原因：
<>'1' 对于 null有【坑】，无法抽出值为null的项目
DB2常用命令、操作总结_ibm db2 的基本操作-CSDN博客
<> null的【坑】在这里有详细记述 ↑
===
数据抽出条件，除了以下
・还没有被处理的数据 【被标记为「已经处理完的数据」以外的数据】
・正常的数据【没有被标记为「伦理删除」的数据】
还有
・业务上的各种Flg（各种状态）是否满足
===
异常系是必须要考虑的问题
・错误的那一条跳过并标记，其他数据能正常处理
・是否需要考虑事务回滚，根据自己的业务决定
=====
・指定时间内，Batch如何没有运行完了，是否要出警告
・效率
xxx
・比如，总件数超过多少件之后，不再继续处理
xxxx
比如有图片数据保存，保存的图片数据是否要进行加密
xxx
xxx
考虑的点：
・Base数据量 （数据库中，最多一共有多少条数据）
・每次抽出多少数据
・查询条件的项目，有多少（比如说UserID，每个UserID有多条数据，有多少个UserID）
・同时多少个人进行查询操作
PT工具【SoapUI】
xxx
Java中的GC（垃圾回收）log ，以及 JVM 介绍_gc log-CSDN博客
比如设置堆内存最大值
・比如有一个循环处理，从数据库中取得数据，编辑后，放入List中。
如果数据库中有70万条数据，最终List中就会有70万件数据。。。。
・List扩大容量，浪费性能。。。
・如果每一数据的内容比较大，最后很容易造成OutOfMemmoryException
xxx
・备份数据的实现，为了不新规Batch，竟然在既有的删除Batch上用Java实现。。。。无语。
后果：数据库中有70万条数据时，直接OutOfMemmoryException。
xxx
上面的【9.】
xxx
比如，物理删除数据库中，超过1年的数据
xxx
如果需要备份数据，要按正规思路操作，
比如使用 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;
===
调查方向，在同一时间，是否还有别的Batch在运行，并且使用了相同的工作目录
（比如ST环境，如果使用一台服务器，搭建多个ST环境，下流只有一个工作目录时，会出现此问题）
调查方向，尝试修改Batch的运行时间，比如延迟5分钟执行
（比如，夜间，在某个整点运行Batch，这时服务器还有别的进程在运行）
1.服务器 IBM WebSphere
2.数据库 DB2
3.账票 SVF
4.batch控制 A-AUTO
A-AUTOバッチ管理ツール（HOLD之后，如何再次启动）-CSDN博客
5.文件传输 HULFT // utladmin
DevOps使用到的工具・术语_devops veracode-CSDN博客
1.代码管理 GitHub
2.Jenkins リリース資材作成，保存，安全性check
└Maven
└Artifactory // jar管理的库 // 可以获取第三方jar，可以上传保存自己工程的jar
└代码安全，脆弱性检查 Veracode // 自动 或者 手动
-----------------------------------------------------
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】的配置文件
==============
●環境
・環境数
（本番１～２，災対）
・環境差異ファイル
主に、本番と災対環境、差異がある。主に接続サーバーの先の配置
●マウント
・マウント
（/DATA フォルダ通常マウント）
・マウントかどうか
（DBサーバーなら、通常、稼働している（SQL運行）DBサーバーとマウント）
（災対サーバーも、通常時/DATAはマウントされておらず）
・マウントのデバイスは同じか（本番と災対）
確認必要、別のシステムは異なるです。
●同期化
・同期化有無
主に、災対サーバーを指します。
・同期化対象フォルダ
・同期タイミング
・削除資材も同期できるか
●監視ログ
新規Batchのログ、監視ログ対象になる必要か。
●バッチスケジュールの停止
※停止対象ジョブ
●バッチスケジュールの停止後の回復
●関連のシステムの閉局・停止 （例えば、onlineシステム）
そのシステム停止時、死活監視があれば、関連の監視除外考慮・連絡必要です。
＝＝＝＝＝＝＝