Data consistency in Rails: Understanding the different between transaction and locking
Tất cả bắt nguồn từ bài post này của bên Grokking VietNam. Đại ý của bài viết như sau:
Một ứng dụng chuyển tiền của ngân hàng có một đoạn code như dưới đây:
1 2 3 4 5 6 7 8 9 10 |
def transfer(A, B, amount) DB.transaction do if A.balance > amount A.balance -= amount A.save! B.balance += amount B.save! end end end |
Ứng dụng chạy một thời gian thì có bug là tài khoản của một vài người dùng bị âm tiền. Vấn đề ở đây là gì và cách giải quyết.
Mới đầu khi đọc bài viết tôi cũng thấy hơi khó hiểu khi đoạn code trên về mặt logic thì không thấy có gì sai cả. Mặc dù không biết tại sao lại bị âm tiền nhưng tôi lại phát hiện một vấn đề khác (có thể cùng một vấn đề của ở trên nhưng do diễn dịch sai) liên quan đến concurency. Tôi (và có thể là các bạn) đã từng nhiều lần viết code giống như kiểu trên và nghĩ rằng không có vấn đề gì xảy ra cả. Tuy nhiên nó lại có vấn đề khá nghiêm trọng và trong bài viết này tôi muốn chỉ ra nó.
Transaction và Locks
Các ứng dụng web có thể được sử dụng bởi nhiều người dùng cùng một lúc. Một application server như Passenger sẽ có nhiều worker process để phục vụ cho một web app, hay thậm chí là có thể có nhiều application server chạy đồng thời nên hệ thống có khả năng xử lý song song nhiều request của người dùng cùng một lúc.
Điều này có nghĩa là ứng dụng của chúng ta cần phải xử lý việc truy cập dữ liệu đồng thời trong hệ thống của mình. Có 2 công cụ chính để thực hiện điều này ở dưới tầng DB là Transaction và *locks. 2 công cụ này không thể thay thế cho nhau. Bạn không thể dùng transaction để thay thế lock cũng như lock không thể dùng để thay thế transaction.
Transaction
Transaction được dùng để đảm bảo một loạt các thay đổi trong DB được diễn ra hoàn toàn hoặc không có gì xảy ra cả. Ví dụ như method transfer
ở trên nếu không có transaction như sau:
1 2 3 4 5 6 |
def transfer(A, B, amount) A.balance -= amount A.save! B.balance += amount B.save! end |
Đoạn code ở trên sẽ gặp vấn đề như sau: nếu A save thành công mà B gặp vấn đề nào đó không save được (validation error …) thì chỉ có balance của A được thay đổi còn B thì không dẫn đến bug mất mát dữ liệu của hệ thống, hệ thống sẽ không còn độ tin cậy nữa.
Khi sử dụng transaction như implement ban đầu, toàn bộ các thao tác trên A và B đều được gộp lại và xử lý cùng một lúc. Tất cả các thay đổi đều được commit trong một tác vụ atomic (single atomic operation) hoặc là tất cả các thay đổi đều bị abort nếu như gặp bất kỳ vấn đề gì. Như ở trên nếu B.save!
có lỗi thì thay đổi từ A.save!
sẽ bị rollback lại.
Khi nào sử dụng transaction thì hợp lý ?
Bất cứ khi nào bạn thực hiện việc thay đổi mà ảnh hưởng nhiều row trong DB, bạn nên sử dụng transaction để đảm bảo việc thay đổi đó được xử lý đồng thời.
Vấn đề nào sẽ xảy ra khi 2 transaction được chạy cùng một lúc ?
Sẽ không có gì đặc biệt xảy ra khi cùng một transaction được chạy cùng lúc (ví dụ hàm transfer phía trên). Chúng sẽ cùng chạy một lúc và sẽ không có gì đảm bảo về thứ tự thực hiện của chúng. Khi 2 transaction chạy đồng thời thực hiện xong, chúng sẽ cố commit thay đổi của mình vào DB. Việc này có thể thành công hoặc không thành công. Ví dụ nếu cả 2 transaction đều thêm cùng một giá trị vào key unique, transaction nào commit trước sẽ thành công. Transaction chạy sau sẽ gặp lỗi từ DB và toàn bộ thay đổi của transaction đó sẽ bị rollback.
Khi 2 transaction chạy đồng thời trong 2 thread riêng biệt, mỗi thread không thể thấy được transaction của thread khác thay đổi như thế nào trừ khi thay đổi đó được commit vào DB. Như vậy các bạn có thể thắc mắc là tại sao đoạn code của bên Grokking VietNam phía trên vẫn gặp lỗi khi mà nó đã có transaction bao bọc ?
Lí do là transaction không phải là mutex, tức là một thời điểm các transaction vẫn có thể access được vào dữ liệu trong DB và do việc không đảm bảo thứ tự thực hiện của transaction nên sẽ dẫn đến trường hợp dữ liệu của một transaction bị một transaction khác làm thay đổi từ đó gây ra bug.
Ta có thể diễn giải như sau:
Giả sử hàm transfer
được chạy cùng một lúc 2 lần, gọi là transfer1 và transfer2. transfer1
sẽ chạy như sau:
1 2 3 4 5 6 7 8 |
#A.balance = 100, amount = 50 if A.balance > amount #A.balance can be used to transfer A.balance -= amount A.save! # A.balance is now 50 B.balance += amount B.save! end |
transfer2
lúc này cũng được thực hiện như sau:
1 2 3 4 5 6 7 8 |
#A.balance = 100, amount = 80 if A.balance > amount #transfer1 haven't finished. A.balance is still 100 A.balance -= amount A.save! # A.balance is now 20 B.balance += amount B.save! end |
Như vậy, vấn đề ở đây là A có thể transfer cho B quá giới hạn balance của A.
Vậy cách giải quyết vấn đề này là như thế nào ? Đơn giản nhất là ta cần một cơ chế đảm bảo là chỉ một thread hoặc process được access vào dữ liệu để thực hiện thao tác trong cùng 1 thời điểm. Để thực hiện điều này thì ta cần một công cụ khác đó là lock.
Lock
Locks được sử dụng để đảm bảo nhiều process hay thread không thể access vào cùng một đối tượng (resource) tại cùng một thời điểm. Có 2 loại lock đó là Optimistic và Pessimistic.
Optimistic locking
Với loại này, dữ liệu có thể được access bởi nhiều process, tuy nhiên nếu các process đồng thời cập nhật dữ liệu thì sẽ xảy ra conflict, chỉ một process thành công và các process khác sẽ không thực hiện được.
1 2 3 4 5 6 7 8 |
p1 = Person.find(1) p2 = Person.find(1) p1.first_name = "Michael" p1.save p2.first_name = "should fail" p2.save # Raises a ActiveRecord::StaleObjectError |
Để tạo Optimistic locking, bạn cần tạo một field để làm lock version (lock_version
) như sau:
1 2 3 4 5 6 7 8 9 |
class AddLockingColumns < ActiveRecord::Migration def self.up add_column :destinations, :lock_version, :integer end def self.down remove_column :destinations, :lock_version end end |
Sau khi tao cột này, mọi update trong model đều sẽ khiến giá trị lock_version này tăng thêm 1. Vậy nên, nếu 2 yêu cầu muốn thực hiện trên cùng một row, yêu cầu đầu tiên sẽ thành công do lock_version sẽ giống như khi nó được đọc. Yêu cầu tiếp theo sẽ fail vì lock_version được tăng lên trong DB.
Nếu bạn muốn dùng tên khác để lock thì bạn có thể thiết lập locking_column
như sau:
1 2 3 |
class Destination self.locking_column = "my_custom_locking" end |
Pessimistic locking
Với loại lock này, chỉ process đầu tiên truy cập đến đỗi tượng sẽ có thể cập nhật nó. Các process khác sẽ không được cập nhật và thậm chí là không thể đọc dữ liệu.
Lock có thể được chain với where
để có thể lock một tập các row hay gọi trên model object để lock 1 row.
1 2 |
<span class="token constant">Account</span><span class="token punctuation">.</span><span class="token function">where</span><span class="token punctuation">(</span><span class="token string">"name = 'xxx'"</span><span class="token punctuation">)</span><span class="token punctuation">.</span><span class="token function">lock</span><span class="token punctuation">(</span><span class="token keyword">true</span><span class="token punctuation">)</span> <span class="token comment"># Lock các Account có tên là xxx</span> |
1 2 3 |
acc <span class="token operator">=</span> <span class="token constant">Account</span><span class="token punctuation">.</span>first acc<span class="token punctuation">.</span>lock <span class="token comment">#lock account đầu tiên</span> |
Việc lock này sẽ chỉ kết thúc khi bạn hoàn thành việc cập nhật:
1 2 3 4 |
account <span class="token operator">=</span> <span class="token constant">Account</span><span class="token punctuation">.</span><span class="token function">find_by_user_id</span><span class="token punctuation">(</span><span class="token number">5</span><span class="token punctuation">)</span> account<span class="token punctuation">.</span>lock<span class="token operator">!</span> <span class="token comment">#no other processes can read this account, they have to wait until the lock is released</span> account<span class="token punctuation">.</span>save<span class="token operator">!</span> <span class="token comment">#lock is released, other processs can read this account</span> |
Hàm transfer có thể viết lại như sau:
1 2 3 4 5 6 7 8 9 10 11 12 |
def transfer(A, B, amount) A.lock B.lock DB.transaction do if A.balance > amount A.balance -= amount A.save! B.balance += amount B.save! end end end |
Kết luận
Khi các bạn viết ứng dụng, ngoài việc sử dụng transaction thì chúng ta cũng nên quan tâm tới việc locking này. Hi vọng bài viết sẽ là guideline giúp các bạn chú ý hơn khi viết code sau này cũng như trong quá trình debug.
References:
https://kipalog.com/posts/Locking-ActiveRecord-Cua-Rails)https://makandracards.com/makandra/31937-differences-between-transactions-and-lockinghttps://blog.engineyard.com/2011/a-guide-to-optimistic-locking