App Engine, giao dịch và idempotency

Question

Hãy giúp tôi tìm hiểu sự hiểu lầm của mình.

Tôi đang viết một RPG trên App Engine. Một số hành động mà người chơi sẽ sử dụng một số liệu thống kê nhất định. Nếu chỉ số đạt đến 0 thì người chơi không thể thực hiện thêm hành động nào. Tôi bắt đầu lo lắng về người chơi gian lận, mặc dù - nếu một người chơi gửi hai hành động rất nhanh, ngay bên cạnh nhau? Nếu mã giảm số liệu thống kê không có trong giao dịch, thì người chơi có cơ hội thực hiện hành động hai lần. Vì vậy, tôi nên quấn mã mà giảm số liệu trong một giao dịch, phải không? Càng xa càng tốt.

Trong GAE Python, tuy nhiên, chúng tôi có điều này trong documentation:

Note: Nếu ứng dụng của bạn nhận được một ngoại lệ khi nộp một giao dịch, nó không luôn có nghĩa là giao dịch thất bại. Bạn có thể nhận được Timeout, TransactionFailedError hoặc ngoại lệ InternalError trong trường hợp giao dịch đã được cam kết và cuối cùng sẽ áp dụng thành công . Bất cứ khi nào có thể, hãy thực hiện các giao dịch Datastore của bạn một cách không cần thiết để rằng nếu bạn lặp lại một giao dịch, kết quả cuối cùng sẽ giống nhau.

Rất tiếc. Điều đó có nghĩa là chức năng tôi đang chạy có dạng như sau:

def decrement(player_key, value=5): 
    player = Player.get(player_key) 
    player.stat -= value 
    player.put() 

Vâng, điều đó không hiệu quả vì điều này không phải là không đáng tin cậy, phải không? Nếu tôi đặt một vòng lặp thử lại xung quanh nó (tôi cần phải trong Python? Tôi đã đọc mà tôi không cần phải trên SO ... nhưng tôi không thể tìm thấy nó trong tài liệu) nó có thể tăng giá trị hai lần, đúng? Kể từ khi mã của tôi có thể bắt một ngoại lệ nhưng kho dữ liệu vẫn cam kết dữ liệu ... huh? Làm thế nào để sửa lỗi này? Đây có phải là trường hợp tôi cần distributed transactions không? Tôi có thực sự?

Answer 1

Trước tiên, câu trả lời của Nick không chính xác. Giao dịch của DHayes không phải là idempotent, vì vậy nếu nó chạy nhiều lần (ví dụ: thử lại khi cố gắng đầu tiên được cho là đã thất bại, khi nó không), thì giá trị sẽ bị giảm đi nhiều lần. Nick nói rằng "kho dữ liệu sẽ kiểm tra nếu các thực thể đã được sửa đổi vì chúng đã được tìm nạp", nhưng điều đó không ngăn được sự cố vì hai giao dịch có các lần tìm nạp riêng biệt và lần tìm nạp thứ hai là SAU giao dịch đầu tiên hoàn thành.

Để giải quyết vấn đề, bạn có thể thực hiện idempotent giao dịch bằng cách tạo "khóa giao dịch" và ghi lại khóa đó trong một thực thể mới như là một phần của giao dịch. Giao dịch thứ hai có thể kiểm tra khóa giao dịch đó, và nếu được tìm thấy, sẽ không làm gì cả. Khóa giao dịch có thể bị xóa khi bạn đã hài lòng rằng giao dịch đã hoàn tất hoặc bạn từ bỏ việc thử lại.

Tôi muốn biết những gì "cực kỳ hiếm" có nghĩa là cho AppEngine (1-trong-một triệu, hoặc 1-trong-một tỷ?), Nhưng lời khuyên của tôi là giao dịch không cần thiết là cần thiết cho các vấn đề tài chính , nhưng không phải cho điểm số trò chơi hoặc thậm chí là "sống" ;-)

Answer 2

Bạn không nên lưu trữ loại thông tin này trong Memcache, nhanh hơn nhiều so với Datastore (thứ bạn cần nếu stat này được sử dụng trong ứng dụng của bạn). Memcache cung cấp cho bạn một chức năng tốt đẹp: decr trong đó:

Giảm một cách nguyên tắc giá trị của khóa. Bên trong, giá trị là số nguyên 64 bit không dấu. Memcache không kiểm tra luồng tràn 64 bit. Giá trị, nếu quá lớn, sẽ quấn quanh.

Tìm kiếm decrhere. Sau đó, bạn nên sử dụng một nhiệm vụ để lưu giá trị trong khóa này vào kho dữ liệu hoặc mỗi x giây hoặc khi một điều kiện nhất định được đáp ứng.

Answer 3

Nếu bạn suy nghĩ kỹ về những gì bạn mô tả, nó có thể không thực sự là một vấn đề. Hãy suy nghĩ về điều này theo cách này:

Bạn có một điểm stat còn lại. Sau đó, anh ta gửi hai hành động (A1 và A2) ngay lập tức mà mỗi cái cần phải tiêu thụ điểm đó. Cả A1 và A2 đều giao dịch.

Đây là những gì có thể xảy ra:

A1 thành công. A2 sau đó sẽ hủy bỏ. Tất cả đều tốt.

A1 không hợp pháp (không thay đổi dữ liệu). Thử lại theo lịch. A2 sau đó cố gắng, thành công. Khi A1 cố gắng một lần nữa, nó sẽ hủy bỏ.

A1 thành công nhưng báo cáo lỗi. Thử lại theo lịch. Lần sau khi A1 hoặc A2 cố gắng, họ sẽ hủy bỏ.

Để làm việc này, bạn cần phải theo dõi xem liệu A1 và A2 đã hoàn thành - có thể cung cấp cho họ một nhiệm vụ UUID và lưu trữ danh sách các tác vụ đã hoàn thành không? Hoặc thậm chí chỉ cần sử dụng hàng đợi nhiệm vụ.

Answer 4

Chỉnh sửa: Điều này không chính xác - vui lòng xem các nhận xét.

Mã của bạn vẫn ổn. Các idempotence các tài liệu tham khảo là liên quan đến tác dụng phụ. Theo các tài liệu giải thích, chức năng giao dịch của bạn có thể được chạy nhiều lần; trong những tình huống như vậy nếu hàm có bất kỳ tác dụng phụ nào, chúng sẽ được áp dụng nhiều lần. Vì chức năng giao dịch của bạn không làm điều đó, nó sẽ ổn thôi.

Một ví dụ về một hàm có vấn đề liên quan đến idempotence sẽ là một cái gì đó như thế này:

def do_something(self): 
    def _tx(): 
    # Do something transactional 
    self.counter += 1 
    db.run_in_transaction(_tx) 

Trong trường hợp này, self.counter có thể được tăng thêm 1, hoặc có khả năng hơn 1. Điều này có thể tránh được bằng cách thực hiện các tác dụng phụ bên ngoài giao dịch:

def do_something(self): 
    def _tx(): 
    # Do something transactional 
    return 1 
    self.counter += db.run_in_transaction(_tx)