hì cảm ơn bạn, đúng rồi theo mình thấy neo4j còn khá nhiều thứ cần khai thác

Nội dung khá thú vị ^^ mà cái neo4j này cũng tiềm năng quá nhỉ?

Bạn làm giúp mình bài này với ạ: Tìm hiểu ngôn ngữ Prolog và thực hiện các đề tài sau: Bốc diêm với giải thuật Minimax Cảm ơn bạn nhiều!

Chờ sớm có bài viết tiếp theo của anh. Cám ơn anh vì bài viết chất lượng.

@nghiepit cái này do trình duyệt edge nó sẽ lỗi mình để ul li vẫn lỗi, nhưng mình đổi class ở ul thành 1 class="social__list-a thêm 1 kí tự bật kì thì dc

đệ tự này cũng đỉnh quá c k dám nhận đâu

@haialison Tài liệu thì mình k có vì trước toàn bộ tài liệu là mình ôn trên web học tập của công ty mình. b lên udamy tìm mua 1 khóa học trên đấy rồi học cũng đc b ạ https://www.udemy.com/course/aws-certified-solutions-architect-associate-saa-c02/ mình thấy có khóa này đang đc đánh giá cao

Ok bạn,. Database đã support sẵn lock, ví dụ như lock trên row, lock trên table... khi một record đc insert/update. Một cách nữa để xử lý vấn đề này đó là sử dụng versioning cho row, nếu đã dùng hibernate thì nó có support điều này. Đó là các cơ chế để đảm bảo không có race-condition trong database.

Về ví dụ của bạn, mình chưa rõ câu hỏi lắm, bạn muốn hỏi về trong 0,5s có 100 async request, mỗi request thực hiện cộng giá trị 1 thêm 1. Với 100 request giá trị là 100, 10k request giá trị là 10k?

Trước hết cần xác định mục tiêu của giá trị đó cần phải như thế nào. Có cần đảm bảo response ngay không, cần update kịp thời ngay lập tức không hay chỉ là giá trị mang tính monitoring, theo dõi các kiểu.

Nếu chỉ là giá trị monitoring, k cần realtime thì có thể đẩy nó sang cache, và có window để cập nhật. Ví dụ 100 request hoặc 10s tùy đkiện nào đến trước. Nếu cần realtime, bạn có 2 phương pháp, 1 sử dụng lock dưới tầng db, 2 async request response về client trước, sau đó thực hiện sync đến database để đảm bảo client đc giải phóng. Việc update mình sẽ handle sau đó với cơ chế mutex: có rất nhiều cách như lock, sync, dùng atomic variable... các bài trước mình có đề cập đến.

Đã xem Codesanbox của bạn, và không thấy vấn đề gì như bạn đã mô tả cả.

Mình có một số góp ý với bạn như sau:

1. REST mà chia ra mỗi action 1 Controller là quá rườm rà, phân tán không cần thiết. Nên gộp chung vào 1 Controller, vd MaterialController
2. Đã dùng Laravel thì đừng bao giờ có new Class trong code, Service Provider để làm gì? Sau cần kế thừa class thì có mà to tay.
3. MaterialPostController.php: dùng materialRepository nào là do MaterialPostApplicationService quyết định, không phải do Controller.
4. Việc validate dữ liệu nên làm như Laravel, thực hiện ngay từ trước khi vào Controller, thực hiện validate khi đã vào tận MaterialPostApplicationService mình nghĩ không nên.
5. MaterialPostApplicationService.php: việc bắt đầu DB::beginTransaction() trước cả materialRepository->create mình nghĩ là vô nghĩa vì chưa xử lý gì DB cả. Hơn nữa nếu chỉ có create thì mình nghĩ cần gì beginTransaction với try catch, khác gì nhau đâu?
6. MaterialPostCommand.php nên cho truyền vào array có key value, rồi bên trong set get gì tùy bạn. Có tầm 10 cái thuộc tính mà set get ở ngoài như bạn mình thấy mệt quá.
7. ...

Tác giả có thể viết 1 bài về đồng bộ request trong database được k. Ví dụ spring boot mỗi request là bất đồng bộ. Các request đó đều trỏ update 1 object (user có.1 trường giá trị là 1). Mỗi request mất 0.5 Trong 0.5s đó có 100 request như thế làm thế nào ra đc kết quả 100 Nếu nhân 100 user request 100 lần là 10k request làm sao đảm bảo thời gian và kết quả đúng nhất

Bài viết rất hay. Thank you!!!

@luongvanphuc post kinh nghiêm đi bạn ơi

Bài viết hữu ích và ví dụ dễ hiểu. Cảm ơn bạn nhé

Cám ơn bạn

thanks a ạ

Chaò bạn. Có thể cho mình xin bộ dataset này được không? hoaidtk@gmail.com Cảm ơn bạn nhiều

không cần dùng substack ở eq cuối em nhé, với cả dùng $$ $$ (hoặc \( \)) để eq vào giữa trang (display mode)

Bài viết rất hay. Cảm ơn tác giả, mình mới vọc aws nên đọc qua cái này đỡ thiệt

Có cách nào để custom lại cái trang login k bạn nhỉ?