开篇：营销日历的三大技术痛点

管理营销日历看似简单，实际落地时会遇到几个技术难题：

1. 多团队协作冲突：市场、销售、产品团队同时修改日历，容易发生活动时间重叠
2. 时区转换复杂性：全球业务需要支持多时区自动换算，夏令时切换时尤其棘手
3. 实时性要求：活动变更需要秒级通知到相关方，传统轮询机制性能堪忧

技术选型对比

存储方案选择

MySQL方案 - 优势：事务支持完善，适合需要强一致性的场景 - 劣势：水平扩展困难，JSON字段查询性能较差

MongoDB方案 - 优势：天然适合嵌套的日历事件结构，分片扩展方便 - 示例文档结构：

interface MarketingEvent {
  _id: string;
  title: string;
  start: Date; // UTC时间戳
  end: Date;
  timezone: string; // 时区标识如'America/New_York'
  participants: string[];
  recurrence?: {
    pattern: 'daily'|'weekly'|'monthly';
    until?: Date;
  };
}

实时通知机制

| 方案类型 | 延迟 | 资源消耗 | 实现复杂度 | |----------------|---------|----------|------------| | Webhook | <1s | 低 | 中 | | 长轮询 | 1-3s | 中 | 低 | | 服务端推送(SSE) | <500ms | 高 | 高 |

核心实现细节

时区转换与冲突检测

from datetime import datetime
import pytz

def check_conflict(new_event, existing_events):
    """
    :param new_event: {'start': datetime, 'end': datetime, 'timezone': str}
    :param existing_events: List[dict]
    :return: bool 是否冲突
    """
    new_tz = pytz.timezone(new_event['timezone'])
    new_start = new_tz.localize(new_event['start']).astimezone(pytz.UTC)
    new_end = new_tz.localize(new_event['end']).astimezone(pytz.UTC)

    for event in existing_events:
        existing_tz = pytz.timezone(event['timezone'])
        existing_start = existing_tz.localize(event['start']).astimezone(pytz.UTC)
        existing_end = existing_tz.localize(event['end']).astimezone(pytz.UTC)

        if not (new_end <= existing_start or new_start >= existing_end):
            return True
    return False

分布式锁实现

public boolean acquireLock(String eventId) {
    String lockKey = "lock:event:" + eventId;
    String requestId = UUID.randomUUID().toString();

    // 尝试获取锁，设置10秒过期
    Boolean success = redisTemplate.opsForValue()
        .setIfAbsent(lockKey, requestId, 10, TimeUnit.SECONDS);

    if (Boolean.TRUE.equals(success)) {
        try {
            // 执行业务逻辑
            return true;
        } finally {
            // 确保只释放自己的锁
            String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " +
                           "return redis.call('del', KEYS[1]) else return 0 end";
            redisTemplate.execute(
                new DefaultRedisScript<>(script, Long.class),
                Collections.singletonList(lockKey),
                requestId);
        }
    }
    return false;
}

性能优化方案

查询优化技巧

1. 分片策略：按组织ID分库，按月份分表
2. 复合索引：对(start_time, end_time, timezone)建立联合索引
3. 读写分离：近3个月数据走主库，历史数据查从库

缓存设计

• 本地缓存：使用Caffeine缓存用户常用日历视图（TTL=5分钟）
• Redis缓存：
• 活动详情：TTL=1小时
• 冲突检测结果：TTL=30秒
• 使用Hash结构存储重复事件规则

生产环境避坑指南

夏令时处理

• 永远以UTC时间存储原始时间戳
• 显示时动态转换时区，使用America/New_York而非EST/EDT
• 对于固定时间活动（如"每天9:00"），需要特殊处理时钟回拨的情况

事件溯源实现

// 使用Event Sourcing模式记录变更
interface CalendarEvent {
  eventId: string;
  changes: Array<{
    timestamp: Date;
    user: string;
    action: 'created' | 'updated' | 'deleted';
    before?: any;
    after?: any;
  }>;
}

关键监控指标

• 冲突检测平均耗时（P99 < 200ms）
• 通知延迟（Webhook响应时间）
• 日历API的5xx错误率
• Redis锁等待时间

开放性问题

对于跨年营销活动（如双11持续到次年），如何设计这些机制？

1. 递归规则如何优雅终止？
2. 年度活动模板如何复用？
3. 预算结算的边界如何处理？

希望这些实践方案能帮助大家构建更可靠的营销日历系统。如果有更好的解决方案，欢迎交流讨论！