实习经历（归档和装盒）

原因

问题描述：基于归档同时装盒导致归档一直处于执行的现状

名词解释

归档：这个是指公司的一些财务的数据，每一个月的过去之后就要将这个档案的数据，由一个"活跃"表转移到另外的一个"归档"表里面，这个涉及到数据的移动，包括数据的移动，状态的更新，以及原始数据的删除和隐藏。
装盒：这个是一个更加频繁的操作，比如用户在前端界面将多份电子档案打包下载，这个过程通常需要更新档案的元数据。

核心的冲突（现状）

1、数据的竞争:当系统事务对同一份档案数据同时进行归档和装盒时，问题就出现了，这两个操作很有可能就可能更新数据库中的同一条记录。然后由于数据库的并发控制机制下，那么数据库就会加上一个行锁，那么此时另外一个表B也试图更新同一条记录，那么此时就可能就会更新一条记录。
2、状态不一致，这个也是现状的最核心的一点，归档任务一定是一个符合任务，他的内部包含着上万条档案的处理，即使其中的几条档案由于锁的冲突而处理失败，整个归档任务的宏观上还是在执行中，我们无法判断任务是否已经完成，这会给监控和运维带来极大的困惑，无法快速的判断任务是否已经完成，部分成功还是完全失败。

解决方案

方案一：归档状态的解决

目标：解决状态不一致的问题
实现：在归档任务的执行逻辑中，为每一条档案的处理建立一个子任务或者结果集，当某一条档案失败时，除了在结果集中记录这条失败信息，必须去判断更新整个归档任务的宏观状态。

方案二：

以归档为中心

思路：归档优先，装盒让行
适合场景：适合归档为关键的场景（比如财务归档），装盒操作自动延迟。
解决方案：
1、在归档的数据id写入redis缓存中控制，缓存中有值即为正在做归档的数据。
2、在装盒中去获取redis缓存中值，有值代表正在归档稍后装盒，无值则可直接归档。

以装盒为中心

思路：装盒优先，归档让行
适合场景：适合装盒为高频操作的场景(如日常业务），归档操作主动等待。
解决方案：
1、装盒时将档案的id写入redis的缓存中，装盒成功之后删除缓存数据。
2、在归档做档案更新时去获取redis缓存中的值包含正在装盒的档案id，有包含值则休眠几秒继续执行，无包含值着不做休眠操作。