主从暴露技术债务

Question

使用rails和postgresql。

我编写应用程序时并没有考虑使用主从配置。

现在，我已经在应用程序中设置了主从程序，现在我遇到了一些技术债务。我的应用程序中的相同进程写入数据库，然后立即从db读取。读取不是发生在读数据库上，但是数据不在那里。在此之前，这是没有效率的，但它并没有造成任何问题，因为两个星展是相同的。现在，这在我脸上爆炸了。

对我来说，问题是很难找到代码中存在此问题的所有位置。有人可以向我建议一种技术，让我的测试运行在这样一种方式，读写使用不同的dbs没有更新，以便我可以找出我的问题所在？

其他解决方案也将受到欢迎！

Answer 1

我强烈建议您重新考虑主/从配置，或者主/从是否适合您的应用程序。

构建一个假设写入持久性存储的数据可以立即读取的系统并不是“技术债务”。这是正常和正确的。虽然您可能可以合理地避免这种模式

write A, ..., look up A.key

与各种简单的缓存方案，试图编码周围。

write A, ..., complex query that *might* fetch A 

要求您保留A的副本，并确定它是否满足单独代码中查询的WHERE子句，因为您不能依赖查询结果。除非您的系统非常小和简单，尝试在系统范围内执行此操作将产生一个超级复杂、脆弱、昂贵和丑陋的代码库。我强烈建议你不要尝试。

主/从持久存储组织的通常目的是脱机读取通信量，而不依赖于写。例如，如果您的系统挖掘数据以生成用户可访问的摘要，则需要脱机度量计算，并让它挖掘从属程序。这样可以防止挖掘查询将资源从用户请求处理中提取出来。从主写到从拷贝之间的小延迟是没有问题的。

如果您的应用程序由于持久性存储负载过多而陷入困境，您可能需要分区数据(有时称为切分)，而不是主/从数据。分区会使您面临另一种问题:没有跨分区事务。但这通常比你所尝试的更容易完成。

Answer 2

在研究了这一领域之后，我同意吉恩的观点，即主奴隶只能用于阅读之前已经写好的读物。

我最初的概念是，更好的方法是使用函数式编程风格，即流程保留参数中的所有信息，然后不再求助于数据库。这种方法的缺点是，人类的大脑很难进行函数式编程，而在一个庞大的计算机程序中，不坚持这种额外的复杂性是有意义的。

如果您想要编写一个函数式方法或流程，那么这是非常棒和非常有效的，但是代码中不应该有任何坚持这一点的东西。