今天這篇呢是從我們身邊朋友介紹看了ㄧ個 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