Elasticsearch 可以持久保存数据。判断是否适合作为主数据库时，应问：写入失败或并发执行时，哪些业务规则必须始终成立？
在订单系统中，搜索商品与确认购买是两种任务。前者关注搜索相关性，后者关注支付和库存变更的正确性。
假设一次购买需要创建订单并扣减库存。如果只有一项成功，业务必须明确如何处理。
[Create order] ---- must coordinate ---- [Reduce stock]
| |
success failure?
Elasticsearch 的 bulk API 一次提交多个文档操作，但某项失败时其他项可能已经成功。它不会将这些操作变成“全部成功或全部失败”的事务，应用需要检查每个结果。。
如果要求跨记录原子变更，事务型数据库通常更直接。自行实现协调会增加失败场景和恢复工作。
乐观并发控制检查文档是否在读取的版本之后发生变化，可以拒绝过时更新，防止一个客户端悄悄覆盖另一个客户端的修改。并发控制。
这种保护针对正在更新的文档，不会自动协调库存文档和订单文档，也不提供关系型外键或任意业务字段的跨文档唯一性规则。
选择存储前，先写下应用需要的规则。这样决策依据是具体要求，而不是“搜索引擎”或“数据库”的标签。
写入成功与搜索结果可见是两个事件：
[Write accepted] -> [Refresh] -> [Search can see the change]
Refresh 让近期变更对搜索可见。因此，按文档 ID 实时读取与搜索查询不同。refresh=wait_for 可以等待搜索可见，但不会创建多文档事务。Refresh 行为。
商品搜索页可能容忍短暂延迟。最终支付或权限决策则需要明确一致性要求，并读取能够提供这种保证的数据源。Refresh 与持久存储也是两个不同问题。
| 要求 | 可考虑的方向 | 原因 |
|---|---|---|
| 订单和相关记录必须原子变更 | 事务型主数据库 | 正确性规则应靠近权威记录。 |
| 用户需要灵活的全文搜索 | Elasticsearch 作为搜索副本 | 搜索数据可以独立建模和重建。 |
| 独立文档，且一致性要求兼容 | Elasticsearch 可能直接作为主存储 | 引入第二个数据库应有明确用途。 |
订单系统的常见设计是：
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
authoritative data search copy
CDC 捕获已提交变更；outbox 在同一事务中记录业务更新及对应事件，再由独立进程传递给索引。这样不必假设两次无关的应用写入总能一起成功。
索引链路仍需稳定 ID、版本处理、删除、重试和延迟监控。要测试从源数据重建索引，否则搜索副本可能变成第二个不一致的事实来源。
无论扮演什么角色，都要规划备份并测试恢复。副本提高可用性，但不能代替备份。根据实际配置定义可接受的数据丢失量和恢复时间。
对于订单例子，我会把事务记录保存在支持其规则的数据库中，再按搜索需求决定是否增加 Elasticsearch。对于独立的搜索型文档，则评估它能否单独满足存储、一致性和恢复要求。
**记住：**根据负载需要的保证选择，然后验证失败与恢复行为。搜索速度只是决策的一部分。
一个包含详细解答的 IT 面试题库——从初级到高级。
捐赠