写在前面
前几天面试的时候，在介绍项目的布防问题时，被问得有点哑口无言，稀里糊涂搪塞了过去。一是忘了原有的方案失效的原因，二是对后改的方案依旧存在问题的心虚，所以就搪塞了过去。今天在复盘的时候想通了，因此想记录一下。
布防问题介绍
为防止自己忘记这个问题来源和其他读者(如果有)方便阅读,特地介绍一下。
布防问题是我在项目中遇到的一个具体问题简称（不是什么学术问题），该问题具体是用户控制摄像头报警（布防）的时间段的一个策略问题。
原有方案
原有的方案是让用户自定义每周布防时间段,然后后端将用户的输入和以前设置的时间段进行合并，然后再将用户全部布防策略发送给第三方（摄像头api端）进行布防。但是在第三方那边处理跨天时间段是无法进行的，所以得分成当天时间段和第二天时间段。
修改方案
修改后的方案是利用其他两个api（一个让摄像头上线，一个让摄像头下线）来进行布防，算法思路就是将用户设置的时间段处理成上线时间和下线时间，但是这样剥离了上线和下线中间的连续性，如果有重合时间段的设置就会很麻烦。并且在检测用户的设置上线和下线时间时，采用的是每分钟轮询所有用户的数据，然后对摄像头进行上线和下线，
复盘后想到的方案
首先帮助用户合并时间段我觉得本身就是自讨苦吃，合并策略有可能不是用户所要的结果，所以从前端下手，在用户输入时就将整周的布防结构图显示出来，用户在此基础上对原有布防进行修改，或者新增时间段，这样就可以避免时间段的合并处理。当然数据到后端后，我们还是需要对时间段是否重合进行校验。
剩下的工作就只剩用户策略的定时上线和下线了，我们其实可以利用定时任务框架来实现，比如Quartz或者InfoQ。只需要用户重新设置布防策略时，对相关的定时任务进行修改和新增即可，这样就避免每分钟从数据库读取数据导致的读取压力。