Hello Uday and Jesper, Thank you so much for the answer. I found another solution and will have a try, https://github.com/gocraft/work, this library use Redis to save the future tasks.
Best Regards, James Uday Kiran Jonnala <judayki...@gmail.com> 于2020年10月20日周二 上午9:29写道： > For the same scenario, we use the following > - Go cron to schedule the job execution > - For crash consistency of the program, use a DB (as mentioned by Jasper > also) with a db entry for job schedule information. > > > On Monday, October 19, 2020 at 2:33:50 AM UTC-7 jesper.lou...@gmail.com > wrote: > >> On Mon, Oct 19, 2020 at 9:51 AM Zhihong GUO <gzh...@gmail.com> wrote: >> >>> >>> I am implementing a reminder system. The purpose is to provide API to >>> client App to add a meeting, and before X minutes the meeting is to open, >>> the reminder system can send notif to user by SMS or email. Here I need a >>> function like: when a meeting is created, check the open time of the >>> meeting, and schedule a job of sending email or sms to be executed just >>> before the X minutes the meeting is open. I checked the goworker but it >>> seems there is no way to enqueue a "delayed" job, any suggestions about the >>> implementation? >>> >>> >> Not knowing your design criteria, I'm just going to make some assumptions >> along the way: >> >> I'd use a database, probably postgresql. It should serve you up to at >> least something like 100k concurrent meetings managed at any point in time. >> It'll break apart at an even larger scale, but chances are you can rewrite >> with new knowledge if that ever happens. You simply have a table tracking >> the interval of each meeting and you can use this information for a lot of >> things, including guarding for meeting conflicts and so on. On the Go side, >> you have a job ticker (time.NewTicker(time.Minute)) and once it fires, you >> look in the database if any meeting is about to start. Postgresql generally >> handles time/date information well enough that you can use its internal >> management to quickly query the eligible meetings. You can then decide if >> you want to throw them on a channel internally and have another part of the >> system responsible for sending out the emails, or if you want to do it in >> the job ticker loop. I'd probably go with the former because you can have a >> channel for each transport method you have (SMS, Email, Cloud Messaging[1], >> etc) >> >> In turn, the Go part of the system simply reacts to events on channels >> and carries out the work. The scheduling parts are handled by the database. >> I think this is a nice split of responsibility in the system, since it will >> simplify both parts: the database doesn't know about transports and their >> design, and the Go system doesn't have to worry about long-term persistence >> of meetings. >> >> Rationale: >> >> * Databases can survive a system reboot or an application restart. You >> probably want your meetings persistent. And you want your meetings to be >> stored in a way such that you don't accidentally lose them. >> * It is a rather simple poll-solution which is fast provided you have the >> right indexes created on the database side. >> * You can use a partial index, created over meetings for which you have >> yet to send out notifications. This severely cuts the index size down. >> * One-shot notifications are probably ok for a 10 minute window. If they >> fail to arrive, they are not important in less than 10 minutes. >> * The relational model is quite strong if you don't know where you are >> going in the long run as it tends to ensure good bounds on most queries. As >> you learn more about your problem, you can look into switching once your >> database reaches a pain threshold (Which is a couple of terabytes for >> Postgres, at the very least). >> >> Alternative: >> >> Use a database, but Go (Hah!) with a more cloud-DBesque solution. This >> could open up for almost infinite scaling, but often has a linear cost with >> the size of your database and your query rate. >> >> [1] Consider Google's FCM solution or something similar for this route. >> They demux the handling of different device types and transports for you, >> as well as handle token refreshing, canonical token updates and so on for >> you. It makes life much easier for everyone if you don't have to struggle >> with the transport-specific APIs. >> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/d580cdbb-3e3a-48d6-bcde-5cf5b27366fen%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/d580cdbb-3e3a-48d6-bcde-5cf5b27366fen%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMhUYgwwitbRMmAOGiU%3DcX9pkL_u54PNQwxx%2ByfHhbSD8Q1WQw%40mail.gmail.com.
