3. Bố cục của luận văn
2.2.4. Nghi thức thỏa thuận ba pha (Three-phase commit – 3PC)
Nghi thức thỏa thuận hai pha như đã trình bày ở trên không tránh được tình trạng phong tỏa (Blocked), dù rằng nó làm giảm đi xác suất phong tỏa do những điều kiện sinh ra bởi sơ đồ của nghi thức thỏa thuận đơn giản. Không có sơ đồ nào có thể tránh được phong tỏa (hoặc tệ hơn là nó sẽ làm cho các thành viên đưa ra những quyết định thỏa thuận/ hủy bỏ khác nhau) trong những tình huống mạng bị mất liên lạc. Tuy nhiên có thể làm giảm bớt những trường hợp xảy ra phong tỏa bằng cách thêm một pha nữa vào quá trình thỏa
thuận tạo thành nghi thức thỏa thuận ba pha (được thể hiện trong hình 2.10 và 2.11)
So với thỏa thuận hai pha, ngoài hai thông báo là commit và abort thì 3PC còn có thêm một thông báo thứ ba là prepare-commit (thông báo được điều phối viên gửi đi trước khi gửi thông báo commit) báo cho mọi thành viên biết rằng tất cả đều muốn thỏa thuận. Khi nhận được thông báo prepare-commit các thành viên sẽ không thỏa thuận ngay mà sẽ gửi thông báo ready-commit để xác nhận đã nhận được prepare-commit từ điều phối viên gửi đến. Trong pha thứ ba, điều phối viên thu thập tất cả các thông báo, và khi đã nhận được tất cả, nó gửi thông báo commit đến tất cả các thành viên để báo rằng tất cả đều đồng ý thỏa thuận, lúc đó các thành viên sẽ thực hiện thỏa thuận.
Để tránh được phong tỏa như trong thỏa thuận hai pha, ta giả sử thỏa thuận ba pha thỏa mãn những giả thiết sau:
1. Chỉ có nút bị sự cố và mạng không bao giờ bị tách thành hai hoặc nhiều nhóm nút vẫn còn hoạt động (nút sống) nhưng không liên lạc được với các nhóm khác.
2. Khi một nút bị sự cố, nó sẽ không thể liên lạc được. Nó không thể gửi các thông báo sai lạc (chẳng hạn gửi abort trong khi đáng lẽ phải gửi commit) và không gửi một số thông báo trong khi lại bỏ những thông báo khác.
3. Khi một nút bị sự cố, đối với một giao dịch, nó trở thành một người “ngoài cuộc” trong khoảng thời gian thực hiện thỏa thuận. Nghĩa là, một nút bị sự cố sẽ biết rằng nó đã gặp sự cố khi được khôi phục, vì vậy nó không tái tham dự vào các quá trình thỏa thuận nếu trước tiên nó không thông báo chính nó cho các nút khác biết và biết được điều gì đã xảy ra.
4. Một nút không bị sự cố sẽ phải trả lời các yêu cầu trong một khoảng thời gian quá hạn được dùng để phát hiện nút bị sự cố.
5. Mạng sẽ không làm mất các thông báo, và nó phân phối các thông báo từ nút A đến nút B theo thứ tự chúng được nhận.
Phiên bản này bỏ qua thông báo xác nhận readly- commit trong pha thứ hai do không cần thiết. Tuy nhiên, cài đặt thuật toán vẫn có thể sử dụng thông báo xác nhận đó bởi vì nó ngăn được một số sự cố khác, chẳng hạn như làm thất lạc các thông báo.
Hình 2.10 hình thức hóa các thảo luận về nghi thức thỏa thuận, có thêm một pha thứ ba để xác định rằng tất cả các thành viên đều biết về ý định thỏa thuận của mọi thành viên khác. Trong hình 2.9 là những bước chuyển trạng thái của các thành viên. Chúng ta lược bỏ tình huống xảy ra khi chuyển đến trạng thái Recover; chúng sẽ được mô tả riêng. Hình 2.10 trình bày các bước chuyển của điều phối viên.
Trong pha 1, điều phối viên sẽ gửi thông báo begin-vote đến tất cả các thành viên, và mỗi thành viên sẽ biểu quyết giống y như thỏa thuận hai pha. Pha 2 và 3 chỉ xảy ra nếu điều phối viên nhận được vote-commit từ tất cả các thành viên. Trong pha 2, điều phối viên gửi prepare- commit đến tất cả các thành viên, và trong pha 3, điều phối viên gửi commit, và các thành viên khi nhận được commit sẽ thỏa thuận.
Có rất nhiều vị trí có thể xảy ra sự cố, làm cho một hoặc nhiều thông báo không được nhận. Giống như với thỏa thuận hai pha, một thành viên đang chờ một thông báo sẽ đánh dấu quá hạn sau một giai đoạn đủ dài để chắc chắn rằng thành viên bên gửi đã gặp sự cố. Trước tiên, các thành viên có thể không nhận được thông báo begin-vote của điều phối viên. Theo như hình 2.9, một thành viên như thế chỉ cần hủy bỏ.
Hình 2. 11. Sơ đồ trạng thái của điều phối viên trong thỏa thuận ba pha
Vị trí thứ hai có thể xảy ra một quá hạn là khi một điều phối viên đang đợi các biểu quyết. Nếu có một biểu quyết nào đó không đến trong khoảng thời gian hạn định thì giống như thỏa thuận hai pha, điều phối viên sẽ quyết định hủy bỏ giao dịch.
Thứ ba, một thành viên đang muốn thỏa thuận có thể đánh dấu quá hạn do đợi thông báo prepare- commit hoặc abort. Nếu như thế, nó chuyển qua trạng thái Recover sẽ đánh được mô tả riêng.
Vị trí cuối cùng có thể xảy ra quá hạn là khi một thành viên đang ở trong trạng thái Readly- to- commit không nhận được thông báo commit của điều
phối viên. Trong tình huống này, nó cũng chuyển sang trạng thái Recover, ở đó các giao dịch còn sống sẽ giải quyết vấn đề này.
Điểm mấu chốt trong thỏa thuận ba pha đó là điều phối viên phải gửi tất cả các thông báo prepare-commit đi trước khi gửi bất kỳ thông báo commit nào. Lý do là prepare-commit thông tin cho các thành viên biết rằng tất cả đều muốn thỏa thuận. Nếu thành viên Ti nhận được commit, nó biết rằng điều phối viên đã gửi đến tất cả các thành viên thông báo prepare-commit, vì vậy mỗi thành viên còn sống đều nhận được thông báo prepare-commit hoặc chuẩn bị nhận nó, bởi vì thông báo có thể đến trễ nhưng không thể thất lạc trong mạng. Nghĩa là việc Ti nhận được commit đã cho Ti biết rằng tất cả mọi thành viên đều đã biết rằng mọi thành viên đều muốn thỏa thuận.
Để rõ hơn về trạng thái của thành viên và điều phối viên trong sơ đồ trên ta bổ sung thêm bổ đề như sau:
Bổ đề 2.1: Trước khi các giao dịch chuyển sang trạng thái phục hồi (Recover), và theo giả thiết rằng các thông báo được phân phối ngay lập tức, các trạng thái sau không tương thích với nhau:
a. Một thành viên (còn sống hoặc bị sự cố) không thể chuyển sang trạng thái Commited trong khi có một thành viên còn sống khác vẫn còn trong trạng thái Willing- to- commited.
b. Một thành viên (còn sống hoặc gặp sự cố) không thể chuyển sang trạng thái Abort trong khi có một thành viên khác (còn sống hoặc gặp sự cố) đã chuyển sang trạng thái Commited, hoặc một thành viên còn sống đã chuyển sang trạng thái Readly- to- commit.