iT邦幫忙

2021 iThome 鐵人賽

DAY 8
0
自我挑戰組

自我學習自我挑戰,主題不設限系列 第 8

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


上一篇
System Design: 讀書心得4
系列文
自我學習自我挑戰,主題不設限8

尚未有邦友留言

立即登入留言