Với GraphQL. Tôi cảm thấy đã đủ mệt mỏi với những làn danh giới giữa FE và BE. Việc tự build linh kiện máy tính, bắt buộc bạn phải là người chuyên nghiệp về khía cạnh đó. Hãy trở thành người chơi GAME xuất sắc, thay vì trở thành người mua máy tính chuyên nghiệp, nếu làm tốt bạn là con người tuyệt vời.
Hôm nay tôi và các đại ca bàn luận về `high concurrency` và nhân tiện trong bài viết này tôi cũng nói thêm về một số trường hợp xử lý khi bạn bị mặc kẹt trong vấn đề này, thông qua một số biện pháp của một số anh em backend
Tôi có hai table mỗi table có 13 triệu records. Và vẫn là câu lệnh SELECT COUNT(*) nhưng một table mất 4.2s và một table mất 0.002s... Vì sao? Chúng ta sẽ đi tìm hiểu
Đây là một kịch bản có thật được thực hiện lại với một table `(products)` trong MySQL có 13 triệu dữ liệu. Và có 3 tính huống tìm kiếm. Và mỗi tình huống có 3 cách, trong đó có 2 cách sử dụng toán tử `LIKE = '%keySearch%'` và `LIKE = 'keySearch%'`. Như sau:
Tôi biết tôi đang ở đâu và hơn 15 năm kinh nghiệm trong lĩnh vực lập trình dường như không mang lại lợi thế gì khi bạn chấp nhận trong ngành nghề này.
Đầu tiên, đừng vội vồ vập, vì chúng ta là những người đã kinh qua không gì phải vội. Hãy nhấn mạnh với họ rằng, công ty bạn đang trừ hàng tồn kho ở giai đoạn nào?
Nhưng nói thêm rằng, nếu từ FE muốn chuyển qua `Back-End(BE)` thì Nest.js không đủ để làm chuyện đó. Vì sao? Tôi có thể kết luận như thế này..
Nếu bạn xuất thấn từ JAVA`, GO và Nestjs thì có lẽ cụm từ `IoC` sẽ xuất hiện tấn suất rất nhiều trong dự án và trong các lần phỏng vấn đúng không?
Nếu một lập trình viên backend hiểu về hệ thông bán hàng đồng thời CAO hoặc kiến trúc đồng thời cao, bạn có thể thấy rằng khấu trừ hàng tồn kho trong Database này không hoàn hảo và nó có vấn đề ở đây.
Vì vậy hãy suy nghĩ nếu như Master bị hẻo thì ai sẽ là người ghi `Slave-01` hay `Slave-02` hoặc `Slave-0N`... Là ai? Công thức nào? Và setup thế nào?
Câu hỏi 2: "Thật sự em chưa có kinh nghiệm làm trong dự án nào có nhiều request đồng thời, vậy có phỏng vấn vào công ty XXXX được không Anh?"... Tôi không có kinh nghiệm về dự án lượng đồng thời cao..
Vì sao tôi vẫn là một nông dân CODE. Với tôi, tôi sẽ cố gắng không phụ thuộc vào AI trừ khi tôi không còn suy nghĩ được vấn đề gì nữa...
Thật sự mà nói thời điểm đó khi tôi bắt đầu học về kafka thì lúc đó trên internet có khác ít những blog hay video để triển khai những khái niệm rất mơ hồ như `HW, LEO, LSO, LW` hoặc `ISR và AR là viết tắt của từ gì trong Kafka? Tỷ lệ ISR có nghĩa là gì?` rất khó tìm được đáp án.
Chúng ta đều đồng ý rằng, trong MySQL dữ liệu càng nhiều thì query càng chậm. Thực tế như sau, khi sử dụng `limit X,Y` để truy vấn, giá trị `X` càng lớn thì tốc độ truy vấn càng chậm.
Tôi còn nhớ JavaEE lúc đó rất phổ biến vì các logic business được quản lý mới Struct, Spring, và không quên đó là Hibernate chịu trách nhiệm quản lý database, nhìn lại một hành trình giờ đây quá nhiều thay đổi với sự xuất hiện của SpringMVC nó đã làm lu mờ đi Struct...
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ủ..
Chắc chắn chúng ta sẽ phải thêm một tuyến phòng thủ tiếp theo để bảo về Redis, tôi nói. Vậy cái gì có performance tốt hơn Redis cache nữa... Bỗng thằng em INTERN cất tiếng nói, Anh em thấy thế này, giọng nó khá trong trẻo..
Đương nhiên có rất nhiều framework opensource hỗ trợ local cache chẳng hạn như `Ehcache`, `Guava cache`, `Caffeine Cache` đương nhiên còn nhiều nữa... Nhưng thật sự bạn hay team bạn đã sử dụng chúng hết chưa, và các bạn phải chọn lựa thì dựa trên tiêu chí nào?
Cách đảm bảo dữ liệu không bị trùng lặp trong các tình huống đồng thời cao. Trước tiên hãy xem câu hỏi và sau đó mỗi chúng ta tự hỏi: "Minhd đã từng gặp phải những tình huống này chưa? Hoặc có thể tương lai sẽ gặp thì mình sẽ thực hiện như thế nào?"
Sau cuộc phỏng vấn đó, tôi dành một chút thời gian để suy nghĩ lại về những gì anh ấy nói. Công nhận về MYSQL việc viết câu lệnh rất đơn giản chỉ xoay quanh bốn cụm từ `SELECT`, `UPDATE`, `DELETE`, `INSERT INTO` tôi tin rằng đây là điều mà mọi lập trình viên có chút kinh nghiệm đều có thể hiểu và làm được. Nhưng hôm nay sao nó lại quá lạ lùng như vậy…
Lúc này hệ thống đã lên tới `6000 request/second`, điều đó có nghĩa là hệ thống bán vé tàu của chúng tôi phát huy sức mạnh với nhiều người quan tâm. Ngáp một hơi lấy tinh thân đi ngủ thôi... Cuộc đời lập trình viên đẹp đến thế là cùng... NHƯNG
Ở phần trước chúng ta đã đến cập đến tuyền phòng thủ đầu tiên trong hệ thống [DDD bán vé tàu TẾT - Đồng thời cao], ở đó có một khái niệm cân được quan tâm đó là `circuitBreaker` và `RateLimiter`. Cốt lõi là `circuitBreaker` nó sẽ phát huy tác dụng trong trường hợp đó chính là quấy bán vé quá tải thì phải lập tức chuyển qua trạng thái OPEN.
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.
Trong dự án bán vé tàu Tết với Spring Boot, chúng tôi sẽ chia ứng dụng thành 5 module chính: start, application, controller, infrastructure, và domain. Hãy quan sát và suy nghĩ..
Trên thực tế, việc xây dựng bán vé TÀU TẾT về cơ bản là một ứng dụng toàn diện của công nghệ có tính đồng thời cao trong các tình huống cụ thể. Ví dụ như mới tổ chức bán vé vào dịp tết, chuẩn bị bán vé liveshow MỸ TÂM, hoặc bán Iphone 17... Các kịch bản có tính đồng thời cao và khả năng thiết kế kiến trúc có tính tương tranh cao là khả năng then chốt không thể thiếu đối với các nhà phát triển. ..
INTERVIEW BACKEND vị trí Fresher BE như sau: Làm thế nào bảo vệ hệ thống cụ thể là nhiệm vụ API FORGOT PASSWORD khi có nhiều request trong một thời gian ngắn hạn.
Nam là một chiến binh PHP dũng mãnh, có thể xử lý bất kỳ thách thức nào với chiếc "gươm" cú pháp của mình. Nhưng rồi một ngày, Nam nhận ra mình bị lạc vào một khu rừng mã code, nơi có những thứ mà PHP không thể cứu vãn được.
Redis String là một trong những cấu trúc dữ liệu cơ bản nhất trong Redis, nó có thể lưu trữ bất kỳ loại dữ liệu nào, bao gồm number, text, object được tuần tự hóa, v.v. String trong Redis có thể lưu trữ tới 512MB dữ liệu.
Tại sao chúng ta cần Elasticsearch (ES) khi chúng ta có MySQL? Nếu cần thì việc đồng bộ giữa MySQL và ES như thế nào? Tôi hỏi đây là cách tốt nhất hay không?
Pagination là một trong những thủ thuật để tối ưu hóa dữ liệu hàng đầu hiện nay. Facebook, reddit đã làm chúng ta mê mẩn đắm chìm trong thế giới của họ, mỗi lần lướt là một quá trình phân trang được thiết kế hoàn hảo. Trong bài này chúng ta sẽ tìm hiểu những thủ thuật đó trong Mongodb.
Một trong những người mới học về database, bất kể mongodb, mysql hay oracle thì việc xây dựng những lược đồ (schema) là một điều quan trọng. Nếu ngay từ đầu bạn làm tốt thì sau này mọi chuyển trở nên đơn giản cho những người đến sau hoặc hệ thống được nâng cấp.
Lượng dữ liệu mới được thêm vào trong một bảng duy nhất đạt 250.000 mỗi ngày! Số lượng yêu cầu mỗi giây trong thời kỳ cao điểm lên tới 10.000! Con số thật là ấn tượng. Shopee có thể đã vượt qua con số đó tại thời điểm tôi đang viết bài này.