假设我们有一个带有数据库的服务器和 N 个可用于使用 Memcache 缓存数据的服务器。数据库中的每条记录都可以在缓存中具有多个（但远少于 N）表示。例如，id 为 108 的实体可以通过键 entity_108_1、entity_108_2、...、entity_108_10 进行缓存。当数据库中的某些记录发生更改时，缓存中的相应记录将被替换为新数据。
为什么这种架构不比主/从数据库设置好？似乎它具有相同的优势，同时又不会受到复制滞后的影响。
【问题讨论】：
标签： database architecture memcached scalability
我认为最好使用 memcache。不仅复制过程中的滞后会造成问题，而且您的 N 个服务器不需要巨大的 HDD 空间（如果我们假设您有巨大的数据库）。另一方面，您不会实现冗余。如果您的主数据库服务器死了，您将没有人来取代它。因此，从属服务器对于这些目的是必要的，但很可能您不需要其中 N 个，并且如果您可以通过使用 memcache 实现可伸缩性，那么没有理由不这样做（我的意思是，如果您开发的应用程序可以知道如何使用它）。根据我的经验，维护 memcached 实例总是比从属 MySQL 服务器更容易（并且可能与其他数据库引擎相同）。
当然，如果您开发的应用程序知道如何使用 memcache，那么所有这些都是有意义的。只需在配置中添加一个连接字符串并将其用于某些数据库服务器的只读目的，就像在 master 中使用它一样，总是更容易。使用来自其他数据源（如 memcache）的数据假定您以这种方式构建应用程序。
【讨论】：
假设即使你有 N 个用于 memcache 的节点，你仍然会有一个主/从设置 db
解决方案有优缺点
如果我们在写繁重的场景中讨论，这并不比主/从更好。
写入过程需要使所有 memcache 节点上的所有缓存对象过期，并且必须等待“成功”响应，因为您希望避免访问旧数据的任何副本。在这种情况下，根据缓存对象副本的数量和网络速度，您可能会遇到性能不佳的问题。也就是说，由于您不知道哪个节点有副本，您将不得不向所有节点发送过期请求...... :(
【讨论】：