如何处理MySQL读/写拆分中的最终一致性问题

我一直在寻找扩展MySQL的解决方案。除了添加Memcached层之外，还有一个经常出现的问题是读/写拆分——所有写操作都会转到主设备，所有读操作都会转到一组负载平衡的从属设备

这种方法的一个明显问题是“最终一致性”。当我在主设备上运行写操作时，复制到读从设备需要一定的时间。因此，如果我请求一个新创建的行，它可能不在那里

---

有人知道处理这个问题的具体策略吗？我读过关于“读你写的东西”的概念性部分解决方案。但是，有人知道如何实现这样的解决方案吗？无论是在概念上，还是在Spring/Hibernate堆栈中？

我没有这样做，但这里有一个想法。在每次读取查询之前，可以在写数据库上连接一个memcache服务器。在执行写操作时，向memcache添加某种密钥，在复制1时，删除该密钥

当您执行memcache读取并且正在读取单个记录时，如果找到记录的键，则应仅从主记录读取。如果要选择多条记录，请从从属设备读取它们，然后根据memcache键查询找到的每个ID。如果在memcache中找到任何记录，请仅从主数据库中重新读取这些记录

您可能会发现，在某些（写重）用例中，这种策略会否定读/写分离的好处。但我敢打赌，在大多数情况下，额外的memcache检查和偶尔的主机重读仍然是值得的

1如果您使用的是标准复制，并且无法跟踪特定记录是否已完全复制，则只需在所有密钥上加时间戳，并在最坏情况下延迟后将其删除/过期即可。例如，如果您的从机落后于主机两分钟，请忽略（并删除）任何超过两分钟的密钥，因为它们肯定会被复制

所有这些都表明：不要忘记，在很多情况下，滞后是可以接受的。例如，如果您有一个网站，用户在该网站上更新他们的配置文件，如果他们的更改在五分钟内没有完全传播，在大多数情况下这是可以的。关键是，在我看来，如果没有必要，不要过度设计某些东西来获得即时传播