@xuanvinhln a k nói shared db để impl distributed transaction. shared db có thể giải quyết đc bài toán dual write. ví dụ với the best case network ổn định, k có singlepointfailure, crash app... mấu chốt của việc create order và deduct payment là: order phải đc tạo thành công (khi đủ tiền trong tài khoản), và trừ tiền thành công (sau khi order được tạo). Tức là local transaction ở order-service hoàn toàn có khả năng tạo order và check balance đc (gần giống như precommit). sau đó sang đến payment chỉ việc trừ tiền nữa thôi. Trong trường hợp user place 2 order cùng lúc thì cần đảm bảo xử lí tuần tự order 1.
tiếp theo là tính đến case crash app.. k trừ tiền thành công, lúc này cần impl nhiều thứ hơn để đảm bảo trừ tiền thành công, retry, timeout, rollback... các thứ.
@xuanvinhln
ví dụ app của mình theo dạng nạp tiền thanh toán trước, kiểu nạp tiền vào game quy đổi ra game point. Thì khi mua item cần 2 step check số dư và add item. Nếu là monolithic thì transaction bao gồm 2 step: check số dư trước, pass thì - tiền và + item. Bây giờ 2 step check số dư và trừ tiền thuộc payment, + item thuộc order. Việc check số dư và tạo order mình có thể làm ở order service, đảm bảo số dư ok r mới tạo order, sau đó deduct money thực hiện sau. Nếu lỗi thì lỗi lúc này k phải do k đủ số dư (tức là data consistence). Ví dụ scrash app, singlepointfailure... thì bh bài toán này mình phải có cách handle khác và nó k nằm trong bài viết này. Mechanism thì vẫn là retry, timeout... Đây là case đầu tiên.
nếu là thanh toán online nhập số thẻ visa/master thì mình có thể k thực hiện đc theo cách này, hoặc đến step deduct money phải làm kiểu khác.
Case t2, giống bài toán monolithic, 3 step kia thuộc cùng transaction, k thực hiện //. Vậy nên nếu làm shared database mình làm như c1, hạn chế dùng //. Nếu vẫn dùng // mình có rất nhiều cách để handle, 1 là read uncommited nhưng k phải database nào cũng support. 2 là dùng database lock.
a nghĩ là e đang hiểu nhầm việc sử dụng shared db để làm transaction cho các service. ý a muốn đề cập đến là việc mình đảm bảo đc data consistency -> dẫn đến việc xử lí data dễ hơn. hoặc em có idea gì khác thì share a nhé
@datbv E thấy chưa clear lắm.
Như vd của a đang có 2 service:
order-service: create order
payment-service: deduct money.
Case 1: nếu thực hiện tuần tự, create order thành công, sau đó deduct money.
Do chạy trên 2 service khác nhau nên create order và deduct money là 2 transaction độc lập. Nếu như bước deduct money bị lỗi, làm sao để order-service biết mà rollback bước create-order?
Case 2: nếu thực hiện song song, create order và deduct money đồng thời.
Nếu DB đặt isolation mặc định ở mức REPEATABLE READ, thì 2 transaction create order và deduct money không nhìn thấy dữ liệu của nhau -> không biết cái nào đã được tạo thành công -> làm sao để cùng nhau commit hoặc rollback?
anh ơi cho em hỏi với ạ, nếu vậy thì canvas nó hiển thị ra trang web nhưng nó lại che đi các element khác mất tiêu ạ, dẫn đến không tác động được gì với trang web đó ạ, anh có cách nào cho nó nằm dưới mà vẫn hiển thị được không anh??
ví dụ 2 action là create order (order-service) và deduct money (payment-service) thực hiện trên 2 service khác nhau với cùng 1 database.
đầu tiên là create order: tạo transaction để làm mấy thứ lquan đến kiểm tra số dư và tạo order.
tiếp theo là deduct money: tạo transaction để check order, trừ tiền, abc này nọ.
2 transaction này thực hiện trên cùng db nên lock lẫn nhau, k lo vấn đề concurrent.
còn việc 1 user có thể order nhiều order, trừ tiền nhiều lần, phần này phải làm sequence r nên cũng k lo việc data race
-> mấu chốt k phải là đưa toàn bộ các action vào cùng transaction mà để tránh việc inconsistence data khi thực hiện các transaction riêng lẻ. my idea, sai sót gì e bổ sung nhé
E xin hỏi, với cách "1.4.1) Sử dụng chung database"
Nếu 3 service A, B, C cùng nhau thực hiện đồng thời 3 action, update payment, update order, update deliver thì làm sao gom 3 action này vào cùng 1 transaction được?
dạ anh ơi, cho em hỏi là em chèn vào trang web được rồi ạ, nhưng em tác động đến trang web đó không được (như click chuột vào các nút button trong trang web...v.v), kiểu nó bị cái canvas che đi nên không tác động được, mà dùng display: none; thì cái canvas lại không hiện lên mà lại tác động được với trang web ạ, anh có cách nào chỉ em với ạ, em cảm ơn anh nhiều.
THẢO LUẬN
Quèo, bài viết rất chi là này nọ
@xuanvinhln a k nói shared db để impl distributed transaction. shared db có thể giải quyết đc bài toán dual write. ví dụ với the best case network ổn định, k có singlepointfailure, crash app... mấu chốt của việc create order và deduct payment là: order phải đc tạo thành công (khi đủ tiền trong tài khoản), và trừ tiền thành công (sau khi order được tạo). Tức là local transaction ở order-service hoàn toàn có khả năng tạo order và check balance đc (gần giống như precommit). sau đó sang đến payment chỉ việc trừ tiền nữa thôi. Trong trường hợp user place 2 order cùng lúc thì cần đảm bảo xử lí tuần tự order 1.
tiếp theo là tính đến case crash app.. k trừ tiền thành công, lúc này cần impl nhiều thứ hơn để đảm bảo trừ tiền thành công, retry, timeout, rollback... các thứ.
💓💓💓💓💓
Hay quá, đúng bài mình cần =)))
@datbv E vẫn chưa hiểu sao có thể dùng shared DB để cài đặt Distributed transaction.
-> Làm sao để đảm bảo 2 hành động hày cùng commit hoặc cùng rollback?
@datbv E đang thấy a viết là dùng shared DB để implement Distributed transaction (xử lý dual write problem) mà nhỉ?
Bạn báo mỗi mã lỗi h10 thì mình chịu, k đủ dữ liệu để trả lời bạn. Command trong file Procfile của bạn là gì? Đã chạy được trên local chưa?
@xuanvinhln ví dụ app của mình theo dạng nạp tiền thanh toán trước, kiểu nạp tiền vào game quy đổi ra game point. Thì khi mua item cần 2 step check số dư và add item. Nếu là monolithic thì transaction bao gồm 2 step: check số dư trước, pass thì - tiền và + item. Bây giờ 2 step check số dư và trừ tiền thuộc payment, + item thuộc order. Việc check số dư và tạo order mình có thể làm ở order service, đảm bảo số dư ok r mới tạo order, sau đó deduct money thực hiện sau. Nếu lỗi thì lỗi lúc này k phải do k đủ số dư (tức là data consistence). Ví dụ scrash app, singlepointfailure... thì bh bài toán này mình phải có cách handle khác và nó k nằm trong bài viết này. Mechanism thì vẫn là retry, timeout... Đây là case đầu tiên. nếu là thanh toán online nhập số thẻ visa/master thì mình có thể k thực hiện đc theo cách này, hoặc đến step deduct money phải làm kiểu khác.
Case t2, giống bài toán monolithic, 3 step kia thuộc cùng transaction, k thực hiện //. Vậy nên nếu làm shared database mình làm như c1, hạn chế dùng //. Nếu vẫn dùng // mình có rất nhiều cách để handle, 1 là read uncommited nhưng k phải database nào cũng support. 2 là dùng database lock.
a nghĩ là e đang hiểu nhầm việc sử dụng shared db để làm transaction cho các service. ý a muốn đề cập đến là việc mình đảm bảo đc data consistency -> dẫn đến việc xử lí data dễ hơn. hoặc em có idea gì khác thì share a nhé
@datbv E thấy chưa clear lắm. Như vd của a đang có 2 service:
Case 1: nếu thực hiện tuần tự, create order thành công, sau đó deduct money.
Case 2: nếu thực hiện song song, create order và deduct money đồng thời.
@HuyDQ ,ừ nhưng sữa lại được rồi,nếu muốn tạo page phải dùng model và cái chức năng elenoque gì đó ha,tạo csdl rồi migratevvvvvvvvvvvvvvv
Sao mình không thấy phần 2.
500 chứ đúng không bạn?
anh ơi cho em hỏi với ạ, nếu vậy thì canvas nó hiển thị ra trang web nhưng nó lại che đi các element khác mất tiêu ạ, dẫn đến không tác động được gì với trang web đó ạ, anh có cách nào cho nó nằm dưới mà vẫn hiển thị được không anh??
ví dụ 2 action là create order (order-service) và deduct money (payment-service) thực hiện trên 2 service khác nhau với cùng 1 database. đầu tiên là create order: tạo transaction để làm mấy thứ lquan đến kiểm tra số dư và tạo order. tiếp theo là deduct money: tạo transaction để check order, trừ tiền, abc này nọ. 2 transaction này thực hiện trên cùng db nên lock lẫn nhau, k lo vấn đề concurrent.
còn việc 1 user có thể order nhiều order, trừ tiền nhiều lần, phần này phải làm sequence r nên cũng k lo việc data race
-> mấu chốt k phải là đưa toàn bộ các action vào cùng transaction mà để tránh việc inconsistence data khi thực hiện các transaction riêng lẻ. my idea, sai sót gì e bổ sung nhé
E xin hỏi, với cách "1.4.1) Sử dụng chung database" Nếu 3 service A, B, C cùng nhau thực hiện đồng thời 3 action, update payment, update order, update deliver thì làm sao gom 3 action này vào cùng 1 transaction được?
bài viết hay ạ.
dạ anh ơi, cho em hỏi là em chèn vào trang web được rồi ạ, nhưng em tác động đến trang web đó không được (như click chuột vào các nút button trong trang web...v.v), kiểu nó bị cái canvas che đi nên không tác động được, mà dùng display: none; thì cái canvas lại không hiện lên mà lại tác động được với trang web ạ, anh có cách nào chỉ em với ạ, em cảm ơn anh nhiều.
heroku hỗ trỡ python 3.9.10 ,mình upload django sử dụng python 3.9.7 bị lỗi app crash 0
kha hay
@hoangviet ,mình dùng lệnh heroku ps:web scale=1 mà vẫn lỗi h10 app crash