Starbucks không thực hiện two-phase commit
Software Engineering
38
White

Ngoc Dao viết ngày 23/03/2016

Nhiều năm trước, tôi làm việc cho một ISP khi ISP này đang đưa ra một dịch vụ DSL mới. Tất nhiên, họ không trực tiếp cung cấp dịch vụ này. Họ cần xe tải, kĩ thuật viên, dây nối và các thứ lằng nhằng khác. Họ chỉ đơn thuần bán lại dịch vụ DSL của công ty Covad. Công ty Covad này lại phụ thuộc rất nhiều vào một đối tác đến từ một công ty điện thoại địa phương là một công ty chỉ muốn Covad chết, chết và chết! Tuy nhiên điều ấn tượng nhất với tôi là thủ tục đăng kí của công ty này hết sức phức tạp. Các anh chàng của chúng ta trưng những tấm poster rất lơn, với những biểu đồ vô cùng phức tạp mà dưới cách nhìn nhận của một programmer, tôi thấy có khá nhiều "bug". Những người cung cấp dịch vụ đã thiết kế thủ tục đăng kí như những người thật tử tế, nhưng không phải như lập trình viên. Họ không biết gì về exception handling, asynchronous processing, two-phase commit, multithreading, và ngay cả mệnh đề “if”. Nhan đề của bài này ngay lập tức thu hút được sự chú ý của tôi. Là một programmer, tôi thích diễn tả các tình huống trong cuộc sống bằng các khái niệm trong lập trình hay các phép ẩn dụ trong kiến trúc phần mềm.

Trong thực tế, tôi nghĩ cần chú ý hơn tới sự tương đồng giữa việc thiết kế các công việc kinh doanh (business process design) với kiến trúc phần mềm (software architecture). Tôi nghĩ các công việc kinh doanh hiện đại phức tạp đến mức cần phải có các kĩ năng về kiến trúc phần mềm để có thể xoay xở được. Cụ thể là lí do mà các công ty điện thoại cung cấp dịch vụ khách hàng quá tệ đơn giản là vì người thiết kế các thủ tục này chẳng hiểu gì về khái niệm two-phase commit. Thế là bạn phải chờ 15 phút, sau đó mất thêm 25 phút với một gã đần chả giúp giải quyết được gì để rồi cuối cùng anh ta chuyển bạn tới gặp cấp trên và ... click, chuông reo.

Hotto Cocoa o Kudasai

Tôi vừa trở về sau chuyến đi hai tuần tới Nhật Bản. Một hình ảnh quen thuộc ở đây là số lượng rất lớn các cửa hàng cà phê Starbucks® đặc biệt là xung quanh khu Shinjuku Roppongi. Trong khi chờ đợi "Hotto Cocoa,” (ca cao nóng), tôi bắt đầu nghĩ về qui trình phục vụ của Starbucks. Starbucks, cũng như các công ty khác, muốn throughput of orders (thông lượng yêu cầu) cao nhất bởi càng nhiều yêu cầu thì càng nhiều doanh thu. Đó là lí do tại sao họ dùng asynchronous processing: Khi bạn đưa ra yêu cầu, thủ quĩ đánh dấu chiếc cốc với yêu cầu của bạn và đưa nó vào queue (hàng chờ). Queue thực ra là một dãy các chiếc cốc xếp trên chiếc máy pha cà phê. Hàng đợi này tách người thủ quĩ với barista (người pha cà phê) giúp cho người thủ quĩ có thể tiếp tục nhận yêu cầu ngay cả khi barista đang bị chất đống bởi một hàng chờ. Nó cũng giúp họ deploy (thực thi) multiple baristas trong “Competing Consumer” nếu cửa hàng trở nên đông đúc.

Sự tương quan

Khi lợi dụng các ưu thế của asynchronous approach, Starbucks cũng phải giải quyết các thách thức của phương pháp này. Ví dụ như sự tương quan (correlation). Đồ uống được hoàn thành không đúng với thứ tự được yêu cầu. Có thể có hai lí do. Thứ nhất, nhiều barista (multiple baristas) cùng thực hiện các yêu cầu với các dụng cụ khác nhau. Các đồ uống hỗn hợp có thể lâu hơn cà phê phin chẳng hạn. Thứ hai, barista có thể làm nhiều thứ giống nhau một lần để tối ưu hóa qui trình (optimize processing time). Kết quả là Starbucks mắc phải vấn đề tương quan (correlation problem). Đồ uống được phân phối (delivered) không đúng thứ tự và cần phải được đưa tới đúng khách hàng. Starbucks giải quyết vấn đề này bằng “pattern” mà chúng ta sử dụng trong kiến trúc truyền tin (messaging architectures) - học sử dụng Bộ xác định tương quan (Correlation Identifier). Ở Mĩ, hầu hết các cửa hàng Starbucks sử dụng bộ xác định tương quan rõ ràng (explicit correlation identifier) bằng cách viết tên bạn lên cốc và gọi lên khi đồ uống hoàn thành. Ở các nước khác, bạn có thể được tương quan với loại đồ uống.

Exception Handling

Xử lí lỗi trong asynchronous messaging có thể khó khăn. Vì thế giới thực viết nên những câu chuyện hay nhất nên chúng ta có lẽ sẽ học được gì đó khi xem xét cách mà Starbucks giải quyết các vấn đề (exception). Họ sẽ làm gì nếu bạn không có đủ tiền trả? Họ sẽ vứt đồ uống của bạn đi nếu nó đã được làm xong hoặc pull (vứt) nó ra khỏi “queue” (hàng đợi). Nếu họ đưa đúng thứ đồ uống của bạn hoặc thứ đó dở thì họ sẽ làm lại. Nếu máy pha cà phê hỏng và họ không thể làm đồ uống phục vụ bạn thì họ sẽ trả lại tiền cho bạn. Các kịch bản sau miêu tả các phương pháp xử lí lỗi (error-handling) phổ biến:

  • Write-off. Đây là cách đơn giản nhất: chả làm gì hết, vứt tất cả những thứ hỏng đã làm. Nghe có vẻ là một cách tồi, nhưng trong thực tế công việc thì đây cũng có khi lại là một lựa chọn chấp nhận được. Chẳng hạn như một số ISP tôi làm việc sử dụng phương pháp này khi có xung đột trong chu trình cung cấp/tính tiền. Kết quả là có thể có những khách hàng được phép sử dụng dịch vụ mà chưa được tính tiền. Thiệt hại ở đây là đủ nhỏ để sử dụng phương án này. Thường kì, họ chạy reconciliation reports để xác định và cắt các “free” accounts này.
  • Retry. Khi một qui trình khá lớn (ví dụ: “transaction”) thất bại, ta có hai lựa chọn: undo tất cả những gì đã thực hiện hoặc retry công việc thất bại. Retry là một lựa chọn hợp lí nếu có khả năng thành công. Ví dụ, nếu như một business rule bị xung đột thì có vẻ như retry không hiệu quả. Tuy nhiên, nếu hệ thống bên ngoài không sẵn sàng, retry có thể thành công.
  • Compensating action. Lựa chọn cuối cùng là undo cả các operations đã hoàn thành để đưa hệ thống về một trạng thái ổn định. “Compensating actions” rất tốt trong trường hợp ở hệ thống tài chính, ta có thể được trả lại (re-credit) khoản tiền đã được ghi nợ.

Các phương pháp trên đều khác phương pháp two-phase commit. Trong ví dụ về Starbucks, một two-phase commit có nghĩa là chờ ở quầy thu ngân cho tới nước được pha xong. Sau đó bạn "tiền trao cháo múc" với người thu ngân. Người thu ngân và khách hàng không được đi đâu cho tới khi “transaction” hoàn tất. Sử dụng giải pháp như thế chắc chắn sẽ làm Starbucks sập tiệm. Bởi vì số khách hàng được phục vụ sẽ giảm đi rất nhiều. Ví dụ này nói lên rằng mặc dù two-phase commit có thể làm cho cuộc sống của chúng ta đơn giản hơn rất nhiều nhưng nó có thể ngăn cản dòng chảy của thông điệp (the free flow of messages) bởi vì nó phải duy trì stateful transaction cho dòng chảy các hành động phức tạp và không đồng bộ (multiple, asynchronous actions).

Hội thoại

Tương tác ở cửa hàng cà phê cũng là một ví dụ tốt của conversation pattern. Tương tác giữa hai bên (khách hàng và cửa hàng) bao gồm các tương tác ngắn đồng bộ (short synchronous interaction) như gọi nước, trả tiền, .. và các tương tác dài, không đồng bộ (long, asynchronous interaction) như làm và nhận đồ uống. Kiểu hội thoại này khá phổ biến trong kịch bản mua hàng. Ví dụ, khi bạn gửi một yêu cầu lên Amazon, một tương tác ngắn gắn cho nó một số thứ tự (order number) và các bước tiếp theo (thanh toán, đóng gói, chuyển hàng) được thực hiện một cách không đồng bộ. Bạn được thông báo qua email (asynchronous) khi các bước này hoàn tất. Nếu có sự cố gì đó, thường thì Amazon sẽ compensate (trả lại tiền đã thanh toán) hoặc retry (gửi lại món hàng).

Kiến trúc của cuộc sống

Tóm lại, có thể thấy rằng thế giới của chúng ta không đồng bộ. Cuộc sống hàng ngày bao gồm những tương tác phối hợp không đồng bộ (đọc và trả lời email, mua cà phê, ..) Có nghĩa là kiến trúc thông điệp không đồng bộ (asynchronous messaging architecture) có thể được sử dụng để mô hình hóa các bước của các tương tác trong cuộc sống. Và chúng ta có thể nhìn vào cuộc sống hàng ngày để tìm ra giải pháp thiết kế cho các vấn đề thông tin. Domo arigato gozaimasu!

Chú thích:

  • Hotto cocoa o kudasai: tiếng Nhật (ホットココアをください) nghĩa là làm ơn cho một ca cao nóng.
  • Roppongi và Shinjuku: hai khu vui chơi nổi tiếng của Nhật.
  • Domo arigato gozaimasu: tiếng Nhật (どうも ありがとう ございます)nghĩa là xin cảm ơn rất nhiều.

Tác giả: Gregor Hohpe.
Nguồn: The best software writting I.

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Ngoc Dao

102 bài viết.
300 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
66 8
Làm thế nào để nâng cấp trang web mà không làm gián đoạn dịch vụ? Đây là câu hỏi phỏng vấn các công ty lớn thường hỏi khi bạn xin vào vị trí làm lậ...
Ngoc Dao viết hơn 2 năm trước
66 8
White
42 1
Bài viết này giải thích sự khác khác nhau giữa hai ngành khoa học máy tính (computer science) và kĩ thuật phần mềm (software engineering), hi vọng ...
Ngoc Dao viết hơn 2 năm trước
42 1
White
38 2
Nếu là team leader, giám đốc công ty hay tướng chỉ huy quân đội, vấn đề cơ bản bạn gặp phải là “hướng mọi người đi theo con đường bạn chỉ ra”. Thử...
Ngoc Dao viết hơn 2 năm trước
38 2
Bài viết liên quan
White
1 1
Lập trình đôi (pair programming) là hình thức lập trình trong đó 2 người cùng hợp tác làm việc trên cùng màn hình (có thể khác bàn phím v.v.). Bài ...
Ngoc Dao viết hơn 2 năm trước
1 1
White
32 4
Như thường lệ, là chuyên mục quảng cáo, bài viết được đăng lại từ https://thefullsnack.com/posts/frameworkorlibrary.html Hôm nay mình nghe podca...
Huy Trần viết 1 tháng trước
32 4
White
7 1
Trong quyển sách Beyond Java, xuất bản vài năm trước có đoạn:Java has characteristics that many of us take for granted. You can find good Java deve...
Ngoc Dao viết hơn 2 năm trước
7 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
102 bài viết.
300 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!