分布式，多个数据库的情况下怎么保证数据复制够快，不影响下单的时候查库存是准确的？加锁就慢了？

1. 分布式事务：使用分布式事务（如两阶段提交、三阶段提交或Saga事务）来协调跨数据库的操作，确保所有更改要么全部成功，要么全部回滚。

2. 最终一致性：采用最终一致性模型，允许短暂的数据不一致，但随着时间推移，所有副本最终会达到一致状态。这通常适用于读多写少的场景，并配合适当的超时和重试机制。

3. 异步复制：通过异步复制技术，主库的变更会被记录在日志中，然后异步地发送到从库。这种方式可以提高性能，但可能在短时间内存在数据延迟。

4. 实时复制：使用实时或近实时的数据复制技术，如MySQL的binlog复制或MongoDB的Oplog，尽可能减少延迟。

5. 读写分离：将读操作指向从库，写操作指向主库，以减轻主库压力并提高读取速度。但是，这要求在写入后，读取操作需要等待一段时间（通常通过超时设置）才能看到最新数据。

6. 分布式锁：虽然加锁可能导致性能下降，但在某些场景下是必要的，尤其是对于强一致性要求的事务。可以使用分布式锁服务（如ZooKeeper、Redis等）来协调并发操作，确保同一时刻只有一个请求可以修改库存。

7. 库存预减：在高并发场景下，可以考虑预先扣除一部分库存，然后在后台异步更新实际库存，避免在下单时因库存更新而导致的阻塞。

8. 设计合理的缓存策略：使用缓存（如Redis）来存储热点数据，减少数据库查询，但要处理好缓存和数据库的一致性问题。

每种策略都有其适用场景和权衡，需要根据业务需求和系统架构来选择合适的方法。