Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Distributed Transaction
in Microservice
Lê Minh Nghĩa
Solution Architect at Tiki.Vn
Contents
1. Distributed Transaction Problem.
2. CAP Theorem
3. Replicate Model
4. Consistency and Eventually Consistency
5...
Phần 1.
Các kiến thức căn bản
Distributed Transaction
Problem
• Là vấn đề đòi hỏi đảm bảo tính nhất quán của dữ
liệu trên môi trường phân tán
• Có sự th...
Data Sources
Database
Service
Write
Caching
Message
Queue
External
Service
Các data source đa dạng
Phải đảm bảo dữ liệu gi...
Transaction
Transaction phải đảm bảo tính ACID:
• Atomic: phải đảm bảo thực thi tất cả hoặc không
gì
• Consistency: đảm bả...
Disitributed Transaction in
Microservice
• Hệ thống chia nhỏ thành các Microservice rất nhỏ
• Phải đảm bảo dữ liệu tất cả ...
CAP Theorem
• Consistency
• Avalaibility
• Partition Tolerant
Một hệ thống phân tán chỉ có
thể đạt được 2 trên ba tính
chấ...
CAP Theorem
• Consistency: Đảm bảo dữ liệu giữa các node là
nhất quán
• Availabiilty: đảm bảo tính available của hệ thống
...
CAP Theorem
in Microservice
Nói chung Microservice chỉ có thể đảm bảo hai tính
chất:
• Avaialability
• Partition Tolerance...
Consistency
vs Eventually Consistency
• Consistency: đảm bảo tính nhất quán của dữ
liệu. Tại mọi thời điểm trên hệ thống d...
Microservice
• Đánh đổi Consistency bằng tính chất Avalaibility
và Partition Tolerance
• Không consistency nhưng phải đảm ...
Phần 2:
Giải pháp
Replicate Model
• Primary Data Backup
• State Machine Model
(Active Active Model)
Replicate Model
• VD: để thay đổi dữ liệu tồn kho khi mua bán và
xuất nhập. Ban đầu có 10. Bán đi 2, nhập vào 5,
bán đi 7....
Replicate Model
• Luôn đảm bảo ghi log các quá trình thay đổi
• Gửi các thay đổi đúng thứ tự và ổn định
Problems in Microservice
Database
Service
Write
Caching
Message
Queue
External
Service
Không có bất cứ cách nào
đảm bảo vi...
Problems in Microservice
• Các kịch bản lỗi:
• Ghi dữ liệu nhưng không gọi được service khác
• Gọi được serivce khác nhưng...
Solutions
• Đảm bảo chỉ thay đổi dữ liệu bắt đầu ở một nguồn.
Không đồng thời thay đổi dữ liệu của tất cả các nguồn.
• Tiế...
Phần 3:
Implementations
1. Log
• Log là phương thức chính và quan trọng nhất để
giải quyết vấn đề replicate dữ liệu trong hệ thống
phân tán
• Xây ...
1. Log
Service
Business
Data
Log
Data
Đảm bảo
transaction
BackGround
Worker
Other Service
Caching
Message
Queue
Other Data...
2. Event Sourcing Pattern
Lưu trữ các thay đổi
dưới dạng log event
Gửi các event tới
các nguồn đích
3. Saga Pattern
Xây dựng cơ chế log
để theo dõi các bước
thực thi
Thực hiện roll back
khi các bước bị lỗi
4. CDC
Capture Data Change
• Bắt trực tiếp các thay đổi Database để replicate
thay đổi tới các data source khác nhau. VD:
...
5. Message Queue
5. Message Queue
• Sử dụng message queue là nền tảng tích hợp
bất đồng bộ chính cho toàn bộ các service
• Loại bỏ việc gọi...
6. Integration Model
6. Integration Model
Log:
• Đảm bảo các dữ liệu cần gửi đi được lưu trữ ổn định. Đảm bảo business data và log data luôn đư...
7. Consistency
Requirements
• Trong ba yếu tố CAP, liệu AP có thể thoả mãn mọi trường hợp?
• Trong trường hợp bắt buộc đòi...
Phần 4
Một số case study
1. Đặt hàng
• Kịch bản: có hai serivce, catalog service quản lý
dữ liệu sản phẩm, order service quản lý đơn
hàng. Khi đặt ...
Solution
Order
Service
Catalog
Service
1. Gửi request giữ tồn (Sync)
Database
2. Place Order
Message Queue
3. Gửi một lệnh...
2. Bài toán trừ tiền
• Kịch bản: có hai service là order service và
payment service. Payment service chứa thông
tin tiền ả...
Solutions
Order
Service Catalog
Service
1. Gửi request giữ tiền (Sync)
Database
2. Place Order
Request Queue
3. Gửi một lệ...
3. Bài toán tính tiền gói hàng
• Kịch bản: giả sử một khách hàng mua 2 sản phẩm trị giá 200k, mỗi món
100k. Đã trả trước 1...
Analysis
Khó khăn:
• Muốn consistency phải gộp hai service làm một
—> Ảnh hưởng tới thiết kế tổng thể.
• Hệ thống không th...
Solution
• Dùng nghiệp vụ giải quyết: ghi nhận lỗi và hoàn
tiền cho khách hàng qua tài khoản ngân hàng
—-> và thống thiết ...
Conclusions
• Khi phân chia hệ thống phải đảm bảo dữ liệu là eventually
consistency
• Cơ bản không có transaction giữa các...
Thank you!
Nächste SlideShare
Wird geladen in …5
×

Distributed Transaction in Microservice

17.539 Aufrufe

Veröffentlicht am

There's no transaction in Microservice. How to guaranteen consistency data in system.

Veröffentlicht in: Ingenieurwesen
  • Girls for sex in your area are there: tinyurl.com/areahotsex
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/btUvO ◀ ◀ ◀ ◀
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Sex in your area is here: www.bit.ly/sexinarea
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Dating for everyone is here: www.bit.ly/2AJerkH
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Sex in your area for one night is there tinyurl.com/hotsexinarea Copy and paste link in your browser to visit a site)
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

Distributed Transaction in Microservice

  1. 1. Distributed Transaction in Microservice Lê Minh Nghĩa Solution Architect at Tiki.Vn
  2. 2. Contents 1. Distributed Transaction Problem. 2. CAP Theorem 3. Replicate Model 4. Consistency and Eventually Consistency 5. Implementation 6. Case Study
  3. 3. Phần 1. Các kiến thức căn bản
  4. 4. Distributed Transaction Problem • Là vấn đề đòi hỏi đảm bảo tính nhất quán của dữ liệu trên môi trường phân tán • Có sự tham gia nhiều hơn một data source vào một quá trình xử lý
  5. 5. Data Sources Database Service Write Caching Message Queue External Service Các data source đa dạng Phải đảm bảo dữ liệu giữa các nguồn nhất quán
  6. 6. Transaction Transaction phải đảm bảo tính ACID: • Atomic: phải đảm bảo thực thi tất cả hoặc không gì • Consistency: đảm bảo nhất quán dữ liệu • Isolation: đảm bảo vấn đề tranh chấp • Duration: dữ liệu phải được lưu trữ ổn định
  7. 7. Disitributed Transaction in Microservice • Hệ thống chia nhỏ thành các Microservice rất nhỏ • Phải đảm bảo dữ liệu tất cả các service phải nhất quán • Các service hầu hết là các restful service • Microservice là một hệ thống phân tán mức độ cao • Về cơ bản: không có Transaction trong kiến trúc Microservice!
  8. 8. CAP Theorem • Consistency • Avalaibility • Partition Tolerant Một hệ thống phân tán chỉ có thể đạt được 2 trên ba tính chất trên
  9. 9. CAP Theorem • Consistency: Đảm bảo dữ liệu giữa các node là nhất quán • Availabiilty: đảm bảo tính available của hệ thống khi một số node không available • Partition Tolerance: đảm bảo khả năng hoạt động khi mạng giữa các node không ổn định
  10. 10. CAP Theorem in Microservice Nói chung Microservice chỉ có thể đảm bảo hai tính chất: • Avaialability • Partition Tolerance Microservice không đảm bảo consistency giữa các node trên toàn bộ hệ thống!
  11. 11. Consistency vs Eventually Consistency • Consistency: đảm bảo tính nhất quán của dữ liệu. Tại mọi thời điểm trên hệ thống dữ liệu phải nhìn nhất quán giữa tất cả các node. • Eventually Consistency: đảm bảo dữ liệu giữa các hệ thống sẽ nhất quán sau một khoảng thời gian nhất định. • Microservice chỉ có thể đảm bảo dữ liệu là Eventually Consistency
  12. 12. Microservice • Đánh đổi Consistency bằng tính chất Avalaibility và Partition Tolerance • Không consistency nhưng phải đảm bảo là eventually consistency giữa các service
  13. 13. Phần 2: Giải pháp
  14. 14. Replicate Model • Primary Data Backup • State Machine Model (Active Active Model)
  15. 15. Replicate Model • VD: để thay đổi dữ liệu tồn kho khi mua bán và xuất nhập. Ban đầu có 10. Bán đi 2, nhập vào 5, bán đi 7. Cần replicate dữ liệu đi các nguồn: • Primary Backup: 8, 13, 6 • State Machine: -2, + 5, -7
  16. 16. Replicate Model • Luôn đảm bảo ghi log các quá trình thay đổi • Gửi các thay đổi đúng thứ tự và ổn định
  17. 17. Problems in Microservice Database Service Write Caching Message Queue External Service Không có bất cứ cách nào đảm bảo việc ghi dữ liệu đồng thời nhiều nguồn dữ liệu thoả mãn tính chất của một transaction
  18. 18. Problems in Microservice • Các kịch bản lỗi: • Ghi dữ liệu nhưng không gọi được service khác • Gọi được serivce khác nhưng không ghi được dữ liệu
  19. 19. Solutions • Đảm bảo chỉ thay đổi dữ liệu bắt đầu ở một nguồn. Không đồng thời thay đổi dữ liệu của tất cả các nguồn. • Tiến hành replicate các thay đổi một cách ổn định tới các nguồn đích • Triển khai hệ thống log để đảm bảo quá trình replicate là ổn định. • Mục tiêu: đảm bảo dữ liệu giữa các hệ thống là Eventually Consistency
  20. 20. Phần 3: Implementations
  21. 21. 1. Log • Log là phương thức chính và quan trọng nhất để giải quyết vấn đề replicate dữ liệu trong hệ thống phân tán • Xây dựng cấu trúc log, lưu trữ các thay đổi muốn gửi đi và gửi bất đồng bộ tới nguồn đích • Đảm bảo transation giữa business data và log data • Xoá bỏ log sau khi gửi đi
  22. 22. 1. Log Service Business Data Log Data Đảm bảo transaction BackGround Worker Other Service Caching Message Queue Other Data Sources
  23. 23. 2. Event Sourcing Pattern Lưu trữ các thay đổi dưới dạng log event Gửi các event tới các nguồn đích
  24. 24. 3. Saga Pattern Xây dựng cơ chế log để theo dõi các bước thực thi Thực hiện roll back khi các bước bị lỗi
  25. 25. 4. CDC Capture Data Change • Bắt trực tiếp các thay đổi Database để replicate thay đổi tới các data source khác nhau. VD: • MySQL: decode file binlog • Mongo: sử dụng cơ chế oplog
  26. 26. 5. Message Queue
  27. 27. 5. Message Queue • Sử dụng message queue là nền tảng tích hợp bất đồng bộ chính cho toàn bộ các service • Loại bỏ việc gọi api chéo giữa các service • Tăng khả năng availability của hệ thống • Giảm thiểu chi phí maitain khi chỉ cần đảm bảo message queue available. Các Service không cần available tại cùng một thời điểm
  28. 28. 6. Integration Model
  29. 29. 6. Integration Model Log: • Đảm bảo các dữ liệu cần gửi đi được lưu trữ ổn định. Đảm bảo business data và log data luôn được lưu trữ ổn định. Background Worker: • Đảm bảo quá trình gửi dữ liệu từ log tới message queue ổn định: chắc chắn gửi được và gửi đúng thứ tự. Message Queue: • Đảm bảo gửi message tới các nguồn dữ liệu đích • Đảm bảo các message được delivery đúng thứ tự gửi vào • Đảm bảo các message được persistent không bị mất • Kafka và Windows Service Bus là các giải pháp tốt nhất Các Data Source khác: • Trực tiếp nhận message từ queue • Chú ý việc chống trùng lặp message (Idempotemcy filtering)
  30. 30. 7. Consistency Requirements • Trong ba yếu tố CAP, liệu AP có thể thoả mãn mọi trường hợp? • Trong trường hợp bắt buộc đòi hỏi Consistency cần phải đánh giá lại mô hình: 1. Liệu việc chia service đã hợp lý hay chưa? Thông thường sẽ không chia nếu dữ liệu bắt buộc phải strong consistency. 2. Có thể điều chỉnh nghiệp vụ được không? Có trade off được giữa đòi hỏi tính nhất quán và khả năng mở rộng không? 3. Có thể triển khai SOAP để handle distributed transaction không? 4. Có thể cài đặt two phase commit để handle distributed transaction không?
  31. 31. Phần 4 Một số case study
  32. 32. 1. Đặt hàng • Kịch bản: có hai serivce, catalog service quản lý dữ liệu sản phẩm, order service quản lý đơn hàng. Khi đặt hàng thì trừ đi một lượng sản phẩm nhất định rồi tạo đơn hàng. • Risk: có thể trừ số lượng sản phẩm mà không tạo được đơn hàng
  33. 33. Solution Order Service Catalog Service 1. Gửi request giữ tồn (Sync) Database 2. Place Order Message Queue 3. Gửi một lệnh trừ tồn 4. Nếu không nhận được lệnh trừ tồn thì sau một khoảng thời gian nhất định thì rollback lại số lượng tồn.
  34. 34. 2. Bài toán trừ tiền • Kịch bản: có hai service là order service và payment service. Payment service chứa thông tin tiền ảo của người dùng. Tiền ảo trừ được thì đơn hàng được đặt. • Risk: tiền trừ mà đơn hàng không đặt được
  35. 35. Solutions Order Service Catalog Service 1. Gửi request giữ tiền (Sync) Database 2. Place Order Request Queue 3. Gửi một lệnh trừ tiền 5. Nếu không nhận được lệnh trừ tiền thì sau một khoảng thời gian nhất định thì rollback lại tiền cho người dùng Response Queue 4. Gửi response
  36. 36. 3. Bài toán tính tiền gói hàng • Kịch bản: giả sử một khách hàng mua 2 sản phẩm trị giá 200k, mỗi món 100k. Đã trả trước 150k, hàng được chia làm hai gói, giao hai lần. Cần thu khách hàng thêm 50k. • Lần 1 đi giao món thứ nhất, không phải thu gì. Đã trừ 100k vào số tiền đã trả. Số tiền khách hàng còn là 50k. • Lần 2 đi giao nốt món còn lại và thu 50k. • Điều gì sẽ xảy ra nếu ngay món hàng 2 xuất giao, thì món hàng thứ nhất bị giao lỗi và phải cập nhật lại số tiền của khách hàng? Kịch bản hợp lý nhất: khách hàng không phải trả thêm tiền. • Nếu hệ thống được chia làm hai service: service để quản lý hàng tại trạm và service quản lý hàng đi giao. Trong trường hợp này handle consistency kiểu gì?
  37. 37. Analysis Khó khăn: • Muốn consistency phải gộp hai service làm một —> Ảnh hưởng tới thiết kế tổng thể. • Hệ thống không thể đảm bảo khi quy trình đã không consistency. VD: nhân viên giao nhận thứ nhất vừa về thì nhân viên thứ hai đã đi, cả hai còn chưa kịp cập nhật qua máy tính.
  38. 38. Solution • Dùng nghiệp vụ giải quyết: ghi nhận lỗi và hoàn tiền cho khách hàng qua tài khoản ngân hàng —-> và thống thiết gọi xin lỗi khách hàng :(((
  39. 39. Conclusions • Khi phân chia hệ thống phải đảm bảo dữ liệu là eventually consistency • Cơ bản không có transaction giữa các data source khác nhau • Không đồng thời ghi dữ liệu vào nhiều nguồn khác nhau. • Lưu trữ log để đẩy các thay đổi một cách ổn định sang các data source khác • Nên sử dụng message queue là nền tảng chính cho việc tích hợp bất đồng bộ giữa các service. Hạn chế sử dụng gọi chéo api. • Đánh giá việc phân chia service phù hợp với đòi hỏi về consistency dữ liệu.
  40. 40. Thank you!

×