View profile

#163 - Cách phòng ngừa double payments của Airbnb

Revue
 
 

Grokking Newsletter

March 22 · Issue #164 · View online

Tuyển tập những bài viết hay cùng sự kiện bổ ích dành cho kĩ sư phần mềm tại Việt Nam.


Thân gửi các bạn đọc,
Nhằm mục đích hiểu thêm về trải nghiệm của bạn đọc cũng như lắng nghe các ý tưởng đóng góp làm sao để cải thiện chất lượng nội dung của newsletter, team Grokking Newsletter muốn làm một buổi phỏng vấn nho nhỏ với 4-5 bạn đọc thường xuyên.
Buổi phỏng vấn sẽ diễn ra online trong thời gian 1 tiếng.
Nếu bạn hứng thú tham gia vào buổi khảo sát này thì hãy điền thông tin của bạn vào form sau để nhóm liên lạc: https://forms.gle/Lp89tqXPVV24d4TX7.
P/S: Nhóm newsletter đồng thời sẽ trao tặng Jetbrain license key cho 2 bạn tham gia ngẫu nhiên sau buổi survey.

Những bài viết hay
Snowflake vs BigQuery Snowflake vs BigQuery
Moving k8s communication to gRPC Moving k8s communication to gRPC
DataHub: Popular metadata architectures explained DataHub: Popular metadata architectures explained
Góc Distributed System
Cách phòng ngừa double payments trong hệ thống thanh toán của Airbnb
Một trong những vấn đề mà các hệ thống thanh toán phải xử lý là data integrity của các giao dịch, ví dụ như một truy vấn xử lý thanh toán bắt buộc phải thực hiện thành công duy nhất một lần (at most once) dù cho truy vấn đó có thể được gọi nhiều lần. Trong bài toán này, tiêu chí quan trọng là tính idempotency của API. Ở airbnb giải pháp cho bài toán này cần phải đủ generic, độc lập, dễ ứng dụng để các services khác nhau có thể sử dụng dễ dàng. Các request tới phải được xác định (identity) và được theo dõi chi tiết trạng thái xử lý phía server. Airbnb đã xây dựng thư viện về idempotency có tên là Orpheus để xử lý vấn đề này. Orpheus kết hợp những yếu tố sau:
  • Generate idempotency key cho từng request
  • Dữ liệu luôn được đọc ghi vào master node của database được thiết kế sharding
  • Lỗi trả về được phân làm 2 loại: retry được hoặc không thể retry.
  • Transaction được chia thành 3 giai đoạn: pre-rpc, rpc và post-rpc để đảm bảo tính atomicity, với hai yêu cầu:
  1. Trong giai đoạn pre-rpc và post-rpc, không tạo hoặc nhận truy vấn over network.
  2. Trong giai đoạn rpc không được truy vấn database.
Trạng thái xử lý của từng truy vấn được phía server lưu trữ đầy đủ để phản hồi những truy vấn lặp lại (retry). Phía client cần lưu trữ và quản lý idempotency key và có cơ chế retry phù hợp.
Orpheus đã giúp Airbnb đạt 99.999 (five nines) đối với tính consistency của hệ thống thanh toán trong khi khối lượng giao dịch mỗi năm tăng lên gấp đôi so với năm trước. Cụ thể mời bạn đọc ở bài viết chi tiết ở đây
Góc Data Warehouse
Presto là một hệ thống phân tán mã nguồn mở được dùng để truy vấn song song các dữ liệu được chứa trong storage hay database bằng các câu lệnh SQL (open-source massive-parallel-processing distributed SQL engine). Presto được xây dựng chủ yếu để tập trung cho các tác vụ phân tích truy vấn tương tác (interactive analysis) mà cần độ trễ thấp (low latency). Hiện tại, Presto được sử dụng phổ biến ở các data warehouse lớn cùng với những hệ thống tương tự như là Spark SQL hay Apache Impala. Bài báo sau đây được các đội ngũ kỹ sư xây dựng Presto đăng trên hội nghị ICDE vào năm 2019 để nói về cách Presto được xây dựng và tối ưu hóa như thế nào ở các giai đoạn như là: query planning, query scheduling, query execution, resource management, …
Về mặt mô hình thiết kế của hệ thống thì Presto có 2 thành phần chính:
  1. Coordinator: Bộ phận này có nhiệm là tiếp nhận các câu lệnh SQL từ người dùng và phân tích cú pháp để mà tạo ra và tối ưu hóa kế hoạch chạy câu lệnh SQL (thường được gọi là query planning). Một ví dụ về kỹ thuật được Presto áp dụng để tối ưu hóa query plan là: predicate pushdown khi mà các câu lệnh predicate/filter của SQL sẽ được đẩy xuống các tác vụ ở các leaf node của query plan để giảm dữ liệu được truy vấn càng sớm càng tốt. Để mà tận dụng các kỹ thuật tối ưu hóa khác thì Presto có các connectors cho việc truy vấn metadata từ các hệ thống storage để Presto hiểu rõ hơn về dữ liệu được cơ cấu như thế nào. Đồng thời, coordinator có nhiệm vụ dàn dựng và điều phối các tác vụ của query plan tới các workers trong một Presto cluster.
  2. Worker: Bộ phận này có nhiệm vụ là chạy các tác vụ được giao cho từ coordinator. Thường một cluster sẽ có rất nhiều workers để chạy các tác vụ. Mỗi worker có thể được dùng cho nhiều tác vụ của các câu lệnh SQL khác nhau. Tuy nhiên, để đạt được độ trễ thấp thì Presto thường chứa dữ liệu của các tác vụ trên bộ nhớ khi xử lý hay là chuyển giao giữa các workers thay vì lưu trên đĩa, đặc biệt là các dữ liệu tạm giữa các stage của query plan.
Đây là link tới bài báo nếu các bạn muốn tìm hiểu thêm về chi tiết từng bộ phận và cách các đội ngũ kỹ sư Presto tối ưu hóa cho từng giai đoạn như thế nào.
Code & Tools
This Week Sponsors
Remitano là một trong các sàn giao dịch P2P năng động tại nhiều quốc gia, Remitano cung cấp thị trường uy tín, an toàn tối đa và đơn giản cho hoạt động mua bán tiền mã hóa của hàng triệu khách hàng, với sản phẩm đầu tư đa dạng, giao dịch tức thời và đội ngũ hỗ trợ 24/7 bao gồm các chuyên gia ngân hàng có nhiều kinh nghiệm trong các sản phẩm tài chính, tiền điện tử, và hệ thống thanh toán, đảm bảo mang đến trải nghiệm tốt với mức phí thấp nhất cho người dùng.
Quotes
“The trick is to fix the problem you have, rather than the problem you want.”
- Bram Cohen
Did you enjoy this issue?
If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Charmington La Pointe, 181 Cao Thang, Dist 10, Ho Chi Minh city, Viet Nam