业务场景

我们如今有一个类似于文件上传的功能。各个子网站接受业务，业务上传文件，各个子网站的文件须要提交到总网站保存。文件是按批次提交到总网站的，也就是说，一个批次以下约有几百个文件。

       考虑到白天提交这么多文件会影响到子网站其它系统带宽，我们将分网站的文件提交到总网站这个操作过程独立出来，放到晚上来做，详细时间是晚上7:00到早上7:00。

       这个操作过程我们暂且称作“排程”。 排程在执行之后，先获取全部须要上传到总网站的批次信息，拿到批次信息之后。将这个批次表的状态置为正在同步数据。这个时候。假设这个批次再有业务人员上传文件。发现批次正在同步。就会返回操作失败。

 

如今产生的问题：

       1，排程获取到批次，准备将批次表状态置为正在同步，注意这时候批次表还没有改成正在同步。

       2，业务人员对这个批次提交100张文件，因为批次表状态还没改成正在同步。所以校验通过，准备插入数据到数据库，注意这时候文件信息还没插入到数据库，仅仅是准备插入。

       3，排程将批次表信息置为正在同步，而且获取到批次以下全部文件信息保存到内存，准备一个一个上传文件。

       4，业务人员上传的文件信息成功保存到数据库。

      

       这样的情况下，就会导致。第四步保存到数据库中的文件信息并没有提交到总网站。

 

分析：

       大家没看懂上面的业务信息，没关系，我们能够以一种更通俗的方式来描写叙述：

       我们去电影院看3D电影， 假如电影是在9:00开播， 9:00之后演播大厅关门，然后服务人员给全部坐在位子上的人发一个滤光眼镜。这时候就会有一个问题。那些正在走向位子上的人怎么办？ 这就是我们如今的问题。

       我们想到2种解决方式：

       1： 我们关上门之后等待一段时间，让全部的人都走到位子上。之后服务人员再发眼镜。

       2：服务人员每隔一段时间就检測下，有没有坐在位子上的人没有眼镜，没有眼镜就发一个。

       注意：业务场景看电影的人是没办法主动要眼镜的 J

 

假设使用另外一种方法，我们几十个分网站会频繁訪问总网站查询数据。这个查询是全表扫描，这对数据库性能影响太大。考虑到这个排程进程是后台进程。第一种方法尽管处理慢点，可是对系统影响更小，并且在一定程度上会减缓server的CPU压力，终于我们选择了第一种方案。

希望能对你有帮助。