On Feb 6, 11:14 pm, Margalit Silver <[email protected]> wrote:
> We set the key to expire after 6 hours so currently we know that the maximum > time a key could have inconsistent data is 6 hours but we would like it to > be updated as soon as there is a DB write. We know that this problem of > inconsistent data would be solved if we used memcache as it is supposed to > be used by adding all the servers using the addServer function, however we > are hesitant to do so because of the time lag that would be caused by a > client having to get data from another server, the reason we are running 4 > identical servers is to have quick response to many client machines. > > Based on all of this we are leaning towards a solution of notifying all > servers of an update. In order not to impact response time and not to have > these servers bogged down in notifications, the best solution might be one > with a master server that notifies the other servers to invalidate cache on > a DB write. It sounds like you're using fear of a potential bottleneck you'd have by using memcached the normal way lead you to the path of something that won't scale well. When you have 40 (10x) servers, how much of the time spent on any one of the frontends will be running work from your distributed cache invalidation tool? What will be the effect of having your cache size not grow by 10x when your traffic and servers do? What's the cost of developing this distributed cache invalidation tool (assuming you'd be building on something like spread, that's still just a starting point)? How does that cost compare to just doing the simple thing and seeing how well it works for you?
