Hệ thống Phân tán

Distributed Systems
II. Các vấn đề cơ bản
Đồng bộ thời gian
1. Giới thiệu
 Thời gian, đồng hồ là vấn đề cần quan tâm trong các hệ thống phân tán
 Thường cần đo thời gian: thời gian xảy ra sự kiện, thời gian giao dịch, ..
 Các cơ chế, thuật toán cần đồng hồ xác định thời gian: timestamp,

 Với hệ thống tập trung:

 Thời gian dựa vào máy chủ
 cần thời gian => gửi yc tới hệ thống
 thời gian ghi nhận yêu cầu xuất hiện theo đúng thứ tự gọi
 Hệ thống phân tán
 vấn đề phức tạp hơn
 Mô hình
 hệ phân tán có N tiến trình, mỗi tiến trình chạy trên 1 CPU
 CPU không chia sẻ bộ nhớ
 các tiến trình trao đối: chỉ qua message passing
 Mỗi process: có thể ở 1 trong P trạng thái (rời rạc)
 Process:
 thực hiện dãy tác vụ: có thể là send, receive, hay thay đổi trạng thái
 sự kiện: tương ứng với tác vụ (send/receive/change state)
 lịch sử: các sự kiện theo thứ tự thời gian
2. Đồng hồ
 Các sự kiện xảy ra theo trình tự => nói chung cần gán nhãn thời gian -
timestamp
 Mỗi máy tính => có đồng hồ vật lý - bộ định thời gian
 cấu tạo: thường dựa trên dao động tinh thể thạch anh
 mỗi giao động => trừ dần giá trị reg, khi giá trị reg=0 => ngắt thời gian
 HĐH: từ giá trị đồng hồ vật lý => tính toán và cung cấp giá trị thời gian cho các
tiến trình
2. Đồng hồ
 Độ lệch và dung sai thời gian đồng hồ (clock skew, drift)
 Trong hệ phân tán: dao động trên các máy khác nhau có khác biệt => đồng hồ
dần không cùng một thời gian => dẫn đến sai lệch trong các tính toán thời gian

 các đồng hồ dựa trên giao động tinh thể thường có sai số khoảng 10-6
(1000000 giây - sai lệch 1 giây)
2. Đồng hồ
 Trong nhiều hệ thống phân tán, thời gian thực: đồng bộ đồng hồ giữa
các nút là quan trọng
 quy chuẩn về một múi giờ thời gian UTC (coordinated universal time)
 có thể đồng bộ với máy chủ thời gian NT server
 đồng hồ nguyên tử: sai số khoảng 10-13.

 Các tiến trình có đồng hồ của mình, và nhiều trường hợp cần bộ để phục vụ cho
các bài toán khác nhau, chẳng hạn ghi nhận nhật ký
 Trường hợp đồng bộ đồng hồ với một nguồn tin cậy => external synch
độ chính xác không quá D
 Các tiến trình có thể đồng bộ với nhau => internal synch
đồng bộ thời gian sai không quá D
2. Đồng hồ
 Đồng bộ trong hệ synch
 để ý: hệ synch: các sai lệch đồng hồ, thời gian truyền - bị chặn trên - dự tính đc
 Tiến trình p1 gửi message chứa thời gian t (local) tới p2
 p2 có thể đặt thời gian t+Ttran , Ttran - thời gian truyền message
 tuy nhiên: thời gian truyền có thể biến thiên
 với hệ synch: thời gian truyền này trong khoảng từ min tới max
 đặt u = max - min, p2 có thể thiết lập thời gian theo 1 số cách
 nếu đặt t + min => độ lệch có thể tới u = max-min (nếu Ttran = max)
 nếu đặt t + max => độ lệch có thể tới u = max-min (nếu Ttran = min)
 nếu đặt t + u/2 => độ lệch có thể tới u/2
2. Đồng hồ
 Đồng bộ với máy chủ tin cậy - phương pháp
Cristian (~ external synch)
 Cristian nhận thấy: mặc dù hệ là asynch, thời gian
round trip của 1 message cụ thể thường đủ ngắn
 Cristian đề xuất đồng bộ với máy chủ thời gian tin cậy

 máy client gửi yc mr tới máy chủ thời gian S

 máy server S trả lời thời gian chuẩn trong thông điệp mt
 client đo thời gian round trip Tr và đặt thời gian t+Tr/2
(với giả định thời gian đi và về bằng nhau)
2. Đồng hồ
 Đồng bộ giữa các nút trong hệ thống (Internal synch)
thuật toán Berkeley:
 Một máy điều phối - master. Các máy khác: slave
 Máy master định kỳ gửi thông điệp thời gian đến slave
 Các slave gửi thông tin thời gian local của mình tới master
 Master tính toán (có tính đến thời gian round trip) thời gian cần điều chỉnh của
từng slave,
 Master gửi giá trị cần
điều chỉnh tới từng slave

 Nếu master có sự cố -
sẽ bình chọn master mới
2. Đồng hồ
 Network time protocol - NTP
 Các thuật toán Cristian, Berkeley: thường dùng trong mạng nội bộ - intranet
 Với mạng Internet: thường dùng NTP
 NTP: cung cấp dịch vụ thời gian, đồng bộ với múi giờ UTC
 Hệ thống phân tán gồm nhiều máy chủ NTP
 Do có thể mất kết nối trong thời gian dài =>
có các máy chủ dự phòng, kết nối dự phòng
 Hệ nhiều máy chủ => đáp ứng số lượng lớn client
 An ninh => sử dụng xác thực => đảm bảo dữ liệu
đến từ nút tin cậy, kiểm tra địa chỉ gửi
2. Đồng hồ
 Network time protocol - NTP
 Hệ thống phân tán gồm nhiều máy chủ NTP
 Các server: tạo thành mạng đồng bộ
• primary (root): bậc 1
• secondary - bậc 2, và thấp hơn nữa
• Thời gian của các server bậc thấp hơn => chính xác hơn
 Đồng bộ thời gian: 3 chế độ
• multicast: thường cho LAN tốc độ cao, máy chủ gửi message broadcast có thời gian
• procedure-call: thủ tục như thuật toán Crisstian
máy chủ nhận msg từ máy khác và trả lời msg + t
thường dùng khi cần độ chính xác cao hơn &
kh hỗ trợ broadcast
• symmetric: server với server cấp cao hơn, cần chính xác hơn
3. Logical time & logical clock
 Nhiều khi không cần khớp thời gian thực tế mà chỉ cần khớp về thứ tự thời gian
=> logical clock
 Đồng hồ Lamport
 Quan hệ tương tự nhân quả: quan hệ xảy ra trước 
 sự kiện a xảy ra trước sự kiện b: a  b nếu
(H1) trong cùng tiến trình và a xảy ra trước b
(H2) khác tiến trình: a là sự kiện gửi msg, b là sự kiện nhận msg
(H3) bắc cầu: nếu a  b và b  c thì a  c
 Với 2 sự kiện e, e' : e  e' , khi đó ta có thể
tìm được chuỗi các sự kiện e1, e2, ..., en:
 e1 = e, en = e'
 và với ei , ei+1: xảy ra (H1) hoặc (H2)
3. Logical time & logical clock
 Logical clock
 Lamport đề xuất cơ chế biểu diễn quan hệ "xảy ra trước" bằng số - logical clock
 Logical clock:
 bộ đếm số nguyên chỉ tăng
 mỗi tiến trình pi có 1 logical clock Li , dược dùng để gán nhãn thời gian timestamp
 sự kiện e của tiến trình pi có nhãn thời gian Li (e), L(e): sự kiện xảy ra kh quan tâm ở
tiến trình nào
 Để thể hiện quan hệ xảy ra trước => tiến trình cập nhật logical clock:
 LC1: Li tăng trước khi thực hiện sự kiện ở tiến trình pi : Li = Li + 1
 LC2:
• Khi tiến trình pi gửi msg m , nó gắn kèm nhãn thời gian t = Li
• Khi tiến trình pj nhận đc (m,t), nó tính clock: Lj = max{t, Lj } và áp dụng luật LC1
trước khi gán nhãn thời gian cho sự kiện e-nhận đc msg m: receive(m)
3. Logical time & logical clock
 Logical clock
 LC1: Li tăng trước khi thực hiện sự kiện ở tiến trình pi : Li = Li + 1
 LC2:
• Khi tiến trình pi gửi msg m , nó gắn kèm nhãn thời gian t = Li
• Khi tiến trình pj nhận đc (m,t), nó tính clock: Lj = max{t, Lj } và áp dụng luật LC1
trước khi gán nhãn thời gian cho sự kiện e-nhận đc msg m: receive(m)
 Có thể thấy nếu e  e'  L(e) < L(e')
ngược lại, L(e) < L(e') chưa chắc đã có e  e'
3. Logical time & logical clock
 Nhãn thời gian xếp thứ tự toàn cục (Totally ordered Timestamp)
 Đồng hồ logical (Lampot) ở trên: có thể có 2 sự kiện ở 2 tiến trình khác nhau có
cùng giá trị
 Đôi khi mong muốn thứ tự tổng thể khác nhau
 Phương án: kết hợp số thứ tự tiến trình
 tiến trình pi có clock Ti => nhãn thời gian toàn cục (Ti , i)
 tiến trình pj có clock Tj => nhãn thời gian toàn cục (Tj , j)
 So sánh 2 nhãn thời gian:
nếu:
hoặc và
3. Logical time & logical clock
 Vector clock
 Vector lock của tiến trình trong hệ N tiến trình là vector N phần tử
 Tiến trình cập nhật clock theo các quy tắc:
VC1: ban đầu, tiến trình pi có clock Vi [j] = 0, j=1, .., N
VC2: trước khi pi gán nhãn thời gian, nó đặt Vi [i]= Vi [i]+1
VC3: tiến trình pi gửi kèm clock t=Vi trong mọi msg gửi đi: (m, t)
VC4: tiến trình nhận pj , khi nhận sẽ tính clock Vj trước khi gán nhãn cho sự kiện nhận:
Vj [k]= max{Vj [k], t [k]}
 Có thể thấy
 Vi [i] thể hiện số sự kiện mà tiến trình thứ i - pi đã gán nhãn
 Vi [j] (i <> j) thể hiện số sự kiện mà tiến trình thứ j - pj đã gán nhãn - có thể ảnh hưởng
đến tiến trình pi
 Vector clock
 Có thể so sánh 2 vector clock:
V=V'  V[i]=V'[i], i=1,..,n
V  V'  V[i]=V'[i], i=1,..,n
V < V'  V  V' và V  V'
4. Trạng thái toàn cục - Global state
 Với hệ thống phân tán: vấn đề xác định giá trị của các thông tin là cần thiết
 không chỉ liên quan đến trạng thái của các tiến trình
 mà còn liên quan đến trạng thái kênh truyền của hệ thống
ví dụ
 Garbage collection
 p1: 2 obj có ref (1 local, 1 remote-p2)
 p2: 2 obj kh có ref ở p2
• 1 obj có ref trong msg đang truyền
• 1 obj kh có ref ở p2 cũng như p1
 ...
4. Trạng thái toàn cục - Global state
 Trạng thái toàn cục và Lát cắt nhất quán
 trạng thái toàn cục của hệ: có thể xem là tập hợp trạng thái của các tiến trình và
kênh truyền
 về lý thuyết: tiến trình (và kênh truyền) có thể ghi nhận trạng thái riêng của
mình tại thời điểm t .
 nếu có thể đồng bộ thống nhất thời gian tuyệt đối, chúng ta có thể thiết lập các tiến
trình cùng ghi nhận trạng thái riêng tại thời điểm t. Và tổng hợp ta có trạng thái toàn
cục tại thời điểm t
 tuy nhiên kh đc do kh đồng bộ chính xác đồng hồ đc
4. Trạng thái toàn cục - Global state
 Trạng thái toàn cục và Lát cắt nhất quán
 Xét hệ phân tán có N tiến trình pi
 có thể đặc trưng việc thực thi của tiến trình qua lịch sử chuỗi các sự kiện của nó

 ta có thể xem xét một giai đoạn tiền sử - prefix của history

 sự kiện: như trên, có thể là xử lý pi hoặc gửi, nhập msg => ghi nhận trong history(pi)
 Trạng thái của tiến trình là trạng thái của pi ngay trước khi xảy ra sự kiện thứ k
kênh truyền có thể liên quan trạng thái hệ thống, tuy nhiên với việc ghi nhận sự kiện
gửi, và nhận tương ứng => ta có thể xác định msg m có thuộc trạng thái kênh truyền
 Lịch sử toàn cục của cả hệ thống là hợp của lịch sử các tiến trình
4. Trạng thái toàn cục - Global state
 Trạng thái toàn cục và Lát cắt nhất quán
 Lát cắt của tiến trình - mô tả sự kiện cuối cùng ghi lại cho mỗi tiến trình
 Lát cắt của hệ thống là tập con mô tả sự kiện cuối cùng
ghi lại cho mỗi tiến trình
 Trạng thái toàn cục của hệ thống - tương ứng tập các tiền sử-prefix của lịch sử
từng tiến trình
 Trạng thái si trong S (tương ứng lát cắt C) là tiến trình pi ngay sau khi xử lý sự
kiện cuối trong lát cắt
tập các sự kiện
gọi là ranh giới (frontier) của lát cắt C
4. Trạng thái toàn cục - Global state
 Trạng thái toàn cục và Lát cắt nhất quán
 Lát cắt nhất quán C: lát cắt mà
với sự kiện e, C chứa mọi sự kiện xảy ra
trước e:
 Sự kiện toán cục nhất quán:
sự kiện ứng với lát cắt nhất quán
 Ta có thể đặc trưng việc thực thi của hệ thống bằng chuỗi chuyển trạng thái toàn
cục
4. Trạng thái toàn cục - Global state
Coordination and agreement
Phối hợp và thỏa thuận
A. Loại trừ nhau
 Hệ thống phân tán =>
 Các tiến trình phối hợp xử lý
 Các tiến trình truy cập tài nguyên chia sẻ chung => cần kiểm soát tránh xảy ra
đụng độ, mất nhất quán => thường áp dụng loại trừ nhau
 Với hệ phân tán: loại trừ nhau phân tán - dựa trên truyền thông điệp
 Giả định
 các tiến trình truy cập tài nguyên chung => vào vùng loại trừ (critical section)
 hệ thống là async, tiến trình không gặp sự cố, thông điệp đảm bảo sẽ gửi được
(và chỉ 1 lần)
 ở mức app: cơ bản có 3 tác vụ:
 enter: có thể phải chờ
1. Yêu cầu cơ bản đối với thuật toán loại trừ nhau
 Yêu cầu cơ bản đối với thuật toán loại trừ nhau
 ME1 (savety): tại 1 thời điểm, có nhiều nhất 1 tiến trình vào vùng loại trừ
 ME2 (liveness): các tiến trình có yc sẽ đc vào vùng loại trừ
 có thể ME3 (order): tiến trình yc trước sẽ được vào vùng loại trừ trước
 Thuật toán:
 Thuật toán tập trung, phi tập trung, phân tán
 Có thể đánh giá so sánh theo:
 chi phí tài nguyên: băng thông, số lượng thông điệp msg cần gửi
 thời gian chờ của tiến trình từ khi enter đến khi exit
 hiệu năng/khả năng thông qua - throughput: sync delay - thời gian từ khi tiến trình 1
thoát đến khi tiến trình tiếp theo vào vùng loại trừ
2. Thuật toán tập trung - tại server
 Một server tập trung cấp quyền vào vùng loại trừ cho tiến trình
(client). Quyền cho tiến trình - qua token
 Tiến trình cần truy cập:
 gửi yêu cầu & chờ
 Server
 nếu kh có tiến trình khác => trả lời token cấp quyền
 nếu có => đưa yc vào hàng đợi
 Tiến trình có token
 khi kết thúc => gửi token báo cho server
 Server
 có token => nếu hàng đợi có tiến trình => gửi token tới tiến trình chờ (FIFFO-lâu
nhất), đưa tiến trình khỏi hàng đợi
 Một server tập trung cấp quyền vào vùng loại trừ cho tiến trình
(client). Quyền cho tiến trình - qua token
 Nhận xét:
 đáp ứng ME1, ME2
 để tiến trình đi vào, ngay cả khi hàng chờ trống: tối thiểu cần 2 thông điệp
 để tiến trình tiếp theo đi vào: tối thiểu 2 thông điệp
 server có thể là điểm ngẽn
3. Thuật toán token ring
 Thuật toán token ring
 Một trong các thuật toán đơn giản nhất, không cần server tập trung
 Các tiến trình lập thành vòng tròn logic
 Mỗi tiến trình: kênh 1 chiều tới tiến trình tiếp theo
 Token quyền vào vùng loại trừ lưu chuyển theo 1 chiều
 Ban đầu: chưa có tiến trình vào vùng loại trừ - token free
 Tiến trình nhận token
 Đến tiến trình có yc vào:
 chiếm token
 thực hiện xong thì giải phóng token và chuyển tiếp
 Thuật toán token ring
 Nhận xét
 Đáp ứng ME1, ME2
 ME3: không
 Khi không có tiến trình vào vùng tới hạn: truyền token liên tục => tốn băng thông
 thời gian chờ: khi token truyền đến nó => giữa 0-N lần truyền tiếp
 sync delay: token truyền tiếp => giữa 1-N
4. Thuật toán quảng bá multicast & logical clock
 Ricart and Agrawala’s algorithm
 Các nguyên tắc:
 Khởi tạo: state = release ~ bên ngoài vùng
 Để vào vùng tới hạn =>
• báo wanted
• gửi msg quảng bá tới tất cả với giá trị T
• chờ đến khi nhận N-1 trả lời => held
 Khi nhận req từ pi:
• nếu cũng đang yc vào & clock nhỏ hơn =>
cho yc của tiến trình pi vào queue
• ngược lại: trả lời cho pi (đồng ý)
 Thoát: trạng thái = released
 & trả lời cho msg trong queue
 Vd
 p1, p2 muốn vào đồng thời, p3 không
 timestamp của p1 = 41, của p2 = 34
 => p2 nhường, p1: lưu queue msg từ p2
 p1 đi tiếp
 Nhận xét
 để đi vào critical: cần gửi 1 msg và nhận N-1 msg
=> cần N msg => tốn băng thông
5. Khả năng chịu lỗi fault tolerance
 Hệ thống vận hành còn đúng không nếu:
 thất lạc message
 process crash
 Các thuật toán trên
 không chịu được lỗi thất lạc message
B. Bầu chọn - Election
 Nhiều trường hợp:
 cần có tiến trình đóng vai trò nào đó như điều phối, mà không xác định trước
tiến trình nào
 hoặc vd trong loại trừ nhau: cần chọn tiến trình nào đó được đi tiếp

 => Cần cơ chế/thuật toán bầu chọn - election

Giới thiệu
 Kêu gọi bầu chọn
 Một tiến trình gọi là kêu gọi bầu chọn nếu nó khởi động việc thực hiện thuật toán bầu
chọn nào đó
 Một tiến trình: chỉ thực hiện nhiều nhất 1 lời kêu gọi bầu chọn tại 1 thời điểm
 Về nguyên tắc, N tiến trình có thể kêu gọi N cuộc bầu chọn đồng thời
 Tại thời điểm t, tiến trình pi có thể
 hoặc là người tham gia - tham gia vào thực hiện cuộc bầu chọn nào đó
 hoặc không tham gia - không tham gia thực hiện cuộc bầu chọn nào
Giới thiệu
 Ràng buộc:
 chỉ có 1 tiến trình duy nhất (sẽ) được bầu chọn ra, ngay cả khi có nhiều cuộc bầu chọn
diễn ra đồng thời
 Định danh
 Tiến trình được chọn - là tiến trình có định danh id lớn nhất
Định danh id - (bộ) giá trị duy nhất và sắp thứ tự đầy đủ
 vd: để chọn tiến trình đang rỗi nhất, có thể dùng giá trị tải của tiến trình: 1/load để
làm định danh, kết hợp số thứ tự i của tiến trình để xếp thứ tự đầy đủ => (1/load, i)

 Mỗi tiến trình pi - có biến lưu giá trị bầu chọn - electedi
 biến electedi :
• nhận giá trị P - là tiến trình được chọn khi kết thúc (có id lớn nhất)
• hoặc giá trị đặc biệt  nếu chưa xác định tiến trình nào
2. Bầu chọn theo vòng - ring based election
Thuật toán thiết kế phù hợp cho tình huống các tiến trình xếp thành vòng kín
(logic):
 tiến trình pi có kênh truyền tới tiến trình tiếp theo
 các msg được truyền theo chiều kim đồng hồ
 giả định không có sự cố, và hệ thống là asynch
 Mục tiêu: bầu chọn tiến trình điều phối - coordinator (có id lớn nhất)
 Vận hành
1. ban đầu: tất cả các tiến trình đánh dấu người không tham gia non-participant
2. tiến trình bất kỳ kêu gọi bầu chọn => nó đánh dấu là người tham gia participant
• nó đặt giá trị Id của chính nó vào election msg và chuyển tiếp theo vòng
3.
2. Bầu chọn theo vòng - ring based election
 Vận hành
3. tiến trình nhận election msg:
• so sánh ID trong election msg với id của tiến trình,
(a) nếu id của nó nhỏ hơn => nó chuyển tiếp msg, đặt nó thành người tham gia
(b) nếu id của nó lớn hơn, và nó chưa tham gia non participant => nó thay id của nó
vào election msg, và đặt nó thành tham gia participant
• còn nếu nó đã là người tham gia => nó chỉ chuyển tiếp
(c) còn nếu id của nó = id trong election msg => nó là tiến trình được chọn
=> nó tạo elected msg, đặt id của nó vào, đặt thành non participant rồi chuyển msg
• tiến trình nhận elected msg:
Đặt biến electedi của nó = id trong msg - id của tiến trình được chọn (trừ chính tiến trình được chọn)
đặt trở thành non participant và chuyển tiếp msg
• quay lại id = idtrong elected msg => kết thúc bầu chọn
2. Bầu chọn theo vòng - ring based election
 Ví dụ

 Đánh giá: giả định 1 process bắt đầu cuộc bầu chọn
 tình huống xấu nhất: process có id cao nhất là cuối cùng
• N-1 lần chuyển msg đi qua để tất cả tham gia => có id max
• N lần chuyển msg để đi đến process có id max =>
• nó trở thành đc chọn và gửi elected msg để thông báo => N lần chuyển
3. Bầu chọn trong môi trường không dây
 Đặc điểm môi trường
 ảnh hưởng bên ngoài => độ tin cậy không cao
 Tiếp cận
 Lựa chọn lãnh đạo tốt nhất trong phạm vi truyền thông
 Vận hành
 Một nút khởi đầu,
 Gửi msg election đến tất cả nút láng giềng (nó biết)
 Nút láng giềng: nhận msg
 nếu là msg lần đầu => đánh dấu nút gửi là nút cha
 trả lời báo nhận
 gửi tiếp msg election tới các nút láng giềng (trừ nút cha)
3. Bầu chọn trong môi trường không dây
C. Điều khiển tương tranh
1. Giới thiệu
 Giao tác - giao dịch - transaction
 Mục đích của giao dịch: đảm bảo các đối tượng, dữ liệu (đc quản lý ở server) duy
trì tính nhất quán trong bối cảnh chúng được truy xuất bởi nhiều giao dịch đồng
thời
 Giao dịch phân tán: đơn vị thực thi nhằm truy cập dữ liệu trên một hay nhiều
nút khác nhau.
 Điều khiển tương tranh: quá trình kiểm soát cho phép nhiều giao dịch xảy ra
đồng thời mà vẫn đảm bảo dữ liệu nhất quán
1. Giới thiệu
 Giao dịch
 Thường server quản lý các object
 Client: yêu cầu thực hiện giao dịch - các tác vụ được thực hiện như tác vụ nhỏ
nhất kh phân chia bởi server quản lý obj/tài nguyên đó.
 Server phải đảm bảo
 hoặc tất cả tác vụ của giao dịch được thực hiện thành công, và kết quả được lưu lại
(bộ nhớ dài hạn)
 hoặc nếu có 1 số tác vụ gặp sự cố => các hậu quả cần bị loại bỏ - trở lại trạng thái như
trước khi thực hiện giao dịch
2. Thực thi đồng bộ
 Client-server
 Server thường thiết kế hỗ trợ muti thread => khả năng xử lý song song
 Server phục vụ nhiều client đồng thời => các tác vụ có thể ảnh hưởng lẫn nhau
=> hệ quả không mong muốn
 Các tác vụ (object method) cần hỗ trợ ngữ cảnh thực thi multi thread
 Có thể cài đặt thực thi đồng bộ => cơ chế đảm bảo chỉ có nhiều nhất 1 thread
truy cập object tại 1thời điểm

 vd: gọi method deposit theo kiểu sync

3. Transaction
 Giao dịch-transaction
 client yc thực hiện chuỗi các tác vụ như là nguyên tử-atomic:
 không bị can thiệp/ảnh hưởng từ các tác vụ bởi client đồng thời khác
 hoặc tất cả tác vụ thành công, hoặc không gì cả
 Giao dịch có thể được đảm bảo bởi
 hệ CSDL
 nền tảng trung gian middleware như CORBA
3. Transaction
 Giao dịch cần có tính nguyên tử kh chia nhỏ (atomic)
 All or nothing - Thực hiện thành công (tất cả) hoặc không gì cả
 và: failure atomic: thành công hoặc không gì cả - đảm bảo ngay cả khi tiến trình server
crash - gặp sự cố
 durability: kết quả thành công được lưu lâu dài - ngay cả khi tiến trình gặp sự cố
 Isolation - Tính tách biệt
 mỗi transaction không gây ảnh hưởng tới transaction khác
với hệ đối tượng phân tán:
object cần hỗ trợ khôi phục - recoverable
3. Transaction
 Đặc điểm của transaction: ACID
 Atomicity: tất cả hoặc không gì cả
 Consistency: trạng thái của hệ thống luôn nhất quán
 Isolation: các giao dịch là tách biệt, không ảnh hưởng qua lại
 Durability: kết quả giao dịch là bền vững
3. Transaction
 Transaction coordinator
 Thường giao dịch được tạo và quản lý bởi transaction coordinator
 Cung cấp các hàm
 khởi tạo
 kết thúc
 hủy
 Tid - định danh
 Khởi tạo => tạo TiD
 thực thi các tác vụ => kèm Tid
 kết thúc/hủy: kèm Tid
3. Transaction
 Transaction coordinator
 Thực hiện transaction: một số cách
1) Phối hợp giữa client, coordinator và server objects:
client gọi opentransaction => nhận về Tid
client gọi các tác vụ tiếp theo: client truyền Tid
2) Nền tảng lớp giữa, vd CORBA
nền tảng lớp giữa tự thêm tham số Tid cho các lời gọi sau khi có Tid từ opentransaction
3. Transaction success fail fail

 transaction bắt đầu:

khi gọi opentransaction
 transaction kết thúc
khi client gọi close/commit
hoặc client gọi abort
hoặc server gọi abort
 Khi server gặp sự cố
 server:
 khởi tạo tiến trình khác;
 hủy/abort transaction chưa kết thúc
 khôi phục giá trị về giá trị toàn vẹn - bởi transaction thành công cuối cùng
 Client:
 nhận biết qua exception/timeout; thường phải thực hiện lại transaction từ đầu
3. Transaction
 Điều khiển/kiểm soát tương tranh (concurrency control)
 Lỗi mất mát khi cập nhật-lost update problem
 Tài khoản của A, B và C có giá trị lần lượt là $100, $200 và $300
 do 2 giao dịch song song
cùng cập nhật
=> lỗi giá trị được ghi lại
3. Transaction
 Điều khiển/kiểm soát tương tranh (concurrency control)
 Lỗi đọc không đồng nhất - inconsistency retrievals
 Tài khoản của A, B và C có giá trị lần lượt là $100, $200 và $300
 do 2 giao dịch song song
đọc dữ liệu ra kết quả khác nhau
3. Transaction
 Điều khiển/kiểm soát tương tranh (concurrency control)
 Tương đương tuần tự:
 Nếu các transaction đi đến quả đúng khi thực hiện một mình => khi chúng thực hiện
từng giao tác tuần tự theo 1 trình tự nào đó - cũng cho kết quả đúng
 Việc thực hiện đan xen các tác vụ của nhiều transaction đưa đến kết quả giống như
thực hiện tuần tự từng transaction theo thời điểm - gọi là tương đương tuần tự (serial
equivalence).
 Ứng dụng: sử dụng để đánh giá việc thực hiện tương tranh đồng thời nhiều
transaction một cách đúng đắn, tránh các lỗi như lost-update, inconsistence-retrieval
 Lost-update: xảy ra khi các transaction đọc giá trị cụ và dùng nó để tính giá trị mới.
Lỗi này sẽ không xảy ra nếu 1 transaction thực thi kết thúc trước transaction thứ 2
(khi đó trans 2 sẽ đọc giá trị kết quả của trans 1)
3. Transaction
 Điều khiển/kiểm soát tương tranh (concurrency control)
 Tương đương tuần tự:
 Lost-update: xảy ra khi các transaction đọc giá trị cụ và dùng nó để tính giá trị mới.
Lỗi này sẽ không xảy ra nếu 1 transaction thực thi kết thúc trước transaction thứ 2
(khi đó trans 2 sẽ đọc giá trị kết quả của trans 1)

vd V thực hiện trước W =>

dữ liệu đọc đúng
3. Transaction
 Điều khiển/kiểm soát tương tranh (concurrency control)
 Tác vụ mâu thuẫn - conflict operation:
 ngược với serial equivalence, 2 tác vụ là mâu thuẫn nếu: kết quả tổng hợp phụ thuộc
thứ tự thực hiện
 Để đơn giản, xem xét 2 tác vụ cơ bản là read & write:
quy tắc mâu thuẫn:
3. Transaction
 Điều khiển/kiểm soát tương tranh (concurrency control)
 Tác vụ mâu thuẫn - conflict operation:
 ví dụ: 2 transaction T, U như sau
T: x = read(i); write(i, 10); write(j, 20);
U: y = read(j); write(j, 30); z = read (i);
chúng có có tác vụ giao nhau
không thỏa serial-equivalence
• Để thỏa serial-equivalence, cần đáp ứng
• hoặc: T truy cập i trước U và T truy cập j trước U
• hoặc: U truy cập i trước T và U truy cập j trước T
3. Transaction
 Liên quan tác vụ abort transaction
 Transaction: ghi lại các kết quả nếu thành công và phục hồi-không thay đổi nếu
abort. Ngoài ra khi abort còn mong muốn kh ảnh hưởng đến các trans khác.
 Biểu diễn tác vụ read ~ getBalance, write ~ setBalance
 Vấn đề Dirty read
 Mong muốn tính cô lập: trans 1 kh được "nhìn thấy" - đọc dữ liệu/trạng thái chưa xử
lý xong của trans 2
 Vấn đề dirty read - là khi có tương tác giữa lệnh read của trans 1 và lệnh write sớm
hơn của trans 2
3. Transaction
 Liên quan tác vụ abort transaction
 Vấn đề Dirty read
 ví dụ: trans T (tăng 10$ cho tài khoản a) và trans U (tăng 20$ cho tài khoản a)
T và U là serial equivalence (nếu cả 2 đều kết thúc commit)
Tuy nhiên nếu T hủy/abort và U kết thúc/commit thì:
U đọc dữ liệu không tồn tại
U commit => không phục hồi đc

 Phục hồi recoverability

• như trên: để phục hồi thì:
U: delay/hoãn commit đến khi
T kết thúc-commit hoặc abort
nếu T abort => U cũng abort
3. Transaction
 Liên quan tác vụ abort transaction
 Cascading aborts:
 Tiếp cận phục hồi recoverability - vẫn có vấn đề:
• nếu U phụ thuộc T, và lại có V phụ thuộc U => U chờ T, V lại chờ U. Nếu T abort => U
phải abort => V cũng phải abort
• có thể dẫn tới cascading abort => không mong muốn - do kh xác định
 Phương án tránh cascading abort
• tất cả Trans nào có nhu cầu đọc dữ liệu => chỉ khi trans khác đang write (cùng đối
tượng/bản ghi) thực hiện kết thúc (commit/abort)
• tức là tác vụ read sẽ bị trì hoãn (delay) đến khi tác vụ write (trên cùng
object/record) kết thúc
3. Transaction
 Liên quan tác vụ abort transaction
 Premature write:
 Tình huống khi 2 trans cùng thực hiện write trên một đối tượng/bản ghi
• Khi abort, thường CSDL sẽ
khôi phục về giá trị ghi nhận
trước khi thực hiện write
• nếu U abort => a=105 - tốt
• nhưng nếu T abort => a = 100
- không mong muốn
 Phương án:
• tương tự, trans thực hiện tác vụ write => phải trì hoãn/delay đến khi trans trước đó
kết thúc tác vụ write
3. Transaction
 Giao dịch lồng nhau - Nested trans
 khi trans chứa trans con và tiếp tục mức sâu hơn
 Nested trans cho phép
• các trans con cùng mức chạy song song
• các trans con độc lập commit/abort
 Quy tắc kết thúc commit/abort:
• trans chỉ commit/abort khi trans con
đã kết thúc
• khi trans cha abort => các trans con abort
• nếu trans con abort => trans cha có thể quyết định commit/abort
• nếu top level trans commit => các trans con đang comit tạm thời
sẽ commit,
4. Lock - khóa
 Giới thiệu
 Cần đáp ứng yc của trans control: lập lịch thực thi để truy cập obj/dữ liệu chung
thỏa serial equivalence
 Có thể thực hiện bằng cách
tuần tự hóa truy cập
(access serialization)
vd bên: T truy cập b xong
mới đến U truy cập b
4. Lock
 Exclusive lock
 Là cơ chế tương đối đơn giản
để cài đặt/thực hiện serial
equivalence hoặc loại trừ
nhau
 Để truy cập obj/dữ liệu, trước
hết, trans cần có được lock
 Khi thực hiện xong, trans sẽ
giải phóng lock
 Trans khác cần truy cập
obj/dữ liệu đó - phải chờ đến
khi lock được giải phóng
vd bên:
4. Lock
 Exclusive lock
 Để ý, thường thì
 Server quản lý số lượng lớn object. Tuy vậy, mỗi trans thường chỉ yc truy cập 1 vài
object và nói chung ít khi tranh chấp với các trans khác
 Phạm vi lock - mức độ chi tiết của lock => ảnh hưởng lớn đến hiệu năng
vd: CSDL: row lock, page lock, table lock
4. Lock
 Read lock, write lock
 Để ý về tranh chấp:
nếu 2 trans cùng read => không bị
mâu thuẫn => Exclusive lock chưa tối ưu
 Để tối ưu: phân biệt 2 loại lock: read và write. (read - đôi khi gọi là shared lock)
 Khi Trans
 đọc => cần yc read lock
 ghi => cần yc write lock
 Quy tắc tránh mâu thuẫn
 Nếu obj đã thiết lập read lock => trans tương tranh khác không được thực hiện write
 Nếu obj đã thiết lập write lock => trans trương tranh khác kh được thực hiện cả read
và write
(cho đến khi kết thúc trans)
4. Lock
 Dead lock
 Cơ chế lock có thể dẫn đến deadlock
 Deadlock: khi trans đang chờ trans khác nhả lock
 Biểu diễn qua đồ thị chờ nhả lock (waiting for)

 Ngăn chặn:
 Phương án lock tất cả từ đầu => tốn kém
 Phương án lock theo trình tự => bất tiện
 Phát hiện
 Phát hiện vòng khép kín trong đồ thị wait-for
 Timeout:
• nếu lock quá thời gian timeout => trans khác đang chờ được đi tiếp, trans có
timeout: abort
5. Điều khiển tương tranh tối ưu
 Optimistic concurrency control
 Giới thiệu
 Cơ chế kiểm soát qua lock có nhược điểm
 Một số vấn đề của cơ chế lock:
 Điều khiển lock hạn chế việc truy cập đồng thời đến dữ liệu chia sẻ - ngay cả tác vụ
đọc, mặc dù kh làm mất nhất quán dữ liệu cũng phải yêu cầu lock để tránh bị trans
khác thực hiện ghi.
 Sử dụng lock có thể dẫn tới deadlock
 Tránh cascading lock => lock chỉ được nhả khi thực hiện xong trans
5. Điều khiển tương tranh tối ưu
 Giới thiệu
 Các tác giả Kung và Robinson (1981) đã đề xuất cơ chế điều khiển tương tranh
tối ưu:
 Quan sát thực tế cho thấy: khả năng có nhiều (2) client đồng thời truy cập 1 đối tượng
là thấp
 Giao dịch được thực hiện bình thường đến khi thực hiện commit
 Nếu có mâu thuẫn thì sẽ thực hiện abort/hủy giao dịch nào đó. Client sẽ phải khởi
động lại giao dịch
5. Điều khiển tương tranh tối ưu
 Các pha thực hiện của giao dịch
 việc thực hiện giao dịch chia thành 3 giai đoạn: working - validating - update
 working phase (thực hiện): giao dịch sẽ thao tác với bản sao của các đối tượng mà nó
sẽ cập nhật - phiên bản cập nhật mới nhất => khi abort sẽ không ảnh hưởng đến đối
tượng
• tác vụ read, nếu bản sao đã có => truy cập bản sao này, nếu kh thì truy cập phiên
bản mới nhất
• tác vụ write sẽ cập nhật vào bản sao
• nếu có vài trans truy cập => có vài bản sao tương ứng, duy trì bởi mỗi trans
• với mỗi trans: quản trị tập các đối tượng cần read và tập đối tượng cần write
5. Điều khiển tương tranh tối ưu
 Các pha thực hiện của giao dịch
 validation phase (phê chuẩn):
 khi có yc kết thúc trans - close/commit => thực hiện kiểm tra xem các tác vụ thực hiện
trên các đối tượng/bản ghi có mâu thuẫn với các trans khác trên cùng đối tượng?
 nếu không mâu thuẫn => trans được kết thúc thành công
 nếu mâu thuẫn => cần thực hiện giải quyết mâu thuẫn, có thể cần hủy trans - abort

 updating phase (cập nhật):

 nếu trans không mâu thuẫn => các thay đổi được ghi lại lâu dài
 với tác vụ đọc => có thể commit ngay
 tác vụ ghi => commit sau khi giá trị (mới) của dữ liệu (bản sao) được ghi xuống nơi
lưu trữ lâu dài
5. Điều khiển tương tranh tối ưu
 Về validating:
 Việc xác nhận dựa trên quy tắc mâu thuẫn tác vụ read-write => để đảm bảo lập
lịch thực hiện các trans thỏa yêu cầu serially equivalence với các trans khác có
giao về thời gian (trans chưa commit vào thời điểm trans đang xét bắt đầu)
 Bắt đầu pha phê chuẩn (validation) - mỗi trans đc gán số hiệu transNo - tăng dần
theo thứ tự thời gian
 nếu i < j => trans Ti bắt đầu giai đoạn phê chuẩn/validation trước trans Tj
 nếu trans phê chuẩn thành công => được giữ transNo
 nếu phê chuẩn thất bại (bị mâu thuẫn, abort) => trả lại transNo
5. Điều khiển tương tranh tối ưu
 Về validating:
 Quy tắc phê chuẩn trans Tv nào đó với trans Ti : so sánh các tác vụ overlap có thỏa bảng:

 Giai đoạn validation & update thường ngắn (so với working), và để đơn giản hóa => thường
thiết lập tuần tự tác vụ validation + update - tại 1 thời điểm chỉ có nhiều nhất 1 trans thực hiện
validatation + update. Có thể áp dụng cơ chế loại trừ nhau để thực hiện.
5. Điều khiển tương tranh tối ưu
 Về validating:
 Backward validation: phê chuẩn trans Tv
 Kiểm tra trans cần phê chuẩn (Tv ) với các trans bị overlap đã đến giai đoạn validation trước
đó
 Kiểm tra
• Các tác vụ read của trans trước đó => kh ảnh hưởng đến các tác vụ write của Tv
• Đặt startTn - No. lớn nhất trong các trans đã kết thúc (commit) vào thời điểm Tv bắt đầu giai
đoạn working
• finishTn - No. lớn nhất trong các trans đã kết thúc vào thời điểm Tv bắt đầu giai đoạn
validation
5. Điều khiển tương tranh tối ưu
 Về validating:
 Backward validation:
 Ví dụ: hình bên
startTv = T1
finishTv=T3
cần kiểm tra tập bản ghi read của Tv
với tập bản ghi write của T2 và T3

 Nếu mâu thuẫn => phải abort

5. Điều khiển tương tranh tối ưu
 Về validating:
 Backward validation:

 Kiểm tra tập dữ liệu read của Tv : có bị mâu thuẫn với các tập dữ liệu write nào của trans trước
(overlap) ? Nếu có => mâu thuẫn - fail validation
 Nếu Tv chỉ có tác vụ write => kh cần kiểm tra
 Tập bản ghi write của trans đã commit trước: cần lưu cho đến khi tất cả trans overlap được
phê chuẩn/validation
 Khi phê chuẩn thành công Tv, giá trị startTv và tập bản ghi write của Tv đc ghi nhận, quản lý
bởi dịch vụ Quản lý giao dịch
6. Thứ tự nhãn thời gian - timestamp ordering
 Điều khiển tương tranh sử dụng thứ tự nhãn thời gian
 Trong giao dịch/trans: mỗi tác vụ đều được phê chuẩn khi thực hiện
 Nếu phê chuẩn/validation thất bại => trans bị hủy abort => client sẽ pải gửi yc thực
hiện trans lại
 Trans được gán nhãn thời gian duy nhất khi bắt đầu

 Với điều kiện: tại mỗi thời điểm chỉ có 1 trans trên object ~ object chỉ có 1 bản
gốc thì quy tắc tránh xung đột với nhãn thời gian là:
 yc ghi/write obj chỉ đc phê chuẩn nếu obj đó đã được truy cập, kết thúc tác vụ ghi bởi
các trans trước
 yc đọc obj chỉ đc phê chuẩn nếu các tác vụ ghi của trans trước đã hoàn tất
 Nhãn thời gian có thể gán dùng giá trị clock hoặc logical clock
 Với điều kiện mỗi trans có bản sao obj riêng (tentative) thì có thể có nhiều trans
tương tranh trên 1 obj:
 tác vụ ghi - thực hiện trên bản sao obj của trans => các trans khác kh "nhìn thấy" - cho đến khi
trans kết thúc thành công
 quản lý obj: mỗi duy trì nhãn thời gian tác vụ ghi và tập các bản sao, mỗi bản sao - có nhãn thời
gian ghi riêng; mỗi obj cũng duy trì tập các nhãn thời gian tác vụ đọc
 nhãn thời gian write khi được commit => phải nhỏ hơn nhãn thời gian tất cả các bản sao
(tentative version)
 khi tác vụ ghi của trans đc chấp nhận => tạo 1 bản sao (tentative) của obj, gán nhãn thời gian =
nhãn thời gian của trans
 tác vụ đọc của trans => điều hướng đọc giá trị phiên bản obj có giá trị nhãn thời gian ghi lớn
nhất & nhỏ hơn thời gian của trans đọc, nếu tác vụ đọc được chấp nhận => thêm nhãn thời
gian đọc vào tập các nhãn thời gian đọc của obj
 Khi trans commit: giá trị bản sao gán cho giá trị gốc obj, và cập nhận nhãn thời gian write
commit của obj
 Trong cơ chế thứ tự nhãn thời gian, kiểm tra theo các quy tắc sau

Tc không đc ghi obj đã được đọc bởi Ti mà Ti > Tc

=> đòi hỏi Tc  giá trị max nhãn thời gian tác vụ đọc obj
Tc không đc ghi obj đã được ghi bởi Ti mà Ti > Tc
=> đòi hỏi Tc > giá trị thời gian tác vụ ghi đã commit trên obj
Tc không đc đọc obj đã được ghi bởi Ti mà Ti > Tc
=> đòi hỏi Tc > giá trị thời gian tác vụ ghi đã commit trên obj