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

Bài viết đưa vào Series: Con đường của một kỹ sư Backend

Để bạn nắm rõ bản chất, chúng ta sẽ "mổ xẻ" thật chi tiết một vấn đề trong lập trình hiện này và từ đó cũng chứng mình một điều Database Engine (MySQL/InnoDB) vì sao 20 năm nay nó vẫn thực sự là hữu ích trong việc nhất quán dữ liệu, và không cần chúng ta phát minh lại khi QPS diễn ra bình thường...

Race Condition API

Khái niệm race condition không còn xa lại với lập trình viên đặc biệt là làm ở vị trí Backend. Đây là một hiện tượng xảy ra khá phổ biến khi lập trình ứng dụng với nhiều luồng truy cập và sửa đổi dữ liệu tại một thời điểm. Có thể nói là rất gay gắt.

Bạn còn nhớ tựa game Võ Lâm Truyền Kỳ​ or Kiếm Thế​ (một thời banh chành, bỏ học thức đêm đi từ biện kinh lên Lâm Du Quan... Mía đi bộ thấy bà nội) khi săn boss thì boss có hệ số máu là X. Nhưng lúc này sẽ có nhiều threads (users) thuộc nhiêu băng nhóm khác nhau vào tổng tấn công boss lúc này. X là sẽ một giá trị và sẽ trừ đi bởi nhiều luồng cho đến khi X = 0 thì end game. Lúc này, trường hợp đúng là X sẽ giá trị không âm. Nếu Sai thì sẽ là âm...

Đó là game. Còn trong phần mềm ecomerce hay stock thì khái niệm "quá bán hàng tồn kho" chính là từ khoá này. Nghĩa là không thể bán âm hàng tồn kho. Ví dụ ngày mai chúng ta sẽ bán X sản phẩm có giá 1/2 giá bán bình thường. Nhằm câu khách hàng vào Shop của chúng ta. Vì vậy điều kiện x = 0 thì lúc này sẽ ngưng bán hàng...

Kịch bản đã rõ. Nhìn vào task này với một dev cấp thấp thì sẽ đi tìm ngay cách làm. Cặm cụi với một con AI, hỏi và trả lời. Fix đi fix lại. Nó tệ thật... Nếu bạn đang trong hoàn cảnh này thì không nên làm vậy sau khi đọc bài viết này và xem video thực hành Dev Senior họ giải thích và xử lý tình huống đồng thời cao như thế nào? Race Condition | Mysql ACID... Thật tệ phải không?

‍

Senior backend thật sự là họ thế nào?

Tôi sẽ không mô tả cách làm việc của một lập trình viên cấp thấp vì nó chả giúp được gì cho đến hiện tại (trong CV lúc nào cũng có những khẩu đại bác như kafka, rabbitmq nhưng chưa bao giờ được bắn), với một senior thì việc đầu tiên bạn phải xác định được hệ thống của mình sẽ chịu tải được bao nhiêu QPS.

Nghĩa là bao nhiêu req/s system api của chúng ta chịu đựng được. Từ đó sẽ có những chiến lược phù hợp bao gồm việc triển khai cũng như tích hợp các vũ khí để bảo vệ hệ thống.

Nếu bạn chưa biết cách tính QPS trong hệ thống của mình thì tôi đã có một bài viết nói về: Cách tính QPS của hệ thống với một Solution Architect. Sau khi tính xong, cố gắng áp dụng công thức 7 và 3 cho phù hợp.

‍

Sau đó hãy tiến hành sử dụng tools​ để đo lường hệ thống theo realtime. Nghĩa là bạn phải force thành thạo những kỹ thuật build sử dụng như grafana, promethues​ đế check CPU, memory, Througput... Hãy xem thêm các bài viết về Sử dụng vũ khí prometheus grafana như một chuyên gia lúc này chúng ta có thể xác định được số lượng hệ thống chịu tải...

Xem thêm:

Backend java - Sử dụng prometheus grafana như một chuyên gia

Backend Go - Sử dụng prometheus grafana như một chuyên gia

OK, xem như xác định xong, chúng ta sẽ có 3 trường hợp sau đây.

1 - Khoảng 500 - 1000 req/s

2 - Khoảng 1000 - 10.000 req/s

3 - Over 10.000 req/s ...

‍

Đã rõ. Chúng ta sẽ bắt tay vào việc. Đầu tiên với case 01 thì lúc này nhẹ nhõm hơn vì MYSQL có thể làm điều đó, mà không cần tốn chi phí thêm cho việc áp dụng thằng nào nữa...

Tôi đã làm rất tốt ở bài viết này. Lúc này bạn hãy xem về Dev Senior họ giải thích và xử lý tình huống đồng thời cao như thế nào? Race Condition | Mysql ACID.. Hãy xem kỹ về nó.. Ngoài ra tôi sẽ nói về giao dịch phân tán, điểm này sẽ giúp bạn hơn 80% những bạn xung quanh..

‍

Còn tiếp... Nó rất đáng xem chi các lập trình viên xem trọng kiến thức thuần tuý...