如新建一个循环会议有这样一条规则
创建一个会议每天早上10点到11点且重复10次：
RRULE:FREQ=DAILY;COUNT=10
目前的处理方式：
在数据库中只生成一个会议记录用一个字段保存这个规则
目前遇到的问题：
有没有好的存储方式，和缓存设计
解决思路：其实个人更建议根据规则生成多条数据维护，虽然数据多了点，但是功能方便拓展且搜索方便。如果不想根据规则循环创建多条记录，可以使用redis存储，给每个用户生成一条信息存到redis中，key为userId,value为会议时间列表和会议信息，当查询某一个人在某一个时间范围内是否有会议时，根据用户id查询出时间列表，循环判断搜索范围是否在列表中，在的话取出对应会议信息。
您需要单独处理事件和事件。 事件明智： 对于事件，您将需要存储recurence规则（可以是rfc5545指定的rrule，但也可以是rfc5545中的rdate等明确的日期集），但也有异常（请参阅rfc5545的exdate以及rfc2445中可能的exrule）。 您还需要跟踪这些规则的变化： rdate，exdate的变化在将来发生时没有问题，在过去的日期会被忽略。 由于影响之前的出现，rrule的变化更加棘手。我个人的偏好是为旧的和新的rrule添加一个特定的属性，以指定它们各自的开始和结束日期。 如果事件的时间跨度有限（比如COUNT或UNTIL属性），则应将其开始和结束存储在表中，以便更容易查询事件（特别是在预先计算的时间窗口之外查找事件时（见下文），可以帮助减少重新计算的事件数量）。 明智的发生： 对于出现的情况，您应该将实例存储在当前周围的预定义窗口内（例如+/- 6个月或12个月并定期计算）并保留此记录以允许重新计算，如果您的用户希望将来进一步查看（对于表演问题）。您还应该考虑计算索引（RECURRENCE-ID）以帮助更容易地找到下一个匹配项。 在后端更少，但在前端更多，你还应该跟踪tzid更改，以询问用户是否在某个给定的tzid上安排的事件，如果它要保持在当前时区，则需要更新（想想萨摩亚岛上有人安排在2011年12月30日星期五举行会议，然后国家决定这一天不存在），同样地，你可以问一下在夏令时期间发生的事件是否意味着“从不发生“或”发生两次“（更多关于此主题） 注意： 您可能需要考虑超出rfc5545中定义的支持，而不仅仅是恢复规则，还要添加对宗教重复规则的支持（请参阅USNO日历介绍或印刷“Calendrical Calculations”（第三版） E. Reingol和N. Dershowitz）。 由于您询问现有实现，您可以轻松检查sunbird（sqlite）或Apple开源日历和联系人服务器的数据库模式，这是caldav服务器的现有开源项目的更完整列表（可能是其中的一部分）你在寻找）可以在这里）