System Design: 读书心得6

今天这篇呢是从我们身边朋友介绍看了ㄧ个 Youtube 影片，有关於 Lyft 的 Architecture。

Title：The 10 Million QPS Redis Architecture Powering Lyft

网址：https://www.youtube.com/watch?v=cSFWlF96Sds

他影片一开始是在讲他们原本的 Design 是用一个 monolithic mongoDB。然後 User 跟 Driver 都在每五秒钟会去 update 一次在那个区域里面的。 但这个架构有些问题，首先以前的 MongoDB 有一个 Global write lock。意思是每次有个更新，他们就必须要拿取这个 lock。再来在 mongoDB里面，你不能做 data sharding 在你用了 unique indexes feature 。最後在那个使用的 region 范围太大，你可能你可能会读取到一些范围太远但用不到的资料。

所以呢 当时（2017) lyft 就改了他们的 design 用了 twemproxy + redis cluster。Twemproxy 可以用来当作 load balancer 跟 consistent hashing 来 data shard 不同的 redis server。但他们发现了一个问题，就是呢当只要任何的 driver 或 user 断线，譬如说进入一个隧道等等。所以他们用了 Redis 的 expirations feature，也用了新的sharding key = region + timestamp (每30秒) 。这样就可以取後面三个靠近的时间。但问题是 region 是一个不太好的 data sharding key，很容易造成hot sharding -> 产生有很多traffic在某几个 server 上面。还有bulk expirations 也会花太多时间。

最後就用了geohash，一个 google open source S2 来当不同 location的区分。这样就不会有上面讲的 region太大的问题。详细还是要看一下S2 

Example:
pipeline.set(user_id, json.dump(loc))
pipeline.zset(geohash, user_id, now_seconds())
pipeline.zremrangebyscore(geohash, -inf, now_seconds() - 30) ////Removing