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

Viết tiếp câu chuyện của CỰU CHIẾN BINH ĐI QUA GIÔNG BÃO CÔNG NGHỆ ...

Bạn có nhớ ở bài viết trước tôi có nói rằng: Vậy tôi nói 80% dự án đều giống nhau về việc sử dụng công nghệ, vậy đó là công nghệ gì? Nếu bạn có thể tiếp xúc sớm với các công nghệ này thì bạn có thực sự hơn 80% những người xung quanh hay không?

Tôi phân tích công nghệ đầu tiên mà tôi chạm phải nhiều nhất ở các dự án đó là Message Queue trong đó họ sử dụng Kafka và RabbitMQ. Vậy là đã làm gì với chúng để có một kết quả mượt mà..

Khuyến nghị: 20% công nghệ được sử dụng trong 80% dự án

Để hình dung trực quan thì tôi sẽ quay về thời gian từ đầu tiếp xúc với công nghệ này, và khi đã thực sự làm chủ được công nghệ này thì đến lúc tôi sẽ chia sẻ cho các bạn 10 câu hỏi chắc chắn hỏi trong vị trí BE, SA, FS về Message Queue - Kafka, RabbitMQ

Kafka cuộc họp đầu tiên!

Hôm đó tôi là ngày đầu tiên đi làm ở một môi trường mới, nó cách xa đến 1000 km với chỗ làm cũ của tôi (Tôi rời nông thôn tới thành phố). Sau khi được giới thiệu về công ty thì HR nói với tôi rằng: Đây là chỗ làm việc của bạn.... Lúc này tôi chợt nhận ra rằng, sắp tới là một chông gai mới.

Tầm 20 phút tôi đã setup bàn làm việc của mình rất ngay ngắn, nó ngay ngắn bởi vì thật ra chả có gì cả ngoài LAPTOP Q Compact của tôi và một máy PC của công ty. Lúc này, một ĐẠI CA xuất hiện và hỏi mấy câu xã giao rồi kết thúc câu chuyện là "10 phút nữa chúng ta có cuộc họp". Người đó sau này là bạn thân tôi, anh ấy đã mở showroom về xe đạp điện.

...

Bước vào phòng họp, nói phòng họp chứ thực chất là chỗ nhà kho được sắp xếp chính giữa là cái bàn họp và mấy chiếc ghế. Xung quanh là toàn ghế, máy tính bị hư hỏng, vứt chồng lên nhau. Bụi bay lả tả... Câu chuyện bắt đầu...

Kafka đã làm gì với hệ thống vậy?

Vừa rồi có một dịch vụ xx vừa gõ cửa chúng ra để xin liên kết lấy thông tin từ hệ thống chấm công của chúng ta.... Tan họp, tôi mở dự án chấm công lên xem và ngắm nghía, nó viết bằng java, về cơ sở dữ liệu thì có redis và mysql. Lúc này chỉ biết TẠM vậy đã.

Buổi trưa sau khi ăn cơm xong thì tôi thấy nhiều ĐẠI CA bắt đầu chơi game, một số thì đọc sách, một số thì trải chiếu/khăn ra nằm. Do tôi chưa có dịp làm quen với với văn hoá, nên chưa dám làm gì chỉ ngồi xem code trong dự án và suy nghĩ về Nội dung cuộc họp.

Lúc đầu hệ thống triển khai chấm công trên 10.000 công nhân. Hiện tại API đã cung cấp cho nhiều dịch vụ khác đến lấy dữ liệu của trung tâm. Tôi có thể tóm tắt như sau và hy vọng bạn sẽ hiểu được bản chất của Kafka.

Chúng tôi có hệ thống A chứa nhiều dữ liệu, ví dụ là userId của công nhân làm việc tốt nhất(Làm việc tăng ca liên tiếp). Sau đó, bây giờ cả hệ thống B và hệ thống C đều cần dữ liệu (userId) để thực hiện các hoạt động liên quan như thống kê, lương...

Nhưng sau vài tháng thì không còn như vậy nữa, hệ thống B gặp trục trặc cho nên không đăng ký dịch vụ lấy thông tin nữa, chỉ còn C mà thôi. Và bắt đầu anh em chúng tôi sẽ viết lại tắt liên kết với B.

Tương tự, sau vài ngày thì có một service khác D lại muốn đăng ký lấy thông tin giống như B đã từng làm. Chúng tôi lại tiếp tục hiệu chỉnh code khi nào xong thì thông báo rằng, D có thể vào được rồi.

Cứ như thế, E, F, H, I, J kẻ đến, người đi. Chúng tôi như muốn phát điên, một số lập trình viên cảm thấy khá nhàm chán nên kết thúc ở môi trường này.

Từ đó TEAM mới quyết định cho phép sử dụng MQ tham gia vào tiến trình này. Hệ thống A tạo ra những dữ liệu và đẩy chúng vào Message queue và hệ thống C và D lấy dữ liệu từ hàng đợi tin nhắn. Lợi ích của việc này là gì ?

Có nghĩa là hệ thống A chỉ chịu trách nhiệm ghi dữ liệu vào hàng đợi và không quan tâm đến việc ai muốn hay không. Muốn thì ký vào HĐ rồi sẽ auto nhận thông qua việc đăng ký lắng nghe. Ngược lại nếu không muốn liên kết thì chỉ cấn unsubs là đủ, chúng tôi không cần sửa or thay đổi bất kỳ điều gì trong code.

Theo cách này, hệ thống A được tách khỏi hệ thống B, C, D. Như vậy cách triển khai này cho chúng ta hiểu các "Tách rời" các service một cách rõ ràng như thế nào trong kiến trúc phần mềm đúng không?

Và đây chính là điểm khởi đầu của tôi khi làm việc với kafka, và kế từ đó yêu thầm nhớ trộm. Nhưng chưa dừng lại tại đây. Sau khi áp dụng Kafka thì TEAM đã sử dụng nó ở nhiều cách khác nhau giúp hiệu suất tăng vọt.

Hãy để tôi kể lần thứ hai gặp lại MQ trong một dự án khác nhưng lần này là sử dụng RabbitMQ. Tất nhiên công cụ để xử lý vấn đề mà thôi. Và lần này thật sự cũng là một điều tuyệt vời không kém.

Đó chính là các "tác vụ không đồng bộ" có thể cải thiện được hiệu suất của hệ thống. Cụ thể như sau. Lấy ví dụ thì tôi đã cắt hình ảnh từ một bài thực hành trên internet rất là tuyệt vời như sau, nếu bạn xem hình ảnh không hiểu thì không sao? Tôi sẽ trình bày thêm một chút về hiểu biết của tôi.

Ví dụ hệ thống A làm nhiệm vụ thống kê chấm công của một userId mất 300ms, sau đó nếu không sử dụng MQ thì mỗi dịch vụ liên kết B, C, D ví dụ lần lượt sẽ là 200ms, 250ms, 300ms. Như vậy mỗi userId được liên kết thì sẽ mất

timeResponse = A + B + C + D = 300 + 200 + 250 + 300 ~ 1 second

Nhưng nếu sử dụng MQ theo hướng dẫn của bài thực hành Kafka đã thay đổi hệ thống eCommerce trở nên mạnh mẽ như thế nào so với cách cũ thì chúng ta chỉ mất 300ms hiệu suất rất tốt đúng không?

Chưa dừng lại tại đó MQ còn giúp hệ thống có thể đảm bảo được lưu lượng cần thiết khi có lượng truy cập đồng thời cao như trường hợp trong dự án Go Senior - bán vé thì lúc mở bán có đến 100.000 users F5 liên tục để mua vé.

Nhưng hệ thống Be của chúng ta chỉ có thể xử lý tối đã 40.000 req/s mà thôi, chính vì vậy khi sử dụng MQ thì 100.000 req đó sẽ vào MQ và sẽ được phân phối qua hệ thống chúng ta từ từ, và lúc này hệ thống an toàn.

Đó là cơ chế của MQ. Nhưng các bạn có biết nếu như vậy thì có thể or có cách nào đạt được hiệu suất tốt kèm theo sử dụng MQ hay không? Đầu tiên tôi sẽ thiết kế thêm về KafKa(05): Hàng triệu Thread/Goroutine TĂNG hiệu suất NHƯNG lại đảm bảo thứ tự trong Kafka, quá khó

Tiếp tục...