从一个简单的功能到实际落地业务场景的处理分析

场景：

   君宁天下大饭堂，每天有1-2万的人数去吃饭，吃饭只能在线点单，如果用户吃完饭N天内没有评价，系统则会默认好评

数据库：

  订单列表 

     userid（用户id），ordertime（下单时间），IsEvaluate（是否评价）

 主要思路：

  base：系统内，做个定时查询，根据ordertime（下单时间）判断是否超过七天，然后修改 IsEvaluate（是否评价）

注意事项：

   以为是每天以最少1-2万量级的数据增加，因此表的体量很大，且积累的会越来越多（暂不考虑清楚or移植旧数据），对表进行如此大的查询注意系统以及数据库性能是否会对其产生影响，系统线上部署是集群方式

解决方案：

  公司主管大人：将业务逻辑用sql脚本方式实现，系统程序调用sql脚本执行处理，使用Windows自带的定时任务功能调用api

      个人分析：程序压力转移给数据库，让数据库承担这个压力，减少程序的性能消耗，缺点是加大了数据库性能消耗

  我在公司写的：业务逻辑在程序内部实现，先查出符合条件的数据，再遍历赋值 （本分析文章场景简化了些许，实际上还要做其他修改，所以要遍历），最后保存到数据库，使用Windows自带的定时任务功能调用api

      个人分析：系统程序主要承担压力，但可能造成资源消耗过多，从而影响系统其他功能，增加系统负载，因为是集群，所以系统程序与数据库资源都浪费严重

  我知识范围内想到的最优方案：每次下单，产生订单数据的同事，向队列（rocketMQ,redisMQ，RabbitMQ等队列）中插入一条数据，单独部署一个程序每天定时扫描队列，执行逻辑判断，符合条件则进行修改数据库

     个人分析：将数据写入队列，减轻对数据库的性能消耗，减少程序频繁访问数据库带来的压力。单独部署程序扫描队列，不会影响主系统。缺点是需要多部署个程序和队列服务，且队列有丢失数据风险

 业界前辈方案：

1、延迟队列

2、数据库定时执行脚本

标签：场景,落地,队列,系统,数据库,程序,简单,定时,数据
来源： https://www.cnblogs.com/ncellit/p/16049223.html