WiredTiger là công cụ lưu trữ giá trị khóa, hiệu suất cao, là công cụ lưu trữ mặc định trong MongoDB 3.2 và mới hơn.
Javascript là một ngôn ngữ phổ biến trên thế giới, nếu không nhầm thì nó đã hơn 20 năm, và hơn bao giờ hết nó đang phát triển một cách mạnh mẽ từ front-end đến backend và thậm chí là database(mongodb). Do đó việc chúng ta sử dụng javascript hằng ngày là điều hiển nhiên. Và javascript là một gợi ý tuyệt vời khi phát triển một dự án nhỏ, nhanh gọn, tối ưu cao.
Bạn đã đọc và thấy đúng không? Chính xác là những nhà tuyển dụng họ rất quan tâm đến việc triển khai nhiều `transaction` cùng một lúc. Vì vậy trọng tâm là bạn muốn apply vào vị trí đó thì nếu như có kịch bản đó xảy ra thì bạn sẽ làm gì?
Để đơn giản cho việc hiểu về MVCC thì có một kịch bản như sau, cùng một thời điểm thì sẽ xảy ra hiện tượng gì? User X đang xem giá và số lượng sản phẩm Z còn hay không trên hệ thống YYYY, User Y đang order sản phẩm Z và giảm số lượng tồn kho trên hệ thông YYYY...
OK xem như đã nắm được kịch bản với 1.000.000 rows và khoảng 50M. Bắt tay vào. NHIỆM VỤ CHÍNH đó là chúng ta phải cải thiện từ `2 phút theo cách thông thường, chúng ta phải giảm xuống 10 seconds`, sau đó sẽ cải thiện tiếp theo cho từng version.
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 MQ cụ thể là Kafka, RabbitMQ.
RPC vs GRPC: Mặc dù hơi thô nhưng nó đúng là vậy, muốn hiểu về nguyên lý bom ba càng thì hay hỏi các CỰU CHIẾN BINH là có thể hiểu rõ nhất, có đúng không?
Kẻ yếu phàn nàn về môi trường, kẻ mạnh tự thay đổi bản thân. Nó đơn giản tới mức hầu như tôi không thể nào áp dụng đúng 100%.
Phỏng vấn GO Backend: Hôm nay quả là một ngày thật tuyệt, tôi đã nhận được một câu trả lời từ một anh chàng và có thể nói rằng với câu phỏng vấn "Nếu MySQL gặp sự cố trong khi thực hiện transaction" thì anh ấy đã làm tốt hơn tôi rất nhiều.
Điều cần làm lúc này là gì? Hôm nay chúng ta sẽ tham khảo một thủ thuật của những người đi trước, họ không có nguồn lực, không có chi phí cao như ngày nay. Nhưng đổi lại họ đã tìm cách vượt qua điều này như thế nào, chúng ta cùng xem xét.
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.
Có bạn comment rằng, `lớp chúng tôi 70% không xin được việc làm`. Uhm, tôi nghĩ rằng còn lại 30% là có nghĩa rằng sẽ có việc làm NHƯNG đi đúng ngành thì chắc 20% còn lại 10% là sẽ chọn không đúng NGÀNH.
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.
Dự án vetautet giải quyết bài toán cải thiện hiệu suất READ API, WRITE API, Data consistency, Distributed Transactions, Distributed data... Ngoài java, go còn có nestjs và nodejs...
CV quá tốt, như vậy thì hệ thống xxxx.com bạn triển khai cho phép một user login trên được nhiều thiết bị phải không?
Ngoài ra một kịch bản khác nữa được đưa ra ngoài chuyện Logout. Khi logout thì token này đã có trong `tokenBlackList` vì vậy khi một ai đó vô tình lấy lại token này để sử dụng or token này bị rò rỉ (leak) và thời gian token này chưa hết hạn...
Mục này sẽ cung cấp hai `OpenSource` về web app ShareScreen được phát triển bởi Go và Nodejs với nhiều tính năng được cải thiện về hình ảnh, độ trễ...
Đầ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.
Trường hợp thứ hai ví dụ muốn xử lý một data trong một `Array()` thì bạn cần phải nắm hai khái niệm chính đó là xử lý `for` với cấp độ bình thường, nhưng khi xử lý một `Array()` lớn thì `for` thôi là chưa đủ, mà thêm khái niệm `Stream()`...
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?
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.
Họ đã đưa ra những kiến thức chuẩn bị cho việc `ngồi ghế nóng` kiểu giống như đề mở vậy. Đó là `k8s`, `docker`, và quan trọng là `kafka`. Nhưng đột nhiên hãy xem hình ảnh tôi đang làm
Ngoài trời đang mưa rả rích, tiếng mưa rơi lộp độp trên của kính của văn phòng của một công ty lớn trong ngành sản xuất phần mềm. Trong phòng phỏng vấn, Senior - một kỹ sư dày dạn kinh nghiệm đang trao đổi với Intern - một ứng viên trẻ tiềm năng.
Gần đây, hiện tại và sắp tới sau khi kỳ tết 2025 thì chuần bị là mùa cao điểm của việc nhảy việc, và nhiều anh em đã gửi các câu hỏi or đã hỏi tôi về các câu hỏi của các stacks ví dụ như phỏng vấn của NVIDIA..
Chuyện cuối tuần - Vật cực tất phản, hôm nay tôi muốn đề cập đến một khái niệm mà tôi đọc qua trong cuộc sống là đúng, nhưng trong lập trình cấp độ ngôn ngữ thì tôi thấy nó chưa đúng, nhưng lạ thay với cấp độ doanh nghiệp thì nó lại đúng. Khái niệm được đề cập như sau:
Đó là ngày đầu tiên của tôi sau khi được tăng chức khi có một bước tiến mới trong việc [Cải thiện hiệu suất API mới kỹ thuật mới trong DDD - Project] với tư cách một Junior tại một công ty công nghệ.
Làm thế nào để đảm bảo message không bị mất sau này chủ yếu được phân tích từ ba giai đoạn này, hãy chú ý nó một cách cẩn thận. Chỉ khi nào bạn thực sự sử dụng nó thì mới thấy 3 giai đoạn này là vô cùng quan trọng.
Chỉ cần hiểu như thế này cho các round phỏng vấn như món tráng miệng đó là `Thread` rất nặng, nó tương ứng mới các thread của hệ điều hành. Vì vậy chắc chắn có limited.
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…
