CHƢƠNG 1 CƠ SỞ LÝ THUYẾT
1.4.2.3. Lợi ích event-driven so với thread-driven
Sẽ có 2 câu hỏi đƣợc đặt ra ở đây đó là:
Một là: Mặc định, NodeJs chỉ có một luồng đƣợc thực thi. Nó khơng cần đợi các
tác vụ vào ra hoặc là chuyển nội dung.Thay vào đó, các tác vụ vào/ra sẽ tự động tạo ra một hàm điều khiển gửi tới các sự kiện khi mà mọi thứ đã xong.Các sự kiện lặp và mơ hình điều hƣớng lặp cũng giống nhƣ cách mà JavaScript ở phía trình duyệt thực hiện.Chƣơng trình sẽ xử lý các hành động và nhanh chóng quay về vịng lặp để gửi các tác vụ khác đến.Khi load 1 trang và đang chờ nó truy xuất cơ sở dữ liệu, thì NodeJs sẽ tranh thủ phục vụ request khác.Trong khi việc chờ truy xuất cơ sở dữ liệu vẫn tiếp tục.Vậy cũng thể coi đó là 2 tiến trình hồn tịan khác nhau.
SVTH: Trần Thị Hồng Ánh – Lớp 09CNTT2 19
Hai là: Ngay trong hệ điều hành đã áp dụng mơ hình dựa theo sự kiện (event-
based) rồi. Nó sẽ khơng chỉ có 1 thread mà sẽ có rất nhiều thread. Và khi 1 thread tiến trình đang bị blocking I/O. Thì hệ điều hành sẽ cho các thread khác đƣợc chạy thay thế. Và nhƣ thế sẽ khơng có thời gian trễ.Nhƣ vậy sẽ khơng có lợi ích gì đáng kể của mơ hình hƣớng sự kiện so với khơng hƣớng sự kiện.
Có thể trả lời 2 câu hỏi trên bằng 1 ví dụ nhƣ sau : (Ở đây ta sẽ so sánh NodeJs với Apache)
Cho 1 đoạn code:
result = query(“select A from B”); do_something(result);
Theo cách thông thƣờng nhƣ trên. Nếu một request đƣợc gửi đến yêu cầu xử lý đoạn code trên. Webservice sẽ phải tạo ra 1 thread để xử lý. Vấn đề là thread đƣợc tạo ra đó sẽ khơng làm gì cả trong khi hàm query() vẫn đang chạy. Cho đến khi kết quả của câu lệnh truy vấn SQL trên xử lý thành cơng, lâu hay nhanh thì tùy thuộc vào độ phức tạp của câu truy vấn. Sau đó thread sẽ gọi hàm do_something. Đó thực sự khơng tốt bởi vì trong khi tồn bộ các tiến trình đang trong trạng thái đợi (trừ tiến trình SQL) thì các yêu cầu mới vẫn tiếp tục đƣợc gửi đến. Lúc này sẽ sinh ra rất nhiều các tiến trình đang đợi thực thi câu lệnh, theo đúng cơ chế blocking, vẫn ngốn tài nguyên máy chủ nhƣng khơng làm gì cả. Và nếu tất cả các tiến trình nhiều đến mức ngốn hết tài nguyên trong khi các tác vụ vẫn chƣa xong vì phải đợi thì lúc đó hệ thống sẽ sụp đổ.Quả thực là rất lãng phí. Mà việc chuyển trạng thái giữa các tiến trình là ln có một khoảng thời gian trễ nào đó, mà càng nhiều tiến trình thì CPU càng mất nhiều thời gian để lƣu trữ và khởi động lại các trạng thái, kéo theo tổng thời gian trễ đợi chuyển giữa các tiến trình là tăng lên. Đơn giản bằng cách không đồng bộ, NodeJs sẽ tận dụng triệt để tài ngun do khơng có tài nguyên nào phải đợi lãng phí nữa. Một điểm yếu của lập trình hƣớng luồng là việc đồng bộ và tính đồng nhất của nó. Độ phức tạp của nó đến từ việc trao đổi giữa các biến và các hàm để tránh việc deadlock và xung đột giữa các luồng với nhau.
NodeJs khiến cho chúng ta phải hiểu theo một nghĩa khác thế nào là đồng nhất. Các hàm callback đƣợc gọi một cách không đồng bộ trong các sự kiện lặp xử lý khá tốt trong việc đồng nhất, khiến cho mơ hình đồng nhất trở nên đơn giản hơn, dễ hiễu hơn và dễ thực hiện hơn.Nhất là khi với việc trễ trong truy xuất các đối tƣợng.Nếu truy suất trong bộ nhớ thì ta chỉ mất với thời gian là nano giây, truy xuất đĩa cứng hoặc qua
SVTH: Trần Thị Hồng Ánh – Lớp 09CNTT2 20
mạng cục bộ thì có thể mất thời gian là mili giây hoặc thậm chí cả giây.Nhƣng việc truy xuất đó chƣa hẳn đã xong, sẽ còn khá nhiều các tác vụ khác nữa trƣớc khi đƣợc đƣa đến ngƣời dùng cuối, họ sẽ phải chờ rất nhiều thời gian để kết quả có thể hiện ra.
Cịn với NodeJs thì câu truy vấn sẽ nhƣ sau:
query(statement: “select A from B”, function(result){ //Xử lý kết quả sau khi trả về
do_something(); });
Theo cách viết dƣới thì NodeJs, sẽ báo cho môi trƣờng hoạt động là khi nào cần tạo tiến trình và phải làm gì. Đơn giản ở đoạn code trên, chƣơng trình vẫn sẽ tạo ra một thread và sẽ báo là khi nếu có câu truy vấn query() thì chƣơng trình sẽ đợi hàm đó chạy xong. Trong lúc đợi query() chạy nó có thể phục vụ các truy vấn khác. Khi nào query() truy vấn cơ sở dữ liệu xong. Chƣơng trình sẽ quay trở lại gọi lại hàm callback ở trên là do_something(). Do đó, thread đó sẽ khơng phải đợi. Việc tính tốn giữa nhiều request có thể thực hiện một cách song song.
Cách viết code ở trên thực hiện y hệt nhƣ code ở phía trƣớc nữa thực hiện. Chỉ có điểm khác biệt là kết quả của việc truy vấn không phải là trả về kết quả truy vấn mà là trả về 1 hàm callback sẽ đƣợc thực thi sau khi truy vấn đƣợc thực thi hoàn toàn. Lúc này khi sau khi truy vấn đƣợc thực thi xong. Ta có thể tồn quyền xử lý với kết quả trả về, đặt thêm các sự kiện khác đến với nó.
Tóm lại, sức mạnh của nodejs khơng dựa vào vịng lặp bắt sự kiện của nó hoặc là đồng bộ vào/ra mà lại dựa vào hệ thống callback của nó đã làm giảm rất nhiều thời gian chờ của hệ thống.
Node Package Manager (NPM)
1.4.3.
1.4.3.1. Giới thiệu về NPM
Đƣợc viết tắt bởi Node Package Manager (Trình quản lý gói của nodejs).Nó vừa là một trình quản lý gói vừa là một hệ thống phân tán phục vụ cho NodeJs.Mục đích chính của nó là tạo ra và phân phối các gói Node, các module qua internet sử dụng dòng lệnh.Với npm chúng ta có thể dễ dàng tìm các module một cách tự động qua mạng.Chỉ với một câu lệnh, ta có thể tải, cài và sử dụng các module.
SVTH: Trần Thị Hồng Ánh – Lớp 09CNTT2 21