我一直在研究扩展 MySQL 的解决方案。除了添加 Memcached 层之外经常出现的一个是读/写拆分——所有写入都转到主服务器，所有读取都转到一组负载平衡的从服务器。
显然，这种方法带来的一个问题是“最终一致性”。当我在主服务器上运行写操作时，复制到读从服务器需要一定的时间。因此，如果我请求新创建的行，它可能不存在。
有谁知道处理这个问题的具体策略？我读过关于“读你写的”能力的概念性部分解决方案。但是，是否有人对如何实现这样的解决方案有任何想法——无论是概念上的，还是具体在 Spring/Hibernate 堆栈中？
最佳答案
我还没有这样做，但这是一个想法。您可以在每次读取查询之前连接到的写入数据库上有一个内存缓存服务器。当您进行写入操作时，将某种类型的 key 添加到您的内存缓存中，而当您复制1 时，删除该 key 。
当您执行 memcache 读取并且您正在读取单个记录时，如果找到记录的键，您应该只从 master 读取它。如果您要选择多条记录，则从从站读取它们，然后根据内存缓存键查询每个找到的 ID。如果在 memcache 中找到任何记录，则仅从 master 数据库中重新读取这些记录。
您可能会发现，在某些(写入密集型)用例中，此策略会抵消读/写拆分的好处。但我敢打赌，在大多数情况下，额外检查 memcache 和偶尔重新读取 master 仍然值得。
1 如果您使用的是标准复制并且无法跟踪特定记录是否已完全复制，只需为所有 key 添加时间戳，并在最坏情况延迟后删除/使它们过期。例如，如果您的奴隶落后于您的主人两分钟，请忽略(并删除)超过两分钟的任何 key ，因为它们肯定会被复制。
总而言之:不要忘记在很多情况下，延迟是可以接受的。例如，如果您有一个用户更新其个人资料的网站，如果他们的更改在五分钟内没有完全传播，这在大多数情况下是可以的。关键是，imo，如果没有必要，不要过度设计某些东西以获得即时传播。
关于mysql - 如何处理MySQL读写分离中的最终一致性问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8158553/