leases at better to fight against thundering herds (too many clients trying to fill a miss) and being a bit more efficient by blocking, but same strong cas can be implemented with regular cas and add. Even the leases can be implemented with a lock on memcache when you try to update some key, implemented with add/delete (but again less efficient that the FB integrated implementation)
>From your example: - client A and Client B want to update the same key, and A(set key=>1)update database before B(set key=>2): - key not exist in cache: (A get-miss)->(B get-miss)->(B set key=2) -> (A set key=1); They should be using add, not set! B add key=2 (success) A add key=1 (fail) A re-reads from master db and updates the key using cas. If read from master db is not an option due to load, re-read from slave but set a low TTL so it's re-read and corrected soon. Said that, it's good to have this leases implemented in the vanilla memcached! Regards, On Tue, Apr 22, 2014 at 11:17 AM, Ryan McElroy <ryan...@gmail.com> wrote: > I'll take a look at the API and behavior and provide feedback. I'll also > ping our former server guys to see if they can take a look at the > implementation. > > Cheers, > > ~Ryan > > > On Sun, Apr 20, 2014 at 12:23 AM, dormando <dorma...@rydia.net> wrote: >> >> Well I haven't read the lease paper yet. Ryan, can folks more familiar >> with the actual implementation have a look through it maybe? >> >> On Thu, 17 Apr 2014, Zhiwei Chan wrote: >> >> > >> > I m working on a trading system, and getting stale data for the system >> > is unaccepted at most of the time. But the high throughput make it >> > impossible to get all data from mysql. So i want to make it more >> > reliable when use memcache as a cache. Facebook's paper "Scaling Memcache >> > at >> > Facebook" mentions a method called ‘lease' and 'mcsqueal', but the >> > mcsqueal is difficult for my case, because it is hard to get the key for >> > mysql. >> > >> > Adding the 'strong cas' feature is devoted to solve the following >> > typical problems, client A and Client B want to update the same key, and >> > A(set >> > key=>1)update database before B(set key=>2): >> > key not exist in cache: (A get-miss)->(B get-miss)->(B set key=2) -> (A >> > set key=1); >> > or key exist in cache: (A delete key)->(B delete key)->(B set key=2) -> >> > (A set key=1); >> > Some thing Wrong! the key=2 in database but key=1 in cache. >> > >> > It is possible to happen in a high concurrent system, and i don't find a >> > way to solve it with the current cas method. So i add two command 'getss' >> > and 'deletess', they will create a lease and return a cas-unique, or >> > tell the client there already exist lease on the server. the client can do >> > something to prevent stale data. such as wait, or invalidate the >> > pre-lease. >> > I also think the lease is a concept of 'dirty lock', because anybody try >> > to update it will replace itself expiration to the lease's expiration(the >> > lease's expiration time should be very short), so in the worst case(low >> > probability), the stale data only exist in cache for a short time. It is >> > accepted for most app in my case. >> > >> > For more detail information, please read doc/strongcas.txt. And hoping >> > for u guys suggestion ~_~ >> > >> > i have created a pull request on github. >> > https://github.com/memcached/memcached/pull/65 >> > >> > -- >> > >> > --- >> > You received this message because you are subscribed to the Google >> > Groups "memcached" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an email to memcached+unsubscr...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> > >> > >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "memcached" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to memcached+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Guille -ℬḭṩḩø- <bishi...@gmail.com> :wq -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
