Sommerville, Ian. Kỹ thuật phần mềm - file n1.doc. III.03.2. a Ứng dụng máy chủ tập tin. Mục tiêu của hoạt động phân tán

Trong chương trước, chúng ta đã xem xét các hệ thống đa bộ xử lý được kết hợp chặt chẽ với bộ nhớ dùng chung, cấu trúc dữ liệu hạt nhân dùng chung và một nhóm dùng chung mà từ đó các tiến trình được gọi để thực thi. Tuy nhiên, thông thường, để đảm bảo việc chia sẻ tài nguyên, người ta mong muốn phân phối các bộ xử lý theo cách sao cho chúng độc lập với môi trường vận hành và các điều kiện vận hành. Ví dụ: giả sử người dùng máy tính cá nhân cần truy cập các tệp nằm trên một máy lớn hơn, nhưng đồng thời vẫn duy trì quyền kiểm soát máy tính cá nhân. Mặc dù một số chương trình như uucp hỗ trợ truyền tệp mạng và các chức năng mạng khác, việc sử dụng chúng sẽ không bị người dùng ẩn vì người dùng biết rằng mình đang làm việc trên mạng. Ngoài ra, cần lưu ý rằng các chương trình như soạn thảo văn bản, chúng không hoạt động với các tệp đã xóa như với các tệp thông thường. Người dùng phải có chức năng hệ thống UNIX tiêu chuẩn và ngoại trừ các hình phạt về hiệu suất có thể xảy ra, người dùng sẽ không gặp phải bất kỳ vi phạm ranh giới máy nào. Vì vậy, ví dụ, công việc của các chức năng hệ thống mở và đọc với các tệp trên máy từ xa sẽ không khác với công việc của chúng với các tệp thuộc hệ thống cục bộ.

Kiến trúc hệ thống phân tán được thể hiện trong Hình 13.1. Mỗi máy tính trong hình là một mô-đun độc lập bao gồm CPU, bộ nhớ và các thiết bị ngoại vi. Việc tuân thủ mô hình không bị vi phạm ngay cả khi máy tính không có hệ thống tệp cục bộ: nó phải có các thiết bị ngoại vi để liên lạc với các máy khác và tất cả các tệp thuộc về nó có thể được đặt trên một máy tính khác. Bộ nhớ vật lý có sẵn cho mỗi máy độc lập với các tiến trình đang chạy trên các máy khác. Tính năng này phân biệt các hệ thống phân tán với các hệ thống đa bộ xử lý được kết hợp chặt chẽ đã thảo luận trong chương trước. Theo đó, nhân hệ thống trên mỗi máy hoạt động độc lập với điều kiện bên ngoài hoạt động của môi trường phân tán.

Hình 13.1. Mô hình hệ thống có kiến trúc phân tán

Các hệ thống phân tán, được mô tả rõ ràng trong tài liệu, thường được chia thành các loại sau:

Các hệ thống ngoại vi, là các nhóm máy có điểm chung riêng biệt và được kết nối với một máy (thường lớn hơn). Bộ xử lý ngoại vi chia sẻ khối lượng công việc của chúng với bộ xử lý trung tâm và chuyển tiếp tất cả các cuộc gọi đến hệ điều hành tới nó. Mục đích của hệ thống ngoại vi là tăng hiệu suất mạng tổng thể và cho phép bộ xử lý được dành riêng cho một quy trình duy nhất trong môi trường vận hành UNIX. Hệ thống chạy như một mô-đun riêng biệt; Không giống như các mô hình hệ thống phân tán khác, hệ thống ngoại vi không có quyền tự chủ thực sự, ngoại trừ các trường hợp liên quan đến gửi tiến trình và phân bổ bộ nhớ cục bộ.

Các hệ thống phân tán như "Newcastle", cho phép liên lạc từ xa bằng cách sử dụng tên của các tệp từ xa trong thư viện (tên được lấy từ bài báo "The Newcastle Connection" - xem). Các tệp bị xóa có thông số kỹ thuật (tên thành phần) chứa các ký tự đặc biệt hoặc các ký tự đặc biệt trong đường dẫn tìm kiếm. thành phần bổ sung tên đứng trước thư mục gốc của hệ thống tập tin. Việc triển khai phương pháp này không liên quan đến việc thực hiện các thay đổi đối với cốt lõi của hệ thống, do đó nó đơn giản hơn các phương pháp khác được thảo luận trong chương này nhưng kém linh hoạt hơn.

Các hệ thống phân tán hoàn toàn “minh bạch”, trong đó để truy cập các tệp nằm trên các máy khác, chỉ cần chỉ định tên ghép tiêu chuẩn của chúng là đủ; Trách nhiệm của kernel là nhận ra những tập tin này đã bị xóa. Đường dẫn tìm kiếm tệp, được chỉ định bằng tên đủ điều kiện của chúng, vượt qua ranh giới máy tại các điểm gắn kết, bất kể có bao nhiêu điểm như vậy được hình thành khi gắn hệ thống tệp trên đĩa.

Trong chương này chúng ta sẽ xem xét kiến trúc của từng mô hình; tất cả thông tin được cung cấp không dựa trên kết quả của những diễn biến cụ thể mà dựa trên thông tin được công bố trong các bài báo kỹ thuật khác nhau. Điều này giả định rằng việc đánh địa chỉ, định tuyến, kiểm soát luồng, phát hiện và sửa lỗi là trách nhiệm của các mô-đun giao thức và trình điều khiển thiết bị, nói cách khác, mỗi mô hình độc lập với mạng đang được sử dụng. Các ví dụ về việc sử dụng các hàm hệ thống được đưa ra trong phần tiếp theo dành cho các hệ thống ngoại vi hoạt động tương tự đối với các hệ thống như Newcastle và đối với các hệ thống hoàn toàn minh bạch, điều này sẽ được thảo luận sau; Do đó, chúng ta sẽ xem xét chúng một cách chi tiết một lần và trong các phần dành cho các loại hệ thống khác, chúng ta sẽ tập trung chủ yếu vào các đặc điểm giúp phân biệt các mô hình này với tất cả các mô hình khác.

13.1 BỘ XỬ LÝ NGOẠI VỆ

Kiến trúc hệ thống ngoại vi được thể hiện trong Hình 13.2. Mục đích của cấu hình này là cải thiện hiệu suất mạng tổng thể bằng cách phân phối lại các tiến trình đang chạy giữa bộ xử lý trung tâm và ngoại vi. Mỗi bộ xử lý ngoại vi không có thiết bị ngoại vi cục bộ nào khác ngoài những thiết bị ngoại vi cần thiết để giao tiếp với bộ xử lý trung tâm. Hệ thống tập tin và tất cả các thiết bị đều thuộc quyền sử dụng của bộ xử lý trung tâm. Giả sử rằng tất cả các tiến trình của người dùng chạy trên bộ xử lý ngoại vi và không di chuyển giữa các bộ xử lý ngoại vi; Sau khi được chuyển đến bộ xử lý, chúng vẫn ở đó cho đến khi hoàn thành. Bộ xử lý ngoại vi chứa phiên bản nhẹ của hệ điều hành được thiết kế để xử lý các cuộc gọi cục bộ đến hệ thống, quản lý các ngắt, phân bổ bộ nhớ, làm việc với các giao thức mạng và với trình điều khiển thiết bị để liên lạc với bộ xử lý trung tâm.

Khi hệ thống được khởi tạo trên bộ xử lý trung tâm, kernel sẽ tải hệ điều hành cục bộ trên mỗi bộ xử lý ngoại vi thông qua đường truyền thông. Bất kỳ quy trình nào chạy trên thiết bị ngoại vi đều được liên kết với quy trình vệ tinh thuộc bộ xử lý trung tâm (xem); Khi một quy trình chạy trên bộ xử lý ngoại vi gọi một chức năng hệ thống yêu cầu riêng các dịch vụ của bộ xử lý trung tâm, quy trình ngoại vi sẽ giao tiếp với đồng hành của nó và yêu cầu được gửi đến bộ xử lý trung tâm để xử lý. Quá trình vệ tinh thực thi chức năng hệ thống và gửi kết quả trở lại bộ xử lý ngoại vi. Mối quan hệ giữa một quy trình ngoại vi và đồng hành của nó tương tự như mối quan hệ máy khách-máy chủ mà chúng ta đã thảo luận chi tiết trong Chương 11: quy trình ngoại vi hoạt động như một máy khách của đồng hành của nó, hỗ trợ các chức năng hệ thống tệp. Trong trường hợp này, tiến trình máy chủ từ xa chỉ có một máy khách. Trong Phần 13.4 chúng ta sẽ xem xét các tiến trình máy chủ có nhiều máy khách.

Hình 13.2. Cấu hình hệ thống ngoại vi

Hình 13.3. Định dạng tin nhắn

Khi một quy trình ngoại vi gọi một chức năng hệ thống có thể được xử lý cục bộ, kernel không cần gửi yêu cầu đến quy trình đồng hành. Vì vậy, ví dụ, để có được bộ nhớ bổ sung một tiến trình có thể gọi hàm sbrk để thực thi cục bộ. Tuy nhiên, nếu các dịch vụ của đơn vị xử lý trung tâm được yêu cầu, chẳng hạn như để mở một tệp, thì kernel sẽ mã hóa thông tin về các tham số được truyền cho hàm được gọi và các điều kiện thực thi của tiến trình thành một thông báo được gửi đến tiến trình đồng hành (Hình 13.3) . Thông báo bao gồm một dấu hiệu cho biết rằng chức năng hệ thống đang được thực thi bởi một quy trình đồng hành thay mặt cho khách hàng, các tham số được truyền cho chức năng và dữ liệu về môi trường thực thi quy trình (ví dụ: mã nhận dạng người dùng và nhóm), trong đó chức năng khác nhau là khác nhau. Phần còn lại của thông báo là dữ liệu có độ dài thay đổi (chẳng hạn như tên tệp đủ điều kiện hoặc dữ liệu được ghi bởi chức năng ghi).

Quá trình vệ tinh chờ yêu cầu từ quá trình ngoại vi; Khi nhận được yêu cầu, nó sẽ giải mã thông báo, xác định loại chức năng hệ thống, thực thi nó và chuyển đổi kết quả thành phản hồi được gửi đến quy trình ngoại vi. Phản hồi, ngoài các kết quả của chức năng hệ thống, bao gồm một thông báo lỗi (nếu có), số tín hiệu và mảng dữ liệu có độ dài thay đổi, chẳng hạn như chứa thông tin được đọc từ một tệp. Quá trình ngoại vi tạm dừng cho đến khi nhận được phản hồi; khi nhận được, nó sẽ giải mã và truyền kết quả cho người dùng. Đây là sơ đồ chung để xử lý các cuộc gọi đến hệ điều hành; Bây giờ chúng ta hãy chuyển sang xem xét chi tiết hơn về các chức năng riêng lẻ.

Để giải thích cách hệ thống ngoại vi hoạt động, chúng ta sẽ xem xét một số chức năng: getppid, open, write, fork, exit và signal. Hàm getppid khá đơn giản vì nó liên quan đến hình thức đơn giản yêu cầu và phản hồi được trao đổi giữa các bộ xử lý ngoại vi và trung tâm. Nhân trên bộ xử lý ngoại vi tạo ra một thông báo cho biết chức năng được yêu cầu là hàm getppid và gửi yêu cầu đến bộ xử lý trung tâm. Quá trình vệ tinh trên bộ xử lý trung tâm đọc tin nhắn từ bộ xử lý ngoại vi, giải mã loại chức năng hệ thống, thực thi nó và nhận mã định danh của cấp độ gốc của nó. Sau đó, nó tạo ra phản hồi và truyền nó đến một quy trình ngoại vi đang chờ ở đầu bên kia của đường truyền. Khi bộ xử lý ngoại vi nhận được phản hồi, nó sẽ chuyển nó tới tiến trình được gọi là chức năng hệ thống getppid. Nếu tiến trình ngoại vi lưu trữ dữ liệu (chẳng hạn như ID tiến trình cha) trong bộ nhớ cục bộ, thì nó hoàn toàn không cần phải giao tiếp với tiến trình đồng hành của nó.

Nếu chức năng hệ thống mở được gọi, quy trình ngoại vi sẽ gửi một thông báo tương ứng đến đồng hành của nó, bao gồm tên tệp và các tham số khác. Nếu thành công, quy trình vệ tinh sẽ phân bổ một chỉ mục và điểm vào cho bảng tệp, phân bổ một mục nhập bảng mô tả tệp người dùng trong không gian của nó và trả về bộ mô tả tệp cho quy trình ngoại vi. Tất cả thời gian này, ở đầu bên kia của đường dây liên lạc, quá trình ngoại vi đang chờ phản hồi. Anh ta không có bất kỳ cấu trúc nào có thể tùy ý sử dụng để lưu trữ thông tin về tệp đang được mở; Điều khiển được trả về bởi open là một con trỏ tới một mục trong bảng mô tả tệp người dùng do quy trình đồng hành sở hữu. Kết quả của hàm được thể hiện trong hình 13.4.

Hình 13.4. Gọi hàm mở từ một tiến trình ngoại vi

Nếu chức năng hệ thống ghi được gọi, bộ xử lý ngoại vi sẽ tạo một thông báo bao gồm thuộc tính chức năng ghi, bộ mô tả tệp và lượng dữ liệu được ghi. Sau đó, từ không gian của quy trình ngoại vi, nó sao chép dữ liệu sang quy trình vệ tinh dọc theo đường truyền thông. Quá trình vệ tinh giải mã tin nhắn nhận được, đọc dữ liệu từ đường truyền và ghi vào tệp tương ứng (bộ mô tả có trong tin nhắn được sử dụng làm con trỏ tới chỉ mục và mục nhập trong bảng tệp); Tất cả những hành động này được thực hiện trên bộ xử lý trung tâm. Khi kết thúc công việc, quy trình vệ tinh sẽ gửi một tin nhắn đến quy trình ngoại vi xác nhận đã nhận được tin nhắn và chứa số byte dữ liệu được sao chép thành công vào tệp. Thao tác đọc tương tự; vệ tinh thông báo cho quá trình ngoại vi về số byte thực sự được đọc (trong trường hợp đọc dữ liệu từ thiết bị đầu cuối hoặc từ một kênh, con số này không phải lúc nào cũng trùng với số được chỉ định trong yêu cầu). Để thực hiện cả hai chức năng, có thể cần phải gửi tin nhắn thông tin nhiều lần qua mạng, điều này được xác định bởi khối lượng dữ liệu được gửi và kích thước của gói mạng.

Chức năng duy nhất cần sửa đổi khi chạy trên CPU là chức năng hệ thống phân nhánh. Khi một tiến trình thực thi chức năng này trên CPU, kernel sẽ chọn bộ xử lý ngoại vi cho nó và gửi một thông báo đến một tiến trình đặc biệt - máy chủ, thông báo cho tiến trình sau rằng nó sắp bắt đầu dỡ bỏ tiến trình hiện tại. Giả sử rằng máy chủ đã chấp nhận yêu cầu, kernel sử dụng hàm fork để tạo một quy trình ngoại vi mới, phân bổ một mục nhập bảng quy trình và không gian địa chỉ. CPU tải một bản sao của quy trình đã gọi hàm fork tới bộ xử lý ngoại vi, ghi đè không gian địa chỉ mới được phân bổ, tạo ra một vệ tinh cục bộ để liên lạc với quy trình ngoại vi mới và gửi tin nhắn đến thiết bị ngoại vi để khởi tạo bộ đếm chương trình cho quá trình mới. Quá trình vệ tinh (trên CPU) là con của quá trình được gọi là hàm fork; Quy trình ngoại vi về mặt kỹ thuật là con của quy trình máy chủ, nhưng về mặt logic, nó là con của quy trình được gọi là hàm fork. Quá trình máy chủ không có kết nối logic với tiến trình con của nó sau khi chức năng fork hoàn thành; Công việc duy nhất của người phục vụ là hỗ trợ dỡ trẻ xuống. Do sự liên kết chặt chẽ giữa các thành phần hệ thống (bộ xử lý ngoại vi không có quyền tự chủ) nên quy trình ngoại vi và quy trình vệ tinh có cùng một mã nhận dạng. Mối quan hệ giữa các tiến trình được thể hiện trong Hình 13.5: đường liên tục thể hiện mối quan hệ cha-con, đường chấm chấm thể hiện mối quan hệ giữa các đối tác bình đẳng.

Hình 13.5. Thực hiện phân nhánh trên CPU

Khi một tiến trình thực thi chức năng phân nhánh trên bộ xử lý ngoại vi, nó sẽ gửi một thông báo đến CPU đồng hành của nó, sau đó CPU này sẽ thực thi toàn bộ chuỗi hành động được mô tả ở trên. Vệ tinh chọn bộ xử lý ngoại vi mới và thực hiện các bước chuẩn bị cần thiết để dỡ bỏ hình ảnh của quy trình cũ: nó gửi yêu cầu đến quy trình ngoại vi gốc để đọc hình ảnh của nó, để đáp lại việc truyền dữ liệu được yêu cầu bắt đầu ở đầu bên kia của kênh truyền thông. Vệ tinh đọc hình ảnh được truyền đi và ghi lại nó cho thiết bị ngoại vi. Khi quá trình dỡ bỏ hình ảnh hoàn tất, quy trình vệ tinh sẽ thực thi chức năng phân nhánh, tạo con của nó trên CPU và chuyển giá trị của bộ đếm chương trình cho con ngoại vi để sau này biết địa chỉ nào sẽ bắt đầu thực thi. Rõ ràng, sẽ tốt hơn nếu tiến trình con của tiến trình vệ tinh được gán cho tiến trình con ngoại vi với tư cách là cấp cha, nhưng trong trường hợp của chúng ta, các tiến trình được sinh ra sẽ có cơ hội chạy trên các bộ xử lý ngoại vi khác, không chỉ bộ xử lý mà chúng được tạo trên đó. . Mối quan hệ giữa các tiến trình sau khi chức năng fork được hoàn thành được thể hiện trong Hình 13.6. Khi quy trình ngoại vi hoàn thành công việc của mình, nó sẽ gửi một thông báo tương ứng đến quy trình vệ tinh và nó cũng chấm dứt. Sáng kiến đóng cửa không thể đến từ một quy trình đồng hành.

Hình 13.6. Fork một bộ xử lý ngoại vi

Trong cả hệ thống đa bộ xử lý và đơn bộ xử lý, một quy trình phải phản hồi các tín hiệu theo cùng một cách: quy trình hoặc chấm dứt chức năng hệ thống trước khi kiểm tra tín hiệu hoặc ngược lại, khi nhận được tín hiệu, ngay lập tức thức dậy từ trạng thái treo và đột ngột làm gián đoạn quá trình xử lý. chức năng hệ thống, nếu điều này phù hợp với mức độ ưu tiên mà anh ta đã bị đình chỉ. Bởi vì một quy trình vệ tinh thực hiện các chức năng hệ thống thay mặt cho một quy trình ngoại vi, nên nó phải đáp ứng các tín hiệu phối hợp với quy trình ngoại vi. Nếu trên hệ thống một bộ xử lý, một tín hiệu khiến một quá trình chấm dứt một chức năng một cách bất thường thì một quá trình đồng hành trên hệ thống đa bộ xử lý NÊN hoạt động theo cách tương tự. Điều tương tự cũng có thể xảy ra khi một tín hiệu khiến một quá trình chấm dứt công việc của nó bằng cách sử dụng chức năng thoát: quá trình ngoại vi thoát ra và gửi một thông báo tương ứng đến quá trình đồng hành, tất nhiên, quá trình này cũng thoát ra.

Khi một quy trình ngoại vi gọi hàm hệ thống tín hiệu, nó sẽ lưu trữ thông tin hiện tại trong các bảng cục bộ và gửi một thông báo đến đồng hành của nó để thông báo liệu tín hiệu đã chỉ định nên được chấp nhận hay bỏ qua. Quá trình đồng hành không quan tâm đến việc chặn tín hiệu và hành động mặc định. Cách một quá trình phản ứng với tín hiệu phụ thuộc vào ba yếu tố (Hình 13.7): tín hiệu có đến trong khi quá trình đang thực thi một chức năng hệ thống hay không, liệu chức năng tín hiệu có được sử dụng để chỉ ra rằng tín hiệu sẽ bị bỏ qua hay không và tín hiệu có bắt nguồn hay không. trên cùng bộ xử lý ngoại vi hoặc trên một số bộ xử lý khác. Hãy chuyển sang xem xét nhiều khả năng khác nhau.

thuật toán thở dài /* thuật toán xử lý tín hiệu */

if (quy trình hiện tại là bạn đồng hành của ai đó hoặc có nguyên mẫu)

nếu (tín hiệu bị bỏ qua)

if (tín hiệu nhận được trong quá trình thực hiện chức năng hệ thống)

đặt tín hiệu trước quá trình vệ tinh;

gửi tin nhắn tín hiệu đến một quy trình ngoại vi;

else ( /* tiến trình ngoại vi */

/* tín hiệu có được nhận trong quá trình thực thi chức năng hệ thống hay không */

gửi tín hiệu đến một quá trình đồng hành;

thuật toán Satellite_end_of_syscall /* kết thúc một hàm hệ thống được gọi bởi một tiến trình ngoại vi */

thông tin đầu vào: không có

thông tin đầu ra: không có

if (xảy ra ngắt trong khi chức năng hệ thống đang thực thi)

gửi tin nhắn hoặc tín hiệu ngắt tới một quy trình ngoại vi;

else /* việc thực thi chức năng hệ thống không bị gián đoạn */

gửi phản hồi: bật cờ cho biết tín hiệu đến;

Hình 13.7. Xử lý tín hiệu trong hệ thống ngoại vi

Giả sử rằng một quy trình ngoại vi đã tạm dừng công việc của nó trong khi một quy trình vệ tinh đang thay mặt nó thực thi một chức năng hệ thống. Nếu tín hiệu xuất hiện ở nơi khác, quy trình vệ tinh sẽ phát hiện ra nó trước khi quy trình ngoại vi thực hiện. Có ba trường hợp có thể xảy ra.

1. Nếu trong khi chờ đợi một sự kiện nào đó, quy trình vệ tinh không chuyển sang trạng thái treo, từ đó nó sẽ thoát ra khi nhận được tín hiệu, nó sẽ thực thi chức năng hệ thống đến cùng, gửi kết quả thực thi đến quy trình ngoại vi và cho biết tín hiệu nào nó nhận được.

2. Nếu quy trình được hướng dẫn bỏ qua tín hiệu thuộc loại này, vệ tinh tiếp tục tuân theo thuật toán thực thi chức năng hệ thống mà không rời khỏi trạng thái treo thông qua longjmp. Phản hồi được gửi đến quy trình ngoại vi sẽ không chứa thông báo nhận tín hiệu.

3. Nếu, khi nhận được tín hiệu, một quy trình vệ tinh làm gián đoạn việc thực thi chức năng hệ thống (thông qua longjmp), nó sẽ thông báo cho quy trình ngoại vi về điều này và cho nó biết số tín hiệu.

Quá trình ngoại vi tìm kiếm phản hồi nhận được để biết thông tin về tín hiệu nhận và, nếu phát hiện được, sẽ xử lý tín hiệu trước khi thoát khỏi chức năng hệ thống. Do đó, hành vi của một tiến trình trên hệ thống đa bộ xử lý hoàn toàn giống với hành vi của nó trên hệ thống một bộ xử lý: nó thoát ra mà không thoát khỏi chế độ kernel hoặc gọi hàm xử lý tín hiệu do người dùng xác định hoặc bỏ qua tín hiệu và thành công. hoàn thành chức năng của hệ thống.

Hình 13.8. Ngắt khi thực hiện một chức năng hệ thống

Ví dụ, giả sử rằng một quy trình ngoại vi gọi một chức năng đọc từ một thiết bị đầu cuối được liên kết với bộ xử lý trung tâm và tự tạm dừng trong khi quy trình đồng hành thực thi chức năng đó (Hình 13.8). Nếu người dùng nhấn phím ngắt, lõi CPU sẽ gửi tín hiệu tương ứng đến quy trình đồng hành. Nếu vệ tinh ở trạng thái treo chờ một phần dữ liệu được nhập vào từ thiết bị đầu cuối, nó sẽ ngay lập tức thoát khỏi trạng thái này và dừng thực hiện chức năng đọc. Để đáp ứng yêu cầu từ quy trình ngoại vi, vệ tinh sẽ báo cáo mã lỗi và số tín hiệu tương ứng với ngắt. Quá trình ngoại vi phân tích phản hồi và vì thông báo cho biết tín hiệu ngắt đã đến nên sẽ gửi tín hiệu đến chính nó. Trước khi thoát khỏi chức năng đọc, nhân ngoại vi sẽ kiểm tra tín hiệu, phát hiện tín hiệu ngắt từ quy trình đồng hành và xử lý tín hiệu đó như bình thường. Nếu do nhận được tín hiệu ngắt, một quy trình ngoại vi chấm dứt công việc của nó bằng cách sử dụng chức năng thoát, thì chức năng này sẽ đảm nhiệm việc hủy bỏ quy trình đồng hành. Nếu một tiến trình ngoại vi chặn các tín hiệu ngắt, nó sẽ gọi chức năng tùy chỉnh xử lý tín hiệu và khi thoát khỏi chức năng đọc sẽ trả về mã lỗi cho người dùng. Mặt khác, nếu vệ tinh đang thực thi chức năng thống kê hệ thống thay mặt cho một quy trình ngoại vi, nó sẽ không làm gián đoạn việc thực thi khi nhận được tín hiệu (chức năng thống kê được đảm bảo phục hồi sau bất kỳ sự đình chỉ nào vì nó có thời gian chờ giới hạn cho nguồn tài nguyên). Vệ tinh hoàn thành chức năng và trả về số tín hiệu cho quy trình ngoại vi. Một quy trình ngoại vi sẽ gửi tín hiệu đến chính nó và nhận nó dưới dạng đầu ra từ một chức năng hệ thống.

Nếu tín hiệu xảy ra trên bộ xử lý ngoại vi trong khi chức năng hệ thống đang thực thi, thì quy trình ngoại vi sẽ không biết liệu điều khiển có sớm quay trở lại với nó từ quy trình đồng hành hay liệu quy trình sau sẽ chuyển sang trạng thái treo vô thời hạn. Quá trình ngoại vi gửi một thông điệp đặc biệt tới vệ tinh, thông báo cho nó về sự xuất hiện của tín hiệu. Lõi trên CPU giải mã tin nhắn và gửi tín hiệu đến vệ tinh, phản ứng của nó khi nhận tín hiệu được mô tả trong các đoạn trước (làm hỏng chức năng hoặc hoàn thành nó). Quá trình ngoại vi không thể gửi tin nhắn trực tiếp đến vệ tinh vì vệ tinh đang bận thực hiện chức năng hệ thống và không đọc dữ liệu từ đường truyền liên lạc.

Sử dụng ví dụ về chức năng đọc, quy trình ngoại vi không biết liệu đồng hành của nó đang chờ đầu vào từ thiết bị đầu cuối hay đang thực hiện các hành động khác. Quá trình ngoại vi gửi tin nhắn tín hiệu đến vệ tinh: nếu vệ tinh ở trạng thái treo với mức ưu tiên cho phép gián đoạn thì ngay lập tức thoát khỏi trạng thái này và ngừng thực thi chức năng hệ thống; mặt khác, chức năng được thực thi để hoàn thành thành công.

Cuối cùng, hãy xem xét trường hợp tín hiệu đến vào thời điểm không liên quan đến việc thực hiện chức năng hệ thống. Nếu tín hiệu bắt nguồn từ bộ xử lý khác, vệ tinh sẽ nhận tín hiệu đó trước và gửi thông báo tín hiệu đến quy trình ngoại vi, bất kể tín hiệu đó có liên quan đến quy trình ngoại vi hay không. Nhân ngoại vi giải mã tin nhắn và gửi tín hiệu đến tiến trình, quá trình này sẽ phản hồi lại nó như bình thường. Nếu tín hiệu bắt nguồn từ bộ xử lý ngoại vi, quy trình sẽ thực hiện các hành động tiêu chuẩn mà không cần dùng đến các dịch vụ của vệ tinh.

Khi một quy trình ngoại vi gửi tín hiệu đến các quy trình ngoại vi khác, nó sẽ mã hóa thông báo hủy và gửi nó đến một quy trình đồng hành thực thi chức năng được gọi cục bộ. Nếu một số quá trình mà tín hiệu dự định được đặt trên các bộ xử lý ngoại vi khác, các vệ tinh của chúng sẽ nhận được tín hiệu (và phản ứng với việc nhận tín hiệu theo cách được mô tả ở trên).

13.2 TRUYỀN THÔNG NEWCASTLE

Trong phần trước, chúng ta đã xem xét một loại hệ thống liên kết chặt chẽ, được đặc trưng bằng cách gửi tất cả các lệnh gọi đến các chức năng của hệ thống con quản lý tệp xảy ra trên bộ xử lý ngoại vi tới bộ xử lý từ xa (trung tâm). Bây giờ chúng ta hãy chuyển sang xem xét các hệ thống ít liên kết chặt chẽ hơn, bao gồm các máy truy cập các tệp nằm trên các máy khác. Ví dụ, trong mạng máy tính cá nhân và máy trạm, người dùng thường truy cập các tệp nằm trên một máy lớn. Trong hai phần tiếp theo chúng ta sẽ xem xét các cấu hình hệ thống trong đó tất cả các chức năng hệ thống được thực hiện trong hệ thống con cục bộ, nhưng đồng thời có thể truy cập các tệp (thông qua các chức năng của hệ thống con quản lý tệp) nằm trên các máy khác.

Các hệ thống này sử dụng một trong hai đường dẫn sau để xác định các tệp đã xóa. Trong một số hệ thống, một ký tự đặc biệt được thêm vào tên tệp ghép: thành phần tên trước ký tự này xác định máy, phần còn lại của tên xác định tệp nằm trên máy này. Vì vậy, ví dụ, một tên ghép

"sftig!/fs1/mjb/rje"

xác định tệp "/fs1/mjb/rje" nằm trên máy "sftig". Sơ đồ nhận dạng tệp này tuân theo quy ước được thiết lập bởi chương trình uucp để truyền tệp giữa các hệ thống loại UNIX. Trong một sơ đồ khác, các tệp đã xóa được xác định bằng cách thêm tiền tố đặc biệt vào tên, ví dụ:

/../sftig/fs1/mjb/rje

trong đó "/../" là tiền tố chỉ ra rằng tệp đã bị xóa; thành phần thứ hai của tên tệp là tên của máy từ xa. Lược đồ này sử dụng cú pháp quen thuộc của tên tệp trong hệ thống UNIX, do đó, không giống như lược đồ đầu tiên, ở đây các chương trình người dùng không cần phải thích ứng với việc sử dụng các tên có cấu trúc khác thường (xem).

Hình 13.9. Xây dựng các yêu cầu tới máy chủ tệp (bộ xử lý)

Chúng ta sẽ dành phần còn lại của phần này để xem xét mô hình hệ thống sử dụng liên kết Newcastle, trong đó hạt nhân không nhận ra các tập tin từ xa; chức năng này hoàn toàn được gán cho các thủ tục từ thư viện C tiêu chuẩn, trong trường hợp này thực hiện vai trò của giao diện hệ thống. Các quy trình này phân tích thành phần đầu tiên của tên tệp, trong cả hai phương pháp nhận dạng được mô tả đều chứa dấu hiệu cho thấy tệp ở xa. Đây là một sự khác biệt so với chuẩn mực trong đó các thủ tục của thư viện không phân tích tên tệp. Hình 13.9 cho thấy các yêu cầu tới máy chủ tập tin được hình thành như thế nào. Nếu tập tin là cục bộ, kernel hệ thống cục bộ xử lý yêu cầu theo cách thông thường. Hãy xem xét trường hợp ngược lại:

open("/../sftig/fs1/mjb/rje/file", O_RDONLY);

Quy trình mở của thư viện C phân tích cú pháp hai thành phần đầu tiên của tên tệp phức hợp và biết rằng tệp đó cần được tìm kiếm trên máy từ xa "sftig". Để có thông tin về việc trước đó quy trình có kết nối với một máy nhất định hay không, chương trình con sẽ tạo một cấu trúc đặc biệt trong đó nó ghi nhớ thực tế này và nếu câu trả lời là phủ định, nó sẽ thiết lập kết nối với máy chủ tệp chạy trên điều khiển từ xa máy móc. Khi một quy trình đưa ra yêu cầu xử lý từ xa đầu tiên, máy chủ từ xa sẽ xác nhận yêu cầu, ghi các trường mã nhận dạng người dùng và nhóm nếu cần, đồng thời tạo một quy trình đồng hành để hành động thay mặt cho quy trình khách.

Để thực hiện các yêu cầu của máy khách, vệ tinh phải có cùng quyền truy cập tệp trên máy từ xa với máy khách. Nói cách khác, người dùng "mjb" phải có cả điều khiển từ xa và Tập tin có sẵn quyền truy cập bình đẳng. Thật không may, có thể mã nhận dạng ứng dụng khách "mjb" có thể trùng với mã nhận dạng của ứng dụng khách khác trên máy từ xa. Do đó, quản trị viên hệ thống trên các máy hoạt động trên mạng phải đảm bảo rằng mỗi người dùng được gán một mã nhận dạng duy nhất cho toàn bộ mạng hoặc thực hiện chuyển đổi mã tại thời điểm đưa ra yêu cầu dịch vụ mạng. Nếu điều này không được thực hiện, quy trình vệ tinh sẽ có quyền của một máy khách khác trên máy từ xa.

Một vấn đề nhạy cảm hơn là có được quyền siêu người dùng để làm việc với các tệp đã bị xóa. Một mặt, máy khách siêu người dùng không được có các quyền tương tự đối với hệ thống từ xa, để không gây nhầm lẫn cho các biện pháp kiểm soát bảo mật của hệ thống từ xa. Mặt khác, một số chương trình, nếu không được cấp quyền siêu người dùng, đơn giản là sẽ không thể hoạt động. Một ví dụ về chương trình như vậy là chương trình mkdir (xem Chương 7), tạo một thư mục mới. Hệ thống từ xa sẽ không cho phép khách hàng tạo thư mục mới vì quyền siêu người dùng không áp dụng trên trang web từ xa. Vấn đề tạo thư mục từ xa là lý do nghiêm trọng để sửa đổi chức năng hệ thống mkdir theo hướng mở rộng khả năng của nó trong cài đặt tự động tất cả các kết nối cần thiết cho người dùng. Tuy nhiên, các chương trình setuid (bao gồm chương trình mkdir) vẫn có quyền siêu người dùng đối với các tệp đã bị xóa. vấn đề thường gặp, yêu cầu quyết định của nó. Nó có khả thi giải pháp tốt nhất vấn đề này sẽ xảy ra với các tập tin đặc điểm bổ sung, mô tả quyền truy cập vào chúng của siêu người dùng từ xa; Thật không may, điều này sẽ yêu cầu thay đổi cấu trúc chỉ mục đĩa (về mặt thêm các trường mới) và sẽ tạo ra quá nhiều nhầm lẫn trong các hệ thống hiện có.

Nếu quy trình mở hoàn tất thành công, thư viện cục bộ sẽ để lại dấu tương ứng trong cấu trúc mà người dùng có thể truy cập chứa địa chỉ nút mạng, mã định danh quy trình vệ tinh, bộ mô tả tệp và thông tin tương tự khác. Dựa trên bộ mô tả, các quy trình đọc và ghi của thư viện sẽ xác định xem tệp có bị xóa hay không và nếu câu trả lời là tích cực thì chúng sẽ gửi một tin nhắn tới vệ tinh. Quá trình máy khách tương tác với quá trình đồng hành của nó trong mọi trường hợp truy cập vào các chức năng hệ thống yêu cầu dịch vụ của máy từ xa. Nếu một quy trình truy cập hai tệp nằm trên cùng một máy từ xa thì nó sẽ sử dụng một vệ tinh, nhưng nếu các tệp nằm trên các máy khác nhau thì nó sẽ sử dụng hai vệ tinh: một vệ tinh trên mỗi máy. Hai vệ tinh cũng được sử dụng khi hai tiến trình đang truy cập một tệp trên máy từ xa. Khi gọi một chức năng hệ thống qua vệ tinh, quy trình sẽ tạo ra một thông báo bao gồm số chức năng, tên đường dẫn tìm kiếm và các thông tin cần thiết khác tương tự như thông tin có trong cấu trúc thông báo trong hệ thống có bộ xử lý ngoại vi.

Cơ chế thực hiện các thao tác trên thư mục hiện tại phức tạp hơn. Khi một tiến trình chọn một thư mục từ xa làm thư mục hiện tại, quy trình thư viện sẽ gửi một thông báo tương ứng tới vệ tinh, thông báo này sẽ thay đổi thư mục hiện tại và quy trình sẽ ghi nhớ rằng thư mục đó là từ xa. Trong mọi trường hợp tên đường dẫn tìm kiếm bắt đầu bằng một ký tự không phải là dấu gạch chéo (/), quy trình sẽ gửi tên đó đến máy từ xa, nơi quy trình đồng hành sẽ theo dõi đường dẫn bắt đầu trong thư mục hiện tại. Nếu thư mục hiện tại là cục bộ, quy trình chỉ cần chuyển tên đường dẫn tìm kiếm tới nhân hệ thống cục bộ. Chức năng hệ thống chroot thực hiện tương tự trên một thư mục từ xa, nhưng việc thực thi nó trên nhân hệ thống cục bộ không được chú ý; nói đúng ra, quy trình có thể bỏ qua thao tác này vì chỉ có thư viện ghi lại việc thực hiện nó.

Khi một tiến trình gọi hàm fork, thủ tục thư viện tương ứng sẽ gửi tin nhắn đến từng vệ tinh. Các quy trình vệ tinh thực hiện thao tác phân nhánh và gửi mã định danh của các quy trình con của chúng cho khách hàng mẹ. Tiến trình máy khách chạy chức năng hệ thống phân nhánh, chuyển quyền kiểm soát cho tiến trình con được tạo ra; đứa trẻ cục bộ tiếp tục đối thoại với vệ tinh con từ xa, địa chỉ của chúng được lưu trữ theo quy trình của thư viện. Việc giải thích chức năng phân nhánh này giúp các quy trình vệ tinh kiểm soát các tệp đang mở và thư mục hiện tại dễ dàng hơn. Khi một quá trình làm việc với các tệp từ xa thoát ra (bằng cách gọi hàm thoát), quy trình sẽ gửi tin nhắn đến tất cả các đồng nghiệp ở xa của nó để chúng thực hiện tương tự khi nhận được tin nhắn. Một số khía cạnh của việc triển khai các chức năng của hệ thống thực thi và thoát được đề cập trong các bài tập.

Ưu điểm của giao tiếp kiểu Newcastle là quyền truy cập của quy trình vào các tệp từ xa trở nên "trong suốt" (người dùng không nhìn thấy) và không cần thực hiện thay đổi nào đối với cốt lõi của hệ thống. Tuy nhiên, sự phát triển này cũng có một số nhược điểm. Trước hết, việc thực hiện nó có thể làm giảm hiệu suất hệ thống. Do sử dụng thư viện C mở rộng, dung lượng bộ nhớ mà mỗi tiến trình sử dụng sẽ tăng lên, ngay cả khi tiến trình đó không truy cập các tệp từ xa; thư viện sao chép các hàm kernel và yêu cầu nhiều dung lượng bộ nhớ hơn. Việc tăng kích thước của các quy trình dẫn đến thời gian khởi động lâu hơn và có thể gây ra nhiều tranh chấp hơn về tài nguyên bộ nhớ, cho phép các tác vụ được phân trang và phân trang thường xuyên hơn. Truy vấn cục bộ sẽ thực thi chậm hơn do thời lượng của mỗi lần truy cập vào kernel tăng lên; sự chậm lại cũng có thể đe dọa việc xử lý các yêu cầu từ xa, chi phí gửi chúng qua mạng tăng lên. Việc xử lý bổ sung các yêu cầu từ xa ở cấp độ người dùng sẽ làm tăng số lượng chuyển đổi ngữ cảnh, hoạt động dỡ tải và phân trang. Cuối cùng, để truy cập các tập tin từ xa, các chương trình phải được biên dịch lại bằng các thư viện mới; các chương trình cũ và mô-đun đối tượng được cung cấp sẽ không thể hoạt động với các tệp đã xóa nếu không có điều này. Tất cả những nhược điểm này đều không có trong hệ thống được mô tả trong phần tiếp theo.

13.3 HỆ THỐNG TẬP TIN PHÂN PHỐI "minh bạch"

Thuật ngữ "phân phối minh bạch" có nghĩa là người dùng làm việc trên một máy có thể truy cập các tệp nằm trên máy khác mà không nhận ra rằng khi làm như vậy, họ đang vượt qua ranh giới máy, giống như họ đang ở trên máy của chính mình khi di chuyển từ hệ thống chia sẻ tệp này sang hệ thống chia sẻ tệp khác. điểm gắn chéo. Tên của các quy trình truy cập tệp nằm trên máy từ xa tương tự như tên của tệp cục bộ: chúng không chứa các ký tự phân biệt. Trong cấu hình hiển thị trong Hình 13.10, thư mục /usr/src thuộc máy B được gắn vào thư mục /usr/src thuộc máy A. Cấu hình này thuận tiện nếu bạn muốn sử dụng cùng mã nguồn hệ thống, theo truyền thống nằm trong thư mục "/usr/src". Người dùng chạy trên máy A có thể truy cập các tệp nằm trên máy B bằng cú pháp tên tệp thông thường (ví dụ: "/usr/src/cmd/login.c") và chính kernel sẽ quyết định xem tệp bị xóa hay cục bộ. Người dùng trên máy B có quyền truy cập vào các tệp cục bộ của họ (không biết rằng người dùng trên máy A cũng có thể truy cập các tệp tương tự), nhưng đến lượt nó không có quyền truy cập vào các tệp nằm trên máy A. Tất nhiên, có thể có các tùy chọn khác, đặc biệt là những hệ thống trong đó tất cả các hệ thống từ xa được gắn vào thư mục gốc của hệ thống cục bộ, cho phép người dùng truy cập tất cả các tệp trên tất cả các hệ thống.

Hình 13.10. Hệ thống tập tin sau khi gắn từ xa

Sự tương đồng giữa việc gắn hệ thống tệp cục bộ và hiển thị hệ thống tệp từ xa đã dẫn đến việc điều chỉnh chức năng gắn kết cho các hệ thống tệp từ xa. Trong trường hợp này, kernel có một bảng mount định dạng mở rộng để sử dụng. Bằng cách thực hiện chức năng gắn kết, kernel tổ chức kết nối mạng với máy từ xa và lưu trữ thông tin mô tả kết nối này trong bảng gắn kết.

Một vấn đề thú vị là tên đường dẫn bao gồm "..". Nếu một tiến trình tạo thư mục hiện tại trên một hệ thống tệp từ xa, việc sử dụng ".." trong tên sau đó sẽ trả lại tiến trình đó về hệ thống tệp cục bộ thay vì cho phép nó truy cập các tệp phía trên thư mục hiện tại. Quay lại Hình 13.10, lưu ý rằng khi một tiến trình thuộc máy A, trước đó đã chọn thư mục "/usr/src/cmd" nằm trên hệ thống tệp từ xa làm thư mục hiện tại, sẽ thực thi lệnh

thư mục hiện tại sẽ là thư mục gốc thuộc về máy A chứ không phải máy B. Thuật toán namei chạy trong kernel của hệ thống từ xa, nhận được chuỗi ký tự "..", kiểm tra xem tiến trình gọi có phải là tác nhân của máy không. tiến trình máy khách và nếu câu trả lời là tích cực, hãy đặt xem máy khách có coi thư mục làm việc hiện tại là gốc của hệ thống tệp từ xa hay không.

Giao tiếp với máy từ xa có một trong hai hình thức: cuộc gọi thủ tục từ xa hoặc cuộc gọi chức năng hệ thống từ xa. Ở dạng đầu tiên, mỗi thủ tục kernel xử lý các chỉ mục sẽ kiểm tra xem chỉ mục đó có trỏ đến một tệp từ xa hay không và nếu có thì sẽ gửi yêu cầu đến máy từ xa để thực hiện thao tác đã chỉ định. Đề án này phù hợp một cách tự nhiên với cấu trúc trừu tượng hỗ trợ cho các loại hệ thống tệp khác nhau, được mô tả trong phần cuối của Chương 5. Do đó, việc truy cập một tệp từ xa có thể bắt đầu truyền một số tin nhắn qua mạng, số lượng được xác định bởi số của các hoạt động ngụ ý trên tệp, với mức tăng tương ứng về thời gian phản hồi cho yêu cầu có tính đến thời gian chờ của mạng. Mỗi bộ hoạt động từ xa bao gồm ít nhất các hành động khóa chỉ mục, đếm tham chiếu, v.v. Để cải thiện mô hình, nhiều giải pháp tối ưu hóa khác nhau đã được đề xuất liên quan đến việc kết hợp một số hoạt động thành một yêu cầu (tin nhắn) và lưu vào bộ đệm dữ liệu quan trọng nhất ( cm. ).

Hình 13.11. Mở một tập tin từ xa

Hãy xem xét quy trình mở tệp từ xa "/usr/src/cmd/login.c", trong đó "src" là điểm gắn kết. Bằng cách phân tích tên tệp (sử dụng sơ đồ namei-iget), kernel phát hiện tệp bị xóa và gửi yêu cầu đến máy nơi nó đặt để lấy chỉ mục bị khóa. Sau khi nhận được câu trả lời mong muốn, kernel cục bộ sẽ tạo một bản sao của chỉ mục trong bộ nhớ tương ứng với tệp từ xa. Sau đó, kernel kiểm tra các quyền truy cập cần thiết vào tệp (để đọc chẳng hạn), bằng cách gửi một tin nhắn khác đến máy từ xa. Việc thực thi thuật toán mở tiếp tục chính xác như kế hoạch trong Chương 5, gửi tin nhắn đến máy từ xa nếu cần cho đến khi thuật toán hoàn thành và chỉ mục được giải phóng. Mối quan hệ giữa các cấu trúc dữ liệu kernel ở cuối thuật toán mở được thể hiện trong Hình 13.11.

Nếu máy khách gọi chức năng hệ thống đọc, nhân máy khách sẽ khóa chỉ mục cục bộ, đưa ra yêu cầu khóa đối với chỉ mục từ xa, đưa ra yêu cầu đọc dữ liệu, sao chép dữ liệu vào bộ nhớ cục bộ, đưa ra yêu cầu giải phóng chỉ mục từ xa, và phát hành chỉ mục cục bộ. Sơ đồ này tương ứng với ngữ nghĩa của nhân bộ xử lý đơn hiện có, nhưng tần suất sử dụng mạng (một số lệnh gọi cho từng chức năng hệ thống) làm giảm hiệu suất của toàn bộ hệ thống. Tuy nhiên, để giảm lưu lượng mạng, nhiều thao tác có thể được kết hợp thành một yêu cầu duy nhất. Trong ví dụ về chức năng đọc, máy khách có thể gửi cho máy chủ một yêu cầu “đọc” chung và chính máy chủ khi thực thi yêu cầu đó sẽ đưa ra quyết định thu giữ và giải phóng chỉ mục. Việc giảm lưu lượng mạng cũng có thể đạt được bằng cách sử dụng bộ đệm từ xa (như đã thảo luận ở trên), nhưng phải cẩn thận để đảm bảo rằng các chức năng tệp hệ thống sử dụng các bộ đệm này chạy đúng cách.

Trong hình thức giao tiếp thứ hai với một máy từ xa (gọi tới một chức năng hệ thống từ xa), kernel cục bộ phát hiện ra rằng hàm hệ thống tham chiếu đến một tệp từ xa và gửi các tham số được chỉ định trong lệnh gọi của nó tới hệ thống từ xa, hệ thống này sẽ thực thi hàm và trả kết quả về cho client. Máy khách nhận kết quả của hàm và thoát khỏi trạng thái cuộc gọi. Hầu hết các chức năng hệ thống có thể được thực hiện chỉ bằng một yêu cầu mạng và nhận được phản hồi trong một khoảng thời gian hợp lý, nhưng không phải tất cả các chức năng đều phù hợp với mô hình này. Ví dụ, khi nhận được một số tín hiệu nhất định, kernel sẽ tạo một tệp cho tiến trình được gọi là "core" (Chương 7). Việc tạo tệp này không liên quan đến một chức năng hệ thống cụ thể mà hoàn thành một số thao tác như tạo tệp, kiểm tra quyền truy cập và thực hiện một số thao tác ghi.

Trong trường hợp chức năng hệ thống mở, yêu cầu thực thi chức năng được gửi đến máy từ xa bao gồm một phần tên tệp, thành phần còn lại của tên đường dẫn tìm kiếm giúp phân biệt tệp từ xa và các cờ khác nhau. Trong ví dụ trước về việc mở tệp "/usr/src/cmd/login.c", kernel sẽ gửi tên "cmd/login.c" tới máy từ xa. Thông báo cũng bao gồm dữ liệu nhận dạng, chẳng hạn như mã nhận dạng người dùng và nhóm, cần thiết để xác minh quyền truy cập vào các tệp trên máy từ xa. Nếu nhận được phản hồi từ máy từ xa cho biết chức năng mở thành công, kernel cục bộ sẽ chọn chỉ mục trống trong bộ nhớ máy địa phương và đánh dấu nó là chỉ mục của tệp từ xa, lưu thông tin về máy từ xa và chỉ mục từ xa và thường xuyên phân bổ lối đi mới trong bảng tập tin. So với chỉ mục thực trên máy từ xa, chỉ mục do máy cục bộ sở hữu là chính thức và không vi phạm cấu hình mô hình, nhìn chung giống với cấu hình được sử dụng khi gọi thủ tục từ xa (Hình 13.11). Nếu một hàm được một tiến trình gọi truy cập vào một tệp từ xa bằng tay cầm của nó, hạt nhân cục bộ sẽ học từ chỉ mục (cục bộ) rằng tệp đó ở xa, tạo thành một yêu cầu bao gồm hàm được gọi và gửi nó đến máy từ xa. Yêu cầu chứa một con trỏ tới chỉ mục từ xa, qua đó quy trình vệ tinh có thể xác định chính tệp từ xa.

Sau khi nhận được kết quả của việc thực thi bất kỳ chức năng hệ thống nào, hạt nhân có thể sử dụng các dịch vụ của một chương trình đặc biệt để xử lý nó (khi hoàn thành chương trình đó, hạt nhân sẽ hoàn thành công việc với chức năng đó), vì quá trình xử lý cục bộ các kết quả được sử dụng trong bộ xử lý đơn hệ thống không phải lúc nào cũng phù hợp với hệ thống có nhiều bộ xử lý. Kết quả là có thể có những thay đổi về ngữ nghĩa của các thuật toán hệ thống nhằm cung cấp hỗ trợ cho việc thực thi các chức năng hệ thống từ xa. Tuy nhiên, cùng lúc đó, một luồng tin nhắn tối thiểu lưu thông trong mạng, đảm bảo thời gian tối thiểu phản ứng của hệ thống đối với các yêu cầu đến.

13.4 MÔ HÌNH PHÂN PHỐI KHÔNG CÓ QUY TRÌNH CHUYỂN GIAO

Việc sử dụng các quy trình truyền tải (quy trình vệ tinh) trong hệ thống phân tán minh bạch giúp theo dõi các tệp từ xa dễ dàng hơn, nhưng bảng quy trình của hệ thống từ xa bị quá tải với các quy trình vệ tinh hầu như không hoạt động. Trong các sơ đồ khác, các quy trình máy chủ đặc biệt được sử dụng để xử lý các yêu cầu từ xa (xem và). Hệ thống từ xa có một tập hợp (nhóm) các quy trình máy chủ mà đôi khi nó chỉ định để xử lý các yêu cầu từ xa đến. Sau khi xử lý yêu cầu, quy trình máy chủ quay trở lại nhóm và sẵn sàng xử lý các yêu cầu khác. Máy chủ không lưu ngữ cảnh của người dùng giữa hai yêu cầu vì nó có thể xử lý yêu cầu từ nhiều quy trình cùng một lúc. Do đó, mỗi thông báo đến từ một tiến trình máy khách phải bao gồm thông tin về môi trường thực thi của nó, cụ thể là: mã nhận dạng người dùng, thư mục hiện tại, tín hiệu, v.v. Các tiến trình vệ tinh nhận dữ liệu này tại thời điểm chúng xuất hiện hoặc trong khi thực thi các chức năng hệ thống.

Khi một tiến trình mở một tệp từ xa, nhân của hệ thống từ xa sẽ gán một chỉ mục cho các tham chiếu tiếp theo tới tệp đó. Máy cục bộ có bảng mô tả tệp người dùng, bảng tệp và bảng chỉ mục với tập hợp các mục nhập thông thường, với một mục nhập trong bảng chỉ mục xác định máy từ xa và chỉ mục từ xa. Trong trường hợp một chức năng hệ thống (chẳng hạn như đọc) sử dụng bộ mô tả tệp, kernel sẽ gửi một thông báo trỏ đến inode từ xa được gán trước đó và truyền thông tin liên quan đến quy trình: mã nhận dạng người dùng, kích thước tệp tối đa, v.v. Nếu máy điều khiển từ xa có quy trình máy chủ tùy ý sử dụng, tương tác với máy khách có dạng được mô tả trước đó, tuy nhiên, kết nối giữa máy khách và máy chủ chỉ được thiết lập trong suốt thời gian hoạt động của hệ thống.

Nếu bạn sử dụng máy chủ thay vì xử lý vệ tinh, việc quản lý luồng dữ liệu, tín hiệu và thiết bị từ xa có thể trở nên phức tạp hơn. Tuyển sinh vào số lượng lớn các yêu cầu tới một máy từ xa trong trường hợp không có đủ số lượng máy chủ phải được xếp hàng đợi. Điều này đòi hỏi một giao thức cấp cao hơn giao thức được sử dụng trên mạng chính. Mặt khác, trong mô hình vệ tinh, tình trạng quá tải yêu cầu được loại bỏ vì tất cả các yêu cầu của khách hàng đều được xử lý đồng bộ. Một khách hàng có thể có tối đa một yêu cầu đang chờ xử lý.

Việc xử lý các tín hiệu làm gián đoạn việc thực thi chức năng hệ thống cũng trở nên phức tạp hơn khi sử dụng máy chủ, vì sau đó máy từ xa phải tìm máy chủ thích hợp để phục vụ chức năng đó. Thậm chí không thể xảy ra trường hợp do tất cả các máy chủ đều bận rộn nên yêu cầu thực thi một chức năng hệ thống lại ở trạng thái chờ xử lý. Điều kiện cạnh tranh xảy ra cũng xảy ra khi máy chủ trả về kết quả thực thi một chức năng hệ thống cho quá trình gọi và phản hồi của máy chủ bao gồm việc gửi một tin nhắn báo hiệu tương ứng qua mạng. Mỗi tin nhắn phải được đánh dấu sao cho hệ thống từ xa có thể nhận ra nó và nếu cần, có thể làm gián đoạn công việc của các quy trình máy chủ. Khi sử dụng vệ tinh, quá trình xử lý yêu cầu của khách hàng được xác định tự động và khi nhận được tín hiệu, việc kiểm tra xem yêu cầu đã được xử lý hay chưa là điều không khó.

Cuối cùng, nếu một chức năng hệ thống được máy khách gọi khiến máy chủ tạm dừng vô thời hạn (ví dụ: trong khi đọc dữ liệu từ thiết bị đầu cuối từ xa), máy chủ không thể xử lý các yêu cầu khác, do đó giải phóng nhóm máy chủ. Nếu một số quy trình truy cập các thiết bị từ xa cùng một lúc và nếu số lượng máy chủ bị giới hạn ở trên thì sẽ xảy ra tình trạng thắt cổ chai khá đáng chú ý. Điều này không xảy ra với vệ tinh vì vệ tinh được phân bổ cho từng tiến trình máy khách. Một vấn đề khác liên quan đến việc sử dụng máy chủ cho các thiết bị từ xa sẽ được thảo luận trong Bài tập 13.14.

Bất chấp những lợi thế do việc sử dụng các quy trình vệ tinh mang lại, nhu cầu về các mục bảng quy trình miễn phí trong thực tế trở nên cấp thiết đến mức trong hầu hết các trường hợp, chúng vẫn sử dụng các dịch vụ của các quy trình máy chủ để xử lý các yêu cầu từ xa.

Hình 13.12. Sơ đồ khái niệm về tương tác với các tập tin từ xa ở cấp độ kernel

13.5 KẾT LUẬN

Trong chương này, chúng ta đã xem xét ba sơ đồ để làm việc với các tệp nằm trên các máy từ xa, xử lý các hệ thống tệp từ xa như một phần mở rộng của hệ thống cục bộ. Sự khác biệt về kiến trúc giữa các sơ đồ này được thể hiện trong Hình 13.12. Ngược lại, tất cả chúng đều khác với các hệ thống đa bộ xử lý được mô tả trong chương trước ở chỗ ở đây các bộ xử lý không chia sẻ bộ nhớ vật lý. Hệ thống bộ xử lý ngoại vi bao gồm một bộ bộ xử lý được liên kết chặt chẽ để chia sẻ tài nguyên tệp trên bộ xử lý trung tâm. Giao tiếp kiểu Newcastle cung cấp quyền truy cập ẩn (“trong suốt”) vào các tệp từ xa, nhưng không thông qua nhân hệ điều hành mà thông qua việc sử dụng thư viện C đặc biệt. Vì lý do này, tất cả các chương trình có ý định sử dụng kiểu giao tiếp này phải được biên dịch lại, đây nói chung là một bất lợi nghiêm trọng của sơ đồ này. Khoảng cách xa của tệp được biểu thị bằng một chuỗi ký tự đặc biệt mô tả máy chứa tệp và đây là một yếu tố khác hạn chế khả năng di chuyển của chương trình.

Trong "minh bạch" hệ thống phân phốiĐể truy cập các tập tin từ xa, việc sửa đổi chức năng hệ thống gắn kết được sử dụng. Các chỉ mục trên hệ thống cục bộ được đánh dấu là tham chiếu đến các tệp từ xa và hạt nhân cục bộ sẽ gửi một thông báo đến hệ thống từ xa mô tả chức năng hệ thống được yêu cầu, các tham số của nó và chỉ mục từ xa. Giao tiếp trong hệ thống phân tán trong suốt được hỗ trợ ở hai dạng: dưới dạng cuộc gọi thủ tục từ xa (một tin nhắn được gửi đến máy từ xa chứa danh sách các hoạt động liên quan đến chỉ mục) và dưới dạng cuộc gọi đến hệ thống từ xa chức năng (thông báo mô tả chức năng được yêu cầu). Phần cuối cùng của chương xem xét các vấn đề liên quan đến việc xử lý các yêu cầu từ xa bằng cách sử dụng các quy trình và máy chủ vệ tinh.

13.6 BÀI TẬP

*1. Mô tả việc triển khai chức năng hệ thống thoát trên hệ thống có bộ xử lý ngoại vi. Sự khác biệt giữa trường hợp này và khi quá trình kết thúc khi nhận được tín hiệu chưa được bắt là gì? Kernel nên kết xuất nội dung của bộ nhớ như thế nào?

2. Các quy trình không thể bỏ qua tín hiệu SIGKILL; giải thích điều gì xảy ra trong hệ thống ngoại vi khi một quá trình nhận được tín hiệu như vậy.

*3. Mô tả việc triển khai chức năng hệ thống thực thi trên hệ thống có bộ xử lý ngoại vi.

*4. Bộ xử lý trung tâm nên phân phối các tiến trình giữa các bộ xử lý ngoại vi như thế nào để cân bằng tải tổng thể?

*5. Điều gì xảy ra nếu bộ xử lý ngoại vi không có đủ bộ nhớ để chứa tất cả các tiến trình được hoán đổi cho nó? Các quy trình nên được dỡ bỏ và hoán đổi trên mạng như thế nào?

6. Hãy xem xét một hệ thống trong đó các yêu cầu tới máy chủ tệp từ xa được gửi nếu phát hiện thấy tiền tố đặc biệt trong tên tệp. Để tiến trình gọi hàm execl("/../sftig/bin/sh", "sh", 0); Tệp thực thi nằm trên máy từ xa nhưng phải được thực thi trên hệ thống cục bộ. Giải thích cách chuyển mô-đun từ xa sang hệ thống cục bộ.

7. Nếu quản trị viên cần thêm máy mới vào hệ thống được kết nối với Newcastle hiện có, cách tốt nhất để thông báo cho các mô-đun thư viện C về điều này là gì?

*số 8. Khi exec được thực thi, kernel sẽ xóa không gian địa chỉ của tiến trình, bao gồm các bảng thư viện được liên kết Newcastle sử dụng để theo dõi các tham chiếu đến các tệp từ xa. Sau khi thực thi chức năng, tiến trình phải giữ lại khả năng truy cập các tệp này bằng các tay cầm cũ của chúng. Mô tả việc thực hiện thời điểm này.

*9. Như được hiển thị trong Phần 13.2, việc gọi chức năng hệ thống thoát trên các hệ thống có kết nối Newcastle sẽ khiến một thông báo được gửi đến quy trình đồng hành, khiến nó chấm dứt. Việc này được thực hiện ở cấp độ thường lệ của thư viện. Điều gì xảy ra khi một tiến trình cục bộ nhận được tín hiệu yêu cầu nó thoát khỏi chế độ kernel?

*10. Làm thế nào, trên một hệ thống có liên kết Newcastle nơi các tệp từ xa được xác định bằng cách thêm tiền tố đặc biệt vào tên tệp, người dùng có thể chỉ định thành phần ".." (thư mục mẹ) của tên tệp để truyền qua điểm gắn kết từ xa không?

11. Từ Chương 7, chúng ta biết rằng các tín hiệu khác nhau tạo ra một quá trình chuyển nội dung của bộ nhớ vào thư mục hiện tại. Điều gì sẽ xảy ra nếu thư mục hiện tại đến từ một hệ thống tập tin từ xa? Bạn sẽ đưa ra câu trả lời gì nếu hệ thống sử dụng kết nối kiểu Newcastle?

*12. Điều gì sẽ tác động đến các quy trình cục bộ nếu tất cả các quy trình hoặc máy chủ vệ tinh bị xóa khỏi hệ thống?

*13. Hãy xem xét cách một hệ thống phân tán trong suốt sẽ triển khai thuật toán liên kết, thuật toán này có thể lấy hai tên tệp từ xa làm tham số và thuật toán exec, bao gồm việc thực hiện nhiều thao tác đọc nội bộ. Hãy xem xét hai hình thức giao tiếp: cuộc gọi thủ tục từ xa và cuộc gọi chức năng hệ thống từ xa.

*14. Khi truy cập vào một thiết bị, quy trình máy chủ có thể rơi vào trạng thái treo, từ đó nó sẽ được đánh thức bởi trình điều khiển thiết bị. Đương nhiên, nếu số lượng máy chủ bị hạn chế, hệ thống sẽ không thể đáp ứng được yêu cầu của máy cục bộ nữa. Đưa ra một thiết kế đáng tin cậy để không phải tất cả các quy trình máy chủ đều bị tạm dừng trong khi chờ I/O liên quan đến thiết bị hoàn tất. Chức năng hệ thống sẽ không ngừng thực thi khi tất cả các máy chủ đều bận.

Hình 13.13. Cấu hình với máy chủ đầu cuối

*15. Khi người dùng đăng nhập vào hệ thống, dòng thiết bị đầu cuối sẽ lưu trữ thông tin rằng thiết bị đầu cuối là thiết bị đầu cuối của nhà điều hành dẫn đầu một nhóm quy trình. Vì lý do này, khi người dùng nhấn phím "break" trên bàn phím đầu cuối, tất cả các tiến trình trong nhóm sẽ nhận được tín hiệu ngắt. Hãy xem xét một cấu hình hệ thống trong đó tất cả các thiết bị đầu cuối được kết nối vật lý với một máy, nhưng việc đăng ký người dùng được triển khai một cách hợp lý trên các máy khác (Hình 13.13). Trong mỗi trường hợp riêng lẻ, hệ thống sẽ tạo một quy trình getty cho thiết bị đầu cuối từ xa. Nếu các yêu cầu tới hệ thống từ xa được xử lý bằng một tập hợp các quy trình máy chủ, cần lưu ý rằng khi thực hiện quy trình mở, máy chủ sẽ ngừng chờ kết nối. Khi chức năng mở hoàn tất, máy chủ sẽ quay trở lại nhóm máy chủ, ngắt kết nối với thiết bị đầu cuối. Tín hiệu ngắt do nhấn phím "break" được gửi đến địa chỉ của các tiến trình có trong cùng một nhóm như thế nào?

*16. Chia sẻ bộ nhớ là một tính năng có nguồn gốc từ các máy cục bộ. Xét về mặt logic, việc lựa chọn Khu vực chung bộ nhớ vật lý (cục bộ hoặc từ xa) cũng có thể được triển khai cho các tiến trình thuộc các máy khác nhau. Mô tả việc thực hiện thời điểm này.

*17. Các thuật toán dỡ bỏ quy trình và phân trang theo yêu cầu, được thảo luận trong Chương 9, giả sử việc sử dụng thiết bị cục bộ dỡ hàng. Những thay đổi nào cần được thực hiện đối với các thuật toán này để cho phép hỗ trợ các thiết bị tải lên từ xa?

*18. Giả sử rằng một lỗi nghiêm trọng đã xảy ra trên một máy (hoặc mạng) từ xa và giao thức lớp mạng cục bộ đã ghi lại thực tế này. Phát triển sơ đồ khôi phục cho hệ thống cục bộ truy cập máy chủ từ xa có yêu cầu. Ngoài ra, hãy xây dựng kế hoạch khôi phục hệ thống máy chủ đã mất liên lạc với khách hàng.

*19. Khi một tiến trình truy cập vào một tệp từ xa, có thể tiến trình đó sẽ di chuyển đến nhiều máy để tìm tệp. Ví dụ: ta lấy tên “/usr/src/uts/3b2/os”, trong đó “/usr” là thư mục thuộc về máy A, “/usr/src” là root mount point của máy B,” /usr/src/uts /3b2" là điểm gắn kết của thư mục gốc của máy C. Việc đi qua một số máy để đến đích cuối cùng được gọi là "multihop". Tuy nhiên, nếu có kết nối mạng trực tiếp giữa máy A và C thì việc gửi dữ liệu qua máy B sẽ không hiệu quả. Mô tả các tính năng triển khai của "multi-hop" trong hệ thống kết nối Newcastle và trong hệ thống phân tán "trong suốt".

Dịch

Tôi gia nhập Uber hai năm trước với tư cách là nhà phát triển thiết bị di động với một số kinh nghiệm về phát triển phụ trợ. Ở đây tôi đang phát triển chức năng thanh toán trong ứng dụng - và trong quá trình đó tôi đã viết lại chính ứng dụng đó. Sau đó, tôi chuyển sang quản lý nhà phát triển và tự mình đứng đầu nhóm. Điều này cho phép tôi làm quen nhiều hơn với phần phụ trợ vì nhóm của tôi chịu trách nhiệm về nhiều hệ thống phụ trợ hỗ trợ thanh toán.

Trước khi làm việc tại Uber, tôi không có kinh nghiệm làm việc với các hệ thống phân tán. Tôi nhận được nền giáo dục truyền thống về Khoa học Máy tính, sau đó tôi đã làm việc trong lĩnh vực phát triển toàn diện trong mười năm. Vì vậy, trong khi tôi có thể vẽ nhiều sơ đồ khác nhau và nói về sự đánh đổi ( sự đánh đổi) trong các hệ thống, vào thời điểm đó tôi chưa hiểu và nhận thức đủ rõ về các khái niệm phân phối, chẳng hạn như tính nhất quán ( Tính nhất quán), khả dụng ( khả dụng) hoặc đẳng thức ( sự bình thường).

TRONG bài này Tôi sẽ nói về một số khái niệm mà tôi cần học và áp dụng vào thực tế khi xây dựng hệ thống thanh toán phân tán, quy mô lớn, có tính sẵn sàng cao mà Uber đang vận hành ngày nay. Đây là một hệ thống có tải lên tới vài nghìn yêu cầu mỗi giây, trong đó chức năng thanh toán quan trọng phải hoạt động chính xác ngay cả trong trường hợp một số bộ phận nhất định của hệ thống ngừng hoạt động.

Đây có phải là một danh sách đầy đủ? Rất có thể là không. Tuy nhiên, nếu cá nhân tôi biết về những khái niệm này sớm hơn thì cuộc sống của tôi sẽ dễ dàng hơn nhiều.

Vì vậy, hãy bắt đầu đi sâu vào SLA, tính nhất quán, độ bền của dữ liệu, tính bền vững của thông báo, tính tạm thời và một số điều khác mà tôi cần phải học trong công việc mới của mình.

SLA

Trong các hệ thống lớn xử lý hàng triệu sự kiện mỗi ngày, chắc chắn sẽ có một số lỗi xảy ra. Đó là lý do tại sao trước khi đi sâu vào quy hoạch hệ thống, bước quan trọng nhất chúng ta cần thực hiện là quyết định xem hệ thống “lành mạnh” có ý nghĩa như thế nào đối với chúng ta. Mức độ “sức khỏe” phải là thứ gì đó Trong thực tế Có thể được đo đạc. Một cách phổ biến để đo lường tình trạng của hệ thống là thông qua SLA ( thỏa thuận cấp độ dịch vụ). Dưới đây là một số loại SLA phổ biến nhất mà tôi đã gặp trong thực tế:

khả dụng: Phần trăm thời gian dịch vụ được thực hiện. Mặc dù việc đạt được mức độ sẵn sàng 100% có thể rất hấp dẫn nhưng việc đạt được kết quả này có thể thực sự là một thách thức và ngoài ra còn khá tốn kém. Ngay cả các hệ thống lớn và quan trọng như mạng thẻ VISA, Gmail hoặc ISP không có sẵn 100% - qua nhiều năm, họ sẽ tích lũy số giây, số phút hoặc số giờ dành cho thời gian ngừng hoạt động. Đối với nhiều hệ thống, tính khả dụng của bốn số chín (99,99% hoặc khoảng 50 phút thời gian ngừng hoạt động mỗi năm) được coi là tính sẵn sàng cao. Để đạt đến cấp độ này, bạn phải làm việc chăm chỉ.
Sự chính xác: Việc mất dữ liệu hoặc thiếu chính xác có được chấp nhận không? Nếu vậy thì bao nhiêu phần trăm có thể chấp nhận được? Đối với hệ thống thanh toán mà tôi đang phát triển, con số này phải là 100% vì không thể nào mất dữ liệu được.
Thông lượng/Công suất (Công suất): Hệ thống có thể chịu được tải bao nhiêu? Số liệu này thường được biểu thị bằng số yêu cầu mỗi giây.
Độ trễ: Hệ thống sẽ phản hồi trong bao lâu? Phải mất bao lâu để phục vụ 95% và 99% yêu cầu? Trong các hệ thống như vậy, thông thường nhiều yêu cầu là "nhiễu", do đó độ trễ p95 và p99 được sử dụng thực tế hơn trong thế giới thực.

Tại sao cần có SLA khi tạo một hệ thống thanh toán lớn? Chúng tôi đang tạo ra một hệ thống mới để thay thế hệ thống hiện có. Để đảm bảo rằng chúng tôi đang làm đúng mọi thứ và hệ thống mới của chúng tôi sẽ “tốt hơn” so với hệ thống tiền nhiệm, chúng tôi đã sử dụng SLA để xác định những kỳ vọng của mình đối với nó. Khả năng tiếp cận là một trong những yêu cầu quan trọng nhất. Sau khi xác định được mục tiêu, chúng tôi cần hiểu sự đánh đổi trong kiến trúc để đạt được những mục tiêu đó.

Chia tỷ lệ ngang và dọc

Khi doanh nghiệp sử dụng hệ thống mới tạo của chúng tôi phát triển, tải trọng dành cho hệ thống đó sẽ chỉ tăng lên. Tại một thời điểm nhất định, cài đặt hiện tại sẽ không thể xử lý bất kỳ sự gia tăng tải nào nữa và chúng tôi sẽ cần tăng khả năng tải. Hai chiến lược chia tỷ lệ phổ biến là chia tỷ lệ theo chiều dọc hoặc chiều ngang.

Chia tỷ lệ theo chiều ngang là việc thêm nhiều máy (hoặc nút) vào hệ thống để tăng thông lượng ( dung tích). Chia tỷ lệ theo chiều ngang là cách phổ biến nhất để mở rộng quy mô hệ thống phân tán.

Chia tỷ lệ theo chiều dọc về cơ bản là "mua một máy lớn hơn/mạnh hơn" - một máy (ảo) có nhiều lõi hơn, sức mạnh xử lý tốt hơn và thêm bộ nhớ. Trong trường hợp hệ thống phân tán, việc chia tỷ lệ theo chiều dọc thường ít phổ biến hơn vì nó có thể đắt hơn so với việc chia tỷ lệ theo chiều ngang. Tuy nhiên, một số trang web lớn nổi tiếng như Stack Overflow đã thành công trong việc mở rộng quy mô theo chiều dọc để đáp ứng tải.

Tại sao chiến lược mở rộng quy mô lại có ý nghĩa khi bạn xây dựng một hệ thống thanh toán lớn? Chúng tôi đã sớm quyết định rằng chúng tôi sẽ xây dựng một hệ thống có thể mở rộng quy mô theo chiều ngang. Mặc dù tỷ lệ theo chiều dọc có thể chấp nhận được trong một số trường hợp, nhưng hệ thống thanh toán của chúng tôi đã đạt đến mức tải dự kiến và chúng tôi bi quan về giả định rằng một máy tính lớn siêu đắt tiền có thể xử lý mức tải này ngay hôm nay, chứ đừng nói đến trong tương lai. Ngoài ra, có một số người trong nhóm của chúng tôi từng làm việc cho các nhà cung cấp dịch vụ thanh toán lớn và có những trải nghiệm tiêu cực khi cố gắng mở rộng quy mô theo chiều dọc ngay cả trên những cỗ máy mạnh nhất mà tiền có thể mua được trong những năm đó.

Tính nhất quán

Sự sẵn có của một trong hai hệ thống là quan trọng. Các hệ thống phân tán thường được xây dựng từ các máy có tính sẵn sàng riêng lẻ thấp hơn tính khả dụng của toàn bộ hệ thống. Hãy để mục tiêu của chúng tôi là xây dựng một hệ thống có độ sẵn sàng 99,999% (thời gian ngừng hoạt động khoảng 5 phút/năm). Chúng tôi sử dụng các máy/nút có độ khả dụng trung bình là 99,9% (chúng có thời gian ngừng hoạt động khoảng 8 giờ/năm). Cách trực tiếp để đạt được chỉ báo về tính khả dụng mà chúng ta cần là thêm một số máy/nút như vậy vào cụm. Ngay cả khi một số nút ngừng hoạt động, những nút khác vẫn tiếp tục hoạt động và tính khả dụng chung của hệ thống sẽ cao hơn tính khả dụng của các thành phần riêng lẻ.

Tính nhất quán là một vấn đề quan trọng trong các hệ thống có tính sẵn sàng cao. Một hệ thống nhất quán nếu tất cả các nút nhìn thấy và trả về cùng một dữ liệu cùng một lúc. Không giống như mô hình trước đây của chúng tôi, nơi chúng tôi đã thêm nhiều nút hơn để đạt được mức độ sẵn sàng cao hơn, việc đảm bảo hệ thống luôn nhất quán không phải là điều tầm thường. Để đảm bảo rằng mỗi nút chứa cùng một thông tin, chúng phải gửi tin nhắn cho nhau để luôn đồng bộ hóa. Tuy nhiên, các tin nhắn do chúng gửi cho nhau có thể không được gửi đi - chúng có thể bị mất và một số nút có thể không truy cập được.

Tính nhất quán là khái niệm khiến tôi mất nhiều thời gian nhất để hiểu và đánh giá cao. Có một số loại tính nhất quán, loại được sử dụng rộng rãi nhất trong các hệ thống phân tán là tính nhất quán mạnh ( tính nhất quán mạnh mẽ), tính nhất quán yếu ( tính nhất quán yếu) và tính nhất quán cuối cùng ( tính nhất quán cuối cùng). Bạn có thể đọc bài phân tích thực tế hữu ích về ưu điểm và nhược điểm của từng mô hình trong bài viết này. Thông thường, mức độ nhất quán được yêu cầu càng yếu thì hệ thống có thể chạy càng nhanh - nhưng càng có nhiều khả năng nó sẽ không trả về bộ dữ liệu mới nhất.

Tại sao tính nhất quán đáng được xem xét khi xây dựng một hệ thống thanh toán lớn? Dữ liệu trong hệ thống phải nhất quán. Nhưng chúng nhất quán đến mức nào? Đối với một số bộ phận của hệ thống, chỉ những dữ liệu có tính nhất quán cao mới phù hợp. Ví dụ: chúng tôi cần lưu trữ thông tin về khoản thanh toán đã được thực hiện ở dạng nhất quán cao. Đối với các phần khác của hệ thống không quan trọng bằng, tính nhất quán cuối cùng có thể được coi là một sự đánh đổi hợp lý.

Điều này được minh họa rõ ràng bằng cách liệt kê các giao dịch gần đây: chúng có thể được thực hiện bằng cách sử dụng tính nhất quán cuối cùng ( tính nhất quán cuối cùng) - nghĩa là giao dịch cuối cùng có thể không xuất hiện ở một số phần của hệ thống cho đến một thời gian sau, nhưng do điều này, truy vấn danh sách sẽ trả về kết quả với độ trễ ít hơn hoặc yêu cầu ít tài nguyên hơn để thực thi.

Độ bền dữ liệu

Độ bền có nghĩa là sau khi dữ liệu được thêm vào kho dữ liệu thành công, dữ liệu đó sẽ có sẵn cho chúng ta trong tương lai. Điều này đúng ngay cả khi các nút hệ thống ngoại tuyến, chúng bị lỗi hoặc dữ liệu nút bị hỏng.

Cơ sở dữ liệu phân tán khác nhau có cấp độ khác nhauđộ bền dữ liệu Một số trong số họ hỗ trợ độ bền dữ liệuở cấp độ máy/nút, một số khác thực hiện việc đó ở cấp độ cụm và một số hoàn toàn không cung cấp chức năng này. Một số hình thức sao chép thường được sử dụng để tăng độ bền - nếu dữ liệu được lưu trữ trên nhiều nút và một trong các nút bị hỏng thì dữ liệu vẫn có sẵn. , điều này giải thích tại sao việc đạt được độ bền trong các hệ thống phân tán có thể là một thách thức lớn.

Tại sao độ bền của dữ liệu lại quan trọng khi xây dựng hệ thống thanh toán? Nếu dữ liệu quan trọng (ví dụ: thanh toán) thì chúng tôi không thể để mất dữ liệu đó ở nhiều phần trong hệ thống của mình. Các kho lưu trữ dữ liệu phân tán mà chúng tôi xây dựng cần hỗ trợ độ bền của dữ liệu ở cấp cụm - để ngay cả khi các phiên bản không thành công, các giao dịch đã hoàn thành vẫn được bảo toàn. Ngày nay, hầu hết các dịch vụ lưu trữ phân tán - như Cassandra, MongoDB, HDFS hoặc Dynamodb - đều hỗ trợ độ bền ở nhiều cấp độ khác nhau và đều có thể được cấu hình để cung cấp độ bền ở cấp độ cụm.

Tính kiên trì và độ bền của tin nhắn

Các nút trong hệ thống phân tán thực hiện tính toán, lưu trữ dữ liệu và gửi tin nhắn cho nhau. Tính năng chính gửi tin nhắn là mức độ đáng tin cậy của những tin nhắn này. Đối với quan trọng hệ thống quan trọng Thường có một yêu cầu là không có tin nhắn nào bị mất.

Trong trường hợp hệ thống phân tán, nhắn tin ( nhắn tin) thường được thực hiện bằng cách sử dụng một số dịch vụ nhắn tin phân tán - RabbitMQ, Kafka hoặc các dịch vụ khác. Những nhà môi giới tin nhắn này có thể hỗ trợ (hoặc được cấu hình để hỗ trợ) các mức độ tin cậy gửi tin nhắn khác nhau.

Tính bền vững của tin nhắn có nghĩa là khi nút xử lý tin nhắn không thành công, tin nhắn sẽ vẫn có sẵn để xử lý sau khi sự cố được giải quyết. Độ bền của tin nhắn thường được sử dụng ở cấp độ hàng đợi tin nhắn. Với hàng đợi tin nhắn lâu dài, nếu hàng đợi (hoặc nút) ngoại tuyến khi tin nhắn được gửi đi, nó vẫn sẽ nhận được tin nhắn khi trực tuyến trở lại. Một bài viết chi tiết tốt về vấn đề này có sẵn ở đây.

Tại sao sự an toàn và độ bền của tin nhắn lại quan trọng khi xây dựng hệ thống thanh toán lớn? Chúng tôi có những tin nhắn mà chúng tôi không thể để mất - ví dụ: một tin nhắn cho biết một người đã bắt đầu thanh toán cho một chuyến đi. Điều này có nghĩa là hệ thống nhắn tin mà chúng tôi sử dụng phải không bị mất dữ liệu: mỗi tin nhắn phải được gửi một lần. Tuy nhiên, việc tạo ra một hệ thống chuyển tải mọi thông điệp trơn tru một lần thay vì ít nhất một lần - đây là những nhiệm vụ có độ khó khác nhau đáng kể. Chúng tôi quyết định triển khai hệ thống nhắn tin gửi ít nhất một lần và chọn bus tin nhắn ( xe buýt nhắn tin), trên hết, chúng tôi quyết định xây dựng nó (chúng tôi đã chọn Kafka, tạo ra một cụm không mất dữ liệu, điều này là bắt buộc trong trường hợp của chúng tôi).

sự bình thường

Trong trường hợp hệ thống phân tán, bất kỳ điều gì cũng có thể xảy ra - kết nối có thể bị ngắt giữa chừng hoặc các yêu cầu có thể hết thời gian chờ. Khách hàng sẽ lặp lại những yêu cầu này thường xuyên. Một hệ thống bình thường đảm bảo rằng bất kể điều gì xảy ra và cho dù một yêu cầu cụ thể được thực hiện bao nhiêu lần thì việc thực hiện thực tế yêu cầu đó chỉ xảy ra một lần. Một ví dụ điển hình là việc thanh toán. Nếu khách hàng tạo yêu cầu thanh toán thì yêu cầu đó thành công nhưng nếu hết thời gian chờ thì khách hàng có thể lặp lại yêu cầu tương tự. Trong trường hợp hệ thống bình thường, người thực hiện thanh toán sẽ không bị tính phí hai lần; nhưng đối với một hệ thống không phải là idemonet thì đây là một hiện tượng hoàn toàn có thể xảy ra.

Việc thiết kế các hệ thống phân tán bình thường đòi hỏi một số loại chiến lược khóa phân tán. Đây là lúc các khái niệm chúng ta đã thảo luận trước đó phát huy tác dụng. Giả sử chúng tôi dự định triển khai tính bình thường bằng cách sử dụng khóa lạc quan để tránh các cập nhật đồng thời. Để chúng tôi sử dụng khóa lạc quan, hệ thống phải nhất quán nghiêm ngặt - để trong khi một thao tác đang chạy, chúng tôi có thể kiểm tra xem một thao tác khác đã bắt đầu hay chưa bằng cách sử dụng một số hình thức lập phiên bản.

Có nhiều cách để đạt được sự bình thường và mỗi lựa chọn cụ thể sẽ phụ thuộc vào các ràng buộc của hệ thống và loại hoạt động được thực hiện. Thiết kế các phương pháp bình thường là một thách thức đáng giá đối với một nhà phát triển - chỉ cần xem các bài đăng của Ben Nadel trong đó anh ấy nói về các chiến lược khác nhau mà anh ấy đã sử dụng, bao gồm cả khóa phân tán và ràng buộc ( hạn chế) Cơ sở dữ liệu. Khi bạn đang thiết kế một hệ thống phân tán, tính bình thường có thể dễ dàng là một trong những phần mà bạn đã bỏ qua. Trong thực tế, chúng tôi đã gặp phải những trường hợp trong đó nhóm của tôi gặp khó khăn do không đảm bảo rằng có sẵn giá trị bình thường chính xác cho một số hoạt động chính.

Tại sao tính bình thường lại quan trọng khi xây dựng một hệ thống thanh toán lớn? Quan trọng nhất: để tránh ghi nợ gấp đôi và hoàn tiền gấp đôi. Cho rằng hệ thống nhắn tin của chúng tôi có ít nhất một lần gửi không mất dữ liệu, chúng tôi phải giả định rằng tất cả các tin nhắn có thể được gửi nhiều lần và hệ thống phải đảm bảo tính bình thường. Chúng tôi đã chọn xử lý vấn đề này bằng cách sử dụng tính năng lập phiên bản và khóa lạc quan, trong đó hệ thống của chúng tôi triển khai hành vi bình thường bằng cách sử dụng một kho lưu trữ nhất quán mạnh mẽ làm nguồn dữ liệu.

Sharding và đại biểu

Các hệ thống phân tán thường cần lưu trữ nhiều dữ liệu hơn mức mà một nút đơn lẻ có thể xử lý. Vậy làm cách nào để lưu trữ tập dữ liệu trên đúng số lượng máy? Kỹ thuật phổ biến nhất cho việc này là sharding. Dữ liệu được phân vùng theo chiều ngang bằng cách sử dụng hàm băm được gán cho phân vùng. Mặc dù nhiều cơ sở dữ liệu phân tán ngày nay triển khai phân mảnh một cách kỹ lưỡng nhưng đây vẫn là một chủ đề thú vị đáng để khám phá—đặc biệt là phân chia lại. Foursquare đã phải ngừng hoạt động trong 17 giờ vào năm 2010 do một vấn đề về sharding, sau đó công ty đã chia sẻ một báo cáo làm sáng tỏ gốc rễ của vấn đề.

Nhiều hệ thống phân tán có dữ liệu hoặc tính toán được sao chép trên nhiều nút. Để đảm bảo rằng các hoạt động được thực hiện một cách nhất quán, một phương pháp bỏ phiếu được xác định, trong đó một số nút nhất định phải có cùng kết quả để một hoạt động được coi là thành công. Quá trình này được gọi là đại biểu.

Tại sao quorum và sharding lại có ý nghĩa khi xây dựng một hệ thống thanh toán lớn tại Uber? Cả hai khái niệm này đều đơn giản và được sử dụng ở hầu hết mọi nơi. Tôi đã gặp họ khi chúng tôi đang thiết lập bản sao ở Cassandra. Cassandra (và các hệ thống phân tán khác) sử dụng đại biểu và đại biểu cục bộ ( đại biểu địa phương) để đảm bảo tính nhất quán giữa các cụm.

Người mẫu diễn viên

Từ vựng thông thường mà chúng ta sử dụng để mô tả các hoạt động lập trình—những thứ như biến, giao diện, lệnh gọi phương thức—giả định trước các hệ thống máy đơn. Khi nói về hệ thống phân tán, chúng ta phải sử dụng các cách tiếp cận khác nhau. Một cách phổ biến để mô tả các hệ thống như vậy là mô hình tác nhân, trong đó chúng ta xem mã dưới dạng giao tiếp. Mô hình này phổ biến vì nó trùng khớp với mô hình tinh thần về cách chúng ta tưởng tượng, chẳng hạn như sự tương tác của mọi người trong một tổ chức. Một cách khác không kém phần phổ biến để mô tả các hệ thống phân tán là CSP, các quá trình tương tác tuần tự.

Mô hình tác nhân dựa trên các tác nhân gửi tin nhắn cho nhau và phản hồi lại chúng. Mỗi diễn viên có thể làm bộ giới hạn mọi thứ - tạo các tác nhân khác, gửi tin nhắn cho người khác hoặc quyết định phải làm gì với tin nhắn tiếp theo. Với sự giúp đỡ của một số quy tắc đơn giản, chúng ta có thể mô tả khá tốt các hệ thống phân tán phức tạp có thể tự phục hồi sau khi một tác nhân “rơi”. Nếu bạn chưa quen với cách tiếp cận này thì tôi giới thiệu cho bạn bài viết

Loại hệ thống này phức tạp hơn về mặt tổ chức hệ thống. Bản chất phân phối hệ thống là để lưu trữ các bản sao cục bộ của dữ liệu quan trọng.

Sơ đồ này ngành kiến trúc có thể được biểu diễn như trong Hình. 5.6.

Cơm. 5.6. Kiến trúc hệ thống phân tán

Hơn 95% dữ liệu được sử dụng trong quản lý doanh nghiệp có thể được đặt trên một máy tính cá nhân, cho phép nó hoạt động độc lập. Dòng sửa đổi và bổ sung được tạo ra trên máy tính này không đáng kể so với lượng dữ liệu được sử dụng. Do đó, nếu bạn lưu trữ dữ liệu được sử dụng liên tục trên chính các máy tính và tổ chức trao đổi các sửa đổi và bổ sung cho dữ liệu được lưu trữ giữa chúng, thì tổng lưu lượng truyền sẽ giảm mạnh. Điều này giúp giảm yêu cầu về kênh liên lạc giữa các máy tính và thường xuyên sử dụng liên lạc không đồng bộ hơn, và nhờ đó, tạo ra các hệ thống thông tin phân tán hoạt động đáng tin cậy sử dụng các liên lạc không ổn định như Internet, thông tin di động và các kênh vệ tinh thương mại để kết nối cá nhân. các phần tử. Và việc giảm thiểu lưu lượng giữa các thành phần sẽ khiến chi phí vận hành kết nối như vậy trở nên khá phải chăng. Tất nhiên, việc triển khai một hệ thống như vậy không hề đơn giản và đòi hỏi phải giải quyết một số vấn đề, một trong số đó là việc đồng bộ hóa dữ liệu kịp thời.

Mỗi máy trạm độc lập, chỉ chứa thông tin cần thiết để làm việc và sự liên quan của dữ liệu trên toàn hệ thống được đảm bảo thông qua việc trao đổi tin nhắn liên tục với các máy trạm khác. Nhắn tin giữa các máy trạm có thể được thực hiện theo nhiều cách khác nhau, từ gửi dữ liệu qua email đến truyền dữ liệu qua mạng.

Một ưu điểm khác của sơ đồ điều hành này và ngành kiến trúc hệ thống là để đảm bảo khả năng chịu trách nhiệm cá nhân về sự an toàn của dữ liệu. Vì dữ liệu có sẵn tại một nơi làm việc cụ thể chỉ được lưu trữ trên máy tính này nên khi sử dụng các công cụ mã hóa và khóa phần cứng cá nhân, quyền truy cập vào dữ liệu của các bên thứ ba, bao gồm cả quản trị viên CNTT, sẽ bị loại trừ.

Như là ngành kiến trúc Hệ thống cũng cho phép bạn tổ chức tính toán phân tán giữa các máy khách. Ví dụ: việc tính toán bất kỳ tác vụ nào yêu cầu tính toán lớn có thể được phân bổ giữa các máy trạm lân cận do thực tế là, theo quy luật, chúng có cùng thông tin trong cơ sở dữ liệu và do đó đạt được hiệu suất hệ thống tối đa.

Hệ thống phân tán có bản sao

Dữ liệu giữa các máy trạm khác nhau và nơi lưu trữ dữ liệu tập trung được truyền bằng cách sao chép (Hình 5.7). Khi nhập thông tin trên máy trạm, dữ liệu cũng được ghi vào cơ sở dữ liệu cục bộ và chỉ sau đó được đồng bộ hóa.

Cơm. 5.7. Kiến trúc của hệ thống phân tán với sự nhân rộng

Hệ thống phân tán với các yếu tố thực thi từ xa

Có một số tính năng nhất định không thể được triển khai hiệu quả trên hệ thống sao chép phân tán thông thường. Những tính năng này bao gồm:

sử dụng dữ liệu từ các thực thể được lưu trữ trên máy chủ (nút) từ xa;

sử dụng dữ liệu từ các thực thể được lưu trữ trên máy chủ khác nhau(nút) một phần;

sử dụng chức năng riêng biệt trên một máy chủ chuyên dụng (nút).

Mỗi loại được mô tả đều sử dụng một nguyên tắc chung: chương trình máy khách truy cập trực tiếp vào máy chủ chuyên dụng (từ xa) hoặc truy cập cơ sở dữ liệu cục bộ, gói gọn quyền truy cập vào máy chủ từ xa (Hình 5.8).

Cơm. 5.8. Kiến trúc hệ thống phân tán thực thi từ xa

Phần mềm nguồn mở đã trở thành nền tảng cốt lõi trong việc tạo ra một số trang web lớn nhất thế giới. Với sự phát triển của các trang web này, các hướng dẫn và phương pháp thực hành tốt nhất cho kiến trúc của chúng đã xuất hiện. Chương này nhằm mục đích đề cập đến một số vấn đề chính cần xem xét khi thiết kế các trang web lớn, cũng như một số thành phần cơ bản được sử dụng để đạt được các mục tiêu này.

Trọng tâm của chương này là phân tích các hệ thống dựa trên web, mặc dù một số tài liệu có thể được ngoại suy sang các hệ thống phân tán khác.

1.1 Nguyên tắc xây dựng hệ thống web phân tán

Chính xác thì việc tạo và quản lý một trang web hoặc ứng dụng có thể mở rộng có ý nghĩa gì? Ở mức độ nguyên thủy, điều này chỉ đơn giản là kết nối người dùng với tài nguyên từ xa thông qua mạng Internet. Và các tài nguyên hoặc quyền truy cập vào các tài nguyên này, được phân phối trên nhiều máy chủ và là liên kết đảm bảo khả năng mở rộng của trang web.

Giống như hầu hết mọi thứ trong cuộc sống, thời gian dành trước để lập kế hoạch xây dựng dịch vụ web có thể hữu ích sau này; Hiểu một số cân nhắc và đánh đổi đằng sau các trang web lớn có thể mang lại quyết định thông minh hơn khi xây dựng các trang web nhỏ hơn. Dưới đây là một số nguyên tắc chính ảnh hưởng đến việc thiết kế hệ thống web quy mô lớn:

Khả dụng: Thời gian hoạt động của trang web rất quan trọng đối với danh tiếng và chức năng của nhiều công ty. Đối với một số nhà bán lẻ trực tuyến lớn hơn, việc không có mặt dù chỉ trong vài phút có thể khiến doanh thu bị mất hàng nghìn hoặc hàng triệu đô la. Do đó, việc phát triển hệ thống của họ để luôn sẵn sàng và có khả năng phục hồi trước thất bại vừa là yêu cầu cơ bản về kinh doanh vừa là yêu cầu công nghệ. Tính sẵn sàng cao trong các hệ thống phân tán đòi hỏi phải xem xét cẩn thận về tính dư thừa của các thành phần chính, khả năng phục hồi nhanh chóng sau các lỗi hệ thống một phần và cắt giảm khả năng một cách trơn tru khi có vấn đề phát sinh.
Hiệu suất: Hiệu suất trang web đã trở thành một thước đo quan trọng đối với hầu hết các trang web. Tốc độ trang web tác động đến trải nghiệm và sự hài lòng của người dùng cũng như thứ hạng của công cụ tìm kiếm—một yếu tố ảnh hưởng trực tiếp đến tỷ lệ giữ chân người xem và doanh thu. Do đó, điều quan trọng là tạo ra một hệ thống được tối ưu hóa để phản hồi nhanh và độ trễ thấp.
Độ tin cậy: hệ thống phải đáng tin cậy sao cho một yêu cầu dữ liệu nhất định sẽ trả về dữ liệu đã chỉ định một cách nhất quán. Trong trường hợp thay đổi hoặc cập nhật dữ liệu, yêu cầu tương tự sẽ trả về dữ liệu mới. Người dùng cần biết rằng nếu nội dung nào đó được ghi lại hoặc lưu trữ trong hệ thống, họ có thể tin tưởng rằng nội dung đó sẽ được giữ nguyên để truy xuất sau này.
Khả năng mở rộng: Khi nói đến bất kỳ hệ thống phân tán lớn nào, kích thước chỉ là một mục trong danh sách cần được xem xét. Điều quan trọng không kém là những nỗ lực tăng thông lượng để xử lý khối lượng công việc lớn, thường được gọi là khả năng mở rộng hệ thống. Khả năng mở rộng có thể đề cập đến các tham số khác nhau của hệ thống: lượng lưu lượng truy cập bổ sung mà hệ thống có thể xử lý, mức độ dễ dàng bổ sung dung lượng lưu trữ hoặc số lượng giao dịch khác có thể được xử lý.
Khả năng kiểm soát: Thiết kế một hệ thống dễ vận hành là một yếu tố quan trọng khác. Khả năng quản lý hệ thống tương đương với khả năng mở rộng các hoạt động “bảo trì” và “cập nhật”. Để đảm bảo khả năng quản lý, cần xem xét tính dễ chẩn đoán và hiểu các vấn đề mới nổi, tính dễ cập nhật hoặc sửa đổi và tính dễ sử dụng của hệ thống. (Nghĩa là, nó có hoạt động như mong đợi mà không có lỗi hoặc ngoại lệ không?)
Giá: Chi phí là một yếu tố quan trọng. Điều này rõ ràng có thể bao gồm chi phí phần cứng và phần mềm, nhưng điều quan trọng là phải xem xét các khía cạnh khác cần thiết để triển khai và bảo trì hệ thống. Lượng thời gian cần thiết của nhà phát triển để xây dựng hệ thống, lượng nỗ lực vận hành cần thiết để thiết lập và chạy hệ thống và thậm chí cả mức độ đào tạo phù hợp đều phải được cung cấp. Chi phí thể hiện tổng chi phí sở hữu.

Mỗi nguyên tắc này cung cấp cơ sở cho việc ra quyết định trong việc thiết kế kiến trúc web phân tán. Tuy nhiên, họ cũng có thể xung đột với nhau vì việc đạt được mục tiêu của một người sẽ phải trả giá bằng việc bỏ bê người kia. Ví dụ đơn giản: sự lựa chọn phép cộng đơn giản nhiều máy chủ dưới dạng giải pháp hiệu suất (khả năng mở rộng) có thể làm tăng chi phí quản lý (bạn phải chạy thêm một máy chủ) và chi phí mua máy chủ.

Khi phát triển bất kỳ loại ứng dụng web nào, điều quan trọng là phải xem xét các nguyên tắc chính này, ngay cả khi cần xác nhận rằng dự án có thể hy sinh một hoặc nhiều nguyên tắc trong số đó.

1.2 Cơ bản

Khi xem xét kiến trúc hệ thống, có một số vấn đề cần được giải quyết, chẳng hạn như thành phần nào đáng sử dụng, chúng khớp với nhau như thế nào và có thể thực hiện những đánh đổi nào. Đầu tư tiền vào việc mở rộng quy mô mà không có nhu cầu rõ ràng không phải là một quyết định kinh doanh thông minh. Tuy nhiên, việc suy tính trước trong việc lập kế hoạch có thể tiết kiệm đáng kể thời gian và nguồn lực trong tương lai.

Phần này tập trung vào một số yếu tố cơ bản quan trọng đối với hầu hết các ứng dụng web lớn: Dịch vụ,
dư, sự phân chia, Và xử lý sự cố. Mỗi yếu tố này đều liên quan đến sự lựa chọn và đánh đổi, đặc biệt trong bối cảnh các nguyên tắc được mô tả ở phần trước. Để làm rõ, hãy đưa ra một ví dụ.

Ví dụ: Ứng dụng lưu trữ hình ảnh

Có lẽ bạn đã từng đăng hình ảnh trực tuyến trước đây. Đối với các trang web lớn lưu trữ và phân phối nhiều hình ảnh, có những thách thức trong việc tạo ra kiến trúc có độ tin cậy cao, hiệu quả về mặt chi phí và có độ trễ phản hồi thấp (truy xuất nhanh).

Hãy tưởng tượng một hệ thống nơi người dùng có khả năng tải hình ảnh của họ lên máy chủ trung tâm và nơi có thể yêu cầu hình ảnh thông qua liên kết trang web hoặc API, tương tự như Flickr hoặc Picasa. Để đơn giản hóa mô tả, hãy giả sử rằng ứng dụng này có hai nhiệm vụ chính: khả năng tải (ghi) hình ảnh lên máy chủ và yêu cầu hình ảnh. Tất nhiên, tải hiệu quả là một tiêu chí quan trọng, nhưng việc phân phối nhanh khi người dùng yêu cầu (ví dụ: hình ảnh có thể được yêu cầu hiển thị trên một trang web hoặc bởi một ứng dụng khác) sẽ được ưu tiên. Chức năng này tương tự như những gì máy chủ web hoặc máy chủ biên của Mạng phân phối nội dung (CDN) có thể cung cấp. Máy chủ CDN thường lưu trữ các đối tượng dữ liệu ở nhiều vị trí, do đó đưa chúng đến gần hơn về mặt địa lý/vật lý với người dùng, dẫn đến hiệu suất được cải thiện.

Các khía cạnh quan trọng khác của hệ thống:

Số lượng hình ảnh được lưu trữ có thể không giới hạn, do đó khả năng mở rộng lưu trữ phải được xem xét từ quan điểm này.
Phải có độ trễ thấp cho việc tải xuống/yêu cầu hình ảnh.
Nếu người dùng tải hình ảnh lên máy chủ, dữ liệu của nó phải luôn được giữ nguyên và có thể truy cập được.
Hệ thống phải dễ bảo trì (khả năng quản lý).
Vì việc lưu trữ hình ảnh không tạo ra nhiều lợi nhuận nên hệ thống phải tiết kiệm chi phí.

Một vấn đề tiềm ẩn khác với thiết kế này là máy chủ web như Apache hoặc lighttpd thường có giới hạn trên về số lượng kết nối đồng thời mà nó có thể phục vụ (mặc định là khoảng 500, nhưng có thể cao hơn nhiều) và với lưu lượng truy cập cao. , bản ghi có thể nhanh chóng sử dụng hết giới hạn này. Vì các lần đọc có thể không đồng bộ hoặc tận dụng các tối ưu hóa hiệu suất khác như nén gzip hoặc phân đoạn, máy chủ web có thể chuyển đổi các lần đọc nguồn cấp dữ liệu nhanh hơn và chuyển đổi giữa các máy khách trong khi phục vụ nhiều yêu cầu hơn số lượng kết nối tối đa (với Apache và với số lượng tối đa các kết nối). kết nối được đặt thành 500, hoàn toàn có thể phục vụ vài nghìn yêu cầu đọc mỗi giây). Mặt khác, các bản ghi có xu hướng giữ kết nối mở trong toàn bộ thời gian tải xuống. Do đó, việc truyền tệp 1 MB đến máy chủ có thể mất hơn 1 giây trên hầu hết các mạng gia đình, dẫn đến máy chủ web chỉ có thể xử lý 500 mục nhập đồng thời này.

Hình 1.2: Phân tách Đọc/Ghi

Dự đoán vấn đề tiềm ẩn này cho thấy cần phải tách việc đọc và ghi hình ảnh thành các dịch vụ độc lập, được hiển thị trong . Điều này sẽ cho phép chúng tôi không chỉ mở rộng quy mô từng dịch vụ một cách riêng lẻ (vì có khả năng là chúng tôi sẽ luôn đọc nhiều hơn ghi) mà còn có thể nhận biết được những gì đang xảy ra trong mỗi dịch vụ. Cuối cùng, nó sẽ phân biệt các vấn đề có thể phát sinh trong tương lai, giúp chẩn đoán và đánh giá vấn đề truy cập đọc chậm dễ dàng hơn.

Ưu điểm của phương pháp này là chúng ta có thể giải quyết các vấn đề độc lập với nhau - mà không phải lo lắng về việc ghi và truy xuất hình ảnh mới trong cùng một ngữ cảnh. Cả hai dịch vụ này vẫn sử dụng kho hình ảnh toàn cầu, nhưng bằng cách sử dụng các kỹ thuật dành riêng cho dịch vụ, chúng có thể tối ưu hóa hiệu suất của chính mình (ví dụ: bằng cách xếp hàng yêu cầu hoặc lưu vào bộ nhớ đệm các hình ảnh phổ biến - sẽ nói thêm về điều này sau). Từ cả góc độ dịch vụ và chi phí, mỗi dịch vụ có thể được mở rộng quy mô một cách độc lập nếu cần. Và đây là một điều tích cực, vì việc kết hợp và trộn lẫn chúng có thể vô tình ảnh hưởng đến hiệu suất của chúng, như trong tình huống được mô tả ở trên.

Tất nhiên, mô hình trên sẽ hoạt động tối ưu nếu có hai điểm cuối khác nhau (trên thực tế, mô hình này rất giống với một số cách triển khai của các nhà cung cấp lưu trữ đám mây và Mạng phân phối nội dung). Có nhiều giải pháp vấn đề tương tự và trong mỗi trường hợp đều có thể tìm được sự thỏa hiệp.

Ví dụ: Flickr giải quyết vấn đề đọc-ghi này bằng cách phân bổ người dùng trên các nhóm khác nhau sao cho mỗi nhóm chỉ có thể phục vụ một số lượng người dùng cụ thể hạn chế và khi số lượng người dùng tăng lên, nhiều nhóm sẽ được thêm vào cụm (xem phần trình bày chia tỷ lệ của Flickr ,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-trình bày-file.html). Trong ví dụ đầu tiên, việc chia tỷ lệ phần cứng dựa trên tải sử dụng thực tế sẽ dễ dàng hơn (số lần đọc và ghi trong toàn bộ hệ thống), trong khi Flickr chia tỷ lệ dựa trên cơ sở người dùng (tuy nhiên, điều này giả định mức sử dụng như nhau giữa những người dùng, vì vậy công suất cần được lên kế hoạch theo tồn kho). Trước đây, việc không có sẵn hoặc có sự cố với một trong các dịch vụ sẽ làm hỏng chức năng của toàn bộ hệ thống (ví dụ: không ai có thể ghi tệp), khi đó việc không có sẵn một trong các mô-đun Flickr sẽ chỉ ảnh hưởng đến những người dùng được liên kết với nó. Trong ví dụ đầu tiên, việc thực hiện các thao tác trên toàn bộ tập dữ liệu sẽ dễ dàng hơn - ví dụ: cập nhật dịch vụ ghi để bao gồm siêu dữ liệu mới hoặc tìm kiếm tất cả siêu dữ liệu hình ảnh - trong khi với kiến trúc Flickr, mỗi mô-đun phải được cập nhật hoặc tìm kiếm ( hoặc dịch vụ tìm kiếm phải được tạo để sắp xếp siêu dữ liệu thực sự dành cho mục đích này).

Đối với các hệ thống này, không có thuốc chữa bách bệnh, nhưng bạn phải luôn tiến hành theo các nguyên tắc được mô tả ở đầu chương này: xác định nhu cầu của hệ thống (tải đọc hoặc ghi hoặc cả hai, mức độ song song, truy vấn trên tập dữ liệu, phạm vi, sắp xếp, v.v.), tiến hành kiểm tra điểm chuẩn so sánh của các lựa chọn thay thế khác nhau, hiểu các điều kiện lỗi hệ thống tiềm ẩn và phát triển kế hoạch toàn diện trong trường hợp thất bại.

Dư

Để xử lý lỗi một cách khéo léo, kiến trúc web phải có tính dự phòng trong các dịch vụ và dữ liệu của nó. Ví dụ: nếu chỉ có một bản sao của một tệp được lưu trữ trên một máy chủ, việc mất máy chủ đó đồng nghĩa với việc mất tệp. Khắc nghiệt tình huống tương tự có thể được mô tả tích cực và thường có thể tránh được bằng cách tạo nhiều bản sao hoặc bản sao lưu.

Nguyên tắc tương tự này cũng áp dụng cho các dịch vụ. Bạn có thể bảo vệ khỏi lỗi nút đơn bằng cách cung cấp một phần chức năng không thể thiếu cho ứng dụng để đảm bảo rằng nhiều bản sao hoặc phiên bản của nó có thể chạy đồng thời.

Tạo dự phòng trong hệ thống cho phép bạn loại bỏ các điểm yếu và cung cấp chức năng dự phòng hoặc dự phòng trong trường hợp khẩn cấp. Ví dụ: nếu có hai phiên bản của cùng một dịch vụ đang chạy trong sản xuất và một trong số chúng bị lỗi hoàn toàn hoặc một phần thì hệ thống có thể khắc phục lỗi bằng cách chuyển sang bản sao làm việc.
Việc chuyển đổi có thể diễn ra tự động hoặc yêu cầu can thiệp thủ công.

Một vai trò quan trọng khác của dự phòng dịch vụ là tạo ra kiến trúc không cung cấp khả năng chia sẻ tài nguyên. Với kiến trúc này, mỗi nút có thể hoạt động độc lập và hơn nữa, trong trường hợp không có “bộ não” trung tâm quản lý trạng thái hoặc điều phối hành động của các nút khác. Nó thúc đẩy khả năng mở rộng vì việc thêm các nút mới không yêu cầu điều kiện hoặc kiến thức đặc biệt. Quan trọng nhất, các hệ thống này không có điểm hỏng hóc nghiêm trọng, khiến chúng có khả năng phục hồi tốt hơn trước khi hỏng hóc.

Ví dụ: trong ứng dụng máy chủ hình ảnh của chúng tôi, tất cả hình ảnh sẽ có bản sao dự phòng ở đâu đó trong một phần cứng khác (lý tưởng là ở một vị trí địa lý khác trong trường hợp xảy ra thảm họa như động đất hoặc hỏa hoạn ở trung tâm dữ liệu) và các dịch vụ việc truy cập vào các hình ảnh sẽ là dư thừa, vì tất cả chúng đều có khả năng phục vụ các yêu cầu. (Cm. .)
Nhìn về phía trước, bộ cân bằng tải là một cách tuyệt vời để thực hiện điều này, nhưng bạn có thể tìm hiểu thêm ở bên dưới.

Hình 1.3: Ứng dụng lưu trữ hình ảnh dự phòng

Phân đoạn

Các tập dữ liệu có thể lớn đến mức không thể chứa chúng trên một máy chủ. Nó cũng có thể xảy ra rằng các hoạt động tính toán yêu cầu quá lớn tài nguyên máy tính, làm giảm hiệu suất và buộc phải tăng công suất. Trong mọi trường hợp, bạn có hai tùy chọn: chia tỷ lệ dọc hoặc ngang.

Chia tỷ lệ theo chiều dọc liên quan đến việc thêm nhiều tài nguyên hơn vào một máy chủ. Vì vậy, đối với một tập dữ liệu rất lớn, điều này có nghĩa là phải thêm nhiều ổ cứng hơn (hoặc lớn hơn) để toàn bộ tập dữ liệu có thể vừa trên một máy chủ. Trong trường hợp hoạt động điện toán, điều này có nghĩa là chuyển việc tính toán sang máy chủ lớn hơn có CPU nhanh hơn hoặc nhiều bộ nhớ hơn. Trong mọi trường hợp, việc chia tỷ lệ theo chiều dọc được thực hiện để tạo một tài nguyên riêng hệ thống máy tính có khả năng xử lý bổ sung dữ liệu.

Mặt khác, việc chia tỷ lệ theo chiều ngang liên quan đến việc thêm nhiều nút hơn. Trong trường hợp tập dữ liệu lớn, điều này có nghĩa là thêm máy chủ thứ hai để lưu trữ một phần trong tổng khối lượng dữ liệu và đối với tài nguyên máy tính, điều này có nghĩa là phân chia công việc hoặc tải cho một số nút bổ sung. Để tận dụng tối đa tiềm năng của quy mô theo chiều ngang, nó phải được triển khai như một nguyên tắc thiết kế nội bộ của kiến trúc hệ thống. Mặt khác, việc thay đổi và cô lập bối cảnh cần thiết cho việc chia tỷ lệ theo chiều ngang có thể gặp vấn đề.

Phương pháp chia tỷ lệ theo chiều ngang phổ biến nhất là chia dịch vụ thành các phân đoạn hoặc mô-đun. Chúng có thể được phân phối theo cách mà mỗi bộ chức năng logic hoạt động riêng biệt. Điều này có thể được thực hiện theo ranh giới địa lý hoặc các tiêu chí khác như người dùng trả tiền và không trả tiền. Ưu điểm của các chương trình này là chúng cung cấp dịch vụ hoặc kho dữ liệu với chức năng nâng cao.

Trong ví dụ về máy chủ hình ảnh của chúng tôi, có thể máy chủ tệp duy nhất được sử dụng để lưu trữ hình ảnh có thể được thay thế bằng nhiều máy chủ tệp, mỗi máy chủ chứa tập hợp hình ảnh duy nhất của riêng nó. (Xem.) Kiến trúc này sẽ cho phép hệ thống lấp đầy từng máy chủ tệp bằng hình ảnh, thêm các máy chủ bổ sung khi nó đầy. không gian đĩa. Thiết kế sẽ yêu cầu sơ đồ đặt tên liên kết tên của tệp hình ảnh với máy chủ chứa nó. Tên hình ảnh có thể được tạo từ sơ đồ băm nhất quán gắn với máy chủ. Hoặc cách khác, mỗi hình ảnh có thể có một ID gia tăng, điều này sẽ cho phép dịch vụ phân phối, khi yêu cầu một hình ảnh, chỉ xử lý phạm vi ID được liên kết với mỗi máy chủ (dưới dạng chỉ mục).

Hình 1.4: Ứng dụng lưu trữ hình ảnh có tính dự phòng và phân đoạn

Tất nhiên, có những khó khăn trong việc phân phối dữ liệu hoặc chức năng trên nhiều máy chủ. Một trong những câu hỏi quan trọng là vị trí dữ liệu; Trong các hệ thống phân tán, dữ liệu càng gần điểm vận hành hoặc tính toán thì hiệu năng hệ thống càng tốt. Do đó, việc phân phối dữ liệu trên nhiều máy chủ tiềm ẩn nhiều vấn đề, vì dữ liệu có thể cần thiết vào bất kỳ lúc nào, có nguy cơ dữ liệu đó không có sẵn tại địa điểm được yêu cầu, máy chủ sẽ phải thực hiện việc truy xuất thông tin cần thiết một cách tốn kém. mạng lưới.

Một vấn đề tiềm ẩn khác phát sinh ở dạng
sự không nhất quán (không nhất quán).Khi dịch vụ khác nhauđọc từ và ghi vào tài nguyên được chia sẻ, có thể là dịch vụ hoặc kho lưu trữ dữ liệu khác, có thể xảy ra tình trạng dồn đuổi - trong đó một số dữ liệu được cho là được cập nhật lên trạng thái mới nhất, nhưng thực tế lại được đọc trước khi được cập nhật - trong đó trường hợp dữ liệu không nhất quán. Ví dụ: trong trường hợp lưu trữ hình ảnh, tình trạng chủng tộc có thể xảy ra nếu một khách hàng gửi yêu cầu cập nhật hình ảnh của một con chó, thay đổi tiêu đề "Chó" thành "Gizmo", trong khi một khách hàng khác đang đọc hình ảnh. Trong tình huống như vậy, không rõ khách hàng thứ hai sẽ nhận được danh hiệu nào, "Dog" hay "Gizmo".

Tất nhiên, có một số trở ngại liên quan đến việc phân đoạn dữ liệu, nhưng việc phân đoạn cho phép bạn tách biệt từng vấn đề với những vấn đề khác: theo dữ liệu, theo tải, theo kiểu sử dụng, v.v. thành các khối được quản lý. Điều này có thể giúp tăng khả năng mở rộng và quản lý, nhưng vẫn có rủi ro. Có nhiều cách để giảm thiểu rủi ro và xử lý thất bại; tuy nhiên, để ngắn gọn, chúng không được đề cập trong chương này. Nếu bạn muốn biết thêm thông tin về chủ đề này, bạn nên xem bài đăng trên blog về khả năng chịu lỗi và giám sát.

1.3. Xây dựng các khối để truy cập dữ liệu nhanh và có thể mở rộng

Sau khi xem xét một số nguyên tắc cơ bản trong phát triển hệ thống phân tán, bây giờ chúng ta hãy chuyển sang một vấn đề phức tạp hơn - mở rộng quy mô truy cập dữ liệu.

Các ứng dụng web đơn giản nhất, chẳng hạn như ứng dụng ngăn xếp LAMP, tương tự như hình ảnh trong .

Hình 1.5: Các ứng dụng web đơn giản

Khi một ứng dụng phát triển, hai thách thức chính sẽ nảy sinh: mở rộng quyền truy cập vào máy chủ ứng dụng và cơ sở dữ liệu. Trong thiết kế ứng dụng có khả năng mở rộng cao, máy chủ web hoặc ứng dụng thường được thu nhỏ và thường triển khai kiến trúc chia sẻ tài nguyên. Điều này làm cho lớp máy chủ ứng dụng của hệ thống có thể mở rộng theo chiều ngang. Kết quả của thiết kế này là công việc khó khăn sẽ được chuyển xuống ngăn xếp tới máy chủ cơ sở dữ liệu và dịch vụ hỗ trợ; Lớp này là nơi phát huy các vấn đề về hiệu suất và quy mô thực sự.

Phần còn lại của chương này đề cập đến một số chiến lược và kỹ thuật phổ biến nhất để cải thiện hiệu suất và khả năng mở rộng của các loại dịch vụ này bằng cách cung cấp quyền truy cập nhanh vào dữ liệu.

Hình 1.6: Ứng dụng web đơn giản hóa

Hầu hết các hệ thống có thể được đơn giản hóa thành một mạch điện trong
đó là một nơi tốt để bắt đầu tìm kiếm. Nếu bạn có nhiều dữ liệu, có thể an toàn khi cho rằng bạn muốn truy cập dữ liệu đó dễ dàng và nhanh chóng như hộp kẹo trong ngăn kéo bàn trên cùng của bạn. Mặc dù sự so sánh này quá đơn giản nhưng nó nêu bật hai vấn đề phức tạp: khả năng mở rộng lưu trữ dữ liệu và truy cập dữ liệu nhanh.

Vì mục đích của phần này, giả sử rằng bạn có nhiều terabyte (TB) dữ liệu và bạn cho phép người dùng truy cập bộ phận nhỏ những dữ liệu này theo thứ tự ngẫu nhiên. (Cm. .)
Nhiệm vụ tương tự là xác định vị trí của tệp hình ảnh ở đâu đó trên máy chủ tệp trong ứng dụng lưu trữ hình ảnh mẫu.

Hình 1.7: Truy cập dữ liệu cụ thể

Điều này đặc biệt khó khăn vì việc tải hàng terabyte dữ liệu vào bộ nhớ có thể rất tốn kém và ảnh hưởng trực tiếp đến I/O của ổ đĩa. Tốc độ đọc từ đĩa thấp hơn nhiều lần so với tốc độ đọc từ RAM - có thể nói rằng việc truy cập bộ nhớ nhanh ngang với Chuck Norris, trong khi việc truy cập vào đĩa chậm hơn so với hàng đợi ở phòng khám. Sự khác biệt về tốc độ này đặc biệt đáng chú ý đối với các tập dữ liệu lớn; Ở dạng số thô, truy cập bộ nhớ nhanh hơn 6 lần so với đọc đĩa để đọc tuần tự và nhanh hơn 100.000 lần khi đọc ngẫu nhiên (xem Pathology of Big Data, http://queue.acm.org/detail. cfm?id=1563874). ). Hơn nữa, ngay cả với số nhận dạng duy nhất, việc giải bài toán tìm vị trí của một mẩu dữ liệu nhỏ có thể khó như việc cố gắng chọn viên kẹo chứa đầy sôcôla cuối cùng ra khỏi hộp hàng trăm viên kẹo khác mà không cần nhìn.

May mắn thay, có nhiều cách tiếp cận có thể được thực hiện để đơn giản hóa mọi thứ, trong đó bốn cách tiếp cận quan trọng nhất là sử dụng bộ đệm, proxy, chỉ mục và bộ cân bằng tải. Phần còn lại của phần này thảo luận về cách sử dụng từng khái niệm này để giúp việc truy cập dữ liệu nhanh hơn nhiều.

Bộ nhớ đệm

Lợi ích của bộ nhớ đệm từ một tính năng nguyên tắc cơ bản: Dữ liệu được yêu cầu gần đây có thể sẽ cần thiết trở lại. Bộ nhớ đệm được sử dụng ở hầu hết mọi cấp độ điện toán: phần cứng, hệ điều hành, trình duyệt web, ứng dụng web, v.v. Bộ nhớ đệm giống như bộ nhớ ngắn hạn: có kích thước giới hạn nhưng nhanh hơn nguồn dữ liệu gốc và chứa các mục được truy cập gần đây. Bộ nhớ đệm có thể tồn tại ở mọi cấp độ trong kiến trúc, nhưng thường được tìm thấy ở cấp độ gần nhất với giao diện người dùng, nơi chúng được triển khai để trả về dữ liệu nhanh chóng mà không cần tải phụ trợ đáng kể.

Vậy làm cách nào để sử dụng bộ đệm để tăng tốc độ truy cập dữ liệu trong API mẫu của chúng tôi? Trong trường hợp này, có một số vị trí bộ đệm phù hợp. Một tùy chọn vị trí có thể là chọn các nút ở cấp độ truy vấn, như được hiển thị trong
.

Hình 1.8: Vị trí bộ đệm trên nút cấp truy vấn

Việc đặt bộ đệm trực tiếp trên nút cấp yêu cầu cho phép lưu trữ cục bộ dữ liệu phản hồi. Mỗi khi một yêu cầu dịch vụ được thực hiện, nút sẽ nhanh chóng trả về dữ liệu cục bộ, được lưu trong bộ nhớ đệm, nếu có. Nếu nó không có trong bộ đệm, nút yêu cầu sẽ yêu cầu dữ liệu từ đĩa. Bộ đệm trên một nút cấp truy vấn cũng có thể được đặt trong bộ nhớ (rất nhanh) hoặc trên đĩa cục bộ của nút (nhanh hơn việc cố gắng truy cập bộ nhớ mạng).

Hình 1.9: Hệ thống bộ đệm

Điều gì xảy ra khi bạn trải rộng bộ nhớ đệm trên nhiều nút? Như bạn có thể thấy, nếu mức yêu cầu bao gồm nhiều nút thì có khả năng mỗi nút sẽ có bộ đệm riêng. Tuy nhiên, nếu bộ cân bằng tải của bạn phân phối ngẫu nhiên các yêu cầu giữa các nút thì yêu cầu tương tự sẽ chuyển đến các nút khác nhau, do đó làm tăng tình trạng thiếu bộ nhớ đệm. Hai cách để vượt qua trở ngại này là bộ nhớ đệm toàn cầu và bộ nhớ phân tán.

Bộ đệm chung

Ý nghĩa của bộ đệm chung đã rõ ràng ngay từ tên gọi: tất cả các nút chia sẻ một không gian bộ đệm duy nhất. Trong trường hợp này, bạn thêm một loại máy chủ hoặc bộ lưu trữ tệp nào đó nhanh hơn bộ nhớ ban đầu của bạn và sẽ có sẵn cho tất cả các nút cấp yêu cầu. Mỗi nút yêu cầu truy vấn bộ nhớ đệm theo cách tương tự như khi nó là cục bộ. Kiểu sơ đồ bộ nhớ đệm này có thể gây ra một số vấn đề vì một bộ nhớ đệm có thể rất dễ bị quá tải nếu số lượng máy khách và yêu cầu tăng lên. Đồng thời, sơ đồ này rất hiệu quả trên một số kiến trúc nhất định (đặc biệt là những kiến trúc được liên kết với phần cứng chuyên dụng giúp bộ đệm chung này hoạt động rất nhanh hoặc có một bộ dữ liệu cố định phải được lưu vào bộ đệm).

Có hai dạng bộ đệm chung tiêu chuẩn được hiển thị trong sơ đồ. Tình huống được hiển thị là khi không tìm thấy phản hồi được lưu trong bộ đệm trong bộ đệm, bộ đệm sẽ tự chịu trách nhiệm truy xuất phần dữ liệu bị thiếu từ bộ lưu trữ cơ bản. Minh họa là trách nhiệm của các nút yêu cầu để truy xuất bất kỳ dữ liệu nào không được tìm thấy trong bộ đệm.

Hình 1.10: Bộ đệm chung, trong đó bộ đệm chịu trách nhiệm truy xuất

Hình 1.11: Bộ đệm chung, trong đó các nút yêu cầu chịu trách nhiệm truy xuất

Hầu hết các ứng dụng tận dụng bộ nhớ đệm chung có xu hướng sử dụng loại đầu tiên, trong đó bộ nhớ đệm tự quản lý việc thay thế và tìm nạp dữ liệu để ngăn chặn các yêu cầu của máy khách đối với cùng một dữ liệu. Tuy nhiên, có một số trường hợp việc triển khai thứ hai có ý nghĩa hơn. Ví dụ: nếu bộ đệm được sử dụng cho các tệp rất lớn, tốc độ truy cập bộ đệm thấp sẽ khiến bộ đệm bộ đệm trở nên quá tải do thiếu bộ đệm; trong tình huống này, việc có một tỷ lệ lớn trong tổng số tập dữ liệu (hoặc tập dữ liệu nóng) trong bộ đệm sẽ giúp ích. Một ví dụ khác là kiến trúc trong đó các tệp được lưu trữ trong bộ đệm là tĩnh và không nên xóa. (Điều này có thể xảy ra do các đặc tính hiệu suất cơ bản liên quan đến độ trễ dữ liệu như vậy - có lẽ một số phần dữ liệu nhất định cần phải rất nhanh đối với các tập dữ liệu lớn - trong đó logic ứng dụng hiểu chiến lược thay thế hoặc các điểm nóng tốt hơn bộ nhớ đệm.)

Bộ đệm phân phối

Các chỉ mục này thường được lưu trữ trong bộ nhớ hoặc một nơi nào đó rất cục bộ đối với yêu cầu đến của máy khách. Berkeley DB (BDB) và cấu trúc dữ liệu cây, thường được sử dụng để lưu trữ dữ liệu trong danh sách có thứ tự, rất lý tưởng cho việc truy cập được lập chỉ mục.

Thường có nhiều lớp chỉ mục hoạt động như một bản đồ, di chuyển bạn từ vị trí này sang vị trí khác, v.v. cho đến khi bạn có được phần dữ liệu mình cần. (Cm.)

Hình 1.17: Chỉ số đa cấp

Các chỉ mục cũng có thể được sử dụng để tạo nhiều chế độ xem khác của cùng một dữ liệu. Đối với các tập dữ liệu lớn, đây là cách tuyệt vời để xác định các bộ lọc và chế độ xem khác nhau mà không cần phải tạo thêm nhiều bản sao dữ liệu.

Ví dụ: giả sử hệ thống lưu trữ hình ảnh được đề cập ở trên thực sự lưu trữ hình ảnh của các trang sách và dịch vụ cho phép khách hàng truy vấn văn bản trong những hình ảnh đó, tìm kiếm tất cả nội dung văn bản về một chủ đề nhất định giống như cách mà các công cụ tìm kiếm cho phép bạn để tìm kiếm nội dung HTML. Trong trường hợp này, tất cả hình ảnh cuốn sách này sử dụng rất nhiều máy chủ để lưu trữ tệp và việc tìm một trang duy nhất để trình bày cho người dùng có thể khá khó khăn. Ban đầu, các chỉ mục đảo ngược để truy vấn các từ và bộ từ tùy ý phải có sẵn; sau đó có nhiệm vụ điều hướng đến đúng trang, vị trí trong cuốn sách đó và lấy ra hình ảnh chính xác cho kết quả tìm kiếm. Vì vậy, trong trường hợp này, chỉ mục đảo ngược sẽ ánh xạ tới vị trí (chẳng hạn như sách B) và sau đó B có thể chứa chỉ mục với tất cả các từ, vị trí và số lần xuất hiện trong mỗi phần.

Một chỉ mục đảo ngược, mà Index1 có thể hiển thị trong sơ đồ trên, sẽ trông giống như thế này: Mỗi từ hoặc tập hợp từ đóng vai trò là chỉ mục cho những cuốn sách có chứa chúng.

Chỉ mục trung gian sẽ trông tương tự nhưng chỉ chứa các từ, vị trí và thông tin cho sách B. Kiến trúc phân lớp này cho phép mỗi chỉ mục chiếm ít không gian hơn nếu tất cả thông tin này được lưu trữ trong một chỉ mục đảo ngược lớn.

Và đây là điểm mấu chốt trong các hệ thống có quy mô lớn, vì ngay cả khi được nén, các chỉ mục này có thể khá lớn và tốn kém để lưu trữ. Giả sử rằng chúng ta có nhiều sách từ khắp nơi trên thế giới trong hệ thống này - 100.000.000 (xem bài đăng trên blog "Bên trong Google Sách") - và mỗi cuốn sách chỉ dài 10 trang (để đơn giản hóa phép tính) với 250 từ mỗi trang : Điều này mang lại chúng ta tổng cộng 250 tỷ từ. Nếu chúng ta lấy số ký tự trung bình trong một từ là 5 và mã hóa mỗi ký tự bằng 8 bit (hoặc 1 byte, mặc dù một số ký tự thực sự chiếm 2 byte), do đó sử dụng 5 byte cho mỗi từ, thì chỉ mục chứa mỗi ký tự từ chỉ một lần sẽ yêu cầu dung lượng lưu trữ lớn hơn 1 terabyte. Vì vậy, bạn có thể thấy rằng các chỉ mục cũng chứa thông tin khác, chẳng hạn như bộ từ, vị trí dữ liệu và số lượng sử dụng, có thể tăng kích thước rất nhanh.

Việc tạo các chỉ mục trung gian như vậy và trình bày dữ liệu theo từng phần nhỏ hơn giúp giải quyết vấn đề dữ liệu lớn dễ dàng hơn. Dữ liệu có thể được phân phối trên nhiều máy chủ và đồng thời có thể truy cập nhanh chóng. Các chỉ mục là nền tảng của việc truy xuất thông tin và là cơ sở cho công nghệ hiện đại ngày nay. công cụ tìm kiếm. Tất nhiên, phần này chỉ nói sơ qua về chủ đề lập chỉ mục và đã có rất nhiều nghiên cứu về cách làm cho chỉ mục nhỏ hơn, nhanh hơn, chứa nhiều thông tin hơn (chẳng hạn như mức độ liên quan) và dễ dàng cập nhật. (Có một số vấn đề với việc quản lý các điều kiện cạnh tranh cũng như số lượng cập nhật cần thiết để thêm dữ liệu mới hoặc thay đổi dữ liệu hiện có, đặc biệt là khi liên quan đến mức độ liên quan hoặc tính điểm).

Việc có thể tìm thấy dữ liệu của bạn một cách nhanh chóng và dễ dàng là điều quan trọng và các chỉ mục là công cụ đơn giản và hiệu quả nhất để đạt được mục tiêu này.

Cân bằng tải

Cuối cùng, một phần quan trọng khác của bất kỳ hệ thống phân tán nào là bộ cân bằng tải. Bộ cân bằng tải là một phần cốt lõi của bất kỳ kiến trúc nào vì vai trò của chúng là phân phối tải giữa các nút chịu trách nhiệm phục vụ các yêu cầu. Điều này cho phép nhiều nút phục vụ cùng một chức năng trong hệ thống một cách minh bạch. (Xem.) Mục đích chính của chúng là xử lý nhiều kết nối đồng thời và định tuyến các kết nối đó đến một trong các nút được yêu cầu, cho phép hệ thống mở rộng quy mô bằng cách chỉ cần thêm các nút để phục vụ nhiều yêu cầu hơn.

Hình 1.18: Cân bằng tải

Có nhiều các thuật toán khác nhauđể phục vụ các yêu cầu, bao gồm lựa chọn nút ngẫu nhiên, quay vòng hoặc thậm chí lựa chọn nút dựa trên các tiêu chí nhất định như mức sử dụng CPU hoặc RAM. Cân bằng tải có thể được triển khai dưới dạng thiết bị phần cứng hoặc phần mềm. Trong số các bộ cân bằng tải phần mềm nguồn mở mã nguồnđược sử dụng rộng rãi nhất là HAProxy.

Trong hệ thống phân tán, bộ cân bằng tải thường được đặt ở "cạnh trước" của hệ thống để tất cả các yêu cầu gửi đến đều truyền trực tiếp qua chúng. Rất có thể trong một hệ thống phân tán phức tạp, một yêu cầu sẽ phải đi qua nhiều bộ cân bằng, như minh họa trong
.

Hình 1.19: Nhiều bộ cân bằng tải

Giống như proxy, một số bộ cân bằng tải cũng có thể định tuyến các yêu cầu khác nhau tùy thuộc vào loại yêu cầu. Chúng còn được gọi là proxy ngược.

Quản lý dữ liệu cụ thể cho một phiên người dùng cụ thể là một trong những thách thức khi sử dụng bộ cân bằng tải. Trên trang web thương mại điện tử Khi bạn chỉ có một khách hàng, rất dễ dàng cho phép người dùng đặt các mặt hàng vào giỏ hàng của họ và lưu nội dung giữa các lần truy cập (điều này rất quan trọng vì khả năng bán được một mặt hàng sẽ tăng đáng kể nếu khi người dùng quay lại trang web, sản phẩm đó sẽ vẫn còn trong giỏ hàng của họ). Tuy nhiên, nếu người dùng được chuyển hướng đến một nút trong phiên đầu tiên, sau đó đến một nút khác trong lần truy cập tiếp theo, thì sự không thống nhất có thể xảy ra do nút mới có thể không biết về nội dung trong giỏ hàng của người dùng đó. (Bạn có khó chịu nếu bạn đặt một gói Mountain Dew vào giỏ hàng của mình và khi bạn quay lại thì nó không có ở đó chứ?) Một giải pháp có thể là làm cho các phiên "dính" để người dùng luôn được dẫn đến cùng một nút. Tuy nhiên, việc tận dụng một số tính năng đáng tin cậy, chẳng hạn như chuyển đổi dự phòng tự động, sẽ khó khăn đáng kể. Trong trường hợp này, giỏ hàng của người dùng sẽ luôn có nội dung, nhưng nếu nút cố định của họ không thể truy cập được thì sẽ cần một cách tiếp cận đặc biệt và giả định về nội dung của giỏ hàng sẽ không còn đúng nữa (mặc dù hy vọng rằng giả định này sẽ không được tích hợp vào ứng dụng). Tất nhiên, vấn đề này có thể được giải quyết bằng cách sử dụng các chiến lược và công cụ khác, chẳng hạn như những chiến lược và công cụ được mô tả trong chương này, chẳng hạn như các dịch vụ và nhiều thứ khác (chẳng hạn như bộ đệm của trình duyệt, cookie và viết lại URL).

Nếu hệ thống chỉ có một vài nút thì các kỹ thuật như băng chuyền DNS có thể sẽ thực tế hơn các bộ cân bằng tải, vốn có thể tốn kém và tạo thêm lớp phức tạp không cần thiết cho hệ thống. Tất nhiên, trong các hệ thống lớn có tất cả các loại thuật toán cân bằng tải và lập kế hoạch khác nhau, bao gồm cả những thứ đơn giản như ngẫu nhiên hóa hoặc băng chuyền, cho đến các cơ chế phức tạp hơn có tính đến các đặc tính hiệu suất của kiểu sử dụng của hệ thống. Tất cả các thuật toán này cho phép phân phối lưu lượng và yêu cầu, đồng thời có thể cung cấp các công cụ đáng tin cậy hữu ích như khả năng chịu lỗi tự động hoặc tự động loại bỏ một nút bị hỏng (ví dụ: khi nó ngừng phản hồi). Tuy nhiên, những tính năng nâng cao này có thể khiến việc chẩn đoán vấn đề trở nên phức tạp. Ví dụ: trong các tình huống tải cao, bộ cân bằng tải sẽ loại bỏ các nút có thể chạy chậm hoặc hết thời gian chờ (do có quá nhiều yêu cầu), điều này sẽ chỉ khiến mọi việc trở nên tồi tệ hơn đối với các nút khác. Giám sát mở rộng rất quan trọng trong những trường hợp này vì mặc dù lưu lượng và tải tổng thể của hệ thống dường như đang giảm (vì các nút đang phục vụ ít yêu cầu hơn), các nút riêng lẻ có thể bị kéo dài đến giới hạn của chúng.

Cân bằng tải là một cách dễ dàng để tăng công suất hệ thống. Giống như các phương pháp khác được mô tả trong bài viết này, nó đóng một vai trò thiết yếu trong kiến trúc hệ thống phân tán. Bộ cân bằng tải cũng cung cấp chức năng quan trọng là kiểm tra tình trạng của các nút. Nếu do kiểm tra như vậy, một nút không phản hồi hoặc bị quá tải thì nút đó có thể bị xóa khỏi nhóm xử lý yêu cầu và nhờ tính dự phòng của hệ thống của bạn, tải sẽ được phân phối lại giữa các nút đang hoạt động còn lại .

Hàng đợi

Cho đến nay chúng ta đã xem xét nhiều cách để đọc dữ liệu nhanh chóng. Đồng thời một cái khác phần quan trọng mở rộng quy mô lớp dữ liệu là cách quản lý hồ sơ hiệu quả. Khi hệ thống đơn giản và có tải xử lý tối thiểu cũng như cơ sở dữ liệu nhỏ, việc ghi có thể được dự đoán là nhanh chóng. Tuy nhiên, trong các hệ thống phức tạp hơn quá trình này có thể mất một thời gian dài vô tận. Ví dụ: dữ liệu có thể phải được ghi vào nhiều nơi trên các máy chủ hoặc chỉ mục khác nhau hoặc đơn giản là hệ thống có thể đang chịu tải cao. Trong trường hợp việc ghi hoặc thậm chí bất kỳ tác vụ nào mất nhiều thời gian, việc đạt được hiệu suất và tính khả dụng đòi hỏi phải xây dựng tính không đồng bộ trong hệ thống. Cách phổ biến để thực hiện việc này là tổ chức hàng đợi yêu cầu.

Hình 1.20: Yêu cầu đồng bộ

Hãy tưởng tượng một hệ thống trong đó mỗi máy khách yêu cầu một tác vụ dịch vụ từ xa. Mỗi máy khách này sẽ gửi yêu cầu của mình đến máy chủ, máy chủ này sẽ thực hiện các tác vụ nhanh nhất có thể và trả kết quả của chúng cho các máy khách tương ứng. Trong các hệ thống nhỏ nơi một máy chủ (hoặc dịch vụ logic) có thể phục vụ các máy khách đến ngay khi chúng đến, các tình huống thuộc loại này sẽ hoạt động tốt. Tuy nhiên, khi máy chủ nhận được nhiều yêu cầu hơn mức nó có thể xử lý thì mỗi máy khách buộc phải đợi yêu cầu của máy khách khác hoàn tất quá trình xử lý trước khi tạo ra phản hồi cho yêu cầu của chính nó. Đây là ví dụ về yêu cầu đồng bộ, được mô tả trong .

Kiểu hành vi đồng bộ này có thể làm giảm đáng kể hiệu suất của máy khách; trên thực tế, khi không hoạt động, máy khách buộc phải đợi cho đến khi nhận được phản hồi cho yêu cầu. Phép cộng máy chủ bổ sungđể đối phó với tải hệ thống, trên thực tế, không giải quyết được vấn đề; Ngay cả khi đã có sẵn tính năng cân bằng tải hiệu quả, việc cung cấp sự phân bổ tải đồng đều và hợp lý cần thiết để tối đa hóa năng suất của khách hàng là vô cùng khó khăn. Hơn nữa, nếu máy chủ xử lý yêu cầu này không khả dụng (hoặc bị hỏng) thì máy khách được kết nối với nó cũng sẽ ngừng hoạt động. Giải pháp hiệu quả Vấn đề này đòi hỏi sự trừu tượng giữa yêu cầu của khách hàng và công việc thực tế được thực hiện để phục vụ yêu cầu đó.

Hình 1.21: Sử dụng hàng đợi để quản lý yêu cầu

Hàng đợi nhập cảnh. Cách thức hoạt động của hàng đợi rất đơn giản: một nhiệm vụ đến, được xếp vào hàng đợi và sau đó các “công nhân” chấp nhận nhiệm vụ tiếp theo ngay khi họ có cơ hội xử lý nó. (Xem.) Những nhiệm vụ này có thể ghi chú đơn giản vào cơ sở dữ liệu hoặc thứ gì đó phức tạp như tạo hình ảnh xem trước cho tài liệu. Khi máy khách gửi yêu cầu tác vụ đến hàng đợi, nó không cần phải đợi kết quả thực thi nữa; thay vào đó, các yêu cầu chỉ cần xác nhận rằng chúng đã được nhận đúng cách. Xác nhận này sau này có thể dùng làm tham chiếu đến kết quả công việc khi khách hàng yêu cầu.

Hàng đợi cho phép máy khách làm việc theo cách không đồng bộ, cung cấp sự trừu tượng hóa mang tính chiến lược về yêu cầu và phản hồi của máy khách. Mặt khác, trong một hệ thống đồng bộ, không có sự phân biệt giữa yêu cầu và phản hồi nên không thể quản lý chúng một cách riêng biệt. Trong hệ thống không đồng bộ, máy khách gửi một tác vụ, dịch vụ sẽ phản hồi bằng thông báo xác nhận rằng tác vụ đã được nhận và sau đó máy khách có thể kiểm tra định kỳ trạng thái của tác vụ, chỉ yêu cầu kết quả sau khi hoàn thành. Trong khi máy khách đang thực hiện yêu cầu không đồng bộ, bạn có thể tự do thực hiện các công việc khác và thậm chí thực hiện các yêu cầu không đồng bộ từ các dịch vụ khác. Cái sau là một ví dụ về cách hoạt động của hàng đợi và tin nhắn trong các hệ thống phân tán.

Hàng đợi cũng cung cấp một số biện pháp bảo vệ chống lại sự gián đoạn và lỗi dịch vụ. Ví dụ: khá dễ dàng để tạo một hàng đợi rất linh hoạt có thể thử lại các yêu cầu dịch vụ không thành công do lỗi máy chủ tạm thời. Nên sử dụng hàng đợi để thực thi đảm bảo chất lượng dịch vụ hơn là khiến khách hàng bị gián đoạn dịch vụ tạm thời, yêu cầu xử lý lỗi phức tạp và thường không nhất quán ở phía khách hàng.

Hàng đợi là nguyên tắc cơ bản trong việc quản lý truyền phân tán giữa phần khác nhau bất kỳ hệ thống phân tán quy mô lớn nào và có nhiều cách để triển khai chúng. Có khá nhiều triển khai hàng đợi nguồn mở như RabbitMQ.
ActiveMQ
BeanstalkD, nhưng một số cũng sử dụng các dịch vụ như Add Tags

Hệ thống thông tin tự động phân tán giờ đây đã trở thành hiện thực hàng ngày. Nhiều hệ thống thông tin tự động của công ty sử dụng cơ sở dữ liệu phân tán. Các phương pháp phân phối dữ liệu và quản lý dữ liệu phân tán, các phương pháp kiến trúc đảm bảo khả năng mở rộng hệ thống, thực hiện các nguyên tắc của kiến trúc máy khách-máy chủ nhiều tầng, cũng như kiến trúc lớp giữa, đã được phát triển.

Kiến trúc di động đang bắt đầu được đưa vào thực tế. Điều này áp dụng cho cả hệ thống cơ sở dữ liệu và ứng dụng Web.

Một cách tiếp cận để xây dựng hệ thống phân tán đang được hồi sinh, dựa trên kiến trúc ngang hàng (Peer-to-Peer), trong đó, không giống như kiến trúc client-server chiếm ưu thế trong các hệ thống phân tán hiện nay, vai trò của các bên tương tác trong mạng không cố định. Chúng được chỉ định tùy thuộc vào tình hình trong mạng và tải trên các nút của nó.

Do sự phát triển chuyên sâu Công nghệ truyền thông AIS di động đang tích cực phát triển. Đã phát triển phương tiện kỹ thuật và phần mềm để tạo ra chúng. Nhờ đó, hệ thống cơ sở dữ liệu di động bắt đầu phát triển. Nhiều nhóm khoa học tiến hành nghiên cứu tính năng cụ thể của những hệ thống như vậy, nhiều nguyên mẫu khác nhau được tạo ra. Một công cụ thiết yếu để phát triển thiết bị di động phần mềmđã trở thành công nghệ Java.

Đã tạo tiêu chuẩn giao thức truy cập không dây các ứng dụng trên Web (Giao thức ứng dụng không dây - WAP), vốn đã được một số kiểu điện thoại di động hỗ trợ. Dựa trên WAP và XML, tập đoàn W3C đã phát triển ngôn ngữ đánh dấu cho truyền thông không dây, WML (Ngôn ngữ đánh dấu không dây).

Trong quá trình phát triển AIS, siêu dữ liệu đã được chú ý nhiều hơn. Ở đây các bước đang được thực hiện theo hai hướng - tiêu chuẩn hóa việc trình bày siêu dữ liệu và đảm bảo sự hỗ trợ của chúng trong hệ thống.

AIS sử dụng nhiều phương pháp và phương tiện khác nhau để trình bày siêu dữ liệu (nhiều loại kho lưu trữ siêu dữ liệu khác nhau). Việc thiếu sự thống nhất trong lĩnh vực này làm phức tạp đáng kể việc giải quyết các vấn đề về tính di động của ứng dụng, tái sử dụng và tích hợp các nguồn thông tin và công nghệ thông tin, cũng như tái cấu trúc AIS.

Để khắc phục những khó khăn này, các tiêu chuẩn siêu dữ liệu tập trung vào các công nghệ thông tin khác nhau đang được tích cực phát triển. Trong lĩnh vực này, đã tồn tại một số tiêu chuẩn quốc tế, quốc gia và công nghiệp xác định cách trình bày siêu dữ liệu và trao đổi siêu dữ liệu trong AIS. Một số trong số họ đã đạt được trạng thái tiêu chuẩn trên thực tế. Chúng tôi sẽ giới hạn ở đây chỉ đề cập đến những điều quan trọng nhất trong số đó.

Có lẽ tiêu chuẩn thực tế đầu tiên trong danh mục này là ngôn ngữ mô tả dữ liệu CODASYL cho cơ sở dữ liệu cấu trúc mạng. Các tiêu chuẩn gần đây hơn bao gồm: tiêu chuẩn ngôn ngữ truy vấn SQL cho cơ sở dữ liệu quan hệ, chứa định nghĩa về cái gọi là lược đồ thông tin - một tập hợp các biểu diễn các lược đồ cơ sở dữ liệu quan hệ; một thành phần của tiêu chuẩn cơ sở dữ liệu đối tượng ODMG mô tả các giao diện kho lưu trữ lược đồ đối tượng; tiêu chuẩn quốc tế IRDS (Hệ thống từ điển tài nguyên thông tin), mô tả các hệ thống tạo và duy trì các thư mục tài nguyên thông tin của tổ chức.

Tiếp theo, chúng ta nên đề cập đến tiêu chuẩn CWM (Mô hình kho chung) do tập đoàn OMG phát triển để thể hiện siêu dữ liệu của kho dữ liệu, dựa trên tiêu chuẩn OIM (Mô hình thông tin mở) trước đây được tạo ra cho các mục đích rộng hơn bởi tập đoàn MDC (Meta Data Coalition).

Nền tảng công nghệ XML mới dành cho Web cũng bao gồm các tiêu chuẩn để biểu diễn siêu dữ liệu. Hỗ trợ siêu dữ liệu là một trong những đổi mới quan trọng nhất của Web, thay đổi hoàn toàn công nghệ quản lý tài nguyên thông tin của nó. Mặc dù việc hỗ trợ siêu dữ liệu vốn đã cần thiết trong các công nghệ cơ sở dữ liệu, Web đầu tiên siêu dữ liệu thế hệ không được hỗ trợ.

Các tiêu chuẩn siêu dữ liệu web bao gồm một tập hợp con của ngôn ngữ XML được sử dụng để mô tả cấu trúc logic Một số loại tài liệu XML. Mô tả này được gọi là DTD (Định nghĩa loại tài liệu). Ngoài ra, nền tảng XML bao gồm Tiêu chuẩn XML Lược đồ, cung cấp các khả năng nâng cao hơn để mô tả các tài liệu XML. Tiêu chuẩn RDF (Khung định nghĩa tài nguyên) xác định ngôn ngữ biểu diễn tri thức đơn giản để mô tả nội dung của tài liệu XML. Cuối cùng, tiêu chuẩn OWL (Ngôn ngữ web bản thể) đang phát triển xác định một ngôn ngữ mô tả bản thể luận chính thức dành cho Web ngữ nghĩa.

Tiêu chuẩn ngôn ngữ UML(Ngôn ngữ mô hình hóa thống nhất), cung cấp bản trình bày siêu dữ liệu của các công cụ CASE để phân tích và thiết kế đối tượng trực quan, được phát triển bởi tập đoàn OMG. Ngôn ngữ này được hỗ trợ trong nhiều sản phẩm phần mềm CASE. Hiệp hội OMG cũng đã tạo ra tiêu chuẩn XMI (Trao đổi siêu dữ liệu XML) để trao đổi siêu dữ liệu giữa các công cụ CASE bằng ngôn ngữ UML.

Điều đáng nói ở đây là tiêu chuẩn Dublin Core (DC) - một tập hợp các phần tử siêu dữ liệu để mô tả nội dung của các tài liệu có tính chất khác nhau. Tiêu chuẩn này nhanh chóng trở nên phổ biến và đặc biệt được ứng dụng rộng rãi trong môi trường Web (xem Phần 3.3).

Công việc phát triển các tiêu chuẩn hiện có và tạo ra các tiêu chuẩn mới để trình bày siêu dữ liệu cho AIS vẫn tiếp tục. Thông tin chi tiết hơn về các tiêu chuẩn được đề cập có thể được tìm thấy trong bách khoa toàn thư.