Video học lập trình mỗi ngày

Rất may mắn khi chúng tôi đã làm việc với Message Queue (MQ) ngay từ những ngày đầu khi được tiếp quản dự án đóng vai trò là middleware. Lúc đó việc làm việc ở trong môi trường đó MQ là một vũ khí không thể tránh khỏi với vị trí backend, nói chung ai cũng phải bắt buộc có kỹ năng đó, vì vậy ai cũng phải học trong thời kỳ đó.

MQ: Đi đâu cũng nghe về nó

Ngay cả khi chúng tôi đi nhậu, hồi đó chỉ có mấy anh em thôi. Quanh đi quẩn lại cũng từng đó. Không trà sữa, không Phúc Long, không 2Lands, chỉ có ngồi vỉa hè bờ sông, dăm ba con cá đuối khô đập dập, vài ba chai bia tươi. Miệng ngậm thuốc SG, cứ thế và bàn luận về task hồi chiều.

Thật ra tôi không còn nhớ chi tiết nhiều, nhưng cảnh đó thật quen thuộc cứ mở miệng là do nó, do mày, ngộ hè, họ làm sao ta. Thằng T bước ra từ WC, miệng nó ngậm điếu thuốc, dương cái mỏ lên nói. Chỉ có dùng MQ thôi, mới đạt được 2 trong 3 vần đề mà chúng mày đưa ra.

Sau này nó đã đúng với khả năng lập trình bất đồng bộ, và khả năng tách rời hệ thống thì sau này [MQ đã trở thành nền tảng của kiến trúc hiện đại] () bạn có thể xem 3 lý do vì sao MQ lại thực sự nổi tiếng vì nó giải quyết được bài toán với 3 vấn đề đưa ra.

Sau này những ai mà sống sót qua thời kỳ đó , thì mọi chuyện dần sáng tỏ cũng như dễ dàng tiếp cận với MQ, đại diện tiêu biểu là Kafka, RabbitMQ, và RocketMQ chúng nó như anh em trong cùng dòng họ, nhưng thằng thì nhanh nhẹn, thằng thì thông minh, thằng thì bền bỉ. Mỗi thằng một vẻ, mười phân vẹn chín thôi.

Dự án A bạn nên chọn RabbitMQ, dự án B bạn nên chọn Kafka

Việc tích hợp MQ trong các dự, giờ là chuyện hiển nhiên như uống BIA vậy. NestJS, JAVA, Go.. đều có thể sử dụng để gia tăng hiệu suất bất đồng bộ. Có điều nói đúng ra thì để sử dụng tốt nhất lợi thế MQ thì JAVA được khuyên nên sử dụng.

Vì trong JAVA khái niệm JUC được đi kèm với lập trình đa luồng. Chính sức mạnh đó, thì có nhiều Sư tổ phát minh ra những Lib mà có thể giúp anh em lập trình nhanh gọn, chỉ cần có đạn và bắn sau khi tập luyện chúng.

Tôi cũng đã nói về những viên đạn Kafka trong Serires về JAVA DDD các bạn quan tâm thì có thể click vào tại đó.

Ngoài ra tôi không phủ nhận sự cố gắng của Nodejs, Go, Nestjs đưa vào MQ để có thể giúp hệ thống mượt mà hơn, nhưng để mà nói thì chưa xứng đáng với JAVA.

Chú ý tôi không cuồng JAVA, chỉ là cách nhìn công tâm.

MQ: Mất mịa thứ tự

Cứ tận hưởng MQ nếu có thể nhưng khi thực sự triển khai nó như bài toán mà tôi đưa ra Kafka (4): Tin nhắn tồn đọng quá nhiều, làm sao Sếp ơi, thì bạn thấy một vấn đề nan giải thường xuất hiện trong thực tế, và nó sẽ nằm trong câu hỏi interview senior 100%, đảm bảo là 100% sẽ có hỏi.

Đó chính là việc làm thế nào để đảm bảo thứ tự của các tin nhắn (msg)? Ngoài ra, nếu các Bro tò tò nói rằng còn câu nảo nữa không thì, 100% sẽ có hai câu nữa, đó là làm thế nào msg không bị mất? hay tính bất biến (imdempotent) của msg xử lý thế nào? 100% sẽ có nha Bro.

Đây cũng là một vấn đề mà chúng ta phải xem xét và giải quyết trong thực tế triển khai dự án, vửa rồi tôi cũng khẳng định việc đồng ý các anh chị đi phỏng vấn là nên: Thay vì hỏi về đã làm gì? Thì hãy hỏi về cái này đi bước đầu tiên ra sao lúc đó sẽ lòi ra AI có thể làm, và AI có thể đọc...

Nó về Ordered MQ thì rõ ràng là gì, là FIFO. Đến trước nhậu trước, thằng sau thì xếp hàng, không nói nhiều. Để nói về hiểu Kafka thì nó có nhiều khái niệm lắm,nhưng theo kinh nghiệm bản thân tôi thì trước tiên hãy thuộc lòng 7 khái niệm không bỏ qua khi tìm hiểu MQ theo tôi, bạn không thể không biết những khái niệm đó.

Khi gặp phải vấn đề về đảm bảo thứ tự thì phản ứng đầu tiên của nhiều Bro đó là gì? "À, có phải là AcquireLock()", Dễ thôi, đưa msg vào P...Nó đúng, chính xác, nhưng nếu như bạn đã xem bài triển khai này: Triển khai Kafka với 1 PARTITION xử lý nhanh gấp 3 (12 còn 2 seconds) NHƯNG thứ thự có đúng không? thì sẽ có câu trả lời chính xác đó là Nó đúng, nhưng trong thực tế họ sẽ hạn chế làm điều đó, khi đưa tất cả MSG vào một P.

Nếu bạn chỉ dừng lại ở cách làm đó, thì bạn sẽ khó có thể triển khai với một hệ thống với nhiều services và quan trọng là nếu ngồi ghế nóng thì câu trả lời bạn chưa thấu tâm canh của người phỏng vấn.

Giải pháp tưởng chừng đơn giản này lại ẩn chứa những cạm bẫy hiệu suất đáng kể, xem lại phát nữa Giải quyết được, nhưng hiệu suất không tăng trog MQ.

Vậy khi nếu như hệ thống muốn cải thiện hiệu suất hoặc giả sử như tôi là người phỏng vấn thì tôi sẽ hỏi thêm chút như cứa dao vào vết thương của các Bro vậy đó là "Những thiếu sót trong giải pháp này là gì?" hoặc "Làm thế nào để tối ưu hóa nó?" vậy anh chị trả lời sao... Chỉ có klinh qua rồi sẽ mới trả lời được..

MQ: Ordered MessageQueue

Được rồi, tôi sẽ triển nó để tôi còn nhớ về một thời xa xưa. Với những miếng mồi quen thuộc và ly bia chát đắng. Lúc đó các vấn đề tiềm ẩn và chiến lược tối ưu hóa đằng sau các giải pháp này là gì? Tôi sẽ giúp bạn hiểu rõ cách đảm bảo việc tiếp nhận tin nhắn tuần tự một cách tinh tế, giúp bạn thành thạo kỹ năng này khi triển khai Prod.

Rất nhiều Bro cho rằng, thứ tự đảm bảo ngay khi nó xuất phát (Producer) đúng hay sai? Có một chi tiết quan trọng cần làm rõ ở đây, đó là "ordered" không phải là từ method send()của Producer mà chính là Broker (B). CHính là nó mới là người phải đảm bảo thứ tự. Trước giờ, tôi hỏi anh em cứ rep sai toàn sai...

Ví dụ... trong cuộc chạy marathon. Thì khi Send() thì thứ tự rất lộn xộn, đông đúc, nhưng về đích thì phải có thứ tự đúng không? Hình dung ra chưa? Nếu chưa thì hãy nghĩ tôi là một BE triển khai hệ thống phân tán, thì sẽ gặp ngay quả này. Có hai Producer đó là P1vs P2 send() lần lượt là msg1, msg2 và msg1 được gửi đi lúc 08:00:00. Nhưng với msg1 thì tốc độ network gặp gió to nên bị delay, or GC trong JAVA hay Go đang dọn rác, thì việc đến Broker là điều bình thường, lúc này msg1 đến 08:00:005. Nhưng msg2 thì lại khác, mặc dù được gửi sau đó là 08:00:00:001 nhưng lại đến Broker sớm hơn là 08:00:002

Vì vậy theo góc nhìn của thằng Broker thì msg2 đến trước msg1có đúng không? Do đó, thứ tự mà tôi và anh chị đang nhầm lẫn là nó được quyết định bởi B, chứ không phải Producer. Vì vậy ở đây mấu chốt là thiếu một thứ...

Thứ gì... và thứ mấy anh em lại hẹn lên bia... Thứ mấy...