Scenario

  1. create event
  2. invite user
  3. notify users at specific time
  4. notify user periodically

Service

  1. User Service. 负责管理用户数据。
  2. Event Service. 负责管理用户创建的 Events
  3. Notification Service。负责notify用户某个 event 到了

Storage

created_by (谁创建的)

strategy (一次性的，还是周期的。如果是周期的，那么周期的策略是什么.
每周，还是每周末，还是什么，可以用一个具体的结构化数据表示出来，并serialize成json之类的存起来）
next_notify_time（下一次什么时候提醒，注意这里是下一次什么时候提醒，而不是第一次什么时候提醒）
attendes: many to many 的 users（实际上会存成另外一张表，记录哪个用户参与了哪个event）

Strategy---- Cron expression

**Expression**
**Meaning**
0 0 12 * * ? Fire at 12pm (noon) every day
0 15 10 ? * * Fire at 10:15am every day
0 15 10 * * ? Fire at 10:15am every day
0 15 10 * * ? * Fire at 10:15am every day
0 15 10 * * ? 2005 Fire at 10:15am every day during the year 2005
0 * 14 * * ? Fire every minute starting at 2pm and ending at 2:59pm, every day
0 0/5 14 * * ? Fire every 5 minutes starting at 2pm and ending at 2:55pm, every day
0 0/5 14,18 * * ? Fire every 5 minutes starting at 2pm and ending at 2:55pm, AND fire every 5 minutes starting at 6pm and ending at 6:55pm, every day
0 0-5 14 * * ? Fire every minute starting at 2pm and ending at 2:05pm, every day
0 10,44 14 ? 3 WED Fire at 2:10pm and at 2:44pm every Wednesday in the month of March.
0 15 10 ? * MON-FRI Fire at 10:15am every Monday, Tuesday, Wednesday, Thursday and Friday
0 15 10 15 * ? Fire at 10:15am on the 15th day of every month
0 15 10 L * ? Fire at 10:15am on the last day of every month
0 15 10 L-2 * ? Fire at 10:15am on the 2nd-to-last last day of every month
0 15 10 ? * 6L Fire at 10:15am on the last Friday of every month
0 15 10 ? * 6L Fire at 10:15am on the last Friday of every month
0 15 10 ? * 6L 2002-2005 Fire at 10:15am on every last friday of every month during the years 2002, 2003, 2004 and 2005
0 15 10 ? * 6#3 Fire at 10:15am on the third Friday of every month
0 0 12 1/5 * ? Fire at 12pm (noon) every 5 days every month, starting on the first day of the month.
0 11 11 11 11 ? Fire every November 11th at 11:11am.

Use a application fetch database, get the Job

主要难Scale 的是，如果是发邮件提醒的那种events，要从服务器端来处理。那么一个进程扫描整个数据库看看到时间的 events有哪些这个是很慢很慢的。所以需要多加机器，通过sharding分开处理。我的想法是按照 created_by 的 user_id 进行 sharding 来让 events存在不同的数据库里。然后弄若干个进程，每个进程负责一个 micro sharding （一个进程负责不了一整个数据库，所以可以按照 micro sharding 来分任务），然后每个进程 Regular 的扫描自己的 micro sharding 中到期的 events，然后创建提醒任务，丢给 MessageQueue。

results matching ""

    No results matching ""