使用 rails 和 postgresql。
我在编写应用时并未考虑使用主从配置。
现在，我已经在应用程序中设置了主从，现在我遇到了一些技术债务。我的应用程序中的相同进程写入数据库，然后立即从数据库读取。读取未在读取数据库上进行，但数据不存在。以前，这效率不高，但不会引起任何问题，因为两个数据库是相同的。现在，这在我脸上炸开了锅。
对我来说，问题是很难在代码中找到存在此问题的所有位置。有人可以向我建议一种技术，让我的测试以这样一种方式运行，即读取和写入使用不同的未更新数据库，以便我找出问题所在？
其他解决方案也将受到欢迎！
【问题讨论】：
replicated_model 添加到您的模型中以强制在主设备上写入并在从设备上读取，请查看此处的“主从复制”部分，也许这会有所帮助：amberbit.com/blog/2014/2/4/…
我强烈建议您重新考虑您的主/从配置，或者主/从是否适合您的应用程序。
构建一个假设写入持久存储的数据可以立即读回的系统并不是“技术债务”。这是正常和正确的。虽然您可以合理地避免这种模式
write A, ..., look up A.key
使用各种简单的缓存方案，尝试编写代码，例如
write A, ..., complex query that *might* fetch A
要求您保留 A 的副本并确定它是否会在单独的代码中满足查询的 WHERE 子句，因为您不能依赖查询结果。除非您的系统非常小且简单，否则尝试在整个系统范围内执行此操作将产生超级复杂、脆弱、昂贵且丑陋的代码库。我强烈建议你不要尝试。
主/从持久存储组织的通常目的是离线读取与写入无关的流量。例如，如果您的系统挖掘数据以生成可供用户访问的摘要，您将离线度量计算并让它挖掘从属服务器。这可以防止挖掘查询将资源从用户请求处理中提取出来。写入master和copy到slave之间的小延迟是没有问题的。
如果您的应用因持久存储上的负载过多而陷入困境，您可能需要分区数据（有时称为分片），而不是主/从。分区会使您面临不同类型的问题：没有跨分区事务。但这通常比您尝试的更容易解决。
【讨论】：
在研究了这个领域之后，我同意 Gene 的观点，即 master slave 应该只用于在 read 之前很长一段时间内已经写入的 read。
我的原始概念是，最好利用函数式编程风格，使过程保留参数中的所有信息，然后不求助于数据库。这种方法的缺点是人类的大脑很难进行函数式编程，在大型计算机程序中，不坚持这种增加的复杂性是有意义的。
如果你想编写一个函数式方法或过程，那很好而且非常高效，但代码中不应该有任何坚持这一点的东西。
【讨论】：