11、性能、并发控制与聚合模式实践

性能、并发控制与聚合模式实践

1. 性能考量

在软件开发中，我们采用聚合建模以实现高性能软件。尽管有时仅需一个批次的数据，却加载了所有批次，但这并非低效，原因如下：
- 单一查询与更新 ：对数据进行有目的的建模，仅需一次数据库查询来读取数据，一次更新来持久化更改。相较于频繁发出临时查询的系统，这种方式性能更佳。在未采用此建模方式的系统中，随着软件的发展，事务往往会变得更长、更复杂。
- 轻量级数据结构 ：数据结构简洁，每行仅包含几个字符串和整数，能在几毫秒内轻松加载数十甚至数百个批次。
- 数据量可控 ：预计每种产品同时仅有约20个批次。当一个批次用完后，可将其从计算中排除，确保获取的数据量不会随时间失控。

若某产品有数千个活跃批次，可采用延迟加载策略。从代码角度看，无需改变，但在后台，SQLAlchemy会分页处理数据，虽会增加请求次数，但每次获取的行数减少。由于只需找到一个有足够容量的批次来满足订单，此方法可能效果良好。

若上述方法均不可行，可考虑更换聚合方式，如按区域或仓库拆分批次，或围绕发货概念重新设计数据访问策略。聚合模式旨在处理一致性和性能方面的技术限制，没有绝对正确的聚合方式，若发现当前边界导致性能问题，应灵活调整。

2. 版本号的乐观并发控制

2.1 实现数据完整性

为在数据库层面确保数据完整性，可在 Product 模型中设置一个属性作为状态更改完成的标记，将其作为并发工作线程争夺的唯一资源。若两个事务同时读取批次状态并都想