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

Tóm tắt phần trước

Như vậy thì ở video trước chúng ta đã lập nên tuyền phòng thủ đầu tiên sử dụng công cụ Resilience4j được Netflix khuyên các hệ thống nên thay thế cho Hystrix. Vì Hystrix đang được maintenance. Tất nhiên các dự án cũ đang còn sử dụng Hystrix thì vẫn có thể sử dụng chúng nhằm giảm lỗi trong hệ thống. Nhưng nếu chúng ta đang phát triển một hệ thống hay dự án mới thì nhất định phải thay thế bằng công nghệ mới đó là Resilience4j được giới thiệu trong phiên bản Spring Cloud GreenWitch.

Thời gian là vô cùng quý giá: Giả sử Shopee sẽ thanh toán qua momo, nhưng một thời điểm Momo failed thì Shopee sẽ hành động như thế nào? Xem - Circuit Breaker vs RateLimiter - Tuyến phòng thủ đầu tiên cho DDD (bán vé trực tuyến)

Ở đó có các tính năng rất quan trọng để bảo vệ hệ thống DDD - bán vé tàu TẾT của chúng ta đang phát triển như sau:

Core Modules - Resilience4j

1. CircuitBreaker
2. Bulkhead
3. RateLimiter
4. Retry
5. TimeLimiter
6. Cache

Với hai module mà rất quan trọng đó là RateLimiter và CircuitBreaker mà chúng ta đã triển khai và thực hành code ở Section 04: DDD - Tuyến phòng thủ đầu tiên. Còn bây giờ, chúng ta chưa dừng lại tại đó, vì ai cũng biết rằng đó chỉ là một tuyền phòng thủ cấp cơ bản.

Thực tế để triển khai một kiến trúc có request đồng thời cao lên đến 100K req/second thì từng đo thì không đủ cho hệ thống mở bán vé tàu ngày đầu tiên. Do đó, chúng ta sẽ đi tiếp video này nói về một thiết kế tiếp theo đó là tuyến phòng thủ thứ hai của hệ thống.

Trước tiên tôi đưa ra architecture để biết chúng ta đang ở đâu.

Nhìn vào chúng ta đã biết rất rõ là chúng ta đang ở đâu trên chặng đường dài.

Video 05 - Tuyến phòng thủ thứ 2 - Distributed Cache Redis

Tiếp theo một kịch bản rất quen thuộc khi ngày đầu tiên mở bán vé mà tôi đã giới thiệu kịch bản này cho các bạn ở video public đó là: DDD - Bán vé tàu TẾT: Ngày đầu tiên mở bán vé, hệ thống SẬP thảm hại lý do sập hệ thống ở đây chính là nguyên nhân tập trung là con người(lập trình viên), họ không lường trước được những kịch bản đồng thời cao đưa ra. Bạn có thể xem lại video public đó để hiểu hơn, vì trong đó chúng tôi đã đưa ra 3 cách xử lý của 3 chàng trai lập trình backend của công ty chúng tôi.

Kịch bản ngày đầu tiên: Vào ngày 11/11 có 1000 vé được tung ra với giá khuyễn mãi là 10.000 VNĐ, trong khi giá gốc sẽ có 100.000 VNĐ. Và giá 10.000 VNĐ sẽ áp dụng cho đến khi lượng tồn kho còn lại trong event này stock = 0.

Khi mở bán thì tôi cho phép test với hệ thống là trong 1s sẽ có 1K req/second truy cập vào để lấy thông tin vé đó ròi mới tiến hành đặt vé. Và đây là 3 cách tương ứng với 3 kỹ sư lập trình backend của chúng tôi.

Lập trình viên backend mới ra trường LEVEL 0, 1

Hình ảnh đầu tiên được đưa ra, dễ hiểu vì sao api chúng tôi lại sập khi mở bán vé ngay ngày đầu tiên.

Nhìn vào hình ảnh chúng ta thấy, anh chàng này quá bất cẩn khi để mysql ra chống chọi với các đợt lấy dữ liệu từ các User bắc, trung và nam. Tất nhiên MYSQL không thể chịu đựng được tần suất query vô cùng lớn như vậy và hậu quả sẽ khiến CPU lên cao và sập nguồn. Hệ thống từ đó lăn ra chết. Đây là code được trích ra từ video public

    public String getTicketItemNoCache(Long id) {
        // Get Ticket Detail via DBS
        String ticketItem = ticketRepository.findById(id);
        log.info("QUERY FROM DBS -> {}, {}", id, ticketItem);
        return ticketItem;
    }

Hãy xem kết quả..

MySQL đã quá tải khi phải hứng chịu 1000 connections trong khoảng thời gian ngắn. Điều này không thể được. Tiếp theo chúng ta hãy xem lập trình viên thứ 2 sẽ khắc phục ra sao..

Lập trình viên backend có kinh nghiệm nhưng chưa triển khai dự án đồng thời cao

Anh chàng này tuy có 2-3 năm kinh nghiệm làm việc ở các dự án, nhưng chưa có cơ hội tiếp xúc với dự án được xây dựng với DDD - Vé bán tàu TẾT mà chúng ta vừa hoàn thành ở video thứ 3.

Vì tôi đã trình bày rất kỹ ở bài DDD - Bán vé tàu TẾT: Ngày đầu tiên mở bán vé, hệ thống SẬP thảm hại cho nên tôi sẽ không giải thích kỹ về cách làm của anh chàng này.

Đơn giản là anh ấy sẽ sử dụng cache redis để làm bức tường bảo về mysql, nhưng anh ta vẫn bị sai lầm khi lượng đồng thời cao ập tới, lớp phòng thủ cache cũng có thể mắc sai lầm và dấn tới có 1000 req/s vẫn lọt vào mysql đến gần 200 connects.

Và đây là hình ảnh output:

Như vậy nếu chỉ sử dụng redis ở mức đơn thuần và cơ bản thì trong trường hợp lượng đồng thời cao như vậy cũng sẽ không đảm bảo được hệ thông sẽ chạy trơn tru. Vậy có cách nào triển khai lớp phòng thủ tốt hay không thì chúng ta cũng đi qua cách thứ 3 của một lập trình viên cao cấp.

Lập trình viên backend java kinh nghiệm như thế nào?

Chúng ta hãy xem anh chàng backend java có kinh nghiệm như thế nào vượt qua khó khắn này. Chờ chút...