Kiến trúc hệ thống
Timestone là dịch vụ dựa trên gRPC. Chúng tôi dùng bộ đệm giao thức (protocol buffers) để định nghĩa định dạng (interface) của dịch vụ và cấu trúc của các gói tin giao tiếp (request and response messages). Sơ đồ hệ thống như hình dưới đây
Hệ thống lưu trữ bản ghi (records)
Hệ thống dử dụng Redis để lưu các bản ghi. Tất cả các yêu cầu ghi (xem bước 1 — nhớ là nó bao gồm cả yêu cầu lấy bản ghi ra khỏi hàng chờ vì chúng thay đổi trạng thái của hàng chờ) tới được máy chủ Redis (bước 2) sẽ được lưu vào nhật ký giao dịch (transaction log) trước khi thông tin được trả lại server (bước 3).
Ở trong cơ sở dữ liệu chúng tôi biểu diễn mỗi hàng chờ thành 1 bộ-tự-sắp-xếp (sorted set) nơi chúng tôi xếp hạng IDs của gói tin (xem mục "Gói tin" bên dưới) tùy theo độ ưu tiên. Chúng tôi lưu các gói tin và cấu hình của hàng chờ (xem mục "Hàng chờ" bên dưới) bằng cấu trúc dữ liệu hashes của Redis. Tất cả cấu trúc dữ liệu liên quan tới hàng chờ - từ gói tin nó chứa cho tới chỉ mục thứ cấp trong bộ nhớ (in-memory secondary indexes) dùng để hỗ trợ lấy gói tin theo bộ lọc chứa trong cùng 1 phân đoạn (shard) của Redis. Chúng tôi làm được việc này thông qua việc sử dụng chung tiền tố (prefix) cho các cấu trúc nằm cùng 1 hàng chờ, sau đó dùng các tiền tố này như Redis hash tag. Mỗi gói tin chứa một khối dữ liệu có độ dài tối đa 32 KiB.
Hầy như tất cả giao tiếp giữa Timestone và Redis (xem mục "Trạng thái gói tin") được lập trình bằng Lua., trong đó chúng tôi có xu hướng cập nhật thêm các cấu trúc dữ liệu. Vì Redis đảm bảo các lệnh được thực thi 1 cách hoàn chỉnh và độc lập (executed atomically) nên các lệnh sẽ được đảm bảo giữ an toàn cho hệ thống.
Tất cả các lệnh qua API đều chỉ có giới hạn trong hàng đợi đó. Tất cả các lệnh qua API thay đổi trạng thái hàng đợi đều đảm bảo chỉ được thực thi 1 lần (idempotent).
Chỉ mục thứ cấp (Secondary indexes)
Với mục đích theo dõi, chúng tôi giám sát các thông tin về các gói tin đang tới và quá trình chuyển đội trạng thái vào 2 chỉ mục thứ cấp chạy bằng Elasticsearch. Khi chúng tôi nhận được các thông tin được trả lại bởi redis từ các yêu cầu ghi, chúng tôi làm 2 việc đồng thời là trả thông tin này về cho khách và chuyển đổi thông tin này thành các sự kiện đưa vào Kafka (bước 4). 2 con Flink, mỗi con đọc thông tin về chỉ mục thứ mà cấp chúng phải xử lý từ Kafka và ghi thông tin đó vào Elasticsearch.
1 chỉ mục ("tức thời") đứa cho chúng tôi thông tin hiện trạng của hệ thống trong khi chỉ mục thứ 2 ("quá khứ") đưa cho chúng tôi thông tin thông suốt về chiều dài quá khứ của 1 gói tin khi chạy qua Timestone va trả lời các câu hỏi như: thời gian qua mỗi trạng thái, số lần xử lý lỗi...
Chúng tôi dùng bộ đếm phiên bản (version counter) cho mỗi gói tin, mỗi lệnh ghi tăng bộ đếm này thêm. Chúng tôi dựa vào bộ đếm phiên bản để sắp xếp chỉ mục quá khứ. Các sự kiện được lưu vào Elasticsearch chỉ được lưu trong 1 số ngày nhất định.
Hiện trạng sử dụng ở Netflix
Hệ thống đang đọc gói tin với tốc độ rất cao ở netflix. Mỗi giây có tới 30 ngàn gói tin được đọc với đọ trễ P99 ở mức 45ms. Để so sánh, chúng tôi đang có 1.2 ngìn gói tin được ghi với độ trễ P99 là 25ms. Những thời điểm cao tải thường xuyên ghi nhận 5 nghìn gói tin được ghi với độ trễ P99 ở mức 85ms. 15 tỉ gói tin đã được thêm vào Timestone trong 3 quý đầu năm 2022. Các gói tin này đã được đọc 400 tỉ lần, các gói tin trương hàng chờ thường ở mức 10 triệu. Chúng tôi trông đợi các thông số này gấp đôi vào năm sau sau khi chúng tôi chuyển đổ hết những phần còn lại của hệ thống cũ là Reloaded sang COSMOS.
