X-Git-Url: https://git.saurik.com/redis.git/blobdiff_plain/a4460ef43f9625e6c09cdc327614d1b47c043489..12ebe2ac17a26ecf263f90b2acdf03db29b00223:/doc/TwitterAlikeExample.html diff --git a/doc/TwitterAlikeExample.html b/doc/TwitterAlikeExample.html index adb9bbaa..0c75cc93 100644 --- a/doc/TwitterAlikeExample.html +++ b/doc/TwitterAlikeExample.html @@ -26,8 +26,7 @@
SET foo barRedis will store our data permanently, so we can later ask for "What is the value stored at key foo?" and Redis will reply with bar:
@@ -242,7 +241,6 @@ Gentle reader, if you reached this point you are already an hero, thank you. Bef The first thing to do is to hash the key and issue the request on different servers based on the key hash. There are a lot of well known algorithms to do so, for example check the Redis Ruby library client that implements consistent hashing, but the general idea is that you can turn your key into a number, and than take the reminder of the division of this number by the number of servers you have:server_id = crc32(key) % number_of_serversThis has a lot of problems since if you add one server you need to move too much keys and so on, but this is the general idea even if you use a better hashing scheme like consistent hashing.
Ok, are key accesses distributed among the key space? Well, all the user data will be partitioned among different servers. There are no inter-keys operations used (like SINTER, otherwise you need to care that things you want to intersect will end in the same server. This is why Redis unlike memcached does not force a specific hashing scheme, it's application specific). Btw there are keys that are accessed more frequently.Special keys
For example every time we post a new message, we need to increment theglobal:nextPostId
key. How to fix this problem? A Single server will get a lot if increments. The simplest way to handle this is to have a dedicated server just for increments. This is probably an overkill btw unless you have really a lot of traffic. There is another trick. The ID does not really need to be an incremental number, but just it needs to be unique. So you can get a random string long enough to be unlikely (almost impossible, if it's md5-size) to collide, and you are done. We successfully eliminated our main problem to make it really horizontally scalable!
There is another one: global:timeline. There is no fix for this, if you need to take something in order you can split among different servers and then merge when you need to get the data back, or take it ordered and use a single key. Again if you really have so much posts per second, you can use a single server just for this. Remember that with commodity hardware Redis is able to handle 100000 writes for second, that's enough even for Twitter, I guess.
Please feel free to use the comments below for questions and feedbacks. -