1.2K 60 11

Đã đăng vào thg 3 31, 4:06 CH 11 phút đọc

1.7K

Bí mật giúp Tinder xử lý 1.6 tỷ lượt quẹt mỗi ngày

Bài viết này mô tả cách hoạt động và kiến trúc của hệ thống Tinder.

Nếu thấy bài viết hay và thú vị thì ủng hộ chúng mình 1 vote và share với bạn bè cùng học về System Design nha

Bắt đầu thôi!!!

Ngày xửa ngày xưa có một học sinh tên là Nam học cơ khí ở Bách Khoa

Anh ta sau đó chuyển ngành sang học công nghệ thông tin ở FPT

Rồi đến một ngày vì ngồi máy tính nhiều quá, bạn gái anh ta chia tay anh ta

Nam đã buồn rất nhiều 😭😭😭

Nam đi giải sầu và được bạn bè giới thiệu vệ một nền tảng kết nối tên là Tinder

Mặc dù là người hướng nội Fulltime nhưng anh ta quyết định dùng thử Tinder xem sao 💔💔💔

Chương 1: Kiến trúc của hệ thống Tinder

Nam bắt đầu với việc tạo tài khoản Tinder và thêm các thông tin về độ đẹp trai và giàu có của bản thân 😂😂

Tạo thông tin người dùng

Tinder lưu trữ thông tin người dùng trong một cơ sở dữ liệu dạng key-value như Amazon DynamoDB. Và sử dụng Dynamo Streams để đẩy các thay đổi trên một bảng đến các địa điểm khác nhau một cách tự động.

Ngoài ra, thông tin người dùng được thêm vào một Message Queue để cập nhật index về địa chỉ người dùng (Location Index). Họ sử dụng Location Index này để tìm kiếm những người dùng Tinder xung quanh và giới thiệu cho nhau một cách hiệu quả.

Tinder sử dụng API Gateway

Trong kiến trúc của Tinder, họ xây dựng một API Gateway để nhận tất cả các request. Nó giống như một cánh cửa đi vào của cả hệ thống để xử lý các yêu cầu từ người dùng. API Gateway cũng có vai trò kiểm tra quyền truy cập và các quy tắc bảo mật (giống như có thêm 1 ảnh bảo vệ đứng canh gác cánh cửa)

Tinder có tới tận 500 microservices đó. Và chúng sử dụng Service Mesh để giao tiếp với nhau. Hãy tưởng tượng Service Mesh như một hạ tầng mạng để quản lý việc giao tiếp giữa các Service một cách hiệu quả nhất

Tầng Service Mesh - Hạ tầng giao thông cho các Service

Chương 2: Người con gái đến từ Nam Định

Nam được Tinder gợi ý cho các cô gái sống gần nơi ở

Hệ thống Tinder phải tìm và gợi ý những người gần đó mà chỉ dựa vào kinh độ, vĩ độ của từng người. Đây là một bài toán khá phức tạp

Các kỹ sư trong quá trình thiết kế, họ đã không chia bản đồ thành các lưới có khoảnh cách đều nhau để tránh gặp phải vấn đề Hot-Shard, bởi vì các lưới trên biển sẽ trống rỗng không có người, trong khi các lưới tại các thành phố lớn lại rất nhiều người nằm trong đó

Một hot shard là một lượng tải quá mức trên một phân vùng đơn lẻ

Thay vào đó họ quyết định sử dụng thư viện S2

S2 là một hệ thống chỉ mục địa lý phân cấp theo hình vuông được tạo ra bởi Google. S2 được biết đến là một thư viện ổn định và hỗ trợ nhiều ngôn ngữ lập trình.

S2 giúp Tinder tìm kiếm những người gần nhau một cách nhanh chóng và giúp chia nhỏ cơ sở dữ liệu lưu trữ vị trí của mọi người (Location Database)

Chia về mặt vào một ô lưới phẳng

S2 chia bề mặt trái đất thành các ô trên một lưới phẳng, gắn cho mỗi ô một ID định danh duy nhất bằng một số nguyên 64 Bit. Mỗi ô sẽ mô phỏng và đại diện cho một khu vực nhỏ trên trái đất

Sau đó sẽ lưu các người dùng có địa chỉ gần nhau trong cùng một Shard trên cơ sở dữ liệu. Qua đó giảm thiểu thời gian xử lý, giảm thiểu số shard cần dùng trong mỗi lần tìm kiếm

S2 có dạng phân cấp, có nghĩa là kích thước các ô sẽ không đều nhau mà có những nơi chia nhỏ ra cell kích cỡ Centimet vuông, có những nơi là Kilomet vuông

Ngoài ra S2 hỗ trợ tìm kiếm một ô cụ thể bằng cách sử dụng tọa độ vị trí, cung cấp tính năng giúp tì kiếm các ô xung quanh một ô cụ thể

Hilbert được Tinder sử dụng

S2 biểu thị tọa độ các điểm dựa vào đường cong Hilbert. Với cách này thì hai điểm gần nhau trên đường cong Hilbert cũng sẽ gần nhau trong không gian vật lý

Tinder sẽ query từ location Index(S2) được lưu trước đó để tìm người đề xuất. Nó sẽ trả về các Shards gần nhất. Sau đó họ sẽ query trên các shard được trả về một cách đồng thời để tìm ra những người dùng nằm trong shard.

Trung bình họ sẽ tìm kiếm trên 3 Shards để tìm kiếm bạn bè trong bán kính 160km, lọc kết quả dựa trên sở thích và đề xuất để người dùng có thể quẹt phải 😉

Và Nam đã tìm được một cô gái tên là Mai trên Tinder 😄😄😄

Nhưng mọi thứ lại không thành công vì Mai bảo rằng cô ấy không muốn yêu xa 😭

Chương 3: Chuyển địa bàn

Nam nghĩ rằng tìm các cô gái đến ở Tuyên Quang thì hợp lý hơn vì các cụ có câu "Chè Thái Gái Tuyên" mà 🤣

Nam bắt đầu sử dụng tính năng của Tinder gọi là Passport để thay đổi vị trí của mình

Tinder cập nhật thông tin địa chỉ

Sau khi Nam thay đổi vị trí, hệ thống Tinder thực hiện cập nhật Index trong Location Index của Nam.

Tinder thêm Nam vào vị trí mới và xóa Nam khỏi vị trí cũ đi và từ đó những cô gái ở Tuyên Quang có thể thấy Nam trên Tinder

Bời vì thao tác này không phải là atomic, nên là nó sẽ có rủi ro khi gặp lỗi.

Giả sử khi Nam đổi vị trí nhiều lần liên tiếp, yêu cầu một của Nam chưa thực hiện xong lại có thêm yêu cầu thứ 2 cần thực hiện luôn dẫn đến các trường hợp lỗi cho hệ thống

Lỗi xảy ra khi hệ thống không đảm bảo được thứ tự yêu cầu

Các kỹ sư Tinder quyết định sử dụng Apache Kafka để giải quyết vấn đề này

Hàng đợi trong Kafka

Để giải quyết vấn đề này, họ sử dụng Apache Kafka. Kafka có thể được hiểu như một nền tảng streaming phân tán dành cho xử lý dữ liệu lớn.

Họ gửi dữ liệu của cùng một người dùng đến một phân vùng Kafka giống nhau. Trong khi đó, những tiến trình consumer (đọc để xử lý) của Kafka sẽ khóa các phân vùng (acquire lock) để tránh xung đột. Do Kafka triển khai dữ liệu dạng hàng đợi FIFO (First-In-First-Out) nên đảm bảo được thứ tự các request và băng thông rất cao.

Ngoài ra, họ còn checkpoint Kafka để quá trình xử lý có thể tiếp tục sau khi consumer bị sập.

Chapter 4: Nam và Phương

Ngày qua ngày, Nam chăm chỉ vào Tinder để quẹt phải

Luồng xử lý khi có lượt quẹt phải

Các lượt quẹt phải của Nam sẽ được gửi về một data stream giống như Amazon Kinesis và có các service gọi là Match Worker sẽ đảm nhiệm vai trò kiểm tra danh sách những người quẹt phải được lưu trong Likes Cache

Sau khi kiểm tra trong** Likes Cache** mà tìm được người cũng quẹt phải với Nam, Tinder sẽ thông báo lượt Match bằng Websocket.

Websocket giúp Tinder gửi thông báo cho Nam một cách tức thì nhờ vào một giao thức kết nối 2 chiều (bidirectional communication protocol)

Thông báo Match được gửi đến tức thì

Tinder cũng lưu lại các lượt quẹt trái(lượt không thích) của Nam và lưu trong một** Data Storage** giống như** Amazon S3**. Và dùng các thông tin đó cho việc phân tích và cải tiến giúp tìm kiếm những người phù hợp với Nam hơn

Tìm thấy chân ái

Cho đến một ngày, Nam match với Phương,

Một cô gái đến từ Tuyên Quang Sau khi lên duyên, Nam vote 5 sao cho Tinder,

Chương 5: Số lượng người dùng ngày càng lớn

Do càng ngày càng có nhiều người như Nam tìm đến Tinder, họ phải cải thiện hệ thống để đáp ứng được lượng người dùng vô cùng lớn

Các kỹ sư Tinder nhận ra hệ thống có rất nhiều yêu cầu đọc dữ liệu được gửi về, và họ quyết định sử dụng Redis cache cho hệ thống

Hệ thống Cache của Tinder

Các thông tin được đọc nhiều lần sẽ được lưu trữ sẵn vào Cache, và khi có một yêu cầu cần đọc dữ liệu, hệ thống sẽ kiểm tra xem có sẵn trong Cache chưa, nếu chưa có thì mới đọc từ Database. Và Cache sẽ được cập nhật dữ liệu