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

Cậu intern mới vào công ty có 3 tháng mà có thể thấy hình như cậu ấy đã chạm vào được trái tim của ứng dụng, của anh em và quan trọng có lẽ danh phận Junior chỉ để nhằm hạn chế lương của cậu ta thôi sao... Tôi tự nhủ..

Bài viết này được đưa vào Series: Hành trình của INTER đánh bại SENIOR thông qua dự án DDD - vetautet.com có lượng đồng thời CAO

Vì cốt truyện có tính logic nên nếu như bạn là một bạn mới ghé thăm vào Blog - Con đường của một backend thì trước tiên để hiểu nội dung thì mỗi bài viết tương ứng ở đây là một kỹ thuật được áp dùng trong dự án thì bạn hãy cố gắng xem những bài viết trước về dự án có lượng đồng thời CAO để có thêm thông tin về hành trình này.

Ngoài ra, nếu như bạn là một người đang tìm kiếm những giải pháp tăng tốc độ hiệu năng trong hệ thống cũng như tiết kiệm nhiều chi phí cho Doanh nghiệp thì có thể tham khảo và lấy code tại A-z: Triển khai DDD Project - vetautet.com hy vọng bạn sẽ có một cách nhìn và thêm một phần tham khảo cho hệ thống của bạn.

Chương 06: DDD - vetautet.com

...

Anh ơi - API đã vượt qua sự kỳ vọng là 25.000 req/s

Sáng hôm sau khi tôi bước vào phòng làm việc, đó là một căn phòng nhỏ vừa đủ 8 người như thường lệ và "Hello Anh em..". Sau đó tôi liếc mắt đưa vào ghế của bạn INTERN thì không thấy bóng dáng cậu ấy, tôi dám cá rằng cậu ta không phải đi vệ sinh vì nhìn qua thì tôi đoán bạn ấy chưa đến.

Chắc là hôm qua chúng tôi bàn về câu chuyện Sự lựa chọn giữa GUAVA và CAFFEINE cho việc tối ưu trước lớp Redis nên ku Cậu có vẻ mệt... Tôi nghĩ vậy và bước chân chậm rãi về chỗ ngồi quen thuộc của mình..

Một tiếng sau. "Em chào các Anh ạ". Tiếng của INTERN vang lên. Ồ nó đây rồi. Tôi tự nhủ trong lòng. Không biết từ khi nào mà tự nhiên chúng tôi lại mong chờ nó hơn bao giờ hết kể từ khi nhận cái project vetautet.com này nữa. Chả nhẽ phụ thuộc vào cậu ta hay sao? Không có đâu, bạn ấy chỉ là một INTERN thôi... Có lẽ chúng tôi sợ mất cậu ta..

Anh Tips, em có chuyện muốn trình bày... Như anh thấy đêm qua chúng ta đã họp và có phương án, em không thể ngủ được vì những kiến trúc đó cứ xuất hiện khi em chợp mắt, khi nhắm mắt chúng nhảy múa và cười nhạo em, cho nên em đã triển khai nó ngay trong đêm và kết quả hơn những gì chúng ta mong đợi anh ạ.

Còn đây là video thực tế: Đây là cách backend nên trang bị cho việc triển khai API hiệu năng

Nó thế này... Chờ em, em sẽ cho anh xem... Một chiếc test về hiệu năng được run và chúng tôi không tin vào mắt mình nữa...

Đầu tiên nó lên 10.000 req/s, sau đó lên 15.000 req/s... Tiếp là 20.000 và cuối cùng là hơn 25.000 req/s.

Xem xong test file thì chúng tôi cảm giác có một luồng sinh khí chảy vào trong mỗi cá nhân trong dự án này. Tôi hỏi: "vậy Chí phí là bao nhiêu?" Intern đáp: "Không, không một đồng chi phí tăng lên anh ạ". Uow, quả là điều kỳ diệu.

Anh ơi - Review code xem được không?

Chúng tôi mở code project lên và xem: Ồ hoá ra là cậu ấy không sử dụng caffeine như chúng tôi đã bàn và sử dụng ngay guava của google đó là một thư viện truyền thống được nhiều dự án sử dụng và có hiệu quả rất tốt về mặt chi phí cũng như hiệu năng có việc tạo dữ liệu ở local cache, điều đó đồng nghĩa với việc giảm tải rất nhiều cho bên tầng distributed cache...

Và đây là cú pháp sử dụng của guava:

// use guava
private final static Cache<Long, TicketDetail> ticketDetailLocalCache = CacheBuilder.newBuilder()
        .initialCapacity(10)
        .concurrencyLevel(12)
        .expireAfterWrite(100, TimeUnit.MINUTES)
        .build();

Sau đó chúng tôi thấy cậu intern đặt một bức tường sử dụng local cache này nằm trước distributed cache như sau..

Còn đây là video thực tế: Đây là cách backend nên trang bị cho việc triển khai API hiệu năng

Có thể thấy rằng, nếu như bạn chỉ nhìn vào và nói "nó rất đơn giản" đúng là như vậy, nhưng thực sự nếu bạn chưa kinh qua và chưa đủ exp để triển khai điều này thì e rằng, khó có thể học được những điều nhỏ nhưng làm chúng ta đến xiêu lòng như vậy, đúng không?

Ồ.. David lên tiếng. Hình như code này có vấn đề về code xấu, nó vi phạm nhiều nguyên tắc mà một lập trình viên lâu năm không cho phép, nhưng cậu ta chỉ mới một năm mà thôi. Tôi đáp..

David: Đúng vậy tôi hiểu với level này chúng ta không đòi hỏi cao được, code có tính logic nhưng khả năng mở rộng sẽ khó vì sau này hệ thống làm ăn tốt sẽ lên tới 100k req/s thì chúng ta không những sử dụng guava và còn nhiều thứ khác nữa thì sao? Ok, hãy để tôi review lại code và hướng dẫn cho em ấy refactor lại code theo võ công mà thôi học bấy lâu nay.

Muốn đi xa hãy có nội lực.

"Vào chỗ ngồi đi, intern..", David nói...

Đầu tiền em thấy code của em giống như code này:

Class A{
    public void featProcessActionUser(){
        OrderItem = featOrder()
        if(OrderItem){
            ProductItem = featProduct()
        }
        ...
        save()

        cache()
        ...
        featPoints()
        ...
    }
}

Em thấy ở đây em đã vi phạm một nguyên tắc thứ 13 trong bad code đó là một func chứa nhiều trách nhiệm, nó vi phạm chữ S - SOLID mà anh tips đã từng Review cho chúng ta..

Vì vậy hãy refactor lại từ từ như sau.

...

Tôi quan sát và thấy bạn INTERN đang chăm chú.. Gương mặt cậu ấy toát lên vẻ cầu tiến và đam mê học hỏi một cách nghiêm túc. Không lời phàn nàn...

Bồng INTERN thốt lên.. Oà anh ơi.. Điều đó thật tuyệt vời, ở trường em chưa học cái này bao giờ...

Vậy điều đó là gì? Và cách refactor code như thế nào mới là đúng và có bao nhiêu khái nhiệm vi phạm code. Chúng ta cùng nhau xem chương sau..

Một ngày quá đẹp khi đạt được mục tiêu là 25.000 req/s.