Chương 1.

Tổng quan & kiến trúc Hệ Phân Tán

I. Định nghĩa
- Hệ phân tán là “A collection of independent connected computers that provides services to its users as
a single coherent system. [Tanenbaum 2006]”.

- Các máy tính độc lập (hoàn toàn không rằng buộc với nhau)

• 1 máy tính không thể nào tạo nên 1 HPT, bắt buộc phải có nhiều
• Các máy tính không phụ thuộc lẫn nhau , có thể khác nhau cả về kiến trúc phần cứng cũng như
kiến trúc phần mềm

- Các máy tính kết nối lẫn nhau (1 hệ thống không phải là 1 HPT nếu các máy tính không kết nối với nhau)

• Kết nối thông qua mạng máy tính

• Các software trên các máy tính khác nhau có khả năng phối hợp , chia sẻ tài nguyên với nhau

- Các máy tính thực hiện một nhiệm vụ chung (chính là dịch vụ mà hệ thống đó mang đến cho người dùng
⇒ gọi là mức độ thống nhất)

- Cung cấp dịch vụ 1 cách thống nhất (về giao diện , cách thức truy cập)

- Users không cần phải quan tâm về chi tiết hệ thống (hoàn toàn trong suốt đối với users)

- Ví dụ: Mỗi khi người dùng ngồi trước máy tính và kết nối với internet . Khi đó bất kì một dịch vụ nào mà
người dùng sử dụng qua mạng internet thì dịch vụ đó được coi là được cung cấp bởi một hệ thống phân
tán (WWW, Email…).

II. Đặc điểm của Hệ Phân Tán

2.1. Chia sẻ tài nguyên
- Kết nối tài nguyên

• Cụ thể là 1 hệ thống có thể cho phép các hệ thống khác hoặc users truy cập vào tài nguyên của hệ
thống mình
• Hoặc là 2 hay nhiều hệ thống có thể cùng nhau chia sẻ tài nguyên . Cụ thể , 2 hay nhiều hệ thống
có thể cùng nhau khai thác chung một data center (họ cùng đặt tài nguyên ở đó)

- Giảm chi phí

→ Do đó không nhất thiết mỗi hệ thống phải triển khai data center của riêng mình ⇒ Nhờ vậy mà giảm
được chi phí và tăng tính sẵn sàng

- Tăng tính sẵn sàng + Hỗ trợ làm việc nhóm

- Tăng rủi ro về an toàn thông tin

→ Do các hệ thống cùng chia sẻ tài nguyên với nhau ➔ Có rủi ro về độ an toàn của thông tin

2.2. Tính trong suốt

- Là cách mà hệ thống che giấu tất cả những yếu tố kĩ thuật, những yếu tố phân tán ở phía sau đối với
người dùng ⇒ Người dùng sẽ hoàn toàn không thể biết được những sự tồn tại của yếu tố đó. Thứ duy
nhất mà người dùng có thể tương tác được với hệ thống chính là thông qua giao diện của hệ thống đó
đưa ra cho người dùng

Tuy nhiên , đối với vai trò là 1 nhà quản trị hệ thống , khi thiết lập mức độ trong suốt đối với hệ thống ,
chúng ta không nên lúc nào cũng thiết lập mức độ trong suốt ở mức cao nhất mà cần phải quan tâm đến
hiệu năng của hệ thống. Khi thiết lập mức độ trong suốt , cần phải cân bằng giữa hiệu năng hệ thống và
mức độ trong suốt

- Cụ thể

• Hệ thống là duy nhất đối với người sử dụng

o Giao diện giống nhau
o Cách thức truy cập giống nhau
• Trong suốt về quy mô và vị trí
• Che giấu tính phân tán của hệ phân tán
• Mức độ trong suốt : cân bằng giữa hiệu năng và độ trong suốt

- Các loại trong suốt

2.3. Tính mở

• Khả năng cho phép các thành phần có thể được sản xuất bởi các NSX khác nhau
• HPT mở cung cấp các dịch vụ theo các đặc tả về cú pháp và ngữ nghĩa của các dịch vụ gọi là giao
diện
• Mô tả bằng IDL
• Khi mà chúng ta đặc tả giao diện , cần phải chú ý về ⇒ Tính đầy đủ của đặc tả
o Nếu mà Quá chi tiết : phụ thuộc vào cài đặt cụ thể của dịch vụ (phụ thuộc vào 1 NSX ⇒
giảm tính mở )
o Nếu mà Không đủ chi tiết : khi cài đặt phải bổ sung thêm (gây khó khăn cho NSX khi họ
sản xuất các thành phần đó)
• Ưu điểm
o Khả năng giao/phối hợp (interoperatability)
o Tính khả chuyển (portability) : tức là có thể bê một thành phần của hệ thống này sang để
thay thế cho một thành phần của hệ thống khác mà vẫn hoạt động bình thường
 o Tính mềm dẻo và mở rộng được (flexibility + extensibility) của các thành phần trong hệ
thống
o Thực hiện : tách biệt chính sách và cơ chế

2.4. Tính co giãn

- Là khả năng mà hệ thống có thể được mở rộng hoặc thu hẹp mà không ảnh hưởng đến chất lượng dịch
vụ , không ảnh hưởng gì đến việc cung ứng dịch vụ cho người dùng

• Xét về tính co giãn , chúng ta xem xét đến 3 góc độ, đó là tính co giãn về
o Tổ chức
▪ Khi ta thay đổi quy mô tổ chức, thêm nhiều miền quản lý vào và vẫn không làm
thay đổi chất lượng dịch vụ ⇒ Hệ thống này có thể coi là co giãn tốt về tổ chức
o Quy mô
▪ Chính là số lượng người dùng và tài nguyên mà hệ thống đó cần phải quản lý
▪ Khi mà một hệ thống có số lượng người sử dụng hoặc tài nguyên tăng một cách
đột biến mà hệ thống vẫn hoạt động tốt , không làm thay đổi chất lượng dịch vụ
⇒ Hệ thống này có thể coi là co giãn tốt về quy mô
o Không gian địa lý
▪ Ví dụ một hệ thống đang hoạt động trong một không gian địa lý nhỏ , hoạt động
tốt trong một mạng cục bộ (LAN) . Nếu bây giờ mà hệ thống mở rộng , triển khai
trong một mạng cỡ lớn (Internet,WAN,…) , nếu hệ thống hoạt động tốt , chất
lượng dịch vụ đảm bảo ⇒ Hệ thống này có thể coi là co giãn tốt về không gian địa
lý
▪ Qui mô vùng địa lý có tài nguyên và NSD thay đổi

- Co giãn theo số lượng

• Mô hình tập trung (1 server phục vụ nhiều client Client-Server )

o Dịch vụ : cổ chai (tức là khi số lượng client gửi request tăng 1 cách đột biến ⇒ rất dễ gây
ra hiện tượng thắt nút cổ chai)
o Dữ liệu : lưu trữ, xử lý (ưu điểm là client khi muốn tìm kiếm dữ liệu thì chỉ cần gửi request
lên cho server là được )
o Giải thuật : thông tin vào ra , xử lý
• Mô hình không tập trung (Hệ thống ngang hàng Peer to Peer )
o Không bị hiện tượng thắt nút cổ chai vì tất cả các nút sẽ phục vụ lẫn nhau ⇒ Việc tăng số
lượng các nút trong hệ thống sẽ không làm quá tải một nút nào hết , khác hoàn toàn so
với mô hình tập trung ⇒ Ưu điểm
o Tuy nhiên , mô hình này lại phức tạp , có vấn đề về tính bảo mật và riêng tư
o Quyết định cục bộ
o Không có thông tin chung
o Không phát hiện được lỗi

- Co giãn theo không gian địa lý

• Gần
o Mạng cục bộ (LAN) ⇒ Rất lý tưởng vì quảng bá, tốc độ cao, tin cậy, độ trễ cố định
 • Xa
o Mạng diện rộng (WAN , Internet) ⇒ tốc độ thấp, không tin cậy, độ trễ thay đổi
• Khác nhau về
o Tốc độ truyền tin và độ trễ
o Đồng bộ / Không đồng bộ
o Các thao tác quảng bá
• Đảm bảo trao đổi thông tin trên mạng diện rộng như với mạng cục bộ

III. Kiến trúc phần mềm và Kiến trúc hệ thống

3.1. Kiến trúc

• Để xem xét kiến trúc tổ chức của 1 hệ thống phân tán , người ta sẽ tách biệt giữa tổ chức logic và
thực thi vật lý
• Tổ chức logic
o Các thành phần phần mềm và cách thức chúng kết nối với nhau , kiểu dữ liệu chúng trao
đổi với nhau là gì ?
o Người ta gọi chung là Kiến trúc phần mềm
• Thực thi vật lý
o Khi chúng ta đã xây dựng xong kiến trúc phần mềm , chúng ta cần phải cài đặt các phần
mềm đó xuống một hạ tầng vật lý (cụ thể là các thiết bị vật lý)
o Cách thức chúng ta xếp đặt chúng xuống hạ tầng vật lý như thế nào thì được gọi là Kiến
trúc hệ thống

⇒ Chúng ta sẽ đi xem xét kiến trúc phần mềm và kiến trúc hệ thống của hệ phân tán

3.2. Các kiến trúc phần mềm thường dùng trong Hệ Phân Tán (23 – 38)
3.3. Kiến trúc hệ thống (39 – 54)

IV. Middleware trong Hệ Phân Tán

4.1. Phần mềm Hệ Phân Tán

• Đặc điểm chung giữa hệ phân tán và hệ điều hành

o Quản lý tài nguyên
o Che giấu tính phức tạp và tính không đồng nhất (tính trong suốt)
• Có 2 loại
o DOS (Distributed OS) : Hệ điều hành phân tán ⇒ OS có liên kết chặt (yêu cầu về sự đồng
nhất trong hệ thống)
o NOS (Network OS) : Hệ điều hành mạng ⇒ OS có liên kết lỏng (không yêu cầu về sự đồng
nhất trong hệ thống)

a) DOS
 • Tầng trên cùng là tầng ứng dụng phân tán (chính là các ứng dụng của hệ thống)
• Tiếp đến DOS sẽ xây dựng một tầng các dịch vụ của hệ điều hành phân tán . Tầng này sẽ phủ kín
toàn bộ tài nguyên ở phía dưới thuộc nhân các OS trong các máy trong hệ
• Ưu điểm : Cung cấp tính trong suốt hoàn toàn cho các ứng dụng ở tầng trên
• Nhược điểm : Để xây dựng đc cái tầng 2 ⇒ Yêu cầu đồng nhất về kiến trúc phần cứng cũng như
phần mềm

b) NOS

• NOS cho phép hoạt động trên 1 hệ thống không đồng nhất
• Các máy tính tham gia hoàn toàn có thể khác nhau về phần cứng cũng như phần mềm
• NOS sẽ triển khai các dịch vụ đối với từng máy , và sẽ cho phép các máy tính có thể truy cập sang
nhau và sử dụng dịch vụ đó
• Nhược điểm : tính trong suốt không cao vì ứng dụng khi muốn khai thác dịch vụ mạng của các
máy khác trong hệ thống ⇒ Phải cung cấp đủ thông tin thì hệ thống mới cho phép truy cập sang
⇒ Các ứng dụng ở trên phải cung cấp những thông số kĩ thuật để thực hiện các truy cập sử dụng
dịch vụ ở máy khác ⇒ Làm giảm tính trong suốt của hệ thống

4.2. Middleware
 • Kết hợp ưu điểm của DOS và NOS
• Dịch vụ trung gian
• Các mô hình middleware nổi tiếng
o Mô hình quản lý tệp trong UNIX
o RPC (các lời gọi thủ tục từ xa) : ví dụ ứng dụng trên 1 máy A hoàn toàn có thể gọi 1 thủ
tục khác đang nằm trên một máy B , mà cơ chế gọi đó lại hoàn toàn là trong suốt (máy A
sẽ không biết là lời gọi của mình đã được chuyển sang các máy khác trong hệ thống)

- So sánh các phần mềm của Hệ Phân Tán

 Kiến Trúc Phần Mềm
1. Kiến trúc phân tầng

• Chức năng của hệ thống được phân rã thành các chức năng con. Mỗi chức năng con lại được đảm
đương thực hiện bởi 1 module.
• Các module này sẽ được kết hợp với nhau . Chúng kết hợp, trao đổi thông tin và có rằng buộc với
nhau trong cùng 1 hệ thống.
• Để đơn giản hóa hệ thống ⇒ ta cần phải giảm thiểu các liên kết , các ràng buộc giữa các module
con đó
• ⇒ Xuất phát từ mục đích trên , chúng ta có kiến trúc phân tầng (bản chất là xếp đặt các module
vào các tầng và mỗi tầng sẽ đảm đương 1 chức năng độc lập).

• Đặc điểm của kiến trúc phân tầng

o Phải đảm bảo trong suốt giữa các tầng (hoạt động của tầng này không làm ảnh hưởng đến
hoạt động của 1 tầng khác )
o Để trao đổi thông tin ⇒ Cách thức là các tầng liền kề nhau trao đổi thông tin
▪ Luồng yêu cầu (Request flow)
▪ Luồng trả lời (Response flow)
• Ví dụ đối với mô hình OSI , khi chúng ta thay đổi về hạ tầng kiến trúc của tầng Network (chuyển
từ hệ thống IPV4 sang IPV6) thì sẽ không làm ảnh hưởng đến bất kì hoạt động của tầng nào khác

• Ví dụ về E-commerce sử dụng kiến trúc phân tầng

 • Ví dụ về search engine

2. Kiến trúc hướng đối tượng

• Ở đây, các thành phần phần mềm tham gia vào kiến trúc này chính là các đối tượng
• Các hình thức giúp chúng liên kết (Connector) với nhau ⇒ được gọi là các lời gọi phương thức
• Đối tượng thực hiện gọi được gọi là Object Client - Đối tượng bị gọi được gọi là Object Server
• Kiến trúc này được gọi là Kết nối lỏng giữa các đối tượng ( tức là các đối tượng hoàn toàn độc lập
với nhau, việc thay đổi đối tượng này sẽ không làm ảnh hưởng đến các đối tượng còn lại trong hệ
thống ). Minh họa:

• Hệ thống CORBA

• Ưu điểm
o Ánh xạ vào các đối tượng trong thế giới thật ⇒ Dễ hiểu
o Dễ bảo trì & nâng cấp - Tính tái sử dụng (Polymorphism&Abstraction)
o Kiểm soát lỗi
o Mở rộng chức năng mà không ảnh hưởng đến hệ thống
o Dễ dàng kiểm thử với Encapsulation
o Giảm thời gian và chi phí phát triển
• Nhược điểm
o Khó khăn trong việc xác định các lớp, các đối tượng
 o Kích cỡ chương trình lớn
o Chương trình chạy chậm hơn so với procedure programs
o Không phải phù hợp với mọi bài toán

3. Kiến trúc hướng sự kiện

• Các thành phần trong hệ thống sẽ trao đổi thông tin với nhau thông qua các sự kiện
• Các sự kiện chứa các thông tin cần trao đổi
• Kiến trúc hướng sự kiện có thể được thực hiện theo mô hình
o Điểm-điểm ( tức là gửi trực tiếp từ thành phần gửi sự kiện đến thành phần nhận sự kiện )
o Trục quảng bá sự kiện (mô hình thuê bao - xuất bản (publisher-subscriber)) như hình bên
dưới
▪ Thành phần publisher chuyên gửi các sự kiện vào hệ thống
▪ Thành phần subscriber: đăng kí với hệ thống kiểu sự kiện mình muốn được nhận
và xử lý

• Liên kết lỏng vì

o Các thành phần trong hệ thống hoàn toàn độc lập với nhau
o Các publisher sẽ không biết đến sự tồn tại của các subcriber và ngược lại
o Đồng thời , việc thay đổi các publisher và subcriber sẽ không làm ảnh hưởng đến hệ thống
và cũng hoàn toàn trong suốt đối với những thành phần khác

4. Kiến trúc hướng dữ liệu

• Các thành phần sẽ gửi và nhận dữ liệu cho nhau

• Kiến trúc này sẽ hướng đến việc là dữ liệu được đảm bảo gửi từ bên gửi cho đến bên nhận ⇒ Để
làm được điều đó , dữ liệu sẽ không được gửi trực tiếp từ thành phần gửi cho đến thành phần
nhận mà nó sẽ đi qua một kho dữ liệu chia sẻ dùng chung
• Kho dữ liệu phải đảm bảo về tính bền vững về dữ liệu (dữ liệu không bị mất đi theo thời gian)
• Có thể coi là 1 liên kết lỏng (thời điểm gửi thì thành phần nhận không nhất thiết phải đang chạy
và ngược lại ⇒ không phụ thuộc lẫn nhau)
• Các thành phần trao đổi thông tin thông qua kho dữ liệu chung
• Ví dụ điển hình là hệ thống thư điện tử ⇒ Các email của người gửi sẽ không gửi trực tiếp đến máy
của người nhận mà sẽ đi qua 1 hệ thống máy chủ đại diện cho 1 kho dữ liệu dùng chung. Sau đó,
bao giờ người nhận kết nối với hệ thống thì sẽ nhận thư điện tử từ kho dữ liệu chung về và đọc
5. Microservices

• Chuyển đổi từ mô hình từ kiến trúc phần mềm truyền thống monolithic → microservices
• Ý tưởng chính
o Xây dựng ứng dụng dựa trên số lượng nhỏ các service (tức là chia chức năng của hệ thống
ra thành nhiều các service nhỏ , mỗi service sẽ chạy trên một tiến trình riêng và hoàn toàn
có thể được triển khai 1 cách độc lập )
o Mỗi service nhỏ có thể được phát triển bởi 1 team và có thể được triển khai một cách độc
lập mà không có sự rằng buộc với các services và teams khác
• Ưu điểm
o Đơn giản triển khai
o Đơn giản để hiểu
o Tái sử dụng
o Nhanh chóng cách ly thành phần bị hỏng
o Giảm thiểu nguy cơ khi thực hiện thay các đổi

⇒ Kiến trúc microservices ngày nay đã được thực hiện triển khai rộng rãi đối với tất cả
các mô hình Cloud
 Kiến Trúc Hệ Thống
1. Kiến trúc tập trung

a) Kiến trúc client-server

- Client: gửi yêu cầu, nhận kết quả , hiển thị cho người sử dụng

- Server: lắng nghe, nhận yêu cầu, xử lý, trả lời

- Tương tác giữa client và server có thể là: Hướng kết nối – Không hướng kết nối

- Vấn đề

• Đăng kí server ntn? ⇒ Nói cách khác là làm thế nào để cho client biết đích xác địa chỉ của server
để gửi request đến
• Có thể lặp lại yêu cầu hay không ? (idempotent) ⇒ Tức là khi client gửi request lên mà không thấy
server trả lời thì client có thể gửi lại request đó hay không ??
• Có bộ nhớ trạng thái hay không? Tức là server có lưu lại các phiên làm việc của client cũ hay không

b) Kiến trúc đa tầng

2. Kiến trúc không tập trung

• Là kiến trúc mà client và server không phân biệt vai trò (tất cả các nút tham gia vào kiến trúc này
đều ngang hàng nhau)
• Các nút này được kết nối với nhau bằng 1 mạng trên mạng hạ tầng (Overlay Network) ⇒ Vấn đề
khó nhất của kiến trúc này là việc quản lý tài nguyên. Nói cách khác , khi một nút cần tài nguyên
thì sẽ không biết được tài nguyên đó đang nằm ở nút nào ⇒ Chính vì vậy , kiến trúc không tập
trung sẽ chia ra thành kiến trúc không tập trung có cấu trúc/không có cấu trúc
a) Kiến trúc P2P có cấu trúc

• Mạng overlay được xây dựng dựa trên một thủ tục định trước
• Được sử dụng rộng rãi nhất là bảng băm phân tán DHT(Distributed Hash Table)

• Cơ chế
o Tài nguyên (data) sẽ được băm (bởi một hàm băm duy nhất). Hàm băm có đặc trưng là
kích cỡ đầu ra không thay đổi
o Hàm băm là 1 chiều , ta không thể băm ngược trở lại ra dữ liệu ban đầu được
o Khi đã băm ra các kết quả có kích cỡ không đổi (gọi là các khóa key) ⇒ người ta sẽ đưa ra
1 hàm để tính toán tương ứng mỗi khóa đến các nút trong mạng overlay (các nút trong
mạng overlay có id riêng , có chung kích cỡ đối với các khóa ⇒ Nói cách khác chúng thuộc
cùng tên ) ⇒ Các khóa sẽ được đẩy đến các nút mà có khoảng cách gần nhất ⇒ Khâu đẩy
tài nguyên về các nút trong mạng
o Để lấy tài nguyên , thì 1 nút phải có khóa của tài nguyên mà nó muốn , sau đó nó sẽ có cơ
chế để xác định được cái khóa đó do nút nào đang quản lý , cuối cùng lấy được tài nguyên

- Ví dụ của hệ thống không tập trung có cấu trúc CAN

• Hệ thống CAN bản chất dựa trên việc quản lý các khóa dựa trên không gian n chiều
• Các ID của các nút và các ID của các khóa cũng dựa trên không gian n chiều đó
• Các nút màu đen chính là các nút quản lý khóa trong vùng mình được phân công
o Việc phân 1 khóa vào hệ thống thì nó sẽ được gắn ID , sau đó ID đó rơi vào vùng nào thì
sẽ được nút tương ứng đó quản lý
o Trong trường hợp 1 nút muốn tham gia vào hệ thống ⇒ Nút đó sẽ được cấp một ID (chính
là 1 tọa độ n chiều) ⇒ Sau đó nút đó sẽ rơi vào 1 vùng . Nút đó sẽ đàm phán với nút đang
quản lý vùng đó để chia vùng quản lý cho nút mới
 o Ngược lại khi 1 nút muốn rời hệ thống thì nút đó sẽ giao vùng mà mình đang quản lý cho
1 trong các nút hàng xóm (là những nút quản lý có vùng giáp biên với nhau )

b) Kiến trúc P2P không có cấu trúc

• Việc quản lý khóa sẽ được thực hiện 1 cách ngẫu nhiên ⇒ Thuật toán ngẫu nhiên để xây dựng
mạng overlay (random graph)
• Mỗi nút sẽ duy trì một danh sách hàng xóm (partial view)
• Dữ liệu được đưa vào hệ thống 1 cách ngẫu nhiên

⇒ Do vậy , mỗi lần cần lấy dữ liệu ra ⇒ Cần phải thực hiện duyệt toàn bộ hệ thống (flooding) ⇒
Để cải thiện , chia thành các domain và mỗi domain sẽ do superpeer quản lý

3. Kiến trúc hỗn hợp

a) Hệ thống máy chủ biên

• Nhà cung ứng nội dung (content provider) thay vì phục vụ trực tiếp các client trong mạng internet
thì nó đã sao chép , nhân bản nội dung của mình đến các máy chủ biên (Edge server). Các máy chủ
biên có thể chính là các nhà cung ứng dịch vụ (ISP). Và từ đó các ISP sẽ phục vụ các client của mình
theo kiến trúc tập trung
• Kết luận :
o Yếu tố không tập trung khi mà content provider nhân bản dữ liệu hay nội dung của mình
đến các máy chủ biên
o Còn yếu tố tập trung được thể hiện từ các máy chủ biên phục vụ các client của mình
- Ví dụ

b) Hệ phân tán hợp tác (Hệ thống chia sẻ file BitTorrent)

- Yếu tố tập trung được thể hiện qua máy chủ tracker

• Nắm bắt các thông tin về các tài nguyên mà các nút trong hệ thống đang nắm giữ
• Khi 1 nút muốn yêu cầu tài nguyên nào thì sẽ gửi thông tin lên cho 1 tracker. Tracker sẽ dựa vào
thông tin mình biết để gửi lại câu trả lời cho nút đó biết là những nút nào đang sẵn sàng chia sẻ
những tài nguyên mà nút yêu cầu đó vừa gửi yêu cầu
• Từ đó , nút yêu cầu sẽ gửi lại các request đến các nút trong danh sách nhận được để yêu cầu
những nút đó chia sẻ tài nguyên với mình
• Như vậy đây là một hệ thống kết hợp giữa kiến trúc tập trung và kiến trúc không tập trung
 Chương 2. Tiến trình – Trao đổi thông tin
I. Tiến trình & Luồng
1.1. Khái niệm
- Tiến trình

• Là chương trình đang hoạt động.

• Tài nguyên : Virtual Processor, Virtual Memory
• Trong suốt tương tranh (chúng hoàn toàn độc lập và không gây ảnh hưởng được lẫn nhau)
• Quá trình tạo 1 tiến trình
→ Để tạo ra được sự trong suốt đó ⇒ OS phải tạo ra được các không gian địa chỉ phải hoàn toàn
độc lập . Việc cấp phát vùng nhớ tương đương với việc khởi tạo vùng nhớ , xóa vùng dữ liệu , copy
chương trình vào vùng nhớ đó, khởi tạo stack cho dữ liệu tạm thời.
• Chuyển ngữ cảnh giữa các tiến trình

- Luồng

• Là 1 luồng thực thi của tiến trình (mỗi luồng có đoạn mã thực hiện riêng, độc lập với các luồng
khác. Tuy nhiên khác với tiến trình, các luồng không cần phải hoàn toàn độc lập trong suốt với
nhau ⇒ Mỗi luồng chỉ cần ghi thông tin ít nhất để cho phép các luồng chia sẻ CPU. Ngữ cảnh của
luồng chính là ngữ cảnh của CPU bao gồm các thông tin như: giá trị thanh ghi, bộ đếm chương
trình,con trỏ stack, và vài thông tin quản lý các luồng khác nữa…Các ứng dụng đa luồng thường
giúp chương trình có hiệu năng cao hơn do các tác vụ được thực hiện song song và việc lập trình
để cho các luồng không ảnh hưởng lẫn nhau là tốn kém, đây chính là tốn kém về chi phí lập trình)
• Tiến trình có nhiều luồng thực thi ⇒ Tiến trình đa luồng
• Các luồng của tiến trình dùng môi trường thực hiện chung của tiến trình : trạng thái CPU
• Trao đổi thông tin giữa các luồng thông qua các biến chia sẻ
• An toàn và hợp lý của tương tác luồng sẽ do lập trình viên quyết định
• Khi xây dựng Luồng ⇒ Cần quan tâm đến chi phí về Hiệu năng + Chi phí lập trình

1.2. Đa tiến trình & Đa luồng trong hệ thống tập trung

• Lợi ích của xử lý song song với xử lý tuần tự (xử lý song song đem lại hiệu năng cao hơn ). 2 biện
pháp để chúng ta có thể áp dụng cơ chế xử lý song song là
• Đa tiến trình hoặc đa luồng
o Chi phí lập trình ⇒ Đa tiến trình có ưu điểm hơn khi không tốn kém chi phí lập trình, sự
tương tranh giữa các tiến trình do OS quản lý . Ngược lại với đa luồng ⇒ lập trình viên
phải kiểm soát sự tương tranh giữa các luồng
o Chi phí chuyển ngữ cảnh ⇒ Đa luồng có ưu thế hơn khi việc chuyển ngữ cảnh giữa các
luồng là gần như không tốn kém vì ngữ cảnh của các luồng chính là ngữ cảnh của tiến
trình sinh ra nó. Ngược lại đa tiến trình rất là tốn kém về chi phí chuyển ngữ cảnh (ví dụ
như hình vẽ dưới)
 o Lời gọi hệ thống dừng (blocking system call) : xảy ra khi ta lập trình đa luồng và có 1 luồng
bị dừng khi nó gọi 1 lời gọi hệ thống dừng ⇒ Luồng đó làm treo luôn tiến trình sinh ra nó
và làm treo luôn các luồng khác mà cũng do tiến trình đó sinh ra
• Cài đặt luồng: Được quản lý bởi gói luồng (thread package) và có 3 tác vụ chính là
o Khởi tạo luồng (1)
o Giải phóng luồng (2)
o Đồng bộ các luồng (3)
o (1),(2),(3) có thể thực hiện dưới chế độ NSD (user) hoặc nhân (kernel)
▪ Chế độ NSD (user) : nếu khai thác ở chế độ này thì có thể khai thác được ưu điểm
của đa luồng. Việc thực hiện (1),(2),(3) sẽ được thực hiện với chi phí hệ thống rất
thấp. Tuy nhiên chúng ta lại gặp vấn đề về lời gọi hệ thống dừng
▪ Chế độ nhân : lúc này sẽ mất hết các ưu điểm của đa luồng vì lúc này (1),(2),(3)
tốn kém như việc làm với các tiến trình ⇒ cần giải pháp mà nó kết hợp ưu điểm
của triển khai ở chế độ người dùng và chế độ nhân
• Cơ chế các tiến trình nhẹ trong Linux
o Một trong những giải pháp để tích hợp ưu điểm của việc triển khai các gói luồng hoàn
toàn ở tầng nhân hoặc hoàn toàn ở tầng user là dùng các tiến trình nhẹ (light weight
process)
o Ý tưởng : thay vì gắn trực tiếp mỗi tiến trình với các luồng thì người ta tạo ra các tiến trình
nhẹ ở giữa . Các tiến trình nhẹ này được triển khai ở tầng nhân . Các luồng vẫn đc triển
khai bthg ở tầng user và với mỗi luồng sẽ đc gắn 1 tiến trình nhẹ ở dưới tầng nhân. Chú ý
các tiến trình nhẹ đều thuộc 1 tiến trình chính ⇒ Ở đây vẫn giữ lại được ưu điểm là triển
khai toàn bộ các luồng ở chế độ user và vấn đề về lời gọi hệ thống dừng đã được giải
quyết khi giả sử 1 luồng thực hiện 1 lời gọi hệ thống dừng ⇒ chỉ dừng 1 LWP
1.3. Tiến trình & Luồng trong hệ thống phân tán

• Server đơn luồng

o Chỉ có thể xử lý được một yêu cầu tại một thời điểm (và các yêu cầu phải được xử lý tuần
tự ⇒ không hiệu quả, không đảm bảo được tính trong suốt tương tranh)
o Các yêu cầu có thể được xử lý tuần tự
o Các yêu cầu có thể được xử lý bởi các tiến trình khác nhau
o Không đảm bảo tính trong suốt
• Client và server đa luồng

• Hình tròn vàng tương đương với tiến trình client và tiến trình server. Các biểu tượng mũi tên
xoay tròn chính là các luồng
• Các yêu cầu sẽ được client gửi lên
• Ở server khi nhận được các yêu cầu từ phía các client khác nhau ⇒ Các yêu cầu sẽ được chuyển
lại cho các luồng phân biệt để thực hiện xử lý song song
• Ta có thể thấy là không chỉ server mới cần đa luồng mà ngay cả client cũng cần đa luồng

1.4. Server trong hệ phân tán

- Mô hình server dispatcher trong hệ phân tán

→ Server dispatcher có vai trò như là điều phối của hệ thống. Nó tiếp nhận các yêu cầu từ tầng mạng
của OS gửi lên và nó sẽ điều phối các công việc cho các luồng thực thi khác:

Ta sẽ xem xét 3 mô hình server đa luồng trong hệ phân tán

Mô hình a là luồng với mỗi yêu cầu Mô hình b là luồng với mỗi kết nối. Mô hình c là luồng với mỗi đối tượng.

Ở đây, với mỗi yêu cầu nhận được
thì server sẽ sinh ra 1 luồng để phục
vụ yêu cầu đó. Bất kì 1 yêu cầu nào
đó được gửi đến sẽ được tạo ra 1
luồng mới và xử lý yêu cầu đó
Ở đây, với mỗi kết nối mà gắn với tiến Tức là với mỗi đối tượng từ xa mà tiến
trình server sẽ được tạo 1 luồng để trình server quản lý, nó sẽ xây dựng 1
chuyên phục vụ các yêu cầu đến từ luồng tương ứng để quản lý
kết nối đó (đến từ client tương ứng
đó)

Ưu điểm của mô hình này là tốc độ 2 mô hình còn lại thì không bị vấn đề đó
xử lý và tối đa hóa băng thông,
không cần hàng đợi (vì mọi yêu cầu
gửi đến đều được xử lí luôn). Và sau
khi xử lí xong thì luồng sẽ bị hủy đi
So sánh các mô hình này thì ở mô
hình a có ưu điểm là tốc độ xử lý và
tối đa hóa băng thông, không cần
hàng đợi
Nhược điểm đó là tốn kém tài Nhược điểm vẫn còn bị có hàng đợi. Ví dụ mô hình b, nếu các yêu cầu đến từ
nguyên overhead của tiến trình khi 1 kết nối quá nhiều thì vẫn cần hàng đợi cho cái luồng xử lý đó tương ứng.
mà nó liên tục phải tạo ra các luồng
mới, liên tục phải hủy luồng Nhược điểm thứ 2 là không có khả năng cân bằng tải cho các cái luồng song
song này (vấn đề xảy ra khi quá nhiều yêu cầu đến với 1 kết nối làm cho luồng
⇒ Nguy cơ quá tải tài nguyên của tương ứng quá tải, còn các luồng khác thì lại không )
tiến trình đó

Còn 1 mô hình khác nữa là mô hình máy trạng thái hữu hạn

o Tiến trình server là 1 tiến trình đơn luồng

o Các yêu cầu từ client và xử lý được sắp hàng
o Tại 1 thời điểm server thực hiện thao tác trong hàng
o Không cần đa luồng
o Các lời gọi xử lý là các lời gọi “không dừng”
o VD: Node.js (bất đồng bộ và hướng sự kiện, đơn luồng nhưng khả năng co giãn cao)
 • Các vấn đề trong thiết kế server cho hệ phân tán
o Tổ chức server
▪ Server lặp : server xử lí tuần tự hay nói cách khác là server đơn luồng
▪ Server đồng thời : server đa tiến trình hoặc đa luồng
o Vấn đề xác định server (1 cơ chế để cho tiến trình client tìm đến đúng server tương ứng)
▪ Xác định được end point (port): Ngoài việc tìm địa chỉ IP đến 1 máy server rồi,
chúng ta phải xác định được cổng tương ứng
▪ Daemon : Vấn đề các server đăng kí để cho các tiến trình client tìm được đến
đúng mình ⇒ Không hiệu quả vì các server luôn luôn phải chạy
▪ Super server : Sau khi đăng kí xong với tiến trình super server, các tiến trình khác
có thể tắt đi, tạm dừng hoạt động. Chỉ khi có client gửi đến , tiến trình super server
sẽ đánh thức các tiến trình server tương ứng lên để phục vụ client
o Vấn đề ngắt server
o Stateless & Stateful server

1.5. Client trong hệ phân tán

Không chỉ có server mà ngay cả client trong hệ phân tán cũng cần phải triển khai đa luồng.

• Cần Client đa luồng

• Tách biệt giao diện người sử dụng và xử lý
• Giải quyết vấn đề các thao tác chờ đợi lẫn nhau
• Tăng tốc độ khi làm việc với nhiều server khác nhau
• Ví dụ: Tải trang web

2. Trao đổi thông tin giữa các tiến trình

2.1. Khái niệm

Để 2 tiến trình có thể trao đổi thông tin được với nhau ⇒ Cần phải thống nhất với nhau về 1 số yếu tố và
sự thống nhất đó được gọi chung là giao thức

• Giao thức là sự thống nhất dựa trên các yếu tố như

o Cấu trúc thông điệp
o Kích cỡ thông điệp
o Thứ tự gửi thông điệp
o Cơ chế phát hiện thông điệp hỏng hay bị mất,…
 • Trong truyền thông mạng, các mô hình mạng được chia ra làm nhiều tầng, hay còn gọi là mô hình
phân tầng
• Có nhiều kiểu loại giao thức khác nhau như
o Hướng kết nối/ Không hướng kết nối (có cần thiết lập kênh hay không thiết lập kênh trước
khi truyền tin)
o Tin cậy/ Không tin cậy (Có cơ chế báo nhận hay không ?)
• Các vấn đề của giao thức
o Send-Receive primitives ( bản chất của giao thức truyền thông là dựa vào 2 hàm cơ bản
là Send và Receive )
o Tùy vào các giao thức đồng bộ hay không đồng bộ thì send và receive là những hàm dừng
hay không dừng. Receive thì sẽ luôn là hàm dừng vì chúng luôn phải tự block mình để
nhận gói tin từ bên gửi. Còn Send sẽ tùy vào giao thức đồng bộ hay không đồng bộ, nếu
là đồng bộ thì nó là hàm dừng
o Đồng bộ/không đồng bộ, dừng, không dừng

• Bản chất của việc trao đổi thông tin giữa các tiến trình là trao đổi thông tin giữa các socket của
tiến trình. Vì vậy, mỗi tiến trình (client và server) đều phải tạo 1 socket cho mình như trên hình và
mỗi socket sẽ đại diện cho 2 thông tin là địa chỉ IP của máy và thông tin về cổng gắn với các socket
đó.
• Mỗi socket thì gắn với 1 cổng, không được có tình trạng 2 socket gắn cùng 1 cổng
• Mỗi socket đại diện cho 2 thông tin ⇒ Mỗi kết nối socket có tổng cộng là 4 thông tin
• Đối với tiến trình server, sau khi tạo socket sẽ phải chủ động gắn socket đó với 1 cổng
• Đối với client, sau khi tạo socket thì chỉ việc thực hiện kết nối đến socket ở bên server tương ứng
• Việc gắn cổng cho socket bên client sẽ do OS đảm nhiệm

2.2. Trao đổi thông tin với UDP

- Đặc điểm: Không hướng kết nối, không tin cậy, không đồng bộ

- Vấn đề: Kích cỡ thông điệp, blocking (send không dừng nhưng reveice dừng), timeouts, receive fr any…

2.3. Trao đổi thông tin với TCP – IP

3. Lời gọi thủ tục từ xa
3.1. Giao thức yêu cầu – trả lời

• Là cơ chế bậc cao hơn truyền thông điệp, cho phép trao đổi thông tin giữa 2 tiến trình bằng 2
thông báo gửi nhận liên tiếp
• Hỗ trợ các lời gọi từ xa, Đồng bộ, Tin cậy

• Trong hình vẽ, 2 hình vuông đại diện cho máy client và máy server
• Hình tròn ở trong đại diện cho tiến trình
• Giao thức yêu cầu trả lời được thực hiện bởi 3 thủ tục doOperation, getRequest và sendReply
• Việc đồng bộ ở chỗ client gửi req xong tự block mình
• Tin cậy ở chỗ có sendReply, không cần phải có những cơ chế kiểm soát luồng phức tạp
• Ví dụ điển hình của giao thức yêu cầu-trả lời : HTTP

3.2. Lời gọi thủ tục từ xa

→ Nằm giữa tầng giao vận và tầng ứng dụng phân tán

- Khái niệm

• Cơ chế: Máy 1 gọi 1 thủ tục, nhưng bản chất thủ tục đó lại được triển khai ở máy 2. Yêu cầu phải
được chuyển từ máy 1 qua hạ tầng mạng rồi đến máy 2, thực thi ở máy 2, sau đó gửi câu trả lời
(nếu có) về cho máy 1. Qúa trình này phải hoàn toàn trong suốt với bên phía client, cụ thể là tiến
trình P1 khi gọi thủ tục f như hình vẽ
• Cơ chế truy cập trong suốt đối với người dùng
• Có 2 vấn đề chính đối với việc lời gọi thủ tục từ xa
o **Hệ thống không đồng nhất ***
▪ Không gian nhớ khác nhau
▪ Cách biểu diễn thông tin khác nhau
o Có lỗi xảy ra
▪ Ví dụ máy 1 thực hiện lời gọi. Yêu cầu được chuyển sang máy 2.
▪ Máy 2 nhận được lời gọi sau đó bị treo
▪ Thế là máy 1 cứ tiếp tục chờ vô hạn

- Cơ chế RPC
 • Như hình minh họa trên, tiến trình client thực hiện 1 thủ tục add với 2 tham số (i,j) với mục đích
tính tổng i và j. Thủ tục add sẽ trả về giá trị tổng của 2 tham số i và j
• Middleware ở phía client (client stub) sẽ đóng gói các cái yêu cầu này và truyền đi trong mạng
đến bên máy server nơi mà có triển khai thủ tục add
• Sau đó đi qua tầng middleware ở bên phía server (server stub), bóc tách các thông điệp và
chuyển thành lời gọi add, đẩy lên trên tiến trình server ở trên, nơi mà có triển khai thủ tục add,
tính tổng i,j
• Cuối cùng truyền ngược theo con đường để trở lại về đến máy client

- Lời gọi thủ tục tông thường (Chú thích : Đọc n bytes từ 1 tệp và ghi vào vùng nhớ trỏ bởi con trỏ buf)

- Vấn đề đối với cơ chế truyền tham số

• Có 2 loại : tham biến và tham chiếu

• Vấn đề đối với 2 loại trên
o Tham biến
▪ Vấn đề khi biểu diễn dữ liệu khác nhau
▪ Các dữ liệu không thuộc cùng một kiểu, các kiểu dữ liệu khác nhau được biểu diễn
khác nhau
o Tham chiếu
▪ Bộ nhớ phân tán
o Vấn đề đối với dữ liệu có cấu trúc
▪ Cụ thể là 1 tiến trình client tự xây dựng cấu trúc riêng cho mình
▪ Khi gửi cái lời gọi thủ tục đó mà có kèm theo dữ liệu có cấu trúc mà tự xây dựng
sang server
▪ Server không thể hiểu được

⇒ Cần thống nhất cho cả 2 bên (yêu cầu và nhận yêu cầu) ⇒ Cần thiết phải đặt tham số cho cả 2
bên ⇒ nhu cầu đặc tả tham số

- Nhu cầu: đặc tả tham số

 • 2 bên gửi và nhận cùng phải thống nhất về đặc tả tham số (tuân thủ 1 kiểu giao thức)
• Các yếu tố thống nhất
o Định dạng thông điệp
o Cách biểu diễn cấu trúc dữ liệu cơ bản
o Kiểu trao đổi thông điệp
o Triển khai client-stub và server-stub

- Tính mở của RPC

• Để đảm bảo tính mở cho RPC ⇒ cả client và server đều có thể được cài đặt bởi các NSX khác
nhau
• Giao diện thống nhất giưã client và server thì cần phải
o Không phụ thuộc công cụ và ngôn ngữ lập trình nào
o Mô tả đầy đủ và trung lập
o Thường dùng ngôn ngữ định nghĩa giao diện

4. Trao đổi thông tin hướng thông điệp

Đây là các cơ chế hướng đến đảm bảo thông điệp được gửi từ nút gửi và đến được với nút đích. Trao
đổi thông tin hướng thông điệp chia ra làm 2 loại là:

4.1. Trao đổi thông tin hướng thông điệp tạm thời

(Thông tin được gửi trực tiếp từ nút gửi cho đến nút nhận)

• Đây là 1 hình thức trao đổi thông tin tương đối đơn giản sử dụng cơ chế ở tầng giao vận (cụ thể
là trao đổi thông điệp bằng socket)
• Các thủ tục cơ bản của trao đổi thông tin sử dụng socket
o socket : khởi tạo socket
 o bind : gán socket với 1 cổng
o listen : chuyển trạng thái của socket sang trạng thái nghe để chấp nhận 1 yêu cầu kết nối
o accept : để chấp nhận 1 yêu cầu kết nối
o connect : gửi yêu cầu kết nối đến socket server
o send & receive : để gửi và nhận
o close : đóng socket
• Thứ tự khởi tạo các socket được diễn ra như hình ở trên

4.2. Trao đổi thông tin hướng thông điệp bền vững

(Cơ chế này sẽ có thành phần trung gian. Và nút thông điệp sẽ được gửi từ nút gửi đến thành phần lưu
trữ trung gian này, sau đó từ thành phần lưu trữ trung gian này thông điệp mới được gửi đến cho nút
nhận)

• Hình thức trao đổi thông tin hướng thông điệp này sử dụng middleware hướng thông điệp được
gọi là MOM (Message-Oriented Middleware)
• Với cơ chế trao đổi thông tin này, nó sẽ sử dụng hệ thống hàng đợi thông điệp hỗ trợ trao đổi
thông tin không đồng bộ bền vững
• Hỗ trợ khả năng lưu trữ trung gian cho thông điệp (có 1 cơ chế lưu trữ trung gian ở giữa bên nút
gửi và nút nhận. Cụ thể là 2 bên nút gửi và nút nhận không cần đồng bộ trong quá trình trao đổi
thông điệp mà nút gửi sẽ gửi thông điệp vào bộ phận lưu trữ trung gian hay hàng đợi lưu trữ trung
gian. Sau đó nút nhận sẽ lấy dần yêu cầu từ hàng đợi trung gian đó ra )
• Hình thức này rất phù hợp với dịch vụ mà chấp nhận độ trễ của thời gian cao
• Ví dụ điển hình là hệ thống thư điện tử (email)

Ví dụ của mô hình hàng đợi thông điệp

• Các hình vuông là 2 nút gửi và nút nhận

• Hình vuông nét liền là nút đó đang chạy, nét đứt là đang không chạy
• 4 ví dụ minh họa cho ta thấy khả năng không cần đồng bộ của bên nút gửi và nút nhận
 • Ở mô hình a, nút gửi gửi thông điệp vào hàng đợi và nút nhận đồng thời lấy thông điệp từ hàng
đợi ra. Cả 2 nút gửi và nhận đều đang chạy
• Ở mô hình b cho phép nút nhận không chạy, tuy nhiên nút gửi vẫn gửi thông điệp vào hàng đợi
• Ở mô hình c ngược lại nút gửi lại không chạy và nút nhận lại đang chạy thì nút nhận sẽ tiếp tục lấy
thông điệp từ hàng đợi ra
• Ở mô hình d cả 2 nút gửi và nhận đều đang không chạy thì các thông điệp sẽ được lưu trữ 1 cách
bền vững vào hàng đợi

Cơ chế định địa chỉ ở mức hàng đợi

• Khi tiến trình sender gửi thông điệp đi qua cái tầng quản lí hàng đợi, sẽ có thực hiện 1 cái cơ chế
tìm kiếm và 1 cơ sở dữ liệu các địa chỉ ở mức giao vận
• Ở đây sẽ định luôn địa chỉ IP và cổng (port) của nút nhận của tiến trình receiver, sau đó đẩy đi
trong mạng và đến ở bên nút nhận thì nhờ thông tin đó sẽ có được địa chỉ ở mức giao vận và đi
được vào đúng hàng đợi của tiến trình nhận tương ứng

Hệ thống hàng đợi thông điệp với các routers

Trong hệ thống hàng đợi thông điệp cần có các đơn vị quản lý hàng đợi được gọi là queue manager

• Queue manager tương tác trực tiếp với ứng dụng gửi và nhận thông điệp
• Tuy nhiên, có 1 vài đơn vị quản lí hàng đợi đặc biệt hoạt động như 1 router (bộ định tuyến). Nó
chuyển tiếp các thông điệp nhận được cho các queue manager khác. Việc sử dụng các router là
hiệu quả trong trường hợp mạng có quy mô lớn, mỗi nút không thể lưu trữ được 1 bảng ánh xạ
đầy đủ hàng đợi tới địa chỉ
• Ví dụ như trong hình, bên gửi A muốn gửi cho bên nhận B ⇒ thông điệp sẽ gửi đến router gần
nhất là R1
• R1 sẽ biết rằng là để đến được tới B, cần phải chuyển tiếp cho R2
• Việc sử dụng router sẽ giúp cho hệ thống hàng đợi thông điệp có tính khả mở. Tuy nhiên, hệ
thống càng mở rộng thì việc cấu hình các đường đi cho các router là càng bất khả thi ⇒ Chính vì
vậy chúng ta cần những cơ chế định tuyến tự thích nghi

Message Broker

Đối với nhu cầu để cho các ứng dụng trong mạng đều hiểu các thông điệp, với việc sử dụng thông điệp có
định dạng chung duy nhất là không phù hợp với hệ thống hàng đợi thông điệp. Lý do là các ứng dụng trong
hệ thống phân tán có thông tin vô cùng là đa dạng ⇒ Ta cần sử dụng 1 nút đặc biệt là message broker

• Message Broker hoạt động như 1 gateway ở mức ứng dụng

• Mục đích chính là chuyển định dạng thông điệp sao cho bên ứng dụng nhận có thể hiểu được
thông điệp ở bên nút gửi
• Ngoài chức năng chuyển đổi định dạng, message broker còn có chức năng xác định đúng ứng dụng
sẽ nhận thông điệp theo publish-subcribe (mô hình thuê bao- xuất bản)

5. Trao đổi thông tin hướng dòng

Đối với các kiểu trao đổi thông tin trước, thì yếu tố thời gian là không quan trọng (cụ thể là trao đổi thông
tin hướng thông điệp). Đối với kiểu trao đổi thông tin đó thì yếu tố về thời gian không làm ảnh hưởng đến
hoạt động của toàn bộ hệ thống. Tuy nhiên, có những kiểu trao đổi thông tin mà thời gian đóng vai trò rất
quan trọng.

5.1. Hỗ trợ cho phương tiện truyền thông liên tục

Để hỗ trợ cho các phương tiện truyền thông liên tục, cần có các

• Phương tiện truyền đạt thông tin, bao gồm

o Lưu trữ
o Truyền tin
o Biểu diễn thông tin (màn hình,…)
• Cần phân biệt giữa Phương tiện truyền thông liên tục/ rời rạc
o Đối với Phương tiện truyền thông liên tục, cần quan tâm đến
▪ Kiểu dữ liệu
▪ Mối quan hệ thời gian giữa các mẫu liên tiếp trong một dòng dữ liệu
▪ Ví dụ : truyền âm thanh như đã phân tích
o Đối với Phương tiện truyền thông rời rạc
▪ Vấn đề thời gian k quan trọng, ví dụ 1 số loại dữ liệu như truyền các tệp dữ liệu
văn bản, ảnh cố định, các tệp chương trình,…

Dòng dữ liệu

• Chuỗi các đơn vị dữ liệu liên tục (dòng dữ liệu hoàn toàn có thể áp dụng cho các phương tiện
truyền tin liên tục hay rời rạc. Ví dụ kết nối TCP/IP ⇒ gửi dòng dữ liệu theo kiểu rời rạc, nhưng để
chạy 1 tệp audio ⇒ thiết lập 1 dòng dữ liệu liên tục giữa file nhạc và thiết bị chơi nhạc )
• Với các dòng dữ liệu liên tục, có những cách truyền tin khác nhau như
o Truyền tin không đồng bộ (các đơn vị dữ liệu được truyền lần lượt, không có rằng buộc
về thời gian ⇒ giống với dòng dữ liệu rời rạc ) VD: 1 tệp được truyền đi thành dòng dữ
liệu, tuy nhiên không biết chính xác tại thời điểm nào, việc gửi các đơn vị dữ liệu được
hoàn thành.
o Truyền tin đồng bộ : có giới hạn độ trễ về thời gian, và phải có độ trễ này giới hạn lớn nhất
cho mỗi đơn vị trong dòng dữ liệu. Ví dụ 1 bộ cảm biến thu nhận mẫu nhiệt độ với 1 tốc
độ xác định và gửi qua mạng đến 1 operator. Lúc này cần xác định thời gian truyền qua
mạng phải < thời gian giữa 2 lần lấy mẫu
o Truyền tin đẳng thời: yêu cầu các đơn vị dữ liệu truyền đi trong 1 ngưỡng thời gian độ trễ
cho trước ⇒ rất phù hợp với Hệ phân tán dữ liệu đa phương tiện
• Dòng dữ liệu có 2 loại
o Đơn : chỉ có 1 chuỗi dữ liệu
o Phức : gồm nhiều các dòng dữ liệu đơn

⇒ Các dòng con (tức là dòng dữ liệu đơn trong 1 dòng dữ liệu phức thì thường có quan hệ về mặt
thời gian với nhau. Ví dụ là dòng về các bộ phim(movie))

• Với dòng dữ liệu thời gian thực ⇒ đoạn video được quay trong thời gian thực rồi gửi đi qua mạng.
Đặc điểm là dòng dữ liệu thời gian thực không có cơ hội để điều chỉnh dòng
• Một số các vấn đề mà ta cần xem xét khi truyền dòng dữ liệu
 o Nén dữ liệu đa phương tiện (như là nén dữ liệu audio, nén dữ liệu truyền đi giúp làm giảm
dung lượng lưu trữ và tài nguyên mạng)
o Kiểm soát chất lượng của đường truyền
o Đồng bộ hóa (đối với những dòng phức khi nhận được)
• Trên hình là kiến trúc chung truyền dữ liệu đa phương tiện qua mạng

• Máy chủ đa phương tiện lấy dữ liệu từ 1 kho đa phương tiện đã được nén
• Sau đó sẽ đi qua 1 bộ điều khiển đảm bảo chất lượng dịch vụ
• Dòng dữ liệu sẽ được truyền qua mạng đến với bên máy nhận
• Bên máy nhận cũng đi qua 1 bộ điều khiển đảm bảo chất lượng dịch vụ ⇒ xem dòng dữ liệu nhận
được có đảm bảo hay không ?
• Sau đó từng dòng dữ liệu đơn sẽ được đi qua các bộ giải mã dòng và chúng sẽ có 1 cơ chế đồng
bộ hóa để phát các dòng dữ liệu đơn này ở máy client

5.2. Dòng dữ liệu và QoS

Ta sẽ xem xét 1 số yếu tố ảnh hưởng đến chất lượng dịch vụ QoS

• Quality of Service (QoS):

o bit-rate
o delay
o e2e delay
o jitter
o round-trip delay
• Việc truyền dòng dữ liệu trên internet nói chung đều dựa trên 1 hạ tầng mạng IP ⇒ Tất cả các dịch
vụ truyền dòng dữ liệu đi đều phải dùng chung 1 hạ tầng mạng IP. Và cơ chế vận hành của hạ tầng
mạng IP:
o Tương đối là đơn giản
o Cơ chế best effort ⇒ cơ chế chuyển dòng dữ liệu đi theo con đường ngắn nhất
 ⇒ Tuy nhiên đối với cơ chế mà đơn giản như vậy ⇒ Không thể đảm bảo chất lượng dịch vụ cho
các dòng dữ liệu truyền đi ⇒ cần giải pháp để đảm bảo chất lượng dịch vụ đầu cuối khi mà chúng
ta không thể can thiệp được vào hạ tầng mạng IP

Để thực thi QoS

a) Cơ chế differentiated services

• Cơ chế này cho phép phân lớp các dịch vụ khác nhau và đặt độ ưu tiên khác nhau cho các loại dịch
vụ
• Từ đó sẽ cải thiện được chất lượng dịch vụ cho các loại dịch vụ ưu tiên mà không cần phải can
thiệp vào hạ tầng mang IP

b) Sử dụng bộ đệm để giảm jitter

Ý tưởng: với dòng dữ liệu được truyền đến ở nút nhận ⇒ sẽ không được chạy ngay cho client mà sẽ lưu
vào bộ đệm ⇒ sau đó sẽ chạy để đảm bảo khoảng thời gian giữa đơn vị dữ liệu liên tiếp nhau đúng với
bên nút gửi ⇒ loại bỏ hoàn toàn jitter

c) FEC (liên quan đến tỉ lệ mất mát gói tin)

Ý tưởng: phân tán sự mất mát gói tin ra toàn bộ dòng dữ liệu ⇒ từ đó có thể cải thiện chất lượng dịch vụ

5.3. Đồng bộ hóa dòng

Các hệ thống ĐPT đều gặp phải vấn đề với dòng dữ liệu phức ⇒ cần phải đồng bộ chúng và duy trì mối
liên hệ về thời gian giữa các dòng dữ liệu

• 2 kiểu đồng bộ
o Đồng bộ dòng dữ liệu rời rạc và dòng dữ liệu liên tục
▪ Ví dụ: truyền 1 slideshow trên wed ⇒ dòng dữ liệu rời rạc là các slide, dòng dữ
liệu liên tục là âm thanh phải gắn với từng slide
o Đồng bộ 2 dòng dữ liệu liên tục
▪ Ví dụ: chạy 1 bộ phim với 2 dòng dữ liệu là video với audio
• Dựa trên đơn vị dữ liệu
• Ở mức đơn vị dữ liệu mà nhận luôn có 1 tiến trình chuyên thực hiện các thao tác đọc ghi 1 vài
dòng dữ liệu để đảm bảo các thao tác này đảm bảo tuân thủ theo các ràng buộc về đồng bộ và
thời gian
• Xem xét 1 bộ phim được biểu diễn bởi 2 dòng dữ liệu đầu vào là audio và video
• Dòng video với ảnh 320*240 px , mỗi px là 1 byte và mỗi đơn vị dữ liệu cho video sẽ là 76800
bytes
• Mỗi ảnh…
• Điểm yếu là các ứng dụng hoàn toàn chịu trách nhiệm hoàn toàn về việc đồng bộ hóa trong khi
chỉ có những cái hàm, thủ tục hay là các cái bộ thư viện cấp thấp ⇒ giải pháp là cung cấp cho ứng
dụng 1 cái giao diện để dễ dàng điều khiển các dòng và thiết bị.
• Với việc thêm vào tầng middleware, mỗi dòng sẽ có 1 giao diện đảm đương quản lý ⇒ kiểm soát
tốc độ hiển thị ảnh và đồng bộ về âm thanh
• NSD sẽ có trình điều khiển cho mỗi dòng dữ liệu tương ứng và trình điều khiển đó sẽ thông qua
các interface để điều chỉnh tốc độ với mục đích đồng bộ hóa các dòng
 Chương 3. Định danh trong Hệ Phân Tán
1. Tổng quan về tên, định danh, địa chỉ

• Một hệ thống phân tán được cấu thành từ rất nhiều các thực thể, mỗi thực thể lại cung ứng 1 tập hợp các tác vụ
nhất định
• Ví dụ, thực thể entity trên hình có thể cung ứng tác vụ 1,2,3
• Vậy để khai thác được những cái tác vụ được cung ứng bởi thực thể này ⇒ đầu tiên chúng ta phải xác định được
vị trí của thực thể trong hệ thống
• Chúng ta cần 1 cơ chế để lấy đầu vào là tên của thực thể ⇒ từ đó xác định được vị trí của thực thể ⇒ cơ chế đó
được thực hiện bởi 1 hệ thống định danh (naming system)

• Để đến được với các thực thể ⇒ ta cần đến được các access point (là điểm truy cập tương ứng của thực thể )
• Mỗi điểm truy cập thì đều được xác định vị trí bởi địa chỉ của nó
• Một thực thể có thể được gắn với nhiều hơn 1 access point
• Ví dụ: 1 máy tính có thể được kết nối với 2 mạng khác nhau nếu có 2 giao diện mạng
 • Ngoài ra, 1 thực thể có thể dịch chuyển giữa các access point
• 1 access point có thể gắn với 1 thực thể khác

⇒ nói cách khác, ta không thể dùng địa chỉ của access point để định danh đích xác 1 thực thể ⇒ cần 1 khái niệm khác để
định danh đích xác 1 thực thể ⇒ khái niệm định danh (identifier)

Định danh

• Đặc điểm
o 1 định danh chỉ đến nhiều nhất 1 thực thể
o Mỗi thực thể chỉ được xác định bởi 1 định danh (quan hệ 1-1 giữa định danh và thực thể)
o Mỗi định danh mãi mãi chỉ trỏ đến 1 thực thể

⇒ Hoàn toàn có thể định danh để xác định đích xác 1 thực thể

• Vấn đề: Cạn kiệt không gian tên

• Giải quyết vấn đề trên bằng cách
o Mở rộng không gian tên
o Tái sử dụng định danh

Phân giải tên & định danh thành địa chỉ

Với cơ chế phân giải tên và định danh, ta có thể thấy

• Mô hình tập trung (với việc dùng bảng ánh xạ tập trung giữa tên và địa chỉ là không phù hợp trong ngữ cảnh của
hệ thống phân tán)
• Vấn đề : vì không phù hợp với 1 hệ thống mạng cỡ lớn
• Do vậy, ta cần 1 hệ thống phân giải tên PHÂN TÁN
• Yêu cầu chung của những dịch vụ phân giải tên
o Quy mô : vô hạn về tên và miền tên
o Bền vững : chịu được các thay đổi
o Sẵn sàng chịu được lỗi , rủi ro về bảo mật

URL, URI và URN

• URI
o Xâu các kí tự để định danh tên của tài nguyên. Với sự biểu diễn tài nguyên trong 1 mạng, với các giao thức
cụ thể, được phân loại như là URL hoặc URN
o Có 5 phần
 ▪ scheme (sự xếp đặt)
▪ authority (nhà cung cấp)
▪ path (đường dẫn)
▪ query (truy vấn)
▪ fragment (phân mảnh)

• URN
o Chỉ số ISBN 0486275574 (run:isbn:0-486-27557-4)
• URL
o file:///home/username/RomeoAndJuliet.pdf

2. Không gian tên phẳng

2.1. Khái niệm

• Chuỗi bit, chuỗi kí tự không có cấu trúc (khi mà người dùng nhìn vào chuỗi này ⇒ không có í niệm gì về không gian
vị trí của thực thể)
• Không cho biết thông tin về vị trí
• Nhiệm vụ của hệ thống định danh đối với những kiểu không gian tên này đó là lấy tên ở đầu vào và xác định được
vị trí của thực thể đó ⇒ cho biết tên, hãy xác định vị trí
• 4 giải pháp để xác định vị trí của thực thể trong không gian tên phẳng
o Các giải pháp thông thường
o Home-based (dựa vào home agent)
o DHT (bảng băm phân tán)
o Cách tiếp cận phân cấp

2.2. Các giải pháp thông thường

a) Quảng bá/thông báo nhóm

• Điều kiện để hệ thống có thể triển khai được giải pháp này đó là: hệ thống phải hỗ trợ việc trao đổi thông tin thông
qua quảng bá
o Nút cần thực hiện phân giải tên sẽ chứa định danh cần phân giải và quảng bá tới tất cả các thực thể trong
hệ thống
o Thực thể nào có đúng định danh trong thông báo nhận được sẽ quảng bá lại 1 thông báo chứa định danh
kèm với địa chỉ của mình
o Tất cả những thực thể khác sẽ nhận được thông báo này và sẽ ghi lại cái thông tin ánh xạ giữa định danh
và vị trí của thực thể nói trên
• Giải pháp kém hiệu quả khi mà kích thước mạng tăng (khi áp dụng vào 1 hệ thống mạng cỡ lớn)
• Thay thế quảng bá bằng truyền thông nhóm trên mạng điểm điểm. Khi một thực thể gửi một thông báo nhóm,
các bộ định tuyến sẽ thực hiện theo chính sách nỗ lực tối đa để chuyển các thông báo này tới đích

Ví dụ điển hình của giải pháp quảng bá : giao thức ARP

• Giao thức được dùng trong mạng LAN với mục đích là phân giải từ địa chỉ IP sang địa chỉ MAC
 • Ta biết rằng trao đổi thông tin trong LAN là sử dụng địa chỉ MAC
• Vì vậy cần 1 giải pháp để chuyển đổi từ địa chỉ IP cục bộ sang địa chỉ MAC ⇒ giao thức ARP thực hiện điều này và
nó dựa trên cơ chế quảng bá
• 1 nút khi cần biết địa chỉ MAC từ 1 địa chỉ IP cục bộ của 1 nút ⇒ nó sẽ quảng bá yêu cầu tìm kiếm gọi là ARP
Request kèm theo địa chỉ IP đó đến tất cả các nút trong mạng
• 1 nút nào khi nhận được thông điệp đó sẽ tra xem có đúng là cái địa chỉ IP cục bộ của mình có nằm trong ARP
Request hay là không ? Nếu đúng thì nó sẽ trả lời nút yêu cầu kèm theo địa chỉ MAC của mình

b) Chuyển tiếp con trỏ (Forwarding Pointers)

• Ý tưởng : mỗi lần mà thực thể thực hiện 1 cái dịch chuyển ⇒ nó sẽ để lại 1 con trỏ ánh xạ từ vị trí cũ ⇒ vị trí mới
của nó trong hệ thống
• Ví dụ như trên hình, 1 đối tượng đang nằm ở tiến trình 3 và nó đã thực hiện dịch chuyển từ tiến trình P3 sang tiến
trình P4 và để lại 1 cái con trỏ từ vị trí cũ của nó sang vị trí mới
• Đối với các tiến trình client khác, khi thực hiện tìm kiếm đối tượng này thì yêu cầu gửi đến tiến trình P3 và nó sẽ
được chuyển tiếp theo con trỏ đến tiến trình P4, nơi mà đối tượng đang nằm ở vị trí hiện tại
• Cơ chế chuyển tiếp này là hoàn toàn trong suốt đối với các tiến trình client
• Lấy ví dụ P1 và P2 sẽ không biết thực tế là yêu cầu đã được chuyển tiếp đi trong 1 chuỗi con trỏ để đến được
object mà nó muốn tìm kiếm
 • Vấn đề chính đối với chuyển tiếp con trỏ
o Thời gian hoạt động của hệ thống càng lâu thì các dịch chuyển của các thực thể trong hệ thống càng nhiều
o Như vậy, nó để lại 1 cái khối lượng các cái con trỏ vô cùng lớn và hệ thống phải duy trì quản lí đối với các
chuỗi con trỏ đó
o Nếu chỉ cần 1 nút nằm giữa chuỗi chuyển tiếp con trỏ đó mà bị tắt, bị hỏng thì tất cả thực thể mà có chuỗi
con trỏ dịch chuyển qua nút đó sẽ đều bị không thể nào tìm kiếm được nữa ⇒ giải pháp đối với vấn đề
này là cơ chế tái định hướng con trỏ
o Như hình a, sau khi 1 nút đến được với object mà muốn tìm kiếm ⇒ xây dựng 1 cái shortcut (1 con trỏ đi
tắt đến thẳng nút đích) ⇒ sau đó tìm cách loại bỏ chuỗi con trỏ ban đầu mà thực hiện tìm kiếm đến đối
tượng đó
o Với cơ chế này ⇒ số lượng các chuỗi con trỏ sẽ giảm dần

2.3. Giải pháp Home-based

• Mỗi thực thể sẽ được gắn với 1 home agent để quản lý vị trí
• Mỗi thực thể dịch chuyển phải gửi lại về cho home-agent địa chỉ hiện tại của nó
• Và như vậy, home agent sẽ quản lý danh sách các thực thể và nó sẽ luôn biết được vị trí hiện tại của các thực thể
đó
 • Mỗi lần client muốn phân giải địa chỉ của 1 thực thể thì nó chỉ việc gửi yêu cầu đến cho home-agent tương ứng và
home-agent sẽ gửi trả lời địa chỉ hiện tại của thực thể đó cho client

• Gỉai pháp này có 1 nhược điểm là thời gian hệ thống càng lâu thì các thực thể có thể chuyển động ra rất xa home-
agent ⇒ nảy sinh vấn đề là đôi khi client rất gần đối với thực thể tìm kiếm rồi nhưng mà lại phải gửi 1 yêu cầu rất
là xa đến home-agent và ngược lại nhận 1 câu trả lời đi từ rất xa

⇒ giải pháp là gắn lại 1 agent mới cho 1 thực thể khi thực thể đó đã chuyển động đủ lâu ở 1 vị trí đủ xa home-agent cũ ⇒
tối ưu hơn về cái quãng đường gửi yêu cầu và trả lời

2.4. Giải pháp sử dụng hàm băm phân tán

2.5. Giải pháp phân cấp

• Ở đây, mạng sẽ được chia ra làm tập hợp các domain

• Mỗi domain đỉnh đơn (single top domain) sẽ nối với toàn bộ mạng
• Mỗi domain lại chia ra làm các domain con
• Domain mức thấp nhất được gọi là domain nút lá ứng với 1 mạng LAN hay 1 thiết bị di động trong máy di động
• Mỗi domain có 1 directory node ⇒ nó sẽ kiểm soát tất cả các nút thành viên trong domain đó
• Cấu trúc này sẽ dẫn đến 1 mô hình cây thư mục các nút
• Directory node của domain level cao nhất gọi là nút root biết thông tin về tất cả các thực thể
• Thông tin của 1 thực thể sẽ có trong tất cả các nút thư mục từ nút lá cho đến nút gốc
• Trong 1 nút thư mục bản ghi có dạng thực thể , con trỏ đến nút thư mục con chứa thông tin về thực thể
• Nếu có 2 địa chỉ ⇒ sẽ có 2 bản ghi trỏ vào 2 nút thư mục con chứa 2 địa chỉ riêng biệt đó
• Để làm giúp tối ưu hơn cho quá trình tìm kiếm ⇒ sử dụng cơ chế bộ đệm
• Khi mà hệ thống xác định 1 thực thể chuyển động loanh quanh trong domain ở 1 khoảng thời gian đủ lâu ⇒ sẽ lưu
lại cái dir node quản lý domain đó ⇒ lần sau khi muốn tìm kiếm thì chỉ cần tra dir node là tìm được
Đối với TH mà thực thể có 2 địa chỉ thì dir node M của 1 cái domain mà nó chứa bao trùm cả 2 địa chỉ thì bản ghi của nó
sẽ có 2 bản ghi trỏ đến 2 subdomain đối với 2 địa chỉ này của thực thể này

• Nếu muốn thêm 1 địa chỉ vào thì ở tại địa chỉ cần thêm sẽ tự thêm vào ⇒ sau đó tiếp tục forward yêu cầu thêm
địa chỉ của thực thể đó lên cho dir node của domain cấp trên
• Và cứ như vậy, nó sẽ forward cho đến khi gặp dir node có chứa thông tin của địa chỉ cũ ⇒ tự chèn thêm 1 bản ghi
nữa vào và dừng quá trình cập nhật lại
• Đối với quá trình xóa cũng tương tự ⇒ xóa dần và sẽ gửi forward yêu cầu cần xóa cho dir node ở cấp trên đến khi
nào gặp dir node có cả 2 thông tin của địa chỉ đó thì nó sẽ xóa 1 nhánh có địa chỉ cần xóa

3. Không gian tên có cấu trúc

Đối với người dùng khi đọc không gian tên có cấu trúc này ⇒ có thể mường tượng được vị trí của thực thể trong hệ thống
 • Các cây được tổ chức vào các không gian tên
• Được biểu diễn như 1 đồ thị gán nhãn với 2 kiểu node
o Node lá : là nút mà không có nhánh đi ra nào , thường lưu thông tin các thực thể mà nó biểu diễn như địa
chỉ để cho các client có khả năng truy cập đến
o Cụ thể node lá được biểu diễn = hình tròn
o Kiểu node thứ 2 là nút thư mục (dir node) : gồm các nhánh đi ra và mỗi nhánh được gán nhãn bởi 1 tên
(biểu diễn = hình vuông)
o Ta thấy dir node vừa có nhánh đi vào, vừa có nhánh đi ra
o Mỗi nút trong đồ thị tên được xem như 1 thực thể của HPT và nó có 1 định danh
o Mỗi nút thư mục lại lưu trữ 1 bảng gọi là dir table (thí dụ dir table của nút n1)
o Và mỗi nhánh đi ra được biểu diễn bởi 1 cặc thông tin (nhãn của nhánh, định danh của nút đi ra)
o VD: n1 có 3 nhánh đi ra là elke,max,steen ứng với 3 nút đầu ra là n2 n3 n4 thì đã được lưu trong bảng dir
table
o Nút k có nhánh vào, chỉ có nhánh ra ⇒ root (n0)
o Đường dẫn trong 1 cây định danh là 1 chuỗi nhãn tương ứng với các nhánh trong đường dẫn đó
(/home/steen/mbox)
o Nếu đường dẫn đầu tiên trong đường dẫn là nút root ⇒ đường dẫn tuyệt đối, ngược lại là tương đối
o 1 nút có thể có nhiều đường dẫn đến nó (VD nút n5)

Trong không gian tên có cấu trúc, ta sẽ đi tìm hiểu 2 khái niệm liên kết là liên kết vật lý và liên kết biểu tượng
 • Cho phép 1 nút có thể có nhiều hơn 1 liên kết trỏ đến nó
• VD: nút n5 có 2 liên kết ⇒ có 2 đường dẫn

• Đường dẫn tới n6 chứa thông tin về đường dẫn đến nút n5
• Trong hệ thống quản lý tệp của Linux cũng có ví dụ về liên kết biểu tượng

Dịch vụ tên phân tán

• Đối với 1 dịch vụ tên phân tán ⇒ đảm bảo 3 chức năng chính
o Đăng kí, loại bỏ các định danh
o Phân giải các định danh
o Tìm kiếm các định danh
• Các dịch vụ này phải có tính chất
o Phân tán trên nhiều máy chủ khác nhau ⇒ Cần phân tán không gian tên
 • Được phân cấp ra 3 mức
o Mức toàn thể
o Mức quản trị
o Mức quản lý
• Với 3 mức này, chúng khác nhau về yêu cầu về hiệu năng của các máy chủ phân giải tên miền
• Sự ổn định/ bất ổn định của các máy chủ
o Với những nút ở tầng trên như mức toàn thể ⇒ hiệu năng đối với các máy chủ phân giải này phải rất cao,
lớn hơn rất nhiều so với mức ở dưới hơn nhưng ngược lại, độ ổn định của chúng lại cao hơn rất nhiều, sự
thay đổi diễn ra chủ yêu ở mức quản lý

Có 2 cơ chế phân giải tên là phân giải tên không đệ quy và phân giải tên đệ quy

• Nút yêu cầu phân giải tên ở phía client

• Đầu tiên gửi đến cho server ở mức cao nhất (máy chủ tên miền ở mức cao nhất là máy chủ root)
 • Sau đó máy chủ root trả về cho client resolver địa chỉ IP của máy chủ phân giải tên miền ở nút tiếp theo
• Qúa trình đc lặp lại cho đến bao giờ đến với nút lá (tức là nút thực thể mà resolver muốn tìm kiếm địa chỉ)
• Sau đó máy chủ tên miền ở mức dưới cùng này trả về cho client resolver địa chỉ mà cần phân giải

• Đầu tiên gửi đến cho server ở mức cao nhất

• Sau đó các máy chủ tên miền ở trong vùng này sẽ tự phân giải với nhau (nút root sẽ gửi dần xuống cho các nút ở
phía dưới hơn )
• Sau khi đến nút cuối cùng, có địa chỉ cần tìm thì gửi ngược lên trên

Ví dụ điển hình của cơ chế phân giải tên có cấu trúc

4. Định danh dựa trên thuộc tính

Ở phần này sẽ tìm hiểu các cơ chế định danh dựa trên 1 không gian tên được xây dựng bằng các thuộc tính của các thực
thể
4.1. Dịch vụ thư mục

• Trong CNPM, 1 thư mục là 1 ánh xạ giữa tên và giá trị

• Với tập thực thể được xem xét ở trong hệ thống ⇒ cần 1 tập các thuộc tính chung để thực hiện việc tìm kiếm trên
CSDL với các thực thể
• Lấy VD: tìm kiếm 1 người mà k biết tên người đó mà chỉ biết các thuộc tính như số đt, giới tính, chiều cao ,… hoặc
muốn tìm 1 cái email mà chỉ biết các thuộc tính như người gửi, người nhận ,…
• ⇒ Việc chọn được các thuộc tính phù hợp với tất cả các thực thể là vô cùng khó khăn, ví dụ như là quản lí CSDL ⇒
cần thống nhất cách mô tả các cái tài nguyên
• Có thể sử dụng tập thuộc tính cứng/động
o Thuộc tính cứng: tập thuộc tính tối ưu
o Thuộc tính động: cần sử dụng khung mô tả tập thuộc tính (Resource Description Framework)
▪ RDS mô tả tài nguyên = tập bộ 3 (subject, predicate,object)
▪ VD: (Person, name, Alice)
• Với cách thức lưu trữ này thì toàn bộ phải lưu trữ trên 1 máy , tuy nhiên ta cần các kỹ thuật để áp dụng vào HT
mà dữ liệu được phân tán nhiều máy.

• Là 1 hướng tiếp cận dịch vụ thư mục phân tán kết hợp không gian tên có cấu trúc và thuộc tính
• Dịch vụ bao gồm nhiều bản ghi tương tự như bản ghi của DNS
• Mỗi bản ghi là tập hợp các cặp (thuộc tính, giá trị)

• Đc dùng để biểu diễn tập các bản ghi của LDAP theo kiểu phân cấp
• Trong đó, mỗi nút biểu diễn 1 mục của LDAP
 Chương 4. Đồng bộ hóa trong Hệ Phân Tán
Các tiến trình thực hiện đồng bộ hóa như nào?

Bài toán 1

• Khi có nhiều tiến trình đều muốn truy cập vào cùng một tài nguyên chia sẻ dùng chung
• Tuy nhiên tài nguyên đó trong 1 thời điểm chỉ đủ phục vụ một hoặc vài tiến trình
→ Các tiến trình cần cơ chế lần lượt vào sử dụng tài nguyên đó

Bài toán 2

• Các tiến trình cần thống nhất thứ tự các sự kiện

*Cả hai bài toán cần xét trên ngữ cảnh hệ phân tán (các tiến trình nằm trên các máy tính độc lập)

→ Phức tạp vì không có đồng hồ dùng chung, bộ nhớ chia sẻ dùng chung

1. Đồng bộ hóa đồng hồ vật lý

(Đồng bộ hóa dựa trên giá trị thời gian thực)
1.1. Network Time Protocol

• B: Máy chủ thời gian (tức là giả sử thời gian máy B luôn đúng)
• A: Máy cần đồng bộ
• A gửi cho B tại thời điểm T1 (của máy A), B nhận được tại thời điểm T2 (của máy B)
• B gửi cho A tại thời điểm T3 (của máy B), A nhận được tại thời điểm T4 (của máy A)
• Công thức tính 𝜙 (độ lệch của đồng hồ máy A so với máy B)
→ Sau khi tính được 𝜙 thì đồng hồ vật lý máy A tự hiệu chỉnh đồng hồ ở máy mình

1.2. Thuật toán Berkeley

(Hướng đến việc đồng bộ hóa đồng hồ vật lý các máy với nhau, tức chỉ cần thời gian các máy giống nhau
chứ không quan tâm chính xác hay không)

Xét ví dụ dưới

• 3 máy tính được kết nối nhau qua hạ tầng mạng

• Mỗi máy tính có giá trị thời gian lệch nhau
Bước 1: Một máy được bầu làm Time deamon, gửi giá trị của máy mình đến các máy còn lại

Bước 2: Các máy khác trả lời độ lệch đồng hồ vật lý máy mình với giá trị quảng bá của time deamon

Bước 3: Time deamon tính ra giá trị trung binh và gửi lại cho các máy giá trị cần phải hiệu chỉnh

1.3. Đồng bộ hóa đồng hồ vật lý trong các mạng không dây
Ở các mạng không dây thì các thiết bị không cắm vào cùng một nguồn điện mà chạy bởi pin.

→ Cần giải thuật đồng bộ hóa sao cho tối ưu các thao tác gửi – nhận các thống điệp, tránh làm lãng phi
năng lượng của các thiết bị

Thuật toán RBS (Reference Broadcast Synchronization)

• Có một nút A (không trực tiếp tham gia quá trình đồng bộ), chỉ có việc là liên tục quảng bá thông
điệp đến các nút khác trong hệ thống
• Nút B, C là các nút tham gia quá trình đồng bộ
Σ𝑀
𝑘=1 (𝑇𝑏,𝑘 −𝑇𝑐,𝑘 )
Ta có Offset[𝑏, 𝑐] =
𝑀

𝑇𝑏,𝑘 và 𝑇𝑐,𝑘 là các thời điểm nút B, C nhận được thông điệp quảng bá từ A
 Offset là độ lệch thời gian của nút B đối với C

Offset = trung bình cộng của độ lệch thời gian mỗi lần nhận được từ A của B và C

→ Đặc biệt ở đây là sau khi tính được offset, B sẽ không tự hiệu chỉnh mà chỉ lưu lại thông tin mình lệch
với C bao nhiêu (cho các lần trao đổi thông tin về sau)

2. Đồng bộ hóa đồng hồ logic

(Đồng bộ hóa dựa trên thứ tự các sự kiện)

2.1. Cơ chế đồng bộ hóa đồng hồ logic của Lamport

- Mối quan hệ “Xảy ra trước” (happens – before) diễn ra với 2 ngữ cảnh sau

• Nếu a và b là các sự kiện của cùng 1 tiến trình, và a xảy ra trước b, thì a → b là đúng.
• Nếu a là sự kiện gửi một thông điệp từ một tiến trình, b là sự kiện nhận của thông điệp đó ở 1 tiến
trình khác, thì a → b

- “Xảy ra trước” là mối quan hệ bắc cầu: a → b và b → c thì a → c

- Với các sự kiện tương tranh a và b thì không tồn tại cả a → b lẫn b → a

• Có 3 tiến trình P1, P2, P3 với clockrate khác nhau

 • Có 4 thông điệp trao đổi giữa 3 tiến trình trên
• M1, m2 thì đúng theo nguyên lý Lamport (thời điểm gửi xảy ra trước thời điểm nhận)
• M3, m4 thì vi phạm
→ Cần có quá trình cập nhật lại đồng hồ vật lý để đúng với nguyên lý Lamport (nhận phải
sau gửi)

Quá trình cập nhật bộ đếm Ci cho tiến trình Pi

• Cập nhật bộ đếm Ci cho tiến trình Pi

• Trước mỗi sự kiện, Pi thực thi: Ci ← Ci + 1
• Khi tiến trình Pi gửi thông điệp m tới Pj , nó sẽ đặt timestamp của m là ts (m) bằng với giá trị Ci
(sau khi thực hiện bước 1).
• Khi nhận được thông điệp m, tiến trình Pj cập nhật lại giá trị bộ đếm cục bộ: Cj ← max{Cj , ts (m)},
sau đó sẽ chuyển thông điệp lên tầng ứng dụng.

Các quá trình hiệu chỉnh đều thực hiện trên Middleware

Áp dụng cho m3, m4:

• Timestamp của m3 là 60 + 1 = 61. P2 sẽ cập nhật thời điểm nhận = max {61, 56} = 61
• Timestamp của m4 là 69 + 1 = 70. P1 sẽ cập nhật thời điểm nhận = max {70, 54} = 70

→ Đảm bảo được nguyên lý của Lamport

Ứng dụng

2.2. Vector Clocks

Vấn đề của Lamport là chưa xét thứ tự xảy ra trước – sau của sự kiện xảy ra trong cùng một tiến trình.

Cần đảm bảo thứ tự gửi thông điệp của các tiến trình ~ thứ tự nhận thông điệp của các tiến trình đó

Ví dụ cái hình trên

• Thời điểm nhận m1 phải trước thời điểm gửi m3 của P2 (quan hệ nhân – quả)
• Thời điểm nhận m2 không có quan hệ gì với thời điểm gửi m3 của P2 (quan hệ tương tranh)
→ Lamport chưa xem xét gì các quan hệ trên

Vector clock được xây dựng bằng cách để mỗi tiến trình Pi quản lý một véc-tơ 𝑉𝐶𝑖 với 2 tính chất sau:

• 𝑉𝐶𝑖 [𝑖] là số các sự kiện đã xảy ra ở 𝑃𝑖 nói cách khác, 𝑉𝐶𝑖 [𝑖] là đồng hồ logic cục bộ của 𝑃𝑖
• Nếu 𝑉𝐶𝑖 [𝑗] = 𝑘 thì 𝑃𝑖 biết đã có k sự kiện xảy ra ở 𝑃𝑗 . Là tri thức của 𝑃𝑖 về thời gian cục bộ ở 𝑃𝑗 .

Cập nhật vector clock để đảm bảo tính chất 2:

• Trước mỗi sự kiện, Pi thực thi: VCi [ i ] ← VCi [i ] + 1.

• Khi Pi gửi thông điệp m tới Pj , nó đặt véc-tơ timestamp ts(m) vào m bằng với VCi sau khi thực
hiện bước 1.
• Khi nhận được 1 thông điệp m, tiến trình Pj cập nhật lại véc-tơ của mình: VCj [k ] ← max{VCj [k ],
ts (m)[k]} với mọi k, sau đó mới gửi thông điệp lên tầng ứng dụng.

• Xét 3 tiến trình P0, P1, P2.

3. Các thuật toán loại trừ lẫn nhau

3.1. Giải thuật tập trung

3.2. Giải thuật phân tán

Muốn vào dùng tài nguyên à quảng bá thông điệp request. Với mỗi tiến trình nhận được request:

• Nếu đang không dùng và không muốn dùng TN: Trả lời OK
• Nếu đang dùng: không trả lời và lưu vào hàng đợi
• Nếu đang không dùng nhưng cũng muốn dùng: so sánh timestamp
Chỉ vào dùng TN khi nhận đủ các OK của các tiến trình khác

3.3. Giải thuật Token Ring

Khởi đầu Tiến trình P0 có token để vào sử dụng TN. Token được truyền đi trong vòng topo Từ Pi truyền
đến P(i+1)mod N

Khi một tiến trình nhận được token:

• Tự kiểm tra xem có muốn vào dùng TN không

• Nếu không, truyền token cho nút kế tiếp
• Nếu có, giữ lại token. Dùng xong thì truyền tiếp đi

4. Các thuật toán bầu chọn

4.1. Giải thuật Bully
1. P gửi thông điệp ELECTION cho tất cả các tiến trình có ID lớn hơn mình

• Nếu không có tiến trình nào trả lời (sau timeout), P biết mình được chọn
• Chỉ cần 1 tiến trình trả lời, P biết mình không được chọn và dừng lại.

2. Quá trình trên lặp lại với các tiến trình nhận được ELECTION
4.2. Giải thuật RING

4.3. Giải thuật bầu chọn cho mạng không dây

4.4. Giải thuật bầu chọn cho mạng cỡ lớn
Yêu cầu cho các giải thuật chọn superpeers:

• Các nút thường khi truy cập đến các superpeers phải có độ trễ thấp
• Các superpeers phải được phân tán đều trong toàn bộ mạng overlay
• Phải định trước tỷ lệ các nút superpeers trong tổng số các nút trong mạng
• Mỗi nút superpeers không được phục vụ quá nhiều nút thường