3. 1.5 Ý nghĩa high performance 8 5-
3.2.1 Thiết kế các hệ thống thời gian thực
Một hệ thống thông tin kinh tế tốt phải được thiết kế theo kiểu thời gian thực. Các hệ thống thời gian thực phải luôn chạy nhanh như (hoặc nhanh hơn) các tiến trình khác mà chúng hỗ trợ. Ví dụ:
- Người dùng đọc, sử dụng và cập nhật thông tin. Các máy tính sẽ cung cấp các thông tin chia sẻ bằng cách đọc và cập nhật cơ sở dữ liệu. Hệ thống máy tính sẽ lưu các bản sao của thông tin quan trọng nhất ở nhiều địa điểm khác nhau sẵn sàng cho các user sử dụng.
- Một số ứng dụng high performance cần có tốc độ truy suất cao tới dữ -
liệu ở xa. Trong trường hợp này, mọi thành phần trên đường truyền thông từ client tới server ở xa được thiết kế và giám sát một cách đặc biệt để đảm bảo nó cung cấp được ứng dụng này. Khi client workstation phải chờ tiến trình trên node khác trong mạng xử lí xong, không chỉ workstation đó hoạt động không hiệu quả mà user cũng tốn thời gian một cách vô ích.
- Với hầu hết các mục tiêu kinh doanh, thông tin cung cấp cho người
dùng không nhất thiết phải tức thời. Một số thông tin có thể không được cập nhật trong thời gian vài giây, vài phút hoặc hàng giờ. Một số
thông tin chỉ mang tính tổng kết. Người dùng chỉ cần biết thông tin đó là cập nhật đến thời điểm nào.
- Hệ thống máy tính phải giữ cho tất cả thông tin nhất quán với nhau. 3.2.2. Thiết kế một ứng dụng phân tán:
Sau khi lựa chọn và đưa ra các chỉ tiêu của ứng dụng core banking trên nền một hệ thống thời gian thực ta sẽ xem xét các khía cạnh của vấn đề thiết kế. 3.2.2.1 Thiết kế nền tảng ứng dụng:
Khi thiết kế một ứng dụng phân tán nói riêng và core banking nói chung, cần phải thực hiện cân bằng với các mục tiêu toàn cục khác của hệ thống:
- Cần có phản hồi khác nhau của hệ thống đối với từng workload cụ thể - Cần tối ưu hoá thông lượng của toàn hệ thống với một tài nguyên cho
trước.
- Chi phí thực hiện các giải pháp này - Thời gian triển khai các giải pháp Các vấn đề kĩ thuật:
a) Tạo sự cân bằng giữa các tài nguyên tính toán: Các tài nguyên tính toán
nếu không được phối hợp sử dụng tốt sẽ sinh ra các "nút cổ chai"
(bottle necks), do đó người ta thường thực hiện trao đổi tài nguyên
bằng cách dùng dư thừa các tài nguyên đó, do đó sẽ cải thiện được thông lượng và thời gian phản hồi toàn hệ thống.
b) Thực hiện giảm thời gian trễ bằng cách sử dụng các nguồn tài nguyên nhanh hơn, đặc biệt là sử dụng disk storage ở lớp mạng I/O, thêm bộ xử lí ở disk I/O, và thêm bộ nhớ (cache) ở bộ xử lí.
c) Thực hiện phân bổ cụ thể từng ứng dụng ứng với từng tài nguyên thông qua ma trận ứng dụng-tài nguyên.
3.2.2.2 Phân tán tài nguyên thông tin
Vấn đề phân bố dữ liệu trong hệ thống phải đảm bảo cân bằng giữa 4 yếu tố sau:
1. Các bảng dữ liệu liên quan đến nhau phải được sử dụng cùng nhau. 2. Các bảng quan trọng cần được sao lưu để đảm bảo tính an toàn.
3. Đảm bảo khả năng lưu trữ cũng như năng lực xử lí của vị trí đặt dữ liệu.
4. Xác định mức độ sử dụng của dữ liệu để thực hiện chia sẻ, ưu tiên thực hiện chia sẻ trong mạng LAN, hạn chế chia sẻ trong mạng WAN. Do đó có thể thực hiện chia nhỏ dữ liệu đến mức nhỏ nhất (cỡ hàng và cột trong một bảng dữ liệu) để tối ưu hoá việc chia sẻ này.
Thực hiện cập nhật các bản sao dữ liệu theo cơ chế nhiều pha:
Để tránh cập nhật nhiều vị trí trong cùng một giao dịch, người ta sử dụng cơ chế cập nhật cận đồng bộ nhiều pha như hình 3.5:
Pha 1: Cập nhật: Các bản cập nhật trước hết sẽ được ghi lại trong một bản sao ở node nội bộ, bản sao này hoạt động như một cache cập nhật nhất của bản chính.
Pha 2: Thu thập, các bản sao của bản cập nhật sẽ được chuyển đến server trung tâm nơi chứa bản sao chính, có nhiều phương pháp thực hiện việc này như gửi các thông điệp cập nhật theo từng lô, hoặc sử dụng các phần mềm tạo bản sao của các hệ quản trị cơ sở dữ liệu.
Pha 3: Tập hợp lại, các bản cập nhật sẽ được cập nhật vào bản sao chính trên máy chủ.
Pha 4: Phát tán bản sao, sau khi được cập nhật, bản sao chính sẽ được phát tán trên toàn hệ thống.
Pha 5: Apply, các bản cập nhật được apply vào phần dữ liệu nằm trên máy nội bộ.
Vấn đề toàn vẹn dữ liệu:
Khi dữ liệu nằm phân tán, ta sẽ giải quyết vấn đề toàn vẹn dữ liệu bằng cách
sử dụng cơ chế locking như mô tả trong chương I. Nếu cập nhật theo lô (batching) thì cần xem xét thêm thời gian xử lí tuỳ thuộc vào nền tảng truyền thông của hệ thống.
3.2.2.4 Phương pháp liên kết tiến trình với dữ liệu: Ta sẽ sử dụng các kĩ thuật truy cập dữ liệu sau đây:
1. Lưu dữ liệu ở máy chủ nội bộ và tạo bản sao nếu cần, việc tạo bản sao sẽ sử dụng cơ chế caching tĩnh và được xác định trước.
2. Sử dụng có chế caching động để thu được bản sao nội bộ của dữ liệu được dùng thường xuyên nhưng nằm trên máy khác.
4. Sử dụng cơ chế nhiều pha để lấy về lượng dữ liệu cần thiết tối thiểu để khởi động lại tiến trình trên máy gửi yêu cầu.
5. Sử dụng middleware để tập hợp các truy cập dữ liệu từ xa. 3.2.2.5 Thiết kế luồng ứng dụng:
Vấn đề cơ bản của việc thiết kế luồng ứng dụng là phương pháp chia nhỏ ứng dụng thành các thành phần nhỏ hơn. Sau khi chia nhỏ ứng dụng thành các thành phần nhỏ hơn ta không thể thiết kế lại ứng dụng và mức vật lí của hệ thống cũng không thể giải quyết được các vấn đề do việc thiết kế tầng ứng dụng để lại.
Thiết kế các ứng dụng nhiều pha:
Các ứng dụng phân tán bao gồm các tiến trình và thông điệp, do đó để thiết kế một ứng dụng phân tán ta phải xác định được hoạt động mỗi tiến trình, mỗi thông điệp và đường đi của các thông điệp này.
Đặc tính của tiến trình:
- Repeatable hay không repeatable: tiến trình có đặc tính repeatable là tiến trình có thể trong đó người dùng (hoặc tiến trình khác) không thể làm ảnh hưởng đến các tài nguyên quan trọng.
- Updating hay nonupdating: đây là khả năng có thể thay đổi dữ liệu hay không của tiến trình.
- Visible hay invisible: nếu thực hiện cập nhật liên tiếp lên một thành phần dữ liệu đơn thì có thể xẩy ra trường hợp các cập nhật sau cùng không khả dụng với các tiến trình khác, vấn đề này đặc biệt có ý nghĩa khi thực hiện tạo bản sao bằng batching hoặc replication.
- Revocable hay irrevocable: Đây là khả năng có thể khôi phục hoạt động của một tiến trình khi có lỗi xẩy ra.
- Compliant hay noncompliant: khả năng chấp nhận yêu cầu của tiến trình.
Các đặc tính của thông điệp: Với mỗi thông điệp giữa các tiến trình, ta phải xác định tính liên tục của nó tới một tiến trình ở xa hoặc tiến trình nội bộ, khả năng phản hồi nếu cần, và thông điệp được truyền theo cơ chế đồng bộ hay cận đồng bộ.
3.2.3 Mô hình thời gian phản hồi tham chiếu:
Trong mục này ta sẽ xem xét các thành phần thời gian phản hồi của một ứng dụng phân tán. Sau đây là mô hình tham chiếu thời gian phản hồi, hình 3.6. Mô hình này bao gồm 20 tầng thể hiện 20 thành phần cơ bản của thời gian phản hồi của giao dịch.
Hình 3.6: Mô hình thời gian phản hồi tham chiếu 3.2.3.1 Giới thiệu:
Mô hình này biểu diễn luồng giao dịch chính của một hệ thống core banking hoạt động trong môi trường client/server. Yêu cầu xuất phát từ workstation và
được xử lí bởi cả server nội bộ và server từ xa và các mạng kết nối, kết quả được gửi trả lại cho client.
Mô hình này tổng hợp tất cả các thành phần khác nhau có thể ảnh hưởng đến thời gian phản hồi của ứng dụng trong môi trường client/server. Nó bao gồm 20 tầng nhưng số tầng có thể thay đổi tuỳ thuộc ứng dụng. Hình 3.7 là một ví dụ về mô hình một ứng dụng xây dựng trên Web.
Hình 3.7: Một dạng của mô hình chuẩn, dựa trên kĩ thuật Web.
Như ta đã biết đối với các hệ thống máy tính, thời gian phản hồi chỉ bao gồm 2 dạng: thời gian sử dụng tài nguyên và thời gian chờ được sử dụng tài nguyên. Thời gian sử dụng tài nguyên sẽ ảnh hưởng lớn đến tổng thời gian phản hồi của ứng dụng nếu tốc độ xử lí của tài nguyên là chậm, ví dụ disk hay mạng WAN. Tuy nhiên trong môi trường phân tán, ứng dụng thường sử dụng nhiều thời gian để chờ được sử dụng các nguồn tài nguyên dùng chung, thời gian chờ này có thể tăng theo hàm mũ khi số lượng người dùng tăng lên. 3.2.3.2 Các thành phần chính cùa hệ thống:
Một số tác vụ có thể liên quan đến client nhưng nếu khả năng xử lí của
workstation không đủ mạnh thì có thể chuyển phần xử lí ứng dụng ra khỏi workstation.
Local server:
Trong hệ thống 2-tier, các hàm chia sẻ sẽ nằm trên server này. Enterprise server:
Nơi đặt hệ quản trị cơ sở dữ liệu và các tiến trình giám sát hoạt động của hệ quản trị cơ sở dữ liệu.
Network:
Để giảm thời gian phản hồi của ứng dụng cần thực hiện giảm lượng dữ liệu trao đổi giữa các client và server. Mạng truyền thông là thành phần chậm nhất và dễ phát sinh lỗi nhất trong hệ thống phân tán. Do đó đây là thành phần có performance kém nhất, để cải thiện performance của thành phần này ta cần thực hiện phân cấp dữ liệu và các tiến trình xử lí dữ liệu để tối thiểu hoá yêu cầu trao đổi dữ liệu giữa máy chủ và client.
3.2.3.3 Thiết kế chi tiết các thành phần của hệ thống: Tầng 1: Client GUI processing:
Trễ ứng dụng đầu tiên phát sinh ở giao diện người dùng (UI), do đó thiết kế giao diện người dùng cũng rất quan trọng. Giao diện người dùng được thiết kế tốt phải giảm được số tác vụ mà người dùng phải thực hiện để thu được dữ liệu theo yêu cầu. Các ứng dụng sử dụng các client dựa trên web sẽ chậm hơn
nếu các thành phần của UI phải thực hiện tải từ Web server. Với các ứng dụng sử dụng lặp đi lặp lại ở client thì nên duy trì các thành phần tĩnh của giao diện trong cache. Để cải thiện tốc độ của client GUI processing ta có thể thực hiện một số thiết kế như sau:
- Tạo các giao diện cố định cho các tác vụ lặp lại. Khi ứng dụng bao gồm nhiêu tác vụ lặp lại liên tiếp nhau thì giao diện người dùng nên bao gồm các cửa sổ, menu, và hộp thoại cố định.
- Tạo các đường dẫn cho giao diện người dùng. Các tác vụ có quan hệ với nhau mà người dùng thường sử dụng nên được thực hiện cùng nhau để cải thiện đáng kể performance của hệ thống.
Tầng 2: Client Data Logic:
Trong tầng này sẽ thực hiện một số tác vụ tương đối đơn giản như kiểm tra tính chính xác của dữ liệu đầu vào và xây dựng các yêu cầu để gửi đến server. Tốc độ của tầng này chủ yếu phụ thuộc vào disk I/O đang xử lí tác vụ khác hoặc cổng giao tiếp mạng đang xử lí dữ liệu thu thập được qua mạng. Các phương pháp cải thiện performance ở tầng này:
- Lưu lại các dữ liệu tĩnh hoặc ít thay đổi: Thực hiện lưu các thông tin được trao đổi một cách thường xuyên để xử dụng lại khi cần mà không phải truy suất đến các thiết bị ngoại vi khác, cũng như không phải thực hiện lại các thao tác tìm kiếm dữ liệu đã được sử dụng trước đó.
- Thừa kế động: Các công cụ phát triển ứng dụng dùng thừa kế động có thể hoạt động một cách không hiệu quả vì các yêu cầu nhận các thành phần thừa kế của client gửi đến server. Để giảm thiểu quá tải của thừa
kế động, cần phải sử dụng công cụ phát triển ứng dụng phù hợp và dùng mô hình phân cấp thừa kế dạng phẳng.
Tầng 3: Client Database I/O:
Giao diện vào ra cơ sở dữ liệu trên client trong tầng này dùng để kiểm tra tính chính xác của các dữ liệu vào trên các bảng, các bảng này có thể đã được lưu trên cache của client hoặc được gửi tới server trong các lô (batch). Phương pháp tối ưu hoá performance trong tầng này:
Tạo bản sao của các bảng: Định kì tải các bảng quan trọng (ví dụ các bảng dùng để kiểm tra tính chính xác của các thông tin đầu vào) tới workstation để tối thiểu hoá truy suất tới máy chủ dữ liệu.
Tầng 4: Truyền dẫn trên mạng LAN (đầu vào):
Các mạng LAN thường có tốc độ cao nhưng chúng dễ bị xung đột khi có quá nhiều người dùng cùng truy cập. Để tối thiểu hoá xung đột ta chứa các câu lệnh SQL trong các thủ tục từ xa hoặc các gói gửi tới server sẽ thao tác trên các dữ liệu của hệ quản trị cơ sở dữ liệu đó.
Tầng 5: Local Server Queuing:
Nếu sử dụng trình giám sát giao dịch hay message queuing middleware để - quản lí tài nguyên máy chủ thì giao dịch có thể phải chờ được một server nào đó xử lí. Để tối ưu hoá hệ thống, người ta sẽ gán data storage, transmission, và các yêu cầu xử lí ứng với từng tải với các tài nguyên phần cứng và phần mềm cụ thể.
Ta cũng có thể sử dụng dedicated application server để chia nhỏ công việc trên một server khi có yêu cầu.
Tầng 6: Local Server Input Processing:
Để tối ưu hoá, các module được sử dụng thường xuyên sẽ được biên dịchi một lần rồi tạo bản sao để sử dụng lại sau đó.
Tầng 7: Local Server Database I/O:
Tầng này chủ yếu thực hiện quá trình indexing và kĩ thuật ODBMS. Tầng 8: WAN queuing:
Máy chủ nội bộ có thể sử dụng middleware để quản lí các yêu cầu của người dùng do đó cần phải có một khoảng thời gian trễ nhất định để xử lí các yêu cầu này.
Độ trễ trong tầng này phụ thuộc kích thước dữ liệu định truyền, băng thông của đường truyền, và khoảng cách truyền dẫn.
Tầng 10: Remote Server Queuing:
Thông thường trong hệ thống core banking, các giao dịch đến thường được
quản lí bởi transaction management middleware( ví dụ TUXEDO…), mục đích là để thực hiện chia sẻ một cách hiệu quả nguồn tài nguyên của máy chủ. Để giảm thời gian chờ người ta thường thực hiện phân mức ưu tiên xử lí theo các ứng dụng cụ thể.
Tầng 11: Remote Server Processing:
Đây là tiến trình xử lí các dữ liệu truy suất, để tối ưu hoá người ta sử dụng các SQL gateway.
Tầng 12: Remote Server Database I/O: Tầng 13: WAN queuing of results:
Giống tầng 8, tuy nhiên ứng với một yêu cầu có thể có nhiều thông điệp phản hồi, do đó cần tập hợp các thông điệp trước khi gửi đi.
Tầng 14: WAN transmission of results:
Giống tầng 9 nhưng nó cũng có thể bao gồm nhiều thông điệp khác nhau. Tầng 15: Local Server queuing:
Giống tầng 5 nhưng có nhiều hơn một yêu cầu được phục vụ, do đó thời gian chờ cần lâu hơn.
Tầng 16: Local server results processing:
Các kết quả riêng lẻ được tập hợp lại theo yêu cầu của ứng dụng. Tầng 17: Local server database I/O:
Các kết quả được chứa trong các bảng nội bộ, nếu lượng thông tin phản hồi quá lớn thì cần chia nhỏ để gửi đến cho client. Có thể cải thiện performance