Lets assume there are n global caches and since the load is to be distributed uniformly among the servers and duplicity needs to be avoided, you need to write a hashfunction f which takes url as an input and returns an integer value. You can store that url on the cache x where x = value % n each time you need to compute the hashvalue and based on that you need to query on the particular cache x, if it's available bingo else store that url to cache x.
Hope it helps. On Sun, Dec 14, 2014 at 2:29 PM, atul anand <atul.87fri...@gmail.com> wrote: > approach i have mentioned have flaws . so what other approaches we can > try to solve this ? > > On Sun, Dec 14, 2014 at 2:23 PM, SOMU <somnath.nit...@gmail.com> wrote: >> >> Then the Domain name is altered from abc to bbc .. That indirectly means >> that the nameserver will change. >> >> So in that case the Cache will point to the New NameServer .. >> >> Thanks, >> Somnath Singh >> >> On Sun, Dec 14, 2014 at 2:04 PM, atul anand <atul.87fri...@gmail.com> >> wrote: >> >>> It is a system design problem . >>> >>> Suppose a http request is sent to server . Now Server maintains cache >>> for fast retrieval . if link is present int the cache then it just takes a >>> data from cache and return it to user but if not , then user will fetch >>> that http address and then store it in its cache and return same to the >>> user . >>> >>> Problem is that there are many server and many global cache as expected >>> in distributed system. Now when request is received by a server then how >>> can we maintain global cache such that server can know which cache to query >>> instead of querying each global cache as it will be inefficient. >>> >>> one approach can be...... maintain 26 global cache . Now when request is >>> received by server it check the web link say , www.*a*bc.com ... here >>> server will query cache-1 . Similarly cache-2 will take care of links with >>> starts from "b"...www.*b*bc.com ....and so on.... >>> >>> above method will avoid duplicity in caches but will not be very >>> efficient as a cache may have higher query rate than others... >>> >>> >>> any other approach ?? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Algorithm Geeks" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to algogeeks+unsubscr...@googlegroups.com. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Algorithm Geeks" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to algogeeks+unsubscr...@googlegroups.com. >> > -- > You received this message because you are subscribed to the Google Groups > "Algorithm Geeks" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to algogeeks+unsubscr...@googlegroups.com. > -- Piyush Grover *"Be a traveler, not a tourist"* -- You received this message because you are subscribed to the Google Groups "Algorithm Geeks" group. To unsubscribe from this group and stop receiving emails from it, send an email to algogeeks+unsubscr...@googlegroups.com.
