方案一:
SQL存储过程、采用JOB的方式在数据库将提醒的结果集处理好
PS:
需要设计一个任务提醒的配置表,主要字段可以类似
提醒任务ID 提醒任务执行人ID 任务执行人类别 提醒周期 提醒开始日期 是否使用 提醒次数 任务复用流程 备用字段1 备用字段2 备用字段3 备注
这个里的提醒周期表示的是每天 每周 每月等,或者说类似每天隔两小时提醒,像隔多少小时或分钟提醒的需要程序去做监控
参考而已,还是需要根据楼主的实际情况看。
PS:
我可以写一个存储过程,用SQL Agent定时查询哪些任务需要提醒,每分钟执行一次,然后再SQL Server中可否调用某某网址(通知网站程序要有新的提醒了)。
如果楼主对JOB比较熟悉的话,也可以采用JOB的方式在数据库将提醒的结果集处理好,然后在前台显示,并采用邮件、短信等方式提醒任务执行人!
SQL Server 调用.NET写的DLL作为扩展存储过程,这个过程调用指定网址,这个网址只是一个入口,一旦被调用则主动查询数据库待提醒的任务,然后发送相关提示短信,可以吗?
用SQL处理发送短信的没有搞过,发送邮件是可以的,短信确实不清楚,如果调用DLL的话应该是可行的。
问题解决了,使用SQL Agent定时调用网站网页进行通知,程序自动发送短信
参考网址:
SQL code?
1 |
|
解决过程:
SQL code?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
|
方案二:
某定时任务系统的方案设计------软件系统设计能力很重要
2017-03-25 11:42:24 stpeace 阅读数 7971更多
分类专栏: s2: 软件进阶 s2: 软件设计 s2: 后台开发
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/stpeace/article/details/65934925
来看这样一个问题:
某账号系统的账号都在unsigned int内, 也就是0-42亿左右。 在这42亿账号中, 有大约1亿账号是相对非常活跃的用户, 用户和用户之间可以建立好友关系(类似于微信那样的好友关系)。 现在要设计一个定时赠言系统, 比如: 今天是2017年3月25日, 那么用户A可以给他的好友B送定时赠言(精确到未来某天, 不包括今天), 预期未来这天到达。而且任何用户都可以给他的多个好友多次送定时赠言。试给出合理的大致设计方案
我们一起来逐步看下, 这里肯定要把定时任务先落地到存储中, 到了设定的定时日期, 读出来, 并发出去。 那存储的数据结构该怎样组织呢? 这是本问题的核心所在。
方案一:
对于每一个定时任务, 用四元组把它存起来, 即{发送者账号, 接受者账号, 定时时间, 赠言}, 对于n个赠言操作, 就有了n个四元组, 然后把这n个四元组存储起来。 然后每天都读取任务, 读取到n个四元组任务后, 根据定时时间筛选出该发送的, 发送出去。
举个例子, 在2017年3月25日, 用户123给好友456送了定时赠言“”“I miss you”, 期望2017年3月28日到, 那么对应的四元组是{123, 456, 20170328, "I miss you"}, 然后存储起来, 于是乎, 在2017年3月26日, 遍历读取存储中的众多定时任务, 发现了{123, 456, 20170328, "I miss you"}, 但时间不对,所以暂时不发。 等2017年3月27日再读取, 发现时间又不对, 所以暂时不发。 等2017年3月28日再读取, 发现时间对了, 就立即发出消息。
我们来审视下这个方案, 很容易发现, 这是个相当低级的设计, 2017年3月26日和2017年3月27日做了两次无用的尝试啊。 从整体来看, 这种无用次数的数量难以想象。问题显而易见, 我们没有按照时间来存储这些定时任务。 于是继续改造。
方案二:
以设定的定时时间为key, 将所有定时在这一天的任务, 落地到同一个存储区。 按照上面的例子, 简单来说就是, 以20170328为key, 于是上述赠言操作就对应一个三元组,{123, 456, "I miss you"}, 读取的时候, 按天读取任务, 然后发出。 这种方案就好多了。 但还是有问题: 三元组作为value, 有n个留言操作, 就是n个三元组的拼接, 太庞大了, 不满足系统的key value存储要求。 于是继续优化。
方案三:
以{20170328, 123}做key, 用{456, "I miss you"}做value, 这样, 通过增加key的个数,来减少value的长度。 但问题在于, 读取的时候怎么去索引呢? 难道要遍历{20170328, 0} --- {20170328, 42亿} ? 我们要考虑到, 只有少数活跃用户啊, 这种42亿的全遍历肯定是不行的。
这里问题的本质是什么? 本质就是漫无目的暴力地去遍历key, 何不把有实际操作的key存下来呢?
方案四: 以20170328为一级key, 将有实际操作的用户作为value, 于是形成了这样的数据结构:20170328--->{123, 231, 101...}, 其中123, 231, 101都是有实际赠言操作的用户。 然后以{20170328, 123}位作为二级key来存放 {456, "I miss you"}. 到了2017年3月28日这边, 读取操作就很顺畅了, 先读取一级value {20170328, 123}, 然后以第一级value为key读取二级value {456, "I miss you"}.. 但发现还有个问题, 二级value的值还是太大(m个二元组的拼接, 很大)。继续优化。
方案五: 根据发送者尾号(比如取尾4位数)对key进行打散, 于是用户123和用户9870123的一级key就是一样的了, 都是{20170328,0123}. 该怎么读取呢? 到了2017年3月28日那边, 遍历{20170328, 0000}---{20170328, 9999}这一万个key(几乎可以肯定的是, 不会存在空遍历的情况), 于是查到123这个用户有赠言操作,于是继续用{20170328, 0123, 123}来获取到二级value {456, "I miss you"}, 然后把消息发出。
好了, 对比下方案一和方案五, 就知道优劣了。 随便说两点:
1. 方案一没法用多进程跑读任务, 慢得蛋疼, 呵呵哒。
2. 方案一没法在紧急情况时取消任务, 都杂糅在一起了, 取消很蛋疼的。
当然, 方案的优化是无止境的, 目前来看, 方案五跑得很顺畅。
方案三:
一日程提醒功能,其提醒的时间与内容放在数据库中,怎么才能高效的时时对比..
如一日程提醒为 时间2005年4月X日 14:20 提醒 开会
因为数据是放在数据库里面的,难道我要做一个Timer每隔一分钟刷新一次数据库对比有没有要提醒的日
程吗?求更好的解决方法
另一相关贴
http://community.csdn.net/Expert/topic/3935/3935316.xml?temp=.9232294
估计只能用TIMER,但可以根据当前时间与提醒时间的时间差来动态设置TIMER的间隔时间
每次提醒的时候取下一次提醒的时间与当前时间的差值作为Timer的参数,这样可以减少一些timer的执行次数
1.timer本身基本不会占系统资源,关键是看timer事件中的语句是否有效率, 设计SQL语句时,要尽量减少网络传输,表记录多的话可以建适当的索引
思路: timer事件中 sql 只检查是否有新消息 只返回一个值, 为true时才进一步去取消息内容. 关键是表的设计及sql的写法. 做得好的话只会占用系统很少资源. 你试试就知道了
2.可以考虑用winsock.
日程提醒功能,不会有时时消息..所以感觉没有用winsock的必要性
这种日程备忘不会有太大的信息量..不可能直接得到现在有没有提醒消息..因为,还有什么星期几才提醒,几号才提醒。隔几天提醒,每个星期几提醒等.. 要经过一个换算..但大多都是判断..执行量应该不大..
按你的说法,这不算是"时时对比"呀, 只要程序启动的时间,去表中取一次数据不就行了,根本不需要用timer. 你把数据取到本地的数据窗口,然后按需要定时提醒当前用户就行了,不需要与服务器的数据"时时对比"