Master + Slave数据库架构与Master + Memcache

时间:2012-01-09 21:31:19

标签: database architecture memcached scalability

假设我们有一台带有数据库的服务器和N台服务器,可用于使用Memcache缓存数据。数据库中的每条记录都可以在缓存中具有多个(但实质上少于N个)表示。例如,具有id 108的实体可以通过键entity_108_1,entity_108_2,...,entity_108_10来高速缓存。当数据库中的某些记录发生更改时,缓存中的相应记录将替换为新数据。

为什么这种架构不比主/从数据库设置好?看起来它具有相同的优点,同时还没有复制滞后。

2 个答案:

答案 0 :(得分:2)

我认为最好使用memcache。复制期间不仅存在滞后问题,而且您的N台服务器不需要巨大的硬盘空间(如果我们假设您拥有庞大的数据库)。另一方面,您将无法实现冗余。如果您的主数据库服务器死了,您就没有任何人可以使用它。因此,奴隶服务器是出于这些目的所必需的,但很可能你不需要其中的N个,如果你可以通过使用memcache来实现可扩展性,那么没有理由不这样做(我的意思是,如果你已经开发了应用程序那么知道如何使用它)。根据我的经验,维护memcached实例总是比从属MySQL服务器更容易(并且可能与其他数据库引擎相同)。

当然,如果您开发了知道如何使用memcache的应用程序,那么所有这些都是有意义的。只需在配置中添加一个连接字符串并将其用于某些数据库服务器的只读目的,就像使用master一样。使用来自其他数据源(如内存缓存)的数据假设您以这种方式填充应用程序。

答案 1 :(得分:0)

假设即使你有用于memcache的N个节点

,你仍然会有db的主/从设置

解决方案附带缺点和专业人士

如果我们在写重的情况下谈话,这并不比主/从更好。

写入过程需要使所有缓存节点上的所有缓存对象失效,并且必须等待“成功”响应,因为您要避免访问旧数据的任何副本。在这种情况下,根据缓存的对象副本数和网络速度,您可能会遇到性能不佳的问题。那说,因为你不知道哪个节点有副本,你将不得不将过期请求发送到所有节点...... :(