thắc mắc Cách mà 1 server hoạt động

Lên Đây Tâm Sự 3 đã nói:

Vậy giả sử có 1 vé trong database

Có rất nhiều người dùng cùng đặt mua vé cùng 1 lúc

Thì nên xử lý cơ chế này như thế nào các bác nhỉ?

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

How to deal with concurrent updates in databases?

What's the common way to deal with concurrent updates in an SQL database ? Consider a simple SQL schema(constraints and defaults not shown..) like create table credits ( int id, int creds, ...

stackoverflow.com

Lên Đây Tâm Sự 3 đã nói:

Vậy giả sử có 1 vé trong database

Có rất nhiều người dùng cùng đặt mua vé cùng 1 lúc

Thì nên xử lý cơ chế này như thế nào các bác nhỉ?

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

vodka_hanoi1 đã nói:

cái này ko liên quan, tụi nó phải có 1 message queue đứng ở đằng trước
và khi người ta order thường dễ nhất nó lock cmn cái slot đó lại luôn (ví dụ trên trang đặt vé cgv, bhd) trong vòng 5 - 10p nếu ko order thì slot đó nó nhả ra

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

Lên Đây Tâm Sự 3 đã nói:

Nhưng mà hệ thống bán vé liên tục sao mà chơi lock được thím

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

Lên Đây Tâm Sự 3 đã nói:

Nhưng mà hệ thống bán vé liên tục sao mà chơi lock được thím

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

sigel đã nói:

em search thì thấy chúng nó bảo là mài hãy xài transaction,

How to deal with concurrent updates in databases?

What's the common way to deal with concurrent updates in an SQL database ? Consider a simple SQL schema(constraints and defaults not shown..) like create table credits ( int id, int creds, ...

stackoverflow.com

thường xử lý thực tế nó sẽ ntn.
khi thím lựa 1 vé để mua thì hệ thống sẽ khóa cái vé đó lại, người sau bấm vào họ sẽ bị báo lỗi là vé đang có người đặt. Việc khóa 1 trường sẽ kèm theo thời gian timeout, quá mức này mà không thanh toán thì nó lại nhả ra như cũ.

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

vodka_hanoi1 đã nói:

ko tin thì tạo 1 tài khoản trên cgv rồi đặt thử xem là biết.
nó lock cái ghế đó lại
xong ông lấy acc khác vào thì đã thấy ghế đó ko click vào dc nữa trừ khi account 1 nhả ghế ra
Còn ví dụ ở trên shopee thì ví dụ hàng đó còn 10 sản phẩm. Thêm đồ đó vào giỏ hàng sẽ đẩy vào queue, nhưng nếu bên kia hết hàng mà mình bấm thanh toán thì nó bung ra lỗi do sản phẩm bị sold out

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

_tucachmo_ đã nói:

Trường hợp đặt ghế trên cgv thì nó lock hẳn cái ghế đấy lại cũng k có vấn đề gì vì có 1 chỗ. Nhưng bài toán kho hàng của shopee thì sao mà lock cứng được. Nhiều người cùng vào đặt mua cùng 1 lúc mà đợi ông đến trước release lock thì đến bao giờ.

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

vodka_hanoi1 đã nói:

ví dụ thế thôi, chứ lúc thiết kế bọn kia nó cũng nghĩ ra tất cả test case rồi

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

vodka_hanoi1 đã nói:

cái này ko liên quan, tụi nó phải có 1 message queue đứng ở đằng trước
và khi người ta order thường dễ nhất nó lock cmn cái slot đó lại luôn (ví dụ trên trang đặt vé cgv, bhd) trong vòng 5 - 10p nếu ko order thì slot đó nó nhả ra

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

_tucachmo_ đã nói:

Trường hợp đặt ghế trên cgv thì nó lock hẳn cái ghế đấy lại cũng k có vấn đề gì vì có 1 chỗ. Nhưng bài toán kho hàng của shopee thì sao mà lock cứng được. Nhiều người cùng vào đặt mua cùng 1 lúc mà đợi ông đến trước release lock thì đến bao giờ.

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

phuctienn đã nói:

Câu hỏi 1:
- 2 máy cùng gọi đến 1 API. API này tốn 10s để thực hiện. Khi máy 1 vừa gọi API, máy 2 cũng gọi đến API đó, vậy máy 2 có phải đợi 10s để server trả xong kết quả cho máy 1 rồi mới thực hiện không. Nếu không thì server thực hiện chia thread hay như thế nào để có thể chạy song song trả kết quả về cho nhiều máy cùng lúc ạ

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

phuctienn đã nói:

Câu hỏi 2:
- Ví dụ 1 hàm thêm sản phẩm. Id của sản phẩm là tự động tăng. Để lấy Id vừa thêm thì ta phải lấy Id lớn nhất trong database. Vậy Id này có đúng không, trường hợp nhiều người thêm sản phẩm 1 lúc thì như thế nào (khi sản phẩm vừa được thêm vào db, cùng lúc đó nhiều sản phẩm khác của người dùng khác cũng được thêm vào db, vậy hàm lấy Id lớn nhất trong database có còn lấy được Id của sản phẩm vừa thêm không)

Hàm có dạng như dưới

C#:

Product InsertProduct(Product product) {
    _db.Products.Insert(product);
    var id = _db.Products.GetLastIndexInserted(); // Lấy Id mới nhất vừa được thêm
    product.Id = id;
    return product;
}

- Câu hỏi em thấy tương tự câu trên: Trong 1 hàm, gọi 2 lần hàm GetNewProducts để lấy danh sách sản phẩm mới nhất, 2 kết quả này có khác nhau không. Nếu giống nhau thì server thực hiện theo cơ chế nào

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

Lên Đây Tâm Sự 3 đã nói:

Ví dụ bảng Product có data như sau:

ProductId | Price
1 | 100

Giả sử có 1 lệnh select
select * from Product where ProductId = 1

Và 1 lệnh update
update Product set Price = 200 where ProductId = 1

Trong trường hợp 2 lệnh cùng 1 thời điểm, không lệch một chút nào thì kết quả trả ra là gì?

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

• nếu thằng select mở transaction với isolation level là REPEATABLE READ VÀ NÓ ĐÃ ĐỌC CÁI RECORD NÀY TRƯỚC ĐẤY thì cho dù select sau thằng update VÀ THG UPDATE ĐÃ COMMIT RỒI thì thg select cũng chỉ thấy price là 100 giống với lúc ban đầu nó thấy.
• nếu thằng select mở transaction với isolation level là READ UNCOMMITTED thì select nó sẽ thấy dữ liệu mới nhất mặc cho thg update có commit hay chưa, tức là thấy 200 đấy.

phuctienn đã nói:

Em cảm ơn bác ạ, câu 1 dễ hiểu lắm, còn câu 2 em tìm hiểu như thế nàyXem tệp đính kèm 2691460

• Theo em hiểu: khi gọi 2 lần hàm GetNewProducts thì sẽ viết 2 câu query xuống db, mỗi câu query lại trong 1 transaction khác nhau nếu mình không gói vào 1 transaction => 2 dữ liệu nhận được có thể khác nhau.
• Tương tự nếu không gói 2 transaction Insert và lấy LAST_INSERT_ID thì khi transaction của câu query _db.Products.Insert(product) thành công, trong quá trình chạy xuống transaction của câu query LAST_INSERT_ID có thể sẽ có nhiều user khác thêm product, và dẫn tới lấy sai Id của product vừa thêm

Không biết em hiểu vầy có đúng không ạ, hay còn cơ chế gì để gói các câu query trong 1 hàm vào 1 transaction to hơn để đảm bảo tính đúng đắn không ạ

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

never_can_tell đã nói:

Mình ko nghĩ là việc thực thi 2 lệnh kia lại được thực hiện tuần tự. Các bạn cứ nghĩ, cả triệu lệnh chờ nhau thì bao giờ mới xong.

2 lệnh đấy sẽ được thực hiện đồng thời.

Thế câu trả lời cho câu hỏi kết quả trả về là cái gì thì câu trả lời là tùy. Về cơ bản khi mà bạn query thì lệnh chỉ được gửi xuống database thôi. Còn lệnh được thực sự chạy lúc nào thì lại do cơ chế tự động của database và lệnh read chỉ thấy được dữ liệu mới khi lệnh update đã thực sự commit xong. Giống source control ấy, code mới chưa commit xong thì những người khác sẽ ko thấy được.

Túm cái váy lại là, trên lý thuyết, thì giá trị trả về của select phụ thuộc vào việc ở thời điểm đọc lệnh update đã commit xong hay chưa. Nếu xong rồi thì 200, không thì 100. Còn thực tế, thì thông thường là write tốn thời gian hơn nhiều so với read nên khả năng lớn là ở thời điểm read thì write chưa commit xong, vậy kết quả là 100.

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

phuctienn đã nói:

Em đang hơi bị conflict, nếu để đồng thời thì id sẽ không tự động tăng được nên em nghĩ phải lock id lại, mà lock lại thì lại không đồng thời được

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