日历财务收支余额计算最优方案及技术选型咨询

一、核心数据模型设计 #

• 收支事件表：存储所有未来收支记录，核心字段包括id、用户ID、金额（正收入负支出）、发生日期、重复规则（如每月15日、每周五，可选）、状态（有效/已取消）
• 余额快照表：存储关键时间节点的余额，核心字段包括用户ID、快照日期、期末余额、关联快照ID（指向前一个快照ID，形成链式结构）

二、余额计算策略：实时计算+预计算快照结合 #

这是平衡性能与准确性的最优方案，既避免全量实时计算的高开销，又解决纯预计算覆盖不全的问题：

1. 预计算关键节点快照
   • 每日凌晨通过后台定时任务，批量计算所有用户当日期末余额：基于上一个有效快照的余额，累加当日所有生效的收支事件（含一次性、重复事件）
   • 每月初额外生成月度期初/期末快照，方便快速查询整月数据
   • 快照采用单向链表结构存储，每个快照仅关联前一个有效快照，回溯时可快速遍历，同时避免环形依赖
2. 实时计算补全
   • 当用户查看未预计算的日期（如未来30天内未到批量计算时间的日期），或刚新增/修改收支事件时，从最近的快照余额开始，实时计算目标时间段内的收支变化，得到对应日期的余额
   • 单月查询：若整月有预计算快照，直接取月度期初、期末余额；若部分日期未预计算，从当月第一天快照（或上月末快照）开始实时计算缺失部分
   • 跨月查询：拼接各月预计算快照余额，再实时计算首尾未覆盖的日期部分

三、数据结构选型 #

• 前端本地缓存：用Map或Object存储用户近期余额快照，键为日期字符串（如2023-04-30），值为余额，同时维护latestSnapshotDate标记最新快照日期，减少重复计算
• 后端存储：余额快照表选用关系型数据库（PostgreSQL/MySQL），建立用户ID+快照日期联合索引，快速查询指定日期范围的快照；收支事件表同样建立用户ID+发生日期联合索引，批量计算时可快速筛选当日事件
• 重复事件处理：后端可提前按规则生成未来N天的重复事件实例（如提前生成半年内的），或计算时实时解析规则生成当日事件——前者优先保障性能，后者优先节省存储空间

四、前后端协同方案 #

1. 后端批量计算：每日凌晨触发定时任务，遍历所有用户，从最近快照开始计算当日收支总和，更新当日期末余额快照并维护链式关联
2. 前端请求优化：
   • 用户查看月视图时，先请求该月快照数据，存在则直接渲染；不存在则请求上月末快照余额+当月所有收支事件，前端实时计算每日余额
   • 用户新增/修改收支事件后，前端先本地更新缓存余额（实时计算受影响日期），同时通知后端触发增量计算，更新相关日期的快照
3. 移动端离线处理：Swift端本地存储用户收支事件与近期余额快照，离线时基于本地数据实时计算余额，联网后同步数据与快照

五、性能优化点 #

• 增量计算：收支事件修改时，仅重新计算该事件影响的日期范围余额，而非全量重算
• 缓存策略：前端缓存用户最近3个月的余额快照，移动端可延长至半年，减少网络请求
• 分页查询：跨月查询时分页加载快照数据，避免一次性加载大量数据
• 重复事件预生成：后端提前生成未来半年内的重复事件实例，计算快照时直接读取，无需实时解析规则

内容的提问来源于stack exchange，提问作者Alex