Luyện nói tiếng Anh bằng Shadowing qua video: Distributed Task Scheduler: System Design Interview (Stripe & Amazon Offers)
Chọn chế độ luyện tập
Mỗi chế độ mở một phòng luyện tập toàn màn hình.
324 câu
Nếu các câu quá ngắn hoặc quá dài, hãy bấm Edit để chỉnh sửa.
1
in this video we are going to design a distributed task
Trong video này, chúng ta sẽ thiết kế một hệ thống tác vụ phân tán.
2
scheduler like aws step functions a distributed task scheduler is a system
bộ lập lịch tương tự AWS Step Functions: một bộ lập lịch tác vụ phân tán là một hệ thống
3
that is designed to execute arbitrary code
được thiết kế để thực thi mã tùy ý
4
or trigger events at a specific time in the future either once
hoặc kích hoạt các sự kiện vào một thời điểm cụ thể trong tương lai chỉ một lần duy nhất
5
or on a recurring basis designing a robust task scheduler requires solving complex distributed systems problems including high precision
hoặc trên cơ sở lặp đi lặp lại, việc thiết lập một bộ lập lịch tác vụ mạnh mẽ đòi hỏi phải giải quyết các vấn đề phức tạp của hệ thống phân tán, bao gồm cả độ chính xác cao.
6
so a tasks should execute exactly when they are supposed to, maintaining fault tolerance so no tasks are lost if a worker node crashes,
do đó các tác vụ phải được thực thi đúng vào thời điểm dự kiến, đảm bảo khả năng chịu lỗi để không có tác vụ nào bị mất nếu một nút công nhân bị lỗi.
7
and avoiding duplicate executions in a highly concurrent environment.
và tránh các lần thực thi lặp lại trong môi trường có mức độ đồng thời cao.
8
And so this is a really popular system design that is asked in interviews by Meta, Amazon, and Microsoft.
Vì vậy, đây là một bài toán thiết kế hệ thống rất phổ biến thường được hỏi trong các buổi phỏng vấn của Meta, Amazon và Microsoft.
9
And they love to ask it because it exposes your understanding of distributed system trade -offs, which is a great way of differentiating the good candidates from the great ones.
Và họ thích đặt câu hỏi này vì nó bộc lộ sự hiểu biết của bạn về những sự đánh đổi trong hệ thống phân tán, một cách tuyệt vời để phân biệt những ứng viên giỏi với những ứng viên xuất sắc.
10
For those of you
Cho những ai trong số các bạn
11
that are struggling with system design I highly recommend you check
những ai đang gặp khó khăn trong việc thiết kế hệ thống thì tôi rất khuyên bạn nên xem qua
12
out Tech Prep where you can see the full write -up
trang Tech Prep của chúng tôi, nơi bạn có thể xem bài viết đầy đủ.
13
and the interactive AI whiteboard
và bảng trắng AI tương tác
14
that walks you through the design exactly like how an interviewer would
điều đó sẽ hướng dẫn bạn qua quy trình thiết kế chính xác giống như cách một người phỏng vấn sẽ làm.
15
and it helped me go from projections to offers from the likes of Stripe and Amazon.
và điều đó đã giúp tôi chuyển từ giai đoạn dự phóng sang nhận được các lời mời làm việc từ những công ty như Stripe và Amazon.
16
There are also a lot of system design concepts and patterns
Ngoài ra còn có rất nhiều khái niệm và mẫu thiết kế hệ thống.
17
that may be new to you in this system design and
điều đó có thể là một điều mới mẻ đối với bạn trong thiết kế hệ thống này và
18
so one way to keep up is to use the AI
vì vậy, một cách để bắt kịp xu hướng là sử dụng AI
19
highlighter where you can highlight anything in the write -up
công cụ tô sáng cho phép bạn đánh dấu bất kỳ nội dung nào trong bài viết
20
and it will give you a full explanation based on the context of this system design.
và nó sẽ cung cấp cho bạn lời giải thích đầy đủ dựa trên bối cảnh của thiết kế hệ thống này.
21
So without further ado let's jump into the requirements.
Vậy thì không chần chừ nữa, chúng ta hãy đi ngay vào các yêu cầu.
22
So for the functional requirements firstly we will need task submission
Về các yêu cầu chức năng, trước hết chúng ta cần có chức năng nộp nhiệm vụ.
23
so users can submit one -off delayed tasks or recurring tasks e .g cron expressions.
để người dùng có thể gửi các tác vụ trì hoãn một lần hoặc các tác vụ lặp đi lặp lại, ví dụ như các biểu thức cron.
24
For task execution the system must execute the provided task payload so this could be a HTTP webhook, a script or a message push at the scheduled time.
Để thực thi tác vụ, hệ thống phải thực thi phần dữ liệu tác vụ được cung cấp, có thể là một webhook HTTP, một tập lệnh hoặc một lần đẩy tin nhắn vào thời gian đã lên lịch.
25
In terms of task management users can query the state of a task so it can be pending,
Về mặt quản lý tác vụ, người dùng có thể truy vấn trạng thái của một tác vụ và trạng thái đó có thể là đang chờ xử lý,
26
running, completed, failed or cancelled and users should be able to cancel an upcoming task.
đang chạy, đã hoàn thành, thất bại hoặc bị hủy và người dùng phải có khả năng hủy một tác vụ sắp diễn ra.
27
We should also then have an execution history
Sau đó chúng ta cũng nên có một lịch sử thực thi.
28
so the system must store the output and execution logs of completed tasks for auditing purposes.
do đó hệ thống phải lưu trữ kết quả đầu ra và nhật ký thực thi của các tác vụ đã hoàn thành cho mục đích kiểm toán.
29
Then for the non -functional requirements firstly scalability the system must handle 10 000 plus task submissions per second
Về các yêu cầu phi chức năng, trước hết là khả năng mở rộng: hệ thống phải xử lý được hơn 10.000 yêu cầu gửi tác vụ mỗi giây.
30
and peak execution bursts of 50 000 tasks per second in
và đạt mức đỉnh điểm thực hiện là 50.000 tác vụ mỗi giây trong
31
terms of high availability we'll want 99 .99 uptime for task submission
Về mặt tính sẵn sàng cao, chúng ta sẽ yêu cầu thời gian hoạt động đạt 99,99% đối với việc gửi tác vụ.
32
and execution routing and then for reliability we want no data loss
và định tuyến thực thi, đồng thời về mặt độ tin cậy, chúng ta không muốn xảy ra tình trạng mất dữ liệu.
33
so once the task is acknowledged as accepted it must be durably stored
vì vậy, một khi nhiệm vụ đã được xác nhận là được chấp nhận, nó phải được lưu trữ lâu dài.
34
and guaranteed to execute and then finally in terms of precision
và được đảm bảo sẽ thực thi, cuối cùng là về mặt độ chính xác.
35
and latency tasks should begin execution within 200 milliseconds of their scheduled time.
và các tác vụ có yêu cầu về độ trễ phải bắt đầu thực hiện trong vòng 200 mili giây kể từ thời gian đã lên lịch của chúng.
36
So now that we've looked at the requirements let's look at the data model we need to build to fulfill those requirements.
Vậy là bây giờ chúng ta đã xem xét các yêu cầu, hãy cùng xem mô hình dữ liệu mà chúng ta cần xây dựng để đáp ứng những yêu cầu đó.
37
So to handle the contrasting demand of strict state management
Vì vậy, để đáp ứng nhu cầu trái ngược về quản lý trạng thái chặt chẽ
38
and the massive write -heavy logging I think a polyglot persistence strategy is required for a system of this scale
và việc ghi nhật ký với khối lượng dữ liệu khổng lồ, tôi nghĩ rằng một chiến lược lưu trữ đa ngôn ngữ là cần thiết cho một hệ thống quy mô như thế này.
39
and so what polyglot persistence simply means is
và vì vậy, sự tồn tại của nhiều loại cơ sở dữ liệu khác nhau (polyglot persistence) đơn giản có nghĩa là
40
that we have to use different data storage types for different things and I'm going to walk through each of them now.
chúng ta phải sử dụng các loại lưu trữ dữ liệu khác nhau cho những mục đích khác nhau, và bây giờ tôi sẽ đi qua từng loại một.
41
So the first thing will be our relational database which you can implement with Postgres.
Vì vậy, thứ nhất sẽ là cơ sở dữ liệu quan hệ của chúng ta, mà bạn có thể triển khai bằng Postgres.
42
So this will serve as the system's source of truth for task definitions, schedules and metadata and we rely heavily on its asset properties
Vì vậy, đây sẽ là nguồn thông tin chính thức của hệ thống đối với các định nghĩa tác vụ, lịch trình và siêu dữ liệu, và chúng tôi phụ thuộc rất nhiều vào các thuộc tính tài sản của nó.
43
and row level locking to manage the state machine of a task without race conditions.
và khóa cấp hàng để quản lý máy trạng thái của một tác vụ mà không xảy ra tình trạng tranh chấp tài nguyên.
44
And the core entities will include a task definition
Và các thực thể cốt lõi sẽ bao gồm một định nghĩa nhiệm vụ.
45
so this is the core configuration object it stores the user's
vậy đây là đối tượng cấu hình cốt lõi, nó lưu trữ thông tin của người dùng
46
intent the payload to be executed for example http webhook url
định nghĩa phần dữ liệu sẽ được thực thi, ví dụ như URL webhook HTTP
47
and body the retry policy and the scheduling logic it's either one off
và phần chính sách thử lại và logic lập lịch, nó thường là một trong hai trường hợp.
48
or a cron expression next will be our task execution
hoặc một biểu thức cron, phần tiếp theo sẽ là phần thực thi tác vụ của chúng ta.
49
so this represents a single distinct run of a task definition
vì vậy điều này đại diện cho một lần chạy riêng biệt của một định nghĩa tác vụ
50
and it acts as the primary state machine
và nó hoạt động như máy trạng thái chính
51
so we'll go from pending to queued to running to either success
vì vậy chúng ta sẽ đi từ trạng thái chờ xử lý sang trạng thái xếp hàng, sau đó sang trạng thái đang chạy và cuối cùng là trạng thái thành công
52
or failed and it includes an item potency key and tracks exactly
hoặc không thành công và nó bao gồm khóa hiệu lực của mặt hàng cũng như theo dõi chính xác
53
when the task was picked up by a worker and when it finished.
khi công việc được một nhân viên tiếp nhận và khi nó được hoàn thành.
54
So this is really important and is the kind of core of our architecture.
Vì vậy, điều này thực sự quan trọng và là cốt lõi của kiến trúc của chúng ta.
55
Next we'll also need an in -memory store which we can implement with Redis and this is also super important.
Tiếp theo, chúng ta cũng sẽ cần một kho lưu trữ trong bộ nhớ mà chúng ta có thể triển khai bằng Redis, và điều này cũng cực kỳ quan trọng.
56
So this will act as the high speed timer and scheduling buffer
Vì vậy, thiết bị này sẽ hoạt động như bộ đếm thời gian tốc độ cao và bộ đệm lập lịch.
57
and we will also utilize Redis sorted sets
và chúng tôi cũng sẽ sử dụng các tập hợp được sắp xếp của Redis
58
so z sets where the score is in the epoch execution time
vì vậy z đặt các vị trí mà điểm số nằm trong thời gian thực thi của epoch
59
and this will allow the system to query for tasks
và điều này sẽ cho phép hệ thống truy vấn các tác vụ.
60
that need to run right now in o log n time bypassing the need to constantly scan the relational database.
các tác vụ cần thực thi ngay lập tức với độ phức tạp thời gian O(log n), giúp loại bỏ nhu cầu phải quét liên tục cơ sở dữ liệu quan hệ.
61
Now if you don't know what red assorted sets are don't worry about
Bây giờ nếu bạn không biết bộ đồ chơi đỏ gồm nhiều loại là gì thì cũng đừng lo lắng.
62
that we're going to explain those in detail later on.
chúng ta sẽ giải thích những điều đó chi tiết hơn sau.
63
We'll also need a message broker so something implemented with either Kafka
Chúng ta cũng sẽ cần một bộ trung gian tin nhắn, tức là một giải pháp được triển khai bằng Kafka.
64
or RabbitMQ which will serve as the durable execution queue and
hoặc RabbitMQ sẽ đóng vai trò là hàng đợi thực thi bền vững và
65
so it decouples the scheduling components from the worker pool allowing the system to absorb massive spikes in task executions
do đó nó tách rời các thành phần lập lịch khỏi nhóm công nhân, cho phép hệ thống hấp thụ các đợt tăng đột biến lớn trong việc thực thi tác vụ.
66
so back pressure without overwhelming the database
để tạo áp lực ngược mà không làm quá tải cơ sở dữ liệu
67
and finally we'll also need a wide column store
và cuối cùng chúng ta cũng sẽ cần một kho lưu trữ cột rộng
68
so something like Cassandra and this is used exclusively for execution logs
ví dụ như Cassandra, và công cụ này chỉ được sử dụng riêng cho các nhật ký thực thi.
69
and history since a single recurring task might generate millions of
và lịch sử vì một tác vụ lặp lại duy nhất có thể tạo ra hàng triệu
70
logs over its lifetime a high write throughput horizontally scalable no sql database is ideal for this
Cơ sở dữ liệu NoSQL có khả năng mở rộng theo chiều ngang, với thông lượng ghi cao trong suốt vòng đời hoạt động, là lựa chọn lý tưởng cho việc lưu trữ nhật ký.
71
and so that's the data model so
và đó chính là mô hình dữ liệu.
72
if you understand these four data storage techniques
nếu bạn hiểu được bốn kỹ thuật lưu trữ dữ liệu này
73
and why they're used you will be in a really good place to move on to our api design
và lý do chúng được sử dụng, bạn sẽ có nền tảng vững chắc để chuyển sang phần thiết kế API của chúng ta.
74
so for a distributed task scheduler we can just use a classic restful API to interact with the data.
vì vậy đối với một bộ lập lịch tác vụ phân tán, chúng ta chỉ có thể sử dụng API RESTful cổ điển để tương tác với dữ liệu.
75
RESTful API is simple, widely used, stateless and they support caching which makes it a great candidate for our system.
RESTful API đơn giản, được sử dụng rộng rãi, không trạng thái và hỗ trợ bộ nhớ đệm, khiến nó trở thành lựa chọn tuyệt vời cho hệ thống của chúng ta.
76
So the first endpoint can be a create task endpoint.
Vì vậy, điểm cuối đầu tiên có thể là một điểm cuối tạo tác vụ.
77
So this will be a post to a v1 tasks.
Vì vậy, đây sẽ là một bài đăng cho các tác vụ v1.
78
It accepts a payload, execution time or a cron and a target and will return a task ID.
Nó nhận một phần dữ liệu (payload), thời gian thực thi hoặc một lịch cron và một đối tượng đích, sau đó sẽ trả về một ID tác vụ.
79
Next will be the get task status.
Tiếp theo sẽ là phần lấy trạng thái tác vụ.
80
This will be a get request to the v1 tasks task id
Đây sẽ là một yêu cầu GET đến endpoint v1/tasks/{task_id}.
81
and it will return the current state and metadata of that task.
và nó sẽ trả về trạng thái hiện tại cùng với siêu dữ liệu của tác vụ đó.
82
A cancel task endpoint so this will be a delete at v1 tasks task id
Một điểm cuối cho tác vụ hủy, vì vậy đây sẽ là một yêu cầu xóa tại đường dẫn v1/tasks/{task_id}.
83
and it marks a pending task as cancelled
và nó đánh dấu một tác vụ đang chờ xử lý là đã bị hủy
84
and then finally for logs we can get a get logs endpoint
và cuối cùng, đối với nhật ký, chúng ta có thể có một điểm cuối để lấy nhật ký.
85
which will be a get to a v1 tasks task id executions
sẽ là một lệnh truy xuất đến các thực thi của id tác vụ trong nhóm tác vụ v1
86
and this will return a paginated execution history of that task.
và điều này sẽ trả về lịch sử thực thi được phân trang của tác vụ đó.
87
Obviously production system will have a lot more endpoints
Rõ ràng là hệ thống sản xuất sẽ có nhiều điểm cuối hơn rất nhiều.
88
but these are the kind of core endpoints to outline to your interviewer what's kind of core to this system
nhưng đây là những loại điểm cuối cốt lõi để trình bày với người phỏng vấn về những yếu tố cốt lõi của hệ thống này.
89
and what we'll need to cover as we go through our high -level system design.
và những gì chúng ta cần đề cập khi đi qua phần thiết kế hệ thống cấp cao của mình.
90
So now that we've mentioned our data model and API design let's look at our high -level design.
Vậy là bây giờ chúng ta đã đề cập đến mô hình dữ liệu và thiết kế API của mình, hãy cùng xem xét thiết kế tổng thể của chúng ta.
91
So at a high level the system architecture can be separated in terms of accepting a task as well as executing it.
Về mặt tổng thể, kiến trúc hệ thống có thể được phân tách theo hai khía cạnh: tiếp nhận nhiệm vụ và thực thi nhiệm vụ.
92
So the first part will be the submission path.
Vậy phần đầu tiên sẽ là quy trình nộp hồ sơ.
93
So this path focuses on securely receiving the task and durably persisting its schedule.
Vì vậy, lộ trình này tập trung vào việc nhận nhiệm vụ một cách an toàn và lưu trữ lịch trình của nó một cách bền vững.
94
So here a client will upload it'll go to the gateway
Vì vậy, ở đây khách hàng sẽ tải tệp lên, và tệp đó sẽ được gửi đến cổng kết nối.
95
this will route the incoming request it'll also authenticate the client
điều này sẽ định tuyến yêu cầu đến và cũng sẽ xác thực khách hàng
96
and enforce rate limits this will then get pushed to our task management service
và thực thi các giới hạn tốc độ, sau đó dữ liệu này sẽ được đẩy đến dịch vụ quản lý tác vụ của chúng ta.
97
which validates the payload and cron expressions
điều này xác thực tính hợp lệ của phần dữ liệu và các biểu thức cron
98
and it writes the task definition to the task database again Postgres with this state of pending and then
và nó lại ghi định nghĩa tác vụ vào cơ sở dữ liệu tác vụ là Postgres với trạng thái đang chờ xử lý này, sau đó
99
if the task is scheduled to run in the very near
nếu tác vụ được lên lịch chạy trong thời gian rất sớm
100
future e .g within the next 15 minutes the service could
trong tương lai, ví dụ như trong vòng 15 phút tới, dịch vụ có thể sẽ
101
also push a lightweight reference to the task directly into the redis zset timer next is the execution path
đồng thời đẩy một tham chiếu nhẹ đến tác vụ trực tiếp vào bộ đếm thời gian zset của Redis, phần tiếp theo là đường dẫn thực thi.
102
and so this path focuses on time triggering the task
và do đó, lộ trình này tập trung vào việc kích hoạt tác vụ theo thời gian.
103
and hand and handing it off to worker nodes
và chuyển giao nó cho các nút công việc
104
so firstly we'll have relay nodes this will be a background batch process
đầu tiên chúng ta sẽ có các nút chuyển tiếp, đây sẽ là một quy trình xử lý hàng loạt chạy ngầm.
105
that periodically queries the task database postgres for tasks scheduled to run in the near future for example 10 minutes
định kỳ truy vấn cơ sở dữ liệu tác vụ Postgres để lấy các tác vụ được lên lịch chạy trong thời gian sắp tới, ví dụ như trong vòng 10 phút.
106
and stages them in the redis zset timer this prevents the database from being continuously hammered by high frequency polling
và sắp xếp chúng trong bộ đếm thời gian zset của Redis, điều này ngăn chặn việc cơ sở dữ liệu bị tấn công liên tục bởi các yêu cầu thăm dò với tần suất cao.
107
and then what we can have is we can have a fleet of lightweight scheduler nodes
và sau đó, chúng ta có thể có một cụm các nút điều phối nhẹ.
108
which will continuously run a process let's say every 100 milliseconds
trong đó sẽ liên tục chạy một quy trình, giả sử là cứ sau mỗi 100 mili giây.
109
to pull the redis z set for tasks whose scheduled time is less than
lấy tập hợp Redis Z chứa các tác vụ có thời gian lên lịch nhỏ hơn
110
or equal to the current time once we've pulled those tasks
hoặc bằng với thời gian hiện tại sau khi chúng ta đã kéo các tác vụ đó ra
111
off the redis z set we can then add them to a task queue
sau đó, chúng ta có thể lấy các phần tử từ tập hợp có thứ tự Redis ZSET và thêm chúng vào hàng đợi tác vụ.
112
and so the task payload is fetched
và do đó, phần dữ liệu của tác vụ được truy xuất
113
and pushed onto this highly available message queue
và được đẩy vào hàng đợi tin nhắn có tính sẵn sàng cao này
114
and to prevent noisy neighbors where one customer submitting 50 000 tasks saturates the queue
và để ngăn chặn tình trạng “hàng xóm ồn ào” khi một khách hàng gửi 50.000 tác vụ làm quá tải hàng đợi
115
and delays others tasks are rooted to tenant specific queues using a hash of the tenant id
và việc làm chậm các tác vụ khác bắt nguồn từ các hàng đợi riêng của từng khách hàng thuê, sử dụng giá trị băm của mã định danh khách hàng thuê.
116
and this allows workers to round robin between tenant queues ensuring
và điều này cho phép các nhân viên luân phiên giữa các hàng đợi của người thuê nhà để đảm bảo
117
equitable compute distribution among our customers next we'll have our worker nodes
phân bổ tài nguyên tính toán một cách công bằng cho các khách hàng của chúng ta, tiếp theo chúng ta sẽ có các nút công việc.
118
and so this is a fleet of horizontally scaled compute nodes
và đây là một cụm các nút tính toán được mở rộng theo chiều ngang.
119
that consume messages from the queue execute the business logic eg
đó tiêu thụ các tin nhắn từ hàng đợi để thực thi logic nghiệp vụ, ví dụ:
120
make the request to the target system the http webhook
gửi yêu cầu đến hệ thống đích thông qua webhook HTTP
121
and then report the successor failure to the task database
sau đó báo cáo thành công hay thất bại cho cơ sở dữ liệu nhiệm vụ.
122
and then keep a historical log in cassandra
sau đó hãy lưu nhật ký lịch sử vào Cassandra
123
so pretty simple system it's not too crazy and so
hệ thống này khá đơn giản, không quá phức tạp đâu.
124
while this high level design does separate our concerns it does contain critical flaws
mặc dù thiết kế cấp cao này đã phân tách các mối quan tâm, nhưng nó vẫn chứa đựng những sai sót nghiêm trọng
125
so pulling our database efficiently we can dive deeper into
vì vậy, bằng cách truy xuất cơ sở dữ liệu của chúng ta một cách hiệu quả, chúng ta có thể đi sâu hơn vào
126
that workers can crash mid -execution leaving tasks stuck in limbo
rằng các worker có thể bị lỗi giữa lúc thực thi, khiến các tác vụ bị kẹt ở trạng thái chưa hoàn thành.
127
which we'll have to deal with
mà chúng ta sẽ phải giải quyết
128
and network retries could cause a payment task to execute twice
và việc thử lại mạng có thể khiến một tác vụ thanh toán được thực hiện hai lần
129
and so we have to deep diaper into all of these and show how we can resolve them.
và vì vậy chúng ta phải đi sâu vào tất cả những vấn đề này để chỉ ra cách chúng ta có thể giải quyết chúng.
130
So firstly let's look at Redis Z sets and how they're implemented so we have a better understanding.
Trước hết, hãy cùng xem xét các Z-Set của Redis và cách chúng được triển khai để chúng ta có sự hiểu biết rõ hơn.
131
So Redis sorted sets is an in -memory data structure that automatically orders unique elements by a specific score.
Vậy các tập hợp được sắp xếp của Redis là một cấu trúc dữ liệu trong bộ nhớ tự động sắp xếp các phần tử duy nhất theo một điểm số cụ thể.
132
In this case the Unix execution timestamp allowing the scheduler to instantly identify
Trong trường hợp này, dấu thời gian thực thi của Unix cho phép bộ lập lịch xác định ngay lập tức
133
and extract tasks run in o log n time without constantly polling
và trích xuất các tác vụ chạy trong thời gian O(log n) mà không cần phải thăm dò liên tục.
134
and overwhelming our primary database and
và làm quá tải cơ sở dữ liệu chính của chúng ta
135
so under the hood the way it's implemented is two data structures the first one is a hash map
về mặt bên trong, cách nó được triển khai là dựa trên hai cấu trúc dữ liệu, cấu trúc đầu tiên là một bản đồ băm.
136
and this is used for o1 point lookups
và cái này được dùng để tra cứu điểm o1
137
so the purpose of this is to get
vậy thì mục đích của việc này là để có được
138
that instant access via task id and
truy cập tức thì thông qua ID tác vụ và
139
so the situation this would be used is like
vậy thì tình huống mà cái này sẽ được sử dụng là như thế này
140
if a user wants to cancel an upcoming task
nếu người dùng muốn hủy một tác vụ sắp diễn ra
141
or the system needs to check its exact scheduled time can check via the task
hoặc nếu hệ thống cần kiểm tra thời gian lên lịch chính xác, bạn có thể kiểm tra thông qua tác vụ.
142
id to get its execution timestamp
ID để lấy dấu thời gian thực thi của nó
143
and redis ignores time -based sorting entirely by consulting this internal hash map to find by key
và Redis hoàn toàn bỏ qua việc sắp xếp theo thời gian bằng cách tham chiếu vào bảng băm nội bộ này để tìm kiếm theo khóa.
144
and instantly return the execution timestamp in o of one time
và ngay lập tức trả về dấu thời gian thực thi với độ phức tạp O(1)
145
so it doesn't have to traverse any list the second data structure is the skip list
vì vậy nó không phải duyệt qua bất kỳ danh sách nào, cấu trúc dữ liệu thứ hai là danh sách nhảy.
146
and this is for o log n time -based polling and
và đây là cho phương thức thăm dò dựa trên thời gian O(log n) và
147
so here this is the purpose of this is for fast traversal by execution timestamp.
vậy thì mục đích của cái này là để duyệt nhanh theo dấu thời gian thực thi.
148
And so the scenario we use this is like the schedule node polls for tasks ready to execute right now.
Vì vậy, kịch bản chúng tôi sử dụng tính năng này là nút lập lịch sẽ thăm dò các tác vụ đã sẵn sàng để thực thi ngay lập tức.
149
So we'll check for tasks that's execution time is less than or equal to right now.
Vì vậy, chúng ta sẽ kiểm tra các tác vụ có thời gian thực thi nhỏ hơn hoặc bằng thời điểm hiện tại.
150
And so obviously Redis cannot use the hash map here because it doesn't know which specific task IDs are right for execution.
Vì vậy, rõ ràng là Redis không thể sử dụng bảng băm ở đây vì nó không biết chính xác những ID tác vụ nào phù hợp để thực thi.
151
Instead it goes to this skip list. And
Thay vào đó, nó sẽ đi vào danh sách bỏ qua này. Và
152
so it uses the upper level express lanes to quickly skip
vì vậy nó sử dụng làn đường cao tốc ở tầng trên để nhanh chóng vượt qua
153
over millions of tasks scheduled far into the future like task C
qua hàng triệu tác vụ được lên lịch cho một thời điểm rất xa trong tương lai, ví dụ như tác vụ C
154
and it drops down to the base level only
và nó chỉ giảm xuống mức cơ sở thôi.
155
when it nears the target timestamp landing directly on the threshold of ready tasks to instantly extract them for the message queue.
khi nó đến gần dấu thời gian mục tiêu, nó sẽ hạ cánh ngay tại ngưỡng của các tác vụ sẵn sàng để ngay lập tức trích xuất chúng cho hàng đợi tin nhắn.
156
So if we look at a quick example let's say we're polling for ready tasks
Vì vậy, nếu chúng ta xem xét một ví dụ nhanh, giả sử chúng ta đang thực hiện thăm dò các tác vụ đã sẵn sàng.
157
and the current timestamp is this one here on the screen.
và dấu thời gian hiện tại là cái này ở trên màn hình.
158
Okay well the first thing we're going to do is start at level three start at our head
Được rồi, việc đầu tiên chúng ta sẽ làm là bắt đầu từ cấp độ ba, bắt đầu từ phần đầu của chúng ta.
159
and then look right and when we look right we can see we have task c
sau đó hãy nhìn sang phải, và khi chúng ta nhìn sang phải, chúng ta có thể thấy rằng chúng ta có nhiệm vụ c.
160
which as you can see is greater than our current time stamp as we can see that's in the future
như bạn có thể thấy thì nó lớn hơn dấu thời gian hiện tại của chúng ta, vì chúng ta có thể thấy rằng đó là thời điểm trong tương lai.
161
so we can ignore it so what do we do
vậy chúng ta có thể bỏ qua nó, vậy bây giờ chúng ta làm gì?
162
so we drop down to the next level
vì vậy chúng ta chuyển xuống cấp độ tiếp theo
163
and again we start out our head and we look to the right
và một lần nữa chúng ta bắt đầu quay đầu và nhìn sang bên phải
164
and as you can see we move across
và như các bạn thấy, chúng ta di chuyển ngang qua
165
and we can see the time stamp is exactly equal to our current time stamp
và chúng ta có thể thấy dấu thời gian hoàn toàn khớp với dấu thời gian hiện tại của chúng ta.
166
and so therefore we know we have found our upper bound
và do đó chúng ta biết rằng chúng ta đã tìm thấy giới hạn trên của mình.
167
and so what we now need to do is find all the elements up to
và vì vậy điều chúng ta cần làm bây giờ là tìm tất cả các phần tử cho đến
168
that upper bound and the way we do
giới hạn trên đó và cách chúng ta thực hiện
169
that is drop down again a level and
đó là lại bị giảm thêm một cấp nữa và
170
because we're at the bottom level here we know this is a perfectly sorted link list
vì chúng ta đang ở mức dưới cùng ở đây, chúng ta biết đây là một danh sách liên kết được sắp xếp hoàn hảo.
171
and so redis instantly knows
và do đó Redis biết ngay lập tức
172
that any node from the head to task b is right for execution
rằng bất kỳ nút nào từ nút đầu đến tác vụ b đều phù hợp để thực thi
173
so it sequentially traverses the level one extracting task a
vì vậy nó sẽ duyệt tuần tự qua từng cấp độ để trích xuất tác vụ A.
174
and task b and returning them to the scheduler to be pushed to the kafka queue
và nhiệm vụ b, sau đó trả chúng về bộ lập lịch để đẩy vào hàng đợi Kafka.
175
so hopefully that makes sense
vậy hy vọng là điều đó có lý nhé
176
and again the primary architectural benefit here is we are able
và một lần nữa, lợi ích kiến trúc chính ở đây là chúng ta có thể
177
to extract ready to run tasks in o log n time without constantly polling and overwhelming the primary database.
để trích xuất các tác vụ sẵn sàng thực thi trong thời gian O(log n) mà không cần phải liên tục thăm dò và gây quá tải cho cơ sở dữ liệu chính.
178
So next we need a look at high precision scheduling.
Tiếp theo, chúng ta cần xem xét về lập lịch độ chính xác cao.
179
So running a select all from the tasks table in our
Vậy là chạy câu lệnh select tất cả từ bảng tasks trong hệ thống của chúng ta
180
Postgres database containing billions of rows every second will instantly melt the database.
Cơ sở dữ liệu Postgres chứa hàng tỷ hàng mỗi giây sẽ ngay lập tức làm quá tải hệ thống cơ sở dữ liệu.
181
We need a way to track time efficiently to achieve that less than 200 milliseconds execution precision without database bottlenecking.
Chúng ta cần một phương pháp theo dõi thời gian hiệu quả để đạt được độ chính xác thực thi dưới 200 mili giây mà không gây tắc nghẽn cơ sở dữ liệu.
182
And so we will implement a push -pull time partitioned architecture.
Và do đó, chúng ta sẽ triển khai một kiến trúc phân chia thời gian kiểu đẩy - kéo.
183
So the first step, again, we have our luck ahead cron.
Vậy bước đầu tiên, xin nhắc lại, chúng ta có cron job kiểm tra may mắn đã được thiết lập sẵn.
184
So this background relay worker will wake up every five minutes
Vì vậy, worker relay chạy nền này sẽ được đánh thức cứ sau năm phút.
185
and it'll query the Postgres database for all tasks scheduled to run in the next 10 minutes.
và nó sẽ truy vấn cơ sở dữ liệu Postgres để lấy tất cả các tác vụ được lên lịch chạy trong 10 phút tới.
186
Then we'll have our Redis sorted set.
Sau đó, chúng ta sẽ có tập hợp được sắp xếp của Redis.
187
The relay will push these upcoming task IDs into the Redis Z set.
Bộ chuyển tiếp sẽ đẩy các ID tác vụ sắp tới này vào tập hợp Z của Redis.
188
And the score in the Z set again is that exact Unix epoch timestamp of when the task should run.
Và điểm số trong tập Z một lần nữa chính là dấu thời gian Unix epoch chính xác của thời điểm tác vụ sẽ chạy.
189
Then we will have sub second polling.
Sau đó, chúng ta sẽ có chế độ thăm dò dưới một giây.
190
So a fleet of lightweight scheduler nodes will pull the Redis Z set every 100 milliseconds.
Vì vậy, một cụm các nút lập lịch nhẹ sẽ truy xuất tập hợp Z của Redis mỗi 100 mili giây.
191
looking for tasks where the score is less than or equal to the current timestamp.
tìm các nhiệm vụ có điểm số nhỏ hơn hoặc bằng thời gian hiện tại.
192
Then we will have an atomic handoff, so using a Lua script.
Sau đó chúng ta sẽ thực hiện chuyển giao nguyên tử bằng cách sử dụng một tập lệnh Lua.
193
So to prevent multiple scheduler nodes from pulling the exact same task during concurrent polling, we use a custom Lua script.
Vì vậy, để ngăn chặn nhiều nút bộ lập lịch lấy cùng một tác vụ trong quá trình thăm dò đồng thời, chúng tôi sử dụng một tập lệnh Lua tùy chỉnh.
194
And because Redis executes Lua scripts as a single indivisible transaction on its single threaded event loop, it guarantees an atomic check and pop.
Và vì Redis thực thi các tập lệnh Lua dưới dạng một giao dịch không thể chia sẻ duy nhất trên vòng lặp sự kiện đơn luồng của nó, nó đảm bảo việc kiểm tra và lấy phần tử ra là nguyên tử.
195
And so this means that the script queries for the ready tasks and immediately deletes them,
Và điều này có nghĩa là tập lệnh sẽ truy vấn các tác vụ đã sẵn sàng và ngay lập tức xóa chúng,
196
safely handing the tasks to exactly one scheduler to then push onto the message queue.
giao các tác vụ một cách an toàn cho đúng một bộ lập lịch để sau đó đẩy vào hàng đợi tin nhắn.
197
And then finally, to mitigate thundering herds.
Và cuối cùng, là để giảm thiểu hiện tượng thundering herd.
198
So, for example, humans will naturally schedule cron jobs at clean intervals, for example, every midnight.
Vì vậy, ví dụ, con người sẽ tự nhiên lên lịch các công việc cron theo các khoảng thời gian rõ ràng, ví dụ, mỗi nửa đêm.
199
And so to prevent massive artificial latency spikes at the top of the hour, the schedule can inject optional execution jitter,
Và do đó, để ngăn chặn các đột biến độ trễ nhân tạo lớn vào đúng giờ, lịch trình có thể đưa vào độ lệch thời gian thực thi tùy chọn.
200
which will add a random number of seconds between, let's say, 0 and 300 delay for tasks
điều này sẽ thêm một khoảng trễ ngẫu nhiên tính bằng giây, nằm trong khoảng từ 0 đến 300 giây cho các tác vụ.
201
that do not require strict millisecond precision so that we can smooth out that load curve,
không đòi hỏi độ chính xác nghiêm ngặt đến từng mili giây để chúng ta có thể làm phẳng đường cong tải đó,
202
ensuring that we don't have massive spikes in executions.
đảm bảo rằng chúng ta không có những đợt tăng đột biến lớn về số lượng lệnh được thực thi.
203
And so the architectural benefit here is the heavy relational database is only queried sequentially in predictable batches,
Và do đó, lợi ích về mặt kiến trúc ở đây là cơ sở dữ liệu quan hệ nặng chỉ được truy vấn tuần tự theo các lô có thể dự đoán trước.
204
while the high frequency sub -second polling and lock frequency concurrency control is handled entirely in memory by Redis.
trong khi việc thăm dò tần số cao dưới một giây và kiểm soát đồng thời tần số khóa được xử lý hoàn toàn trong bộ nhớ bởi Redis.
205
Next, we need to look at our worker fault tolerance.
Tiếp theo, chúng ta cần xem xét khả năng chịu lỗi của các worker.
206
So a major distributed system problem is the stuck task.
Vì vậy, một vấn đề lớn của hệ thống phân tán là tác vụ bị kẹt.
207
So what happens if a worker node pulls a critical task from the queue, but the server suffers a hard crash before finishing?
Vậy điều gì sẽ xảy ra nếu một nút công nhân lấy một tác vụ quan trọng ra khỏi hàng đợi, nhưng máy chủ bị sập hoàn toàn trước khi hoàn thành tác vụ đó?
208
Well, the task must not be lost, nor can it be duplicated prematurely.
Chà, nhiệm vụ không được để thất lạc, cũng không thể sao chép sớm trước thời hạn.
209
So to guarantee at least once delivery and fault tolerance,
Vì vậy, để đảm bảo việc giao nhận ít nhất một lần và khả năng chịu lỗi,
210
we rely on visibility timeouts and explicit acknowledgements natively supported by brokers like AWS SQS or RabbitMQ.
chúng tôi dựa vào thời gian chờ hiển thị và các xác nhận rõ ràng được hỗ trợ nguyên bản bởi các broker như AWS SQS hoặc RabbitMQ.
211
what we need is
những gì chúng ta cần là
212
when a worker pulls a message the broker does not delete
khi một công nhân kéo một tin nhắn, nhà môi giới không xóa nó
213
it instead it will update the metadata attribute on the message
thay vào đó, nó sẽ cập nhật thuộc tính siêu dữ liệu trên tin nhắn
214
for example we could have a field invisible underscore until timestamp and so
ví dụ, chúng ta có thể có một trường có tên `invisible_until_timestamp` và các trường tương tự.
215
when other workers pull the queue the broker's internal query simply
khi các worker khác kéo hàng đợi, truy vấn nội bộ của broker sẽ đơn giản là
216
filters out messages where the invisible until is greater than the current time
lọc bỏ các tin nhắn có thời gian ẩn cho đến lúc lớn hơn thời gian hiện tại
217
because that is currently being executed
vì hiện tại nó đang được thực thi
218
and we should not touch it we'll also have the receipt handle
và chúng ta không nên chạm vào nó, chúng tôi cũng sẽ giữ phiếu thu.
219
and so upon pulling the message the broker also gives the worker a unique temporary identifier
và do đó, khi lấy tin nhắn, bộ điều phối cũng cung cấp cho tiến trình xử lý một mã định danh tạm thời duy nhất.
220
so this receipt handle or delivery tag and we'll see why that's important in just a second.
vậy thì đây là phần xử lý hóa đơn hoặc nhãn giao hàng, và chúng ta sẽ thấy tại sao điều này lại quan trọng ngay sau đây.
221
We'll also have heartbeats so this is the visibility extension so
Chúng tôi cũng sẽ có tính năng nhịp tim, vậy nên đây là phần mở rộng về khả năng hiển thị.
222
if a task naturally takes a long time a background thread on the worker periodically pings the broker to overwrite
nếu một tác vụ tự nhiên mất nhiều thời gian, một luồng nền trên máy công nhân sẽ định kỳ gửi tín hiệu ping đến broker để ghi đè.
223
and extend the invisible until timestamp actively maintaining its exclusive lock and preventing other workers from touching it.
và kéo dài thời gian ẩn cho đến khi dấu thời gian chủ động duy trì khóa độc quyền của nó và ngăn các worker khác can thiệp vào.
224
We'll also have the ACK which is the final deletion and
Chúng ta cũng sẽ có ACK, tức là tín hiệu xóa cuối cùng và
225
so upon successful completion the worker sends the receipt handle
sau khi hoàn tất thành công, tiến trình sẽ gửi mã biên nhận.
226
which we saw previously back to the broker in an ACK request
mà chúng ta đã thấy trước đó được gửi trở lại cho broker trong một yêu cầu ACK
227
and the broker uses this handle to locate the message in O of one time
và nhà môi giới sử dụng định danh này để xác định vị trí của tin nhắn trong thời gian O(1).
228
and permanently hard delete it from its memory or disk so that it is never picked up again by any other worker.
và xóa vĩnh viễn nó khỏi bộ nhớ hoặc đĩa lưu trữ để không có worker nào khác có thể truy xuất lại được nữa.
229
And then in the case of handling the crash well
Và sau đó là trường hợp xử lý tốt tình huống va chạm.
230
if a worker crashes it stops sending the heartbeats
nếu một worker bị lỗi, nó sẽ ngừng gửi các tín hiệu heartbeat.
231
and never sends the ACK and so once the invisible until timestamp expires
và không bao giờ gửi gói ACK, do đó một khi thời gian chờ của dấu thời gian không nhìn thấy được hết hạn.
232
and it's in the past the message naturally becomes visible again for a healthy worker node to claim
và khi thời gian đó đã qua, thông điệp sẽ tự động hiển thị trở lại để một nút worker đang hoạt động ổn định tiếp nhận.
233
and process and so this is a really nice way of handling
và quy trình, và đây là một cách rất hay để xử lý vấn đề.
234
that worker fault tolerance that most candidates won't be able to answer.
khả năng chịu lỗi của worker mà hầu hết các ứng viên sẽ không thể trả lời được.
235
Next we need to look at execution guarantees and
Tiếp theo chúng ta cần xem xét các đảm bảo thực thi và
236
because our fault tolerance mechanism relies on timeouts
vì cơ chế chịu lỗi của chúng ta dựa trên thời gian chờ
237
and retries we guarantee at least once execution however this means
và các lần thử lại, chúng tôi đảm bảo thực thi ít nhất một lần, tuy nhiên điều này có nghĩa là
238
that a task might run twice and
rằng một tác vụ có thể chạy hai lần và
239
so strict exactly once delivery is theoretically impossible over an unreliable
việc đảm bảo giao nhận chính xác một lần một cách nghiêm ngặt là không thể về mặt lý thuyết trên một kênh không đáng tin cậy
240
network therefore we must implement idempotency to make duplicate executions harmless
do đó, đối với mạng, chúng ta phải triển khai tính chất đồng nhất (idempotency) để đảm bảo các lần thực thi trùng lặp không gây hại.
241
so we need optimistic concurrency control
vì vậy chúng ta cần cơ chế kiểm soát đồng thời lạc quan
242
so before a worker executes a payload it attempts to update the task status in postgres
vì vậy trước khi một worker thực thi một payload, nó sẽ cố gắng cập nhật trạng thái tác vụ trong PostgreSQL
243
so you'll update the status to running
vậy bạn sẽ cập nhật trạng thái thành đang chạy
244
and increment its version number by one right and so this means
và tăng số phiên bản của nó lên một đơn vị, đúng không, và điều này có nghĩa là
245
if the worker crashed previously
nếu tiến trình đã bị lỗi trước đó
246
and a duplicate worker picks up the same task the database will reject the second update
và nếu một worker trùng lặp nhận cùng một tác vụ, cơ sở dữ liệu sẽ từ chối bản cập nhật thứ hai.
247
because the status is no longer pending
vì trạng thái không còn là đang chờ xử lý nữa
248
and the worker knows to safely discard the duplicate and again
và nhân viên biết cách vứt bỏ bản sao một cách an toàn và tiếp tục quy trình.
249
that version number acts as a unique constraint
số phiên bản đó hoạt động như một ràng buộc duy nhất
250
so once one worker increments it from one to two the second worker's update fails
vì vậy khi một nhân viên tăng giá trị từ một lên hai, bản cập nhật của nhân viên thứ hai sẽ thất bại.
251
because it will still be looking for version one and
vì nó vẫn sẽ tiếp tục tìm kiếm phiên bản một và
252
so this implements the optimistic locking ensuring exactly one worker can claim a task even under high concurrency
vì vậy điều này triển khai khóa lạc quan, đảm bảo chỉ có đúng một worker có thể nhận một tác vụ ngay cả trong điều kiện đồng thời cao.
253
and the version number means the check and update operation truly is atomic
và số phiên bản có nghĩa là hoạt động kiểm tra và cập nhật thực sự là nguyên tử.
254
and we'll also need client side item potency keys
và chúng ta cũng sẽ cần các khóa hiệu lực của mục ở phía máy khách
255
so for HTTP webhook tasks the scheduler will inject an item
vì vậy đối với các tác vụ webhook HTTP, bộ lập lịch sẽ chèn một mục vào
256
potency key header generated from the task id plus the execution timestamp into the outbound request
tiêu đề khóa hiệu lực được tạo từ mã nhiệm vụ cộng với dấu thời gian thực thi vào yêu cầu gửi đi
257
and the downstream system receiving the webhook is responsible for using this key to ignore duplicate HTTP calls
và hệ thống ở phía sau nhận webhook sẽ chịu trách nhiệm sử dụng khóa này để loại bỏ các yêu cầu HTTP trùng lặp.
258
and so by using these mechanisms we are improving our execution guarantees.
và bằng cách sử dụng những cơ chế này, chúng tôi đang cải thiện các đảm bảo thực thi của mình.
259
And then finally looking at scaling our storage layer
Và cuối cùng là xem xét việc mở rộng quy mô lớp lưu trữ của chúng ta.
260
because handling 10 ,000 plus continuous task commissions per second pushes the limits of single node architectures.
vì việc xử lý hơn 10.000 lệnh tác vụ liên tục mỗi giây sẽ vượt quá giới hạn của các kiến trúc nút đơn.
261
This translates to 10 ,000 plus database inserts operations per second plus B3 index updates all
Điều này tương đương với hơn 10.000 thao tác chèn dữ liệu vào cơ sở dữ liệu mỗi giây, cùng với việc cập nhật chỉ mục B3.
262
while serving continuous select queries from the relay components.
trong khi vẫn tiếp tục xử lý các truy vấn chọn lọc liên tục từ các thành phần relay.
263
And so to prevent severe CPU and disk IO bottlenecks both the relational database
Và do đó, để ngăn chặn các điểm nghẽn nghiêm trọng về CPU và I/O đĩa, cả cơ sở dữ liệu quan hệ
264
and the in -memory Redis cluster must be horizontally partitioned
và cụm Redis lưu trữ trong bộ nhớ phải được phân vùng theo chiều ngang
265
so firstly looking at postgres you know
đầu tiên thì chúng ta hãy xem xét PostgreSQL nhé
266
while a heavily provisioned single postgres primary can technically peak at 10 000 tps running it at
trong khi một máy chủ PostgreSQL chính được trang bị mạnh mẽ về mặt kỹ thuật có thể đạt đỉnh 10.000 giao dịch mỗi giây khi chạy ở mức
267
that threshold and production guarantees latency spikes and lock contention and
ngưỡng đó và việc sản xuất đảm bảo sẽ gây ra sự tăng vọt về độ trễ và xung đột khóa
268
so firstly we'll need horizontal sharding
vì vậy trước hết chúng ta sẽ cần phân chia dữ liệu theo chiều ngang
269
so we distribute the right load across multiple independent postgresql clusters
vì vậy chúng tôi phân bổ khối lượng công việc phù hợp trên nhiều cụm PostgreSQL độc lập.
270
for a multi -tenant sas platform we shard based on tenant id
Đối với nền tảng SaaS đa khách thuê, chúng tôi phân mảnh dữ liệu dựa trên ID của khách thuê.
271
and this ensures data locality
và điều này đảm bảo tính cục bộ của dữ liệu
272
so all tasks for specific customer reside on the same database node keeping transactions highly localized
vì vậy tất cả các tác vụ cho một khách hàng cụ thể sẽ nằm trên cùng một nút cơ sở dữ liệu, giúp các giao dịch có tính cục bộ cao.
273
and by provisioning 10 distinct nodes the load drops to a highly manageable 1000 tps per primary
và bằng cách cung cấp 10 nút riêng biệt, tải trọng sẽ giảm xuống mức rất dễ quản lý là 1000 tps cho mỗi nút chính.
274
and then we'll also have time -based table partitioning
và sau đó chúng ta cũng sẽ có phân vùng bảng dựa trên thời gian
275
so as the system scales to billions of executed tasks the
khi hệ thống mở rộng quy mô lên đến hàng tỷ tác vụ được thực thi thì
276
active database shard will become bloated slowing down the look ahead cron queries
phân đoạn cơ sở dữ liệu đang hoạt động sẽ bị quá tải, làm chậm các truy vấn cron tìm kiếm trước.
277
and so we can mitigate this by partitioning the task tables by month
và do đó chúng ta có thể giảm thiểu vấn đề này bằng cách phân vùng các bảng nhiệm vụ theo tháng.
278
or week and
hoặc tuần và
279
so this allows the system to quickly drop historical partitions archiving
do đó điều này cho phép hệ thống nhanh chóng loại bỏ các phân vùng lịch sử đang được lưu trữ.
280
them to cold storage like s3 without running expensive delete queries and keeping the active b3 index incredibly small and fast
chuyển chúng vào kho lưu trữ lạnh như S3 mà không cần chạy các truy vấn xóa tốn kém, đồng thời giữ cho chỉ mục B3 đang hoạt động luôn cực kỳ nhỏ gọn và nhanh chóng.
281
next looking at redis and so
tiếp theo là xem xét Redis và các công nghệ tương tự
282
because redis operates entirely in memory a single instance can handle
vì Redis hoạt động hoàn toàn trong bộ nhớ nên một phiên bản duy nhất có thể xử lý
283
100 000 simple operations per second however a single node creates a single point of failure
Tuy nhiên, với khả năng thực hiện 100.000 thao tác đơn giản mỗi giây, một nút duy nhất sẽ tạo ra một điểm yếu duy nhất trong hệ thống.
284
and a massive single sorted set degrades performance and
và một tập hợp được sắp xếp đơn lẻ có quy mô lớn sẽ làm giảm hiệu suất
285
so we can see time complexity duration so because we rely on zadd
để chúng ta có thể xem được độ phức tạp về thời gian, vì chúng ta đang dựa vào zadd.
286
and z range by score queries both of
và phạm vi z theo các truy vấn điểm số của cả hai
287
which operate o log n time as a single z set
hoạt động với độ phức tạp thời gian O(log n) như một tập hợp Z duy nhất
288
grows to millions of elements the single threaded redis event loop will begin to block
khi số lượng phần tử tăng lên hàng triệu, vòng lặp sự kiện đơn luồng của Redis sẽ bắt đầu bị chặn.
289
and so therefore we will need time bucketed keys
và vì vậy chúng ta sẽ cần các khóa được phân loại theo khoảng thời gian.
290
so instead of one global schedule task zset we can partition
vì vậy thay vì dùng một zset duy nhất cho tác vụ lên lịch toàn cục, chúng ta có thể phân vùng nó.
291
zsets by time bucket for example tasks minute you know 2 30
Các zset được phân loại theo khoảng thời gian, ví dụ như các tác vụ theo phút, bạn biết đấy, 2 giờ 30 phút.
292
and tasks minute 2 31 and as well as
và các nhiệm vụ ở phút thứ 2 giây 31 cũng như
293
that we can also have a hash slot distribution
rằng chúng ta cũng có thể có phân bổ khe băm
294
so by deploying a redis cluster these time bucketed keys are deterministically hashed
vì vậy khi triển khai cụm Redis, các khóa được phân bổ theo khoảng thời gian này sẽ được băm một cách xác định.
295
and distributed across redis primary nodes and this horizontally scales both the memory footprint
và được phân bổ trên các nút chính của Redis, đồng thời việc mở rộng theo chiều ngang này giúp tối ưu cả về dung lượng bộ nhớ
296
and the olog n compute overhead ensuring this layer never blocks under massive concurrency
và chi phí tính toán của olog n đảm bảo lớp này không bao giờ bị chặn ngay cả khi có sự đồng thời lớn.
297
and so look we've gone deep on you know high precision scheduling worker fault tolerance execution guarantees
và vì vậy, chúng tôi đã đi sâu vào các vấn đề như lập kế hoạch độ chính xác cao, khả năng chịu lỗi của nhân công và các đảm bảo thực thi.
298
and scaling the storage layer so
và mở rộng quy mô lớp lưu trữ để
299
if you need know these things these are the core things interviewers are going to ask you
Nếu bạn cần biết những điều này, đây là những nội dung cốt lõi mà người phỏng vấn sẽ hỏi bạn.
300
so knowing them in depth will really bulletproof you
vì vậy việc hiểu rõ sâu sắc chúng sẽ thực sự giúp bạn trở nên vững vàng hơn rất nhiều.
301
when you go into your interview and
khi bạn bước vào buổi phỏng vấn và
302
so to finish up let's just walk through the complete architecture one last time
để kết thúc, chúng ta hãy cùng xem lại toàn bộ kiến trúc một lần cuối cùng nhé.
303
so you've kind of got that one mental snapshot of understanding how everything works together
vậy là bạn đã có được cái nhìn tổng quan trong đầu về cách mọi thứ hoạt động cùng nhau.
304
so a client will submit a payload to the API gateway
vì vậy một khách hàng sẽ gửi một gói dữ liệu đến cổng API
305
that will then get routed to the task management service which writes
sau đó sẽ được chuyển đến dịch vụ quản lý tác vụ, nơi sẽ ghi lại
306
that persistent configuration to Postgres the relay service every few minutes
cấu hình liên tục đó gửi yêu cầu đến Postgres từ dịch vụ chuyển tiếp mỗi vài phút
307
in a batch process will pull tasks scheduled for the near future from Postgres
trong một quy trình xử lý theo lô sẽ kéo các tác vụ được lên lịch trong thời gian sắp tới từ Postgres
308
and stage them to our Redis Z set keyed by their
và sắp xếp chúng vào tập hợp Z của Redis của chúng ta, được đánh khóa theo
309
precise execution epoch time high frequency scheduler nodes then continuously pull Redis
các nút bộ lập lịch tần số cao với thời gian thực thi chính xác theo epoch sẽ liên tục kéo dữ liệu từ Redis
310
and when a task's time arrives a Lua script atomically pops it from redis
và khi thời gian của một nhiệm vụ đến, một tập lệnh Lua sẽ tự động lấy nhiệm vụ đó ra khỏi Redis một cách nguyên tử.
311
and pushes it onto a partitioned kafka
và đẩy nó vào một Kafka được phân vùng
312
or rabbit mqq utilizing tenant -based routing to avoid noisy neighbors
hoặc Rabbit MQQ sử dụng định tuyến dựa trên tenant để tránh tình trạng “hàng xóm ồn ào”
313
a worker node claims a task triggering a visibility timeout the
một nút công nhân yêu cầu một tác vụ, điều này kích hoạt thời gian chờ hiển thị
314
worker then updates the database state to running using optimistic locking
sau đó, worker cập nhật trạng thái cơ sở dữ liệu thành đang chạy bằng cơ chế khóa lạc quan
315
to prevent concurrent execution races the worker then executes the arbitrary code
để ngăn chặn các tình trạng xung đột thực thi đồng thời, tiến trình công việc sau đó sẽ thực thi đoạn mã tùy ý.
316
or http webhook injecting an item potency key to protect downstream systems from network retries
hoặc webhook HTTP chèn khóa hiệu lực của mục để bảo vệ các hệ thống phía dưới khỏi các lần thử lại qua mạng
317
and the worker then sends an act to the queue to permanently delete the message updates the state
và sau đó worker gửi một hành động đến hàng đợi để xóa vĩnh viễn các bản cập nhật trạng thái của tin nhắn
318
and postgres to complete it
và Postgres để hoàn thành nó
319
and flushes the execution logs asynchronously into the cassandra wide column
và đồng bộ hóa các nhật ký thực thi một cách bất đồng bộ vào cột rộng của Cassandra
320
store for permanent auditing to check out the full write -up
lưu trữ cho mục đích kiểm toán vĩnh viễn để xem xét toàn bộ hồ sơ ghi chép
321
and the ai whiteboard head over to techprep .app
và bảng trắng AI, hãy truy cập techprep.app
322
and hopefully you got some value out of this
và hy vọng bạn đã nhận được một số giá trị từ điều này.
323
if you did please like and subscribe
nếu bạn thích nội dung này, hãy nhấn thích và đăng ký kênh nhé
324
and share with a friend it helps the channel out a lot and i will see you in the next one
và hãy chia sẻ cho một người bạn nhé, điều đó sẽ giúp kênh rất nhiều, và hẹn gặp lại các bạn trong những video tiếp theo.
Tải Ứng Dụng
Mọi thứ bạn cần để nói trôi chảy
Chấm điểm AIChấm từng câu nói
Luyện IPAThành thạo mọi âm
Từ vựngMở rộng vốn từ
Game Từ vựngHọc qua chơi
Cùng kênh
FOR YOU
Video gợi ý
C12
264 câu
System Design Mock Interview: Design WhatsApp
Business EnglishInterview EnglishUniversity Students
C17
198 câu
2025 DevOps, SRE, Cloud Engineer Interview Questions: Ace Your Interview with This Guide
Business EnglishInterview EnglishUniversity Students
C16
277 câu
Distributed Transactions Explained: 2 Phase Commit vs Saga Pattern
Business EnglishUniversity StudentsWorking Adults
C12
356 câu
Concurrency in Low-level Design Interviews w/ Staff Engineer
Business EnglishInterview EnglishUniversity Students
C11
309 câu
Claude Code: The Advanced Guide (99% of Devs Skip These Features)
Business EnglishUniversity StudentsWorking Adults
C1162 câu
Incident Management Process: A Step by Step guide
Business EnglishInterview EnglishUniversity Students
![[2026] TOEFL iBT Speaking Take an Interview | Step-by-Step Strategies #0008](https://img.youtube.com/vi/Bo4ARkCDQLk/mqdefault.jpg)
C12
160 câu
[2026] TOEFL iBT Speaking Take an Interview | Step-by-Step Strategies #0008
TOEFL PrepBusiness EnglishInterview English
C17
99 câu
How to Answer System Design Interview Questions (Complete Guide)
Business EnglishInterview EnglishUniversity Students
C12
119 câu
Introduction to RTOS Part 1 - What is a Real-Time Operating System (RTOS)? | Digi-Key Electronics
Business EnglishUniversity StudentsWorking Adults
C12
257 câu
A/B Testing in Data Science Interviews by a Google Data Scientist | DataInterview
Business EnglishInterview EnglishUniversity Students
C12
42 câu
System Design: How to Build an API Rate Limiter
Business EnglishUniversity StudentsWorking Adults
C12
239 câu
Excellent 2 Years AWS DevOps Engineer Mock Interview with Questions and Answers | Cloud | Docker
Business EnglishInterview EnglishUniversity Students
Từ vựng và ghi chú luyện nói cho bài học này
Bài luyện nói trình độ C1 này dựa trên video “Distributed Task Scheduler: System Design Interview”. Những từ được nhắc lại nhiều nhất trong bài: task, execution, worker, redis, database. Video này có 324 câu và 4079 từ để luyện shadowing. Phần lời nói dài 22:56. Người nói nói với tốc độ tự nhiên, khoảng 178 từ mỗi phút, gần với hội thoại hằng ngày. Chỉ 73% số từ nằm trong 3.000 từ tiếng Anh thông dụng nhất, nên từ vựng khá khó.
Từ vựng quan trọng trong video
15 từ khó nhất trong video, kèm phiên âm và nghĩa:
| Từ | Phiên âm | Nghĩa |
|---|---|---|
| node danh từ | /noʊd/ | gióng |
| queue danh từ | /kju/ | xếp nối đuôi |
| timestamp danh từ | /ˈtaɪmˌstæmp/ | dấu thời gian, mốc thời gian |
| endpoint danh từ | đầu mút, mút | |
| firstly trạng từ | /ˈfɜɹstli/ | trước hết, trước nhất |
| broker danh từ | /ˈbɹoʊkɚ/ | người môi giới |
| duplicate động từ | /ˈd(j)uː.plɪˌkeɪt/ | nhân bản, sao chép |
| hash danh từ | /ˈhæʃ/ | thịt băm, thịt bằm |
| millisecond danh từ | /ˈmɪlɪˌsɛkənd/ | một phần nghìn giây |
| invisible tính từ | /ɪnˈvɪzəb(ə)l/ | vô hình, tàng hình |
| epoch danh từ | /ˈɛp.ək/ | thời đại |
| metadata danh từ | /ˈmɛt.əˌdeɪ.tə/ | siêu dữ liệu |
| optimistic tính từ | /ˌɒptɪˈmɪstɪk/ | lạc quan |
| receipt danh từ | /ɹɪˈsiːt/ | biên nhận, biên lai |
| whiteboard danh từ | /ˈwaɪtbɔɹd/ | bảng trắng |
Cụm động từ bạn sẽ nghe
| Từ | Phiên âm | Nghĩa |
|---|---|---|
| pick up động từ | nhặt, lượm | |
| check out động từ | tính tiền, trả phòng | |
| wake up động từ | /ˌweɪk ˈʌp/ | thức dậy, dậy lên |
Ngữ pháp trong video
Những cấu trúc người nói dùng nhiều nhất, kèm đúng cụm từ trong video:
| Cấu trúc | Trong video |
|---|---|
| Câu bị động be + quá khứ phân từ — nhấn vào việc xảy ra, không phải người làm | is designed · are lost · is asked |
| Thì hiện tại hoàn thành have/has + quá khứ phân từ — việc đã xảy ra nhưng còn liên quan đến hiện tại | we've looked · we've mentioned · we've pulled |
| Mệnh đề quan hệ who / which + mệnh đề — thêm thông tin về người hoặc vật | offs, which is · RabbitMQ which will · caching which makes |
Phát âm cần chú ý
Người nói dùng 40 dạng rút gọn, ví dụ we'll, we're, we've. Hãy nói theo dạng ngắn đúng như bạn nghe.
- Âm “sh” và “zh”: scheduler /ˈʃɛdjələ/, precision /pɹɪˈsɪʒ.ən/, hash /ˈhæʃ/, partition /pɑɹˈtɪ.ʃən/, submission /səbˈmɪʃən/
- Từ dài — đặt trọng âm cho đúng: concurrency /kəŋˈkʌɹənsi/, millisecond /ˈmɪlɪˌsɛkənd/, invisible /ɪnˈvɪzəb(ə)l/, metadata /ˈmɛt.əˌdeɪ.tə/, visibility /ˌvɪz.əˈbɪl.ɪ.ti/
Những âm người Việt thường gặp khó:
- Cụm phụ âm cuối — đọc đủ từng âm, đừng nuốt âm cuối: timestamp /ˈtaɪmˌstæmp/, tenant /ˈtɛ.nənt/, tolerance /ˈtɑ.lə.ɹəns/, millisecond /ˈmɪlɪˌsɛkənd/, concurrent /kəŋˈkʌɹənt/
- Âm /tʃ/, /dʒ/ và /ʒ/ — tiếng Việt không có, đừng đọc thành “ch” hay “gi”: precision /pɹɪˈsɪʒ.ən/, inject /ɪnˈd͡ʒɛkt/, sequentially /səˈkwɛntʃəli/, batch /bæt͡ʃ/, architectural /ˌɑɹkɪˈtɛkt͡ʃəɹəl/
- Âm /æ/ — mở miệng rộng hơn âm “e”: timestamp /ˈtaɪmˌstæmp/, hash /ˈhæʃ/, extract /ˈɛkstɹækt/, batch /bæt͡ʃ/
Cách luyện với video này
- Nghe hết video một lần, chưa cần nói, và ghi lại những từ bạn chưa biết.
- Bắt đầu ở tốc độ 0,75×, nói đuổi từng câu, rồi quay lại tốc độ bình thường khi đã quen.
- Ghi âm giọng mình rồi so với bản gốc, chú ý các từ như node, queue, timestamp.
Phương Pháp Shadowing Là Gì?
Shadowing là kỹ thuật học ngôn ngữ có cơ sở khoa học, ban đầu được phát triển cho chương trình đào tạo phiên dịch viên chuyên nghiệp và được phổ biến rộng rãi bởi nhà đa ngôn ngữ học Dr. Alexander Arguelles. Nguyên lý cốt lõi đơn giản nhưng cực kỳ hiệu quả: bạn nghe tiếng Anh của người bản xứ và lặp lại to ngay lập tức — như một "cái bóng" (shadow) đuổi theo người nói với độ trễ chỉ 1–2 giây. Khác với luyện ngữ pháp hay học từ vựng bị động, Shadowing buộc não bộ và cơ miệng phải đồng thời xử lý và tái tạo ngôn ngữ thực tế. Các nghiên cứu khoa học xác nhận phương pháp này cải thiện đáng kể phát âm, ngữ điệu, nhịp điệu, nối âm, kỹ năng nghe và độ lưu loát khi nói — đặc biệt hiệu quả cho người luyện IELTS Speaking và muốn giao tiếp tiếng Anh tự nhiên như người bản ngữ.