数据与数据库架构
架构目标
FastBee 的数据架构以“业务数据稳定、设备数据高吞吐、热点数据高命中、历史数据可追溯”为目标。关系型数据库承载业务主数据和事务一致性，时序数据库承载海量设备数据，Redis 承载缓存、会话和分布式协同。
数据分层
数据库职责
| 类型 | 代表组件 | 主要职责 | 适用数据 |
|---|---|---|---|
| 关系型数据库 | MySQL、PostgreSQL、达梦、人大金仓等 | 事务、权限、配置、业务表 | 用户、机构、产品、设备、规则、告警 |
| 时序数据库 | TDengine、IoTDB、InfluxDB | 高写入、时间维度查询、历史归档 | 设备属性、采集值、遥测数据 |
| 缓存 | Redis、Redisson | 热点读取、会话、分布式锁、限流 | Token、设备状态、物模型、配置缓存 |
| 桥接数据源 | 数据库桥接与动态数据源 | 对接外部数据库或规则输出 | 规则转发、第三方系统同步 |
数据访问层
- MyBatis Plus 统一分页、SQL 过滤、审计字段填充和 ID 生成。
- 动态数据源用于适配主库、时序库和外部数据源。
- 分页查询应限制单页大小，导出任务建议异步化。
- 复杂查询需要结合索引、查询计划和慢 SQL 日志持续优化。
缓存策略
| 缓存对象 | 建议 |
|---|---|
| 设备状态 | 短 TTL 或事件驱动更新，避免状态长期不一致 |
| 物模型与产品配置 | 启动预热或首次访问加载，修改后主动失效 |
| Modbus/网关配置 | 配置变更后刷新缓存，避免采集任务读取旧配置 |
| OTA 任务 | 结合任务状态和设备响应设置过期策略 |
| 规则与场景 | 规则发布后刷新运行态配置，保留执行日志 |
一致性原则
- 强一致数据优先落关系型数据库，例如用户、权限、订单类业务数据。
- 设备上报和规则触发可以采用最终一致策略，通过消息、日志和补偿机制保障可追踪。
- 缓存更新遵循“先更新数据库，再失效缓存”或业务确认过的延迟双删策略。
- 分布式锁只用于必要的并发控制，锁粒度要尽量小，必须设置过期时间。
备份与迁移
- 上线前保留初始化 SQL、升级 SQL 和当前配置快照。
- 关系型数据库定期做逻辑备份，生产环境建议增加增量备份或物理备份。
- 时序数据按保留周期、冷热分层和业务合规要求规划归档。
- Redis 不作为唯一持久化数据来源，关键数据必须能够从数据库恢复。
- 跨版本升级先在测试环境回放 SQL 和核心业务流程，再切换生产环境。
排障清单
- 数据库连接失败：检查连接串、账号权限、网络、防火墙和容器服务名。
- 查询慢：查看慢 SQL、执行计划、索引命中和分页参数。
- 缓存异常：检查 key 命名、TTL、序列化方式、缓存穿透和锁释放。
- 时序写入失败：检查驱动版本、端口、时区、磁盘空间和数据库保留策略。
- 数据不一致：确认消息是否重复/丢失，检查规则执行日志和缓存失效路径。