IT - Về xử lý ở SV

qualayeuduoi

Senior Member

• 24/3/20

• #1

Chào các thím, em lại mò lên nhờ các thím giải đáp vài câu hỏi, mong các thím chỉ dẫn.
Theo em biết thì truyển tin qua internet là tuần tự - Vậy 2 gói tin từ 2 client truyền lên sv là tuần tự trước sau đúng không ? Vậy vấn đề trong database còn 1 item nhưng 2 khách hàng cùng bấm mua có xảy ra hay ko? Nếu có xảy ra (trong trường hợp đa luồng hay gì đó) thì phải xử lý vấn đề này thế nào.?
Thêm nữa, giả sử có 1000 req cùng lúc, mỗi req mất 0,1s thì phải giải quyết vấn đề như thế nào?

 

[Yi]

Mastery

• 24/3/20

• #2

Có xảy ra thì dùng transaction
Lệnh 1: Thực hiện lệnh update ,insert
Lệnh 2: Xác nhận đã update dữ liệu thành công chưa, nếu chưa thì rollback

 

D

daovanman

Junior Member

• 24/3/20

• #3

Xử lý trên là xử lý đồng bộ, giờ thì đều sử dụng bất đồng bộ rồi, 1000 req gửi lên server thì là bắt cả 1000 req 1 lúc luôn còn trả về kết quả thì tùy vào tối ưu của code và sức mạnh của server, hệ thống phân tán.
Xử lý ghi vào server với số lượng req lớn là một vấn đề khá to, thông thường sẽ khoá isolation row ở bảng nhưng cái này hiệu năng kém nhưng vẫn đáp ứng được đa số các trường hợp, cách ghê gớm hơn là message quere, cái này thì nói chú cũng chưa hiểu dc.

 

tglfc

Senior Member

• 24/3/20

• #4

Transaction thôi. Hiểu đơn giản là trong cùng 1 thời điểm, chỉ có 1 request được thao tác (Update, insert, delete) với DB

 

Nick.Thu.4

Senior Member

• 24/3/20

• #5

cái này chạy trước thì success cái nào chạy sau thì throw ra lỗi thôi.

 

H

hgdom

Member

• 24/3/20

• #6

tglfc đã nói:

Transaction thôi. Hiểu đơn giản là trong cùng 1 thời điểm, chỉ có 1 request được thao tác (Update, insert, delete) với DB

Nhấp để mở rộng...

Thường Transaction là để đảm bảo tính toàn vẹn của dữ liệu (VD 2 command trong transaction mà 1 cái bị fail thì cái còn lại cũng không được commit)
Ở ISOLATION LEVEL mặc định của Transaction thì nó sẽ không lock read và insert khi transaction update dữ liệu trên bảng liên quan => sẽ ko giải quyết được vấn đề của thớt vì transaction khác vẫn có thể read và insert được
Nếu chủ động áp ISOLATION LEVEL cao hơn cho Transaction thì dễ gây ảnh hưởng lớn tới hiệu suất của hệ thống, tuy là vậy nhưng tệ hại là trong nhiều trường hợp vẫn không giải quyết được vấn đề tương tự như của thớt
Mình thường sử dụng lock object ở tầng app để xử lý những trường hợp tương tự như thớt hiện tại

 

Sửa lần cuối: 24/3/20

sonym4aqua

Junior Member

• 24/3/20

• #7

tìm hiểu về Pessimistic và Optimistic Locking xem.

 

d.dungg

Member

• 24/3/20

• #8

daovanman đã nói:

Xử lý trên là xử lý đồng bộ, giờ thì đều sử dụng bất đồng bộ rồi, 1000 req gửi lên server thì là bắt cả 1000 req 1 lúc luôn còn trả về kết quả thì tùy vào tối ưu của code và sức mạnh của server, hệ thống phân tán.
Xử lý ghi vào server với số lượng req lớn là một vấn đề khá to, thông thường sẽ khoá isolation row ở bảng nhưng cái này hiệu năng kém nhưng vẫn đáp ứng được đa số các trường hợp, cách ghê gớm hơn là message quere, cái này thì nói chú cũng chưa hiểu dc.

Nhấp để mở rộng...

Công nhận message queue nghe qua thì dễ, cơ chế đơn giản mà bắt tay vào làm phận fresher như em chả hiểu con mẹ gì