Em định để tất cả các luồng dùng chung 1 đối tượng kết nối, và khi luồng nào dùng phương thức kết nối thì các luồng khác sẽ phải chờ, và nếu k dùng cách đó thì e sẽ dùng mỗi luồng 1 đối tượng kết nối riêng, và sẽ lock table. Nhưng đang phân vân không biết các dev chuyên nghiệp, app lớn thì dùng cách nào để tối ưu hiệu suất và tránh đụng độ
use case của fen là gì, chứ như này thì multi thread có tác dụng gì đâu, connection chỉ có 1 thằng hold còn lại chờ
thím masterr java k ? e xin nhận làm đệ
Bạn sử dụng pessimistic lock hoặc optimistic lock của Mysql
Mình ở SG nè, inbox kết nối giao lưu nghề nghiệp bạn
cơ bản nhất là Socket. Js thì lên copy code, còn Backend thì Spring socket.Các bác ơi, em đang có dự định làm 1 web chat realtime đơn giản với Java thì em nên sử dụng những công nghệ nào ạ, các bác cho em xin 1 số gợi ý với
Dùng optimistic lock (MySQL) là được nha bác, và nên lock trên row cần update chứ không cần phải lock cả table, Nhưng nếu tất cả các thread chỉ update 1 record trong thời gian dài thì dễ gây bottleneck. Synchronized sẽ không giải quyết được vấn đề khi bạn scale lên nhiều process trên môi trường production.
Cách dễ nhất để tối ưu hiệu suất lúc làm việc với csdl là dùng connection pool để giảm thời gian thiết lập kết nối. Ngoài ra còn có thể sử dụng các thư viện bất đồng bộ - async (RxJava, SmallRye Mutiny) để tối ưu CPU utilization.
java firebase admin sdk (Firebase | Firestore vs. Realtime Database) - nhanh gọn lẹCác bác ơi, em đang có dự định làm 1 web chat realtime đơn giản với Java thì em nên sử dụng những công nghệ nào ạ, các bác cho em xin 1 số gợi ý với
)
Em ở HCM, có gì thím chỉ em với được không
dạ vâng bác, trước em có làm 1 cái bé bé bằng websocket rồi, nên chắc lần này sẽ tìm hiểu cái nàyjava firebase admin sdk (Firebase | Firestore vs. Realtime Database) - nhanh gọn lẹ
Java 17 chứ
E ké luôn a.Em ở HCM, có gì thím chỉ em với được không
cái này thì fen xử thế nào
, và nhân độ khó cho maintain lên 1000 lần 
lúc thanh toán thì cho vào queue hết và update tuần tự. Mình có thể tính toán số lượng stock mà không cần update vào đb liên tục. Tính xong rồi flush vào db hoặc tính vào luôn db cũng đc. Đến khi nào stock về 0 thì thôicái này thì fen xử thế nào
ví dụ update số lượng sản phẩm đặt hàng của thương mại điện tử, 1 sp sẽ có rất nhiều đơn đặt hàng cùng lúc, vd lúc sale
giải pháp của tôi là chia số lượng thành batch, vd 100, 100k sp sẽ có 1k batch, vậy khi update 1sp thì tôi sẽ là update 1k cái record kia, chia bottle neck thành 1000 lần
hoặc maintain 1 cái table order riêng, ko update sp nữa mà validate là cộng tổng của order, chấp nhận có sai số, vậy là ko lock gì hết
Khi scale nhiều instance, người ta áp dụng thêm queue và distributed lock ví dụ như redis.cái này thì fen xử thế nào
ví dụ update số lượng sản phẩm đặt hàng của thương mại điện tử, 1 sp sẽ có rất nhiều đơn đặt hàng cùng lúc, vd lúc sale
giải pháp của tôi là chia số lượng thành batch, vd 100, 100k sp sẽ có 1k batch, vậy khi update 1sp thì tôi sẽ là update 1k cái record kia, chia bottle neck thành 1000 lần
hoặc maintain 1 cái table order riêng, ko update sp nữa mà validate là cộng tổng của order, chấp nhận có sai số, vậy là ko lock gì hết
1000 request 1 lúc block 1 cái key thì chết
Ví dụ nhé, sản phẩm sp1 có 1000 đơn vị
