按照某种格式存储也行,参考crontab
的设计,可以实现比较复杂的场景,同时可以配置多规则,转为JSON存储起来,查询后解析一下规则就行了。
- 24小时营业
- 每天10点营业至20点
- 2月份6点营业至18点
- 2022年5月份7点营业至19点
- 2023年8月6日13点营业至15点
* * * * *
* * * 10:00 20:00
* 02 * 06:00 18:00
2022 05 * 07:00 19:00
2023 08 06 13:00 15:00
门店少的情况下配合任务调度,更新当前门店的是否营业字段。
门店多的情况下就比较复杂了,建议写一个服务来处理,假设门店修改了营业时间,业务系统需要推送到这个服务,服务接收门店ID和当前营业状态及营业时间规则,然后存到数组或者文件中。接下来服务只需要遍历存储的数据,解析营业规则再判断是否需要修改营业状态,推送到业务系统就可以了。
这种方案查询当前营业的门店很简单,但是对营业时间段的筛选查询就比较困难了,不过我觉得可以再完善一下能够支持这种场景。
当然这种方案实现起来比较复杂,但是支持的场景比较多,一般项目不建议使用。
ES数据库或者redis存一份今天营业的,记录他的时间段。定时任务来对状态进行更改也是可以的,如果数据规模大,可以根据地域来区分节点和分片。这样店家临时有事也可以快速的更改状态来进行关门的动作,数据库存原数据。查询全部走ES和redis。
开始、结束两个字段均为秒数,后端存储如果跨天时结束时间在86400后累积,查询时将小时转为秒数,并自增86400秒兼容跨天数据 newNow = now + 86400 (now >= start AND now <= end) OR (newNow >= start AND newNow <= end)
按照某种格式存储也行,参考crontab
的设计,可以实现比较复杂的场景,同时可以配置多规则,转为JSON存储起来,查询后解析一下规则就行了。
- 24小时营业
- 每天10点营业至20点
- 2月份6点营业至18点
- 2022年5月份7点营业至19点
- 2023年8月6日13点营业至15点
* * * * *
* * * 10:00 20:00
* 02 * 06:00 18:00
2022 05 * 07:00 19:00
2023 08 06 13:00 15:00
门店少的情况下配合任务调度,更新当前门店的是否营业字段。
门店多的情况下就比较复杂了,建议写一个服务来处理,假设门店修改了营业时间,业务系统需要推送到这个服务,服务接收门店ID和当前营业状态及营业时间规则,然后存到数组或者文件中。接下来服务只需要遍历存储的数据,解析营业规则再判断是否需要修改营业状态,推送到业务系统就可以了。
这种方案查询当前营业的门店很简单,但是对营业时间段的筛选查询就比较困难了,不过我觉得可以再完善一下能够支持这种场景。
当然这种方案实现起来比较复杂,但是支持的场景比较多,一般项目不建议使用。
直接单独一个表存储,
shop_id, start_at,endt_at
1,08:00, 12:00
1,13:00,15:00
1,17:00,23:00
查询的时候关联查询和去重查询应该就可以了,至于跨天。。跟产品说实现不了。。
按照某种格式存储也行,参考
crontab
的设计,可以实现比较复杂的场景,同时可以配置多规则,转为JSON存储起来,查询后解析一下规则就行了。门店少的情况下配合任务调度,更新当前门店的是否营业字段。
门店多的情况下就比较复杂了,建议写一个服务来处理,假设门店修改了营业时间,业务系统需要推送到这个服务,服务接收门店ID和当前营业状态及营业时间规则,然后存到数组或者文件中。接下来服务只需要遍历存储的数据,解析营业规则再判断是否需要修改营业状态,推送到业务系统就可以了。
这种方案查询当前营业的门店很简单,但是对营业时间段的筛选查询就比较困难了,不过我觉得可以再完善一下能够支持这种场景。