Đồ án Xây dựng hệ thống tương tác trực tuyến

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ──────── * ───────

ĐỒ ÁN

TỐT NGHIỆP ĐẠI HỌC NGÀNH CÔNG NGHỆ THÔNG TIN

XÂY DỰNG HỆ THỐNG TƯƠNG TÁC TRỰC TUYẾN

Sinh viên thực hiện: Lê Văn Thành

Lớp: CNTT 5 – K55

Giáo viên hướng dẫn: ThS. Hoàng Anh Việt

HÀ NỘI 05-2015

Xây dựng hệ thống tương tác trực tuyến

Sinh viên thực hiện: Lê Văn Thành 20102156 Khóa 55 1

PHIẾU GIAO NHIỆM ĐỒ ÁN TỐT NGHIỆP 1. Thông tin về sinh viên

Họ và tên sinh viên: Lê Văn Thành

Điện thoại liên lạc: 0987 886 025 Email: [email protected]

Lớp: CNTT 5 Hệ đào tạo: Chính quy

Đồ án tốt nghiệp được thực hiện tại: Bộ môn công nghệ phần mềm - Viện CNTT và TT

Thời gian làm ĐATN: Từ ngày 28/02/2015 đến 28/05/2015

2. Mục đích nội dung của ĐATN

Mục đích của đồ án là xây dựng một giải pháp hệ thống tương tác trực tuyến, từ đó xây dựng một game online để demo hệ thống.

3. Các nhiệm vụ cụ thể của ĐATN

9 Nghiên cứu và áp dụng cơ chế Non-blocking IO Network giải quyết xử lý số lượng kết nối đồng thời dùng lớn

9 Nghiên cứu giải pháp phân cụm Clustering và áp dụng Hazelcast vào giải quyết vấn đề về mở rông, chịu tải, chịu lỗi.

9 Nghiên cứu giải pháp cơ chế Extension (Plugin) cho phép các nhà phát triển chạy các đoạn mã dưới phần mở rộng

9 Xây dựng hệ thống tương tác trực tuyến client – server áp dụng cho game online.

4. Lời cam đoan của sinh viên

Tôi - Lê Văn Thành - cam kết ĐATN là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của Ths. Hoàng Anh Việt. Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ công trình nào khác.

Hà Nội, ngày 29 tháng 05 năm 2015

Tác giả ĐATN

Lê Văn Thành

5. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo vệ:

Hà Nội, ngày 29 tháng 05 năm 2015

Giáo viên hướng dẫn

Ths. Hoàng Anh Việt



TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP Sự phát triển vũ bão của Intenet và mạng di động đã mở ra cơ hội rất lớn cho thị

trường các dịch vụ tương tác trực tuyến.

Mục tiêu của đồ án là pháp triển một giải pháp hỗ trợ xây dựng các hệ thống tương tác trực tuyến, từ đó đi tới xây dựng một game online để demo hệ thống.

Trong đồ án này sẽ trình bày các phân tích, thiết kế hệ thống và 3 giải pháp cụ thể giải quyết các vấn đề của hệ thống tương tác online.

Đồ án được chia thành 4 chương:

x Chương 1: Đặt vấn đề, định hướng, giải pháp x Chương 2: Phân tích, thiết kế hệ thống x Chương 3: Cài đặt và thử nghiệm hệ thống x Kết luận và hướng phát triển



LỜI CẢM ƠN

Lời đầu tiên, em xin đu ợc gửi lời cảm o n chân thành đến các thầy cô trong tru ờng Đại Học Bách Khoa Hà Nọi cũng nhu các thầy cô giáo trong Viẹ n Công Nghẹ Thông Tin và Truyền Thông đã truyền dạy cho em nhưng kiến thức và kinh nghiẹ m quý báu trong suốt quá trình học tạ p và tu du ơng trong 5 na m qua.

Em xin đu ợc gửi lời cảm o n chân thành tới thầy Ths. Hoàng Anh Viẹ t - Giảng viên bộ môn công nghẹ phần mềm, Viẹ n Công Nghẹ Thông tin và Truyền đã huớng dẫn, chỉ dạy và giúp đơ em rất nhiều trong quá trình học tạ p nghiên cứu. Thầy không chỉ cho em nhưng kiên thức chuyên môn mà cả nhưng kĩ năng mềm trong cuộc sống, kĩ năng ra quyết định giúp em trưởng thành hơn rất nhiều.

Em xin được gửi lời cảm ơn tới anh Nguyễn Hoàng Bách – CNPM K51 đã giúp đơ em, cho em rất nhiều kiến thức, kinh nghiệm làm việc thực tế trong suốt quá trình làm đồ án.

Em cũng xin được cảm ơn tới anh Vũ Trọng Quý và tập thể công ty Tap Studio đã tạo mọi điều kiện để em có thể hoàn thành đồ án một cách tốt nhất.

Cuối cùng, em xin đu ợc gửi lời cảm o n chân thành tới gia đình, bạn bè đã quan tâm, đọ ng viên, đóng góp ý kiến giúp đơ em trong quá trình học tạ p, nghiên cứu và hoàn thành đồ án tốt nghiẹ p.

Hà Nội, Ngày 29 tháng 5 năm 2015

Lê Văn Thành



MỤC LỤC

PHIẾU GIAO NHIỆM ĐỒ ÁN TỐT NGHIỆP .................................................... 1

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP ................................................... 2

LỜI CẢM ƠN ........................................................................................................... 3

MỤC LỤC ................................................................................................................ 4

DANH MỤC HÌNH ẢNH ........................................................................................ 6

DANH MỤC CÁC BẢNG ....................................................................................... 7

DANH MỤC CÁC TỪ VIẾT TẮT ......................................................................... 7

Chương 1: ĐẶT VẤN ĐỀ, ĐỊNH HƯỚNG VÀ GIẢI PHÁP .............................. 8

1.1. Đặt vấn đề ................................................................................................................ 8

1.1.1. Khái niệm hệ thống tương tác trực tuyến .......................................................... 8

1.1.2. Tiềm năng thị trường các dịch vụ tương tác trực tuyến .................................... 8

1.2. Phát biểu bài toán ................................................................................................. 11

1.3. Phương hướng giải quyết bài toán ...................................................................... 12

Chương 2: PHÂN TÍCH THIẾT KẾ HỆ THỐNG ............................................ 13

2.1. Mô tả hệ thống ....................................................................................................... 13

2.2. Phân tích thiết kế hệ thống ................................................................................... 14

2.2.1. Kiến trúc hệ thống ........................................................................................... 14

2.2.1.1. Kiến trúc tổng quan .............................................................................................. 14

2.2.1.2. Kiến trúc game engine ......................................................................................... 16

2.2.2. Biểu đồ UseCase ............................................................................................. 18

2.2.3. Thiết kế database............................................................................................. 19

2.2.4. Thiết kế phần mở rộng .................................................................................... 20

2.2.5. Biểu đồ tuần tự chức năng .............................................................................. 24

2.2.5.1. Chức năng đăng nhập ........................................................................................... 24

2.2.5.2. Chức năng chọn phòng ........................................................................................ 26

2.2.5.3. Chức năng gửi lời mời thách đấu ......................................................................... 27

2.2.5.4. Chức năng chấp nhận lời mời thách đấu .............................................................. 28

2.2.5.5. Chức năng chơi game........................................................................................... 30

Chương 3: CÁC GIẢI PHÁP TRỌNG TÂM ..................................................... 32

3.1. Cơ chế NIO Network ............................................................................................ 32



3.1.1. Giao thức truyền tin TCP/IP và UDP .............................................................. 32

3.1.1.1. Giao thức TCP/IP ................................................................................................. 32

3.1.1.2. Giao thức UDP ..................................................................................................... 35

3.1.2. Cơ chế NIO Network ...................................................................................... 37

3.2. Hệ thống phân cụm Clustering ............................................................................ 41

3.2.1. Khái niệm hệ thống phân cụm ........................................................................ 42

3.2.2. Giới thiệu Hazelcast và ứng dụng ................................................................... 44

3.3. Cơ chế Extension (Plugin) .................................................................................... 47

Chương 4: Kết quả đạt được ................................................................................ 51

4.1. Môi trường cài đặt ................................................................................................ 51

4.2. Cài đặt và kiểm thử hệ thống ............................................................................... 51

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN ............................................................ 56

Đánh giá kết quả đạt được .......................................................................................... 56

Phương hướng phát triển ............................................................................................ 56

TÀI LIỆU THAM KHẢO ..................................................................................... 57



DANH MỤC HÌNH ẢNH Hình 1.1: Thống kê sử dụng Intenet tại Việt Nam ........................................... 9

Hình 2.1: Mô hình hệ thống PIS .................................................................... 13

Hình 2.2: Kiến trúc tổng quan hệ thống ......................................................... 14

Hình 2.3: Kiến trúc game engine ................................................................... 16

Hình 2.4: Biểu đồ usecase hệ thống ............................................................... 18

Hình 2.5: Mô hình phần lõi database ............................................................. 20

Hình 2.6: Biểu đồ usecase game Đấu Trí Online ........................................... 21

Hình 2.7: Mô hình CSDL game Đấu Trí Online ........................................... 23

Hình 2.8: Biểu đồ tuần tự chức năng đăng nhập ............................................ 24

Hình 2.9: Biểu đồ tuần tự chức năng chọn phòng ......................................... 26

Hình 2.10: Biểu đồ tuần tự chức năng gửi lời mời thách đấu ........................ 27

Hình 2.11: Biểu đồ tuần tự chức năng chấp nhận lời mời ............................. 28

Hình 2.12: Biểu đồ tuần tự chức năng chơi game .......................................... 30

Hình 3.1: Cổng truy nhập dịch vụ TCP ......................................................... 32

Hình 3.2: Dạng thức Segment của TCP ......................................................... 34

Hình 3.3: Dạng thức gói tin UDP .................................................................. 36

Hình 3.4: Mô hình quan hệ họ giao thức TCP/IP .......................................... 37

Hình 3.5: Các công đoạn xử lý request của hệ thống .................................... 39

Hình 3.6: Mô hình NIO Network ................................................................... 40

Hình 3.7: Kiến trúc Apache Mina .................................................................. 41

Hình 3.8: Biểu đồ hoạt động sử dụng Hazelcast ............................................ 46

Hình 3.9: Biểu đồ hoạt động cài đặt buffer insert (update) Hazelcast ........... 47

Hình 3.10: Cấu trúc thư mục cài đặt phần mở rộng ....................................... 48

Hình 3.11: Cơ chế load class trong Java ........................................................ 49

Hình 3.12: Biểu đồ hoạt động load extension ................................................ 50



DANH MỤC CÁC BẢNG Bảng 1: Giá các sản phẩm phiên bản SmartFoxBasic ................................... 10

Bảng 2: Giá các sản phẩm Smartfox 2X ........................................................ 11

Bảng 3: Giá các các sản phẩm Electro Server ............................................... 11

Bảng 4: Giá các sản phẩm PhotonServer ....................................................... 11

Bảng 5: Thiết kế database phần lõi PIS ......................................................... 20

Bảng 6: Thiết kế database phần mở rộng Đấu Trí Online ............................. 23

Bảng 7: Các kết quả kiểm thử hệ thống ......................................................... 55

DANH MỤC CÁC TỪ VIẾT TẮT

STT Từ viết tắt Ý nghĩa

1 OTT Over The Top: giải pháp cung cấp nội dung dựa trên Internet mà không phải các nhà cung cấp dịch vụ Internet (ISP) đưa đến

2 LTV lập trình viên

3 HTTP Hypertext Transfer Protocol: Giao thức truyền tải siêu văn bản

4 TCP Transmission Control Protocol: Giao thức điều khiển truyền vận, là một trong các giao thức cốt lõi của bộ giao thức TCP/IP

5 IP Internet Protocol

6 UDP User Datagram Protocol

7 JVM Java Vitual Machine: máy ảo Java

8 CPU Central Processing Unit: đơn vị xử lý trung tâm

9 CCUs Concurrent Users: số lượng người truy cập đồng thời

10 NIO Non-blocking IO

11 CSDL Cơ sở dư liệu

12 RAM Random Access Memory: bộ nhớ truy cập ngẫu nhiên



Chương 1: ĐẶT VẤN ĐỀ, ĐỊNH HƯỚNG VÀ GIẢI PHÁP

Nội dung chương này trình bày nhưng vấn đề sau: 9 Giới thiệu các hệ thống tương tác trực tuyến 9 Tiền năng và sự phát triển các dịch vụ tương tác trực tuyến 9 Một số giải pháp hệ thống tương tác trực tuyến đã có 9 Mục tiêu đề tài 9 Giải pháp cụ thể giải quyết đề tài

1.1. Đặt vấn đề

1.1.1. Khái niệm hệ thống tương tác trực tuyến

Hệ thống tương tác trực tuyến là hệ thống cho phép người dùng tương tác, kết nối trực tiếp với nhiều người khác trong việc trao đổi thông tin hoặc cùng sử dụng một dịch vụ nào đó. Một hệ thống tương tác trực tuyến phải có khả năng tích hợp nhiều dịch vụ, có tính kết nối, chia sẻ, và thời gian trả về đáp ứng được nhu cầu của người sử dụng.

Một số hệ thống tương tác trực tuyến phổ biến như mạng xã hội (facebook, twitter,…), các dịch vụ OTT (zalo, viber,…), các hệ thống đào tạo trực tuyến, các dịch vụ giải trí online như xem TV, video chat, game online…

1.1.2. Tiềm năng thị trường các dịch vụ tương tác trực tuyến

Sự phát triển của Internet tại Việt Nam

Cùng với sự phát triển Internet trên thế giới, Việt Nam đã liên tục đứng trong top 20 quốc gia có số lượng người dùng Internet lớn nhất thế giới, với tỷ lệ hơn 30% [1] dân số. Sự phát triển hạ tầng của công nghệ 3G của các nhà mạng cùng với gói cước hấp dẫn khiến cho người truy cập Internet trên điện thoại di động tăng lên trong thời gian gần đây chiếm 30%, trong tổng số 27,5 [2] triệu thuê bao di động.



Hình 1.1: Thống kê sử dụng Intenet tại Việt Nam [3]

Internet và mạng di động đã thúc đẩy các loại hình dịch vụ trực tuyến. Sự phát triển của Internet cũng kéo theo nhưng nhu cầu về thông tin, chia sẻ tăng lên theo. Cụ thể, thay vì chỉ là nhưng trang web tĩnh thuần mang nội dung nay đã xuất hiện nhưng trang web có tính chia sẻ như forum, các trang mạng chia sẻ ảnh, video. Tiếp đến là thời kỳ của các dịch vụ có tính tương tác cao như gọi video, chơi game online, học online, mạng xã hội, nhắn tin qua mạng…

Thị trường các dịch vụ tương tác trực tuyến

Theo thống kê trong số 31 triệu người đang sử dụng Internet có đến 86% sử dụng truy cập mạng xã hội, hơn 6.5 triệu [4] người đang sử dụng các dịch vụ OTT. Sự phát triển mạnh mẽ của các ứng dụng OTT thậm chí là mối lo cho các nhà mạng, bởi các công nghệ kết nối Wifi, 3G ngày càng phổ biến, việc sử dụng ứng dụng OTT với chi phí rẻ đang dần thay thế cách nhắn tin, gọi điện truyền thống.

Về giáo dục, xu hướng phát triển các hệ thống đào tạo trực tuyến là điều tất yếu. Song việc triển khai các dự án đào tào trực tuyến ở Việt Nam còn gặp nhiều khó khăn bởi các dịch vụ này vẫn bị coi là phụ thay cho cách học chính (học trực tiếp tại lớp) và tính tương tác chưa cao hoặc chưa khai thác hết các tiện ích của việc học qua Internet.



Bên cạnh đó, các dịch vụ giải trí online có tính tương tác cao phát triển mạnh, xuất hiện ngày nhiều càng và đa dạng như chơi game online, video call, xem TV trực tuyến, các chương trình game show, trò chuyện với thần tượng…

Một số giải pháp xây dựng hệ thống tương tác trực tuyến

Sự đa dạng trong các dịch vụ tương tác trực tuyến đòi khỏi các nhà phát triển cần có một giải pháp xây dựng hệ thống đa phương tiện, có cơ chế mở rộng để có thể xây dựng không chỉ một dịch vụ mà nhiều dịch vụ, ứng dụng chạy trên đó. Lấy ví dụ từ một hệ thống lớp học online không chỉ cung cấp cách học online mà còn cung cấp chức năng chat nhóm, chơi game giải trí ngoài giờ học.

Hiện nay có một số giải pháp đáp ứng được các yêu cầu trên như: NodeJS, Licode, Google Cloud Service, ElectroServer, SmartFoxServer, Photon Server, Raknet Server… Trong đó, hầu hết các giải pháp liên quan tới game, vì một cách bản chất, game server đáp ứng tất cả các yêu cầu của một hệ thống tương tác trực tuyến như đã nói trên.

Đặc điểm chung của các giải pháp game server trên là:

x Hỗ trợ API đa nền tảng Adobe Flash, Unity, iOS, Android, Windows Phone 8, HTML5, Windows 8

x Hỗ trợ đầy đủ các phương thức kết nối (TCP, UDP, HTTP, WebSocket)

x Cho phép cài đặt extension (plugin) x Hỗ trợ tốt xây dựng hệ thống thời gian thực, nhiều người dùng x Xử lý được số lượng request đồng thời lớn

Giá bán của một số giải pháp trên là:

a) SmartFoxServer

Phiên bản SmartFoxBasic

Sản phẩm Đặc điểm Giá

SmartFoxServer Basic Unlimited Users license

Không giới CCUs € 800

SmartFoxServer Basic 500 Users license

Giới hạn 500 CCUs € 400

SmartFoxServer Basic 100 Users license


Bảng 1: Giá các sản phẩm phiên bản SmartFoxBasic

Phiên bản SmartFox2X




SmartFoxServer 2X Unlimited Users + Analytics Pro license

Không giới hạn CCUs € 4000

SmartFoxServer 2X 5000 Users + Analytics Pro license


SmartFoxServer 2X 500 Users + Analytics Basic license


Bảng 2: Giá các sản phẩm Smartfox 2X

Ngoài ra còn phiên bản SmartFoxPro có giá từ €400 - €2000

b) ElectroServer


Electro 1000 User 1000 CCUs $ 999

Electro Unlimited Users Không giới hạn CCUs $ 4999

Bảng 3: Giá các các sản phẩm Electro Server

c) PhotonServer


FREE 100 CCUs 0

500 CCUs 500 CCUs, 200.000 active trong tháng $25 / tháng

Unlimited CCU

Không giới hạn CCUs, không giới hạn lượng active

$175 / tháng

Enterprise Không giới hạn CCUs, lượng active, số server

$1500 / tháng $750/tháng cho startup

Bảng 4: Giá các sản phẩm PhotonServer

Các nhà phát triển Việt Nam có nhiều ý tưởng sáng tạo, mong muốn xây dựng các ứng dụng có tính tương tác cao, tuy nhiên rào cản về ngôn ngư dẫn đến không hoàn toàn làm chủ được công nghệ và thu nhập khiến cho việc tiếp cận các giải pháp trên gặp nhiều khó khăn.

1.2. Phát biểu bài toán

Như vậy qua nhưng con số thống kê cho thấy tiềm năng từ các dịch vụ tương tác trực tuyến là rất lớn tuy nhiên các nhà phát triển gặp rào cản trong việc tiếp cận các giải pháp có sẵn. Vì vậy, mục tiêu của đồ án tốt nghiệp là phát triển được một



giải pháp hỗ trợ xây dựng các hệ thống tương tác trực tuyến, từ đó xây dựng một game online để demo hệ thống.

1.3. Phương hướng giải quyết bài toán

Để phát triển được một giải pháp hỗ trợ xây dựng các hệ thống tương tác trực tuyến, người viết đồ án phải giải quyết một số vấn đề cụ thể như: duy trì số lượng người dùng lớn, cơ chế cho phép cắm các phần mở rộng. Bên cạnh đó một hệ thống tương tác online phải có khả năng chịu tải, chịu lỗi, đáp ứng nhu cầu về mở rộng, mềm dẻo trong việc tích hợp nhiều dịch vụ.

Nhiệm vụ của đồ án là xây dựng một hệ thống online hoàn chỉnh bao gồm client và server, trong đó tập trung nghiên cứu ba giải pháp cụ thể để giải quyết các vấn đề sau:

- Giải pháp Non-blocking IO Network áp dụng xử lý số lượng kết nối, request đồng thời lớn. Mục tiêu của hệ thống là xử lý được 5000 CCUs

- Giải pháp quản lý Extension (Plugin) cho phép các nhà pháp triển chạy các đoạn mã của họ như một phần mở rộng.

- Giải pháp phân cụm Clustering đáp ứng yêu cầu khi cần scale hệ thống, tăng khả năng chịu tải, chịu lỗi.

Kết chương

¾ Như vậy ở chương 1 người viết đồ án đã trình bày các vấn đề: Giới thiệu hệ thống tương tác trực tuyến, tiềm năng của các dịch vụ tương tác trực tuyến, một số giải pháp sẵn có trên thị trường và mục tiêu của đồ án.

¾ Sang chương 2 người viết đồ án sẽ trình bày về phân tích, thiết kế hệ thống cho phần engine và phần mở rộng game online.



Chương 2: PHÂN TÍCH THIẾT KẾ HỆ THỐNG

Nội dung chương này trình bày nhưng vấn đề sau: 9 Mô tả hệ thống PIS 9 Phân tích thiết kế hệ thống PIS 9 Phân tích thiết kế cho phần mở rộng game online

2.1. Mô tả hệ thống

Trong khuôn khổ đồ án tốt nghiệp này, người viết đồ án tập trung vào xây dựng server side bao gồm phần lõi là game server engine cho phép cắm các phần mở rộng, rồi từ đó xây dựng phần mở rộng phục vụ game logic “Đấu Trí Online”. Client side do một người khác đảm nhiệm thuộc công ty Tap Studio, trong thời gian em thực tập tại đây.

Giải pháp có tên gọi là Parrot Interactive Solution.

Game ServerEngine

JVM

Extension 0

Extension 1

Extension n

Đấu Trí Game LogicExtension

Hình 2.1: Mô hình hệ thống PIS

Đấu Trí Online là một game online, mô phỏng game show truyền hình trực tuyến “Đuổi hình bắt chư”, thông qua giao diện chương trình người chơi được lựa chọn đối thủ thách đấu, rồi cùng trả lời câu hỏi của hệ thống trong một thời gian nhất định. Người chơi hoàn toàn được trải niệm sự thú vị thông qua việc sử dụng bảo bối, chức năng cửa hàng, các kênh thanh toán, kết bạn, tặng quà.

Để xây dựng PIS (Parrot Interactive Solution) người viết đồ án lựa chọn ngôn ngư lập trình Java bởi sự tiện lợi và sức mạnh khi làm việc với hệ thống lớn cần đòi hỏi tốc độ cao, khả năng xử lý song song, đa tiến trình rất phù hợp với hệ thống online.



Mặc khác, Java là một ngôn ngư lập trình mở, có hàng ngàn bộ thư viện hỗ trợ mọi đòi hỏi phía LTV (lập trình viên), giúp LTV rút ngắn thời gian phát triển và bảo trì hệ thống.

2.2. Phân tích thiết kế hệ thống

Bài báo cáo này sử dụng phương pháp phân tích thiết kế hướng đối tượng, sử dụng các kí pháp của UML 2.0 để mô hình hóa, đặc tả hệ thống. Các bước tiến hành thiết kế hệ thống được xây dựng theo mô hình prototype trong quy trình phát triển phần mềm. Dựa trên quy trình này người viết đồ án đưa ra các mô hình phân tích, mô hình thiết kế, tiến hành xây dựng hệ thống bằng thực nghiệm đã xây dựng được.

2.2.1. Kiến trúc hệ thống

2.2.1.1. Kiến trúc tổng quan

Mobile Desktop

Internet

WebBrowser Tablet

PaymentWebService

<<Http>>

Cluster

Server

Hazelcast DataGrid

Mysql Database

Cluster

Server

Hazelcast DataGrid

Cluster

Server

Hazelcast DataGrid

Hình 2.2: Kiến trúc tổng quan hệ thống



Hệ thống được thiết kế theo mô hình client – server. Với mô hình này, một server có vai trò là nhà cung cấp, chờ đợi các yêu cầu xử lý và trả về cho client. Client và server giao tiếp với nhau thông qua Internet.

Hệ thống có thể giao tiếp với nhiều client đa nền tảng và hỗ trợ các phương thức kết nối HTTP, TCP, UDP, WebSocket.

Các hệ thống game server đòi hỏi số lượng công việc tương tác với CSDL rất lớn và liên tục. Để tăng khả năng sẵn sàng của hệ thống khi làm việc với CSDL, người viết đồ án đưa ra mô hình phân cụm dư liệu. Trong đó các server chia sẻ dư liệu in-memory được hỗ trợ bởi giải pháp Hazelcast. Các dư liệu này được lưu trư phân tán trên RAM của các node trong hệ thống Hazelcast. Các dư liệu thường được lưu trư in-memory là nhưng dư liệu cần insert, update nhiều vào hệ thống như log activity, log transaction, log game, sau đó hệ thống thiết lập một khoảng thời gian xử lý các dư liệu này theo lô vào database, mỗi lô thường gộp tối đa 10000 query thành 1 query, rồi thực hiện batch insert, batch update vào MySQL, tối thiểu hóa các thao tác đóng mở kết nối với database tốn nhiều tài nguyên, tận dụng tối đa hiệu năng của MySQL đem lại, tối ưu thời gian xử lý của hệ thống. Mô hình phân cụm dư liệu có khả năng chịu lỗi cao do dư liệu in-memory được đồng bộ trên nhiều server đảm bảo dư liệu không bị mất đi khi một server nào đó gặp sự cố.



2.2.1.2. Kiến trúc game engine

Hazelcast Mysql Server

Executor ServiceLobby System

Extensions Manager

NIO Networking

Encode/DecodeMessage

Event Driven

Session ManagerConnection

Core

Data Layer

Hình 2.3: Kiến trúc game engine

Phần lõi của giải pháp có vai trò rất quan trọng trong việc điều khiển mọi hoạt động của hệ thống như: nhận kết nối từ phía client, xử lý (encode/decode) message, điều khiển luồng vào ra của người chơi, load các extensions, thao tác với CSDL. Do đó, hệ thống chỉ chạy tốt khi phần lõi của giải pháp có một kiến trúc tốt, có khả năng xử lý nhanh, đồng thời, có khả năng chịu lỗi và chịu tải lớn.

Kiến trúc của game server được chia thành 3 tầng:

Tầng Connection

- Quản lý các phiên kết nối, giúp server liên lạc với client dễ dàng thông qua session id

- Cơ chế Non-blocking IO Network giúp hệ thống chịu tải được số lượng lớn kết nối đồng thời

Tầng Core



- Lobby System: hệ thống phân cấp các khu vực trong game, cung cấp API để các phần mở rộng có thể quản lý được luồng vào ra của người dùng

- Executor Service: cung cấp các phương thức xử lý multi-threading thông qua quản lý các thread bằng thread pool cho phép hệ thống tối ưu hóa CPU, đáp ứng các công việc cần xử lý đồng thời.

- Extension Manager: quản lý extensions, cơ chế load các file extension config, cùng các thư viện đóng gói game logic, từ đó chạy các đoạn mã do người phát triển tạo ra.

- Encode/Decode Message: xử lý tối ưu hóa thông điệp trao đổi bằng việc giảm kích thước gói tin, tăng tốc độ truyền nhận client-server.

Tầng Data

- Hệ quản trị CSDL MySQL: là CSDL miễn phí tốt nhất. Sự tiện lợi của MySQL được thể hiện qua tốc độ xử lý nhanh, độ tin cậy cao, và dễ dàng sử dụng rất thích hợp với mô hình client – server.

- Hazelcast: là giải pháp hỗ trợ in-memory data grids theo mô hình phân cụm dư liệu. Hazelcast phù hợp với hệ thống game server cần khả năng scale-out, khả năng chịu lỗi, phục hồi.



2.2.2. Biểu đồ UseCase

Developer

Manage Extensions

Control Lobby System

Handle Client Request

Handle Client Events

Create Plugins

Config Extension

Manage Room/Zone

Move User To Room or Zone

Handler Client Login<<extends>>

Handle Client Logout

Handle Client Disconnect

<<extends>>

<<extends>>

Handle Client Join Room

<<extend>>

Receive Message

Send Message

<<extend>>

<<extend>>

Write Logs

GamePlayĐấu Trí Extension

<<include>>

Hình 2.4: Biểu đồ usecase hệ thống

Hệ thống (game engine) cung cấp các API cho người phát triển để giao tiếp với hệ thống, từ đó người phát triển có thể thực hiện các chức năng sau:



x Quản lý các phần mở rộng (extensions): người phát triển có thể quản lý phần mở rộng thông qua file config Extension.xml. Bộ ExtensionLoader có tác dụng đọc các file config này rồi sinh ra các đối tượng tương ứng và nối chúng vào các class thực thi thông qua classloader. Từ đó người phát triển có thể tạo ra các Plugin là các đối tượng xử lý logic trong phần mở rộng và chạy nó cùng server.

x Điều khiển Lobby System: Lobby System là một hệ thống phân cấp các khu vực giành cho client khi tương tác với hệ thống. Hệ thống cho phép người phát triển quản lý các khu vực, tạo ra các khu vực mới hay di chuyển client theo giưa các khu vực này.

x Xử lý request từ client: hệ thống cung cấp các Plugin Api cho người phát triển bắt các request từ phía client và chủ động gửi các message về cho client.

x Xử lý các sự kiên từ client: login, logout, disconnect, join room, leave room.

x Ghi log hệ thống: hệ thống log chi tiết giúp bảo trì, theo dõi tình trạng hệ thống và kiểm soát lỗi tốt hơn.

2.2.3. Thiết kế database

Hệ thống hỗ trợ người phát triển cơ chế làm việc với database đáp ứng nhu cầu phát triển nhiều dịch vụ dưới dạng phần mở rộng. Hầu hết các dịch vụ này đều có nhưng đặc điểm chung như quản lý user, activity, user asset, log. Do dó thiết kế database phải có tính sử dụng lại, thiết kế tốt sẽ giúp cho người phát triển dễ dàng quản lý các phần mở rộng cắm thêm vào.

Thiết kế database được chia thành 2 phần: phần lõi và các phần mở rộng.

Phần lõi database của hệ thống được thiết kế có tính tái sử dụng cho bất kì dạng game hay ứng dụng nào. Giúp người phát triển quản lý người dùng, quản lý hệ thống admin thông qua permission, quản lý user asset, quản lý user activity, quản lý các ứng dụng, games của họ một cách thuận tiện và đồng nhất.

Phần lõi này gồm có 9 bảng chính:

STT Tên bảng Ý nghĩa

1 user lưu trư các thông tin người dùng như: username đăng nhập, password, email, facebook_id…

2 asset_type các loại tài sản của user mà người phát triển định nghĩa cho các phần mở rộng của mình

3 transaction các lượt giao dịch làm thay đổi tài sản của người chơi



4 device các thiết bị mà người dùng đăng nhập tương tác với hệ thống

5 user_device cho biết user đang sở hưu các thiết bị nào

6 permission định nghĩa các quyền truy cập toàn user trong hệ thống, khi cần quản lý quyền đăng nhập các hệ thống front-end.

7 user_permission thông tin nhưng người phần quyền, được phân quyền trong hệ thống

8 application thông tin về ứng dụng, game của người phát triển

9 device_token lưu trư thông tin token dùng trong việc push notification

Bảng 5: Thiết kế database phần lõi PIS

Hình 2.5: Mô hình phần lõi database

2.2.4. Thiết kế phần mở rộng



Thông qua kiến trúc giải pháp trên, người viết đồ án tiến hành áp dụng xây dựng phần mở rộng là game “Đấu Trí Online”.

Biểu đồ usecase game Đấu Trí Online

Với phần mở rộng này, hệ thống có thêm tác nhân là người dùng cuối, là người chơi game “Đấu Trí Online”. Biểu đồ usecase sau đây mô tả các chức năng mà game cung cấp:

User

Login

Play Game

Make Friends

Buy Items

Payment

Send Challenge

Accept Challenge

Share Result

Use Magic

Login Facebook Login DeviceAccount

Manage Profile

Receive Gift

<<extend>>

<<extend>>

<<extend>>

<<extend>>

Hình 2.6: Biểu đồ usecase game Đấu Trí Online

Người dùng tương tác với hệ thống thông qua việc sử dụng các chức năng:

x Đăng nhập: người dụng có thể lựa chọn đăng nhập qua facebook hoặc đăng nhập bằng tài khoản máy. Với cách đăng nhập này hệ thống đảm bảo sẽ khôi phục lại được tài khoản người chơi trong trường hợp cài lại app hoặc sử dụng trên thiết bị khác.

x Chơi game: đây là chức năng chính của game, để chơi game người chơi phải gửi lời mời thách đấu cùng số “ngọc” (tài sản trong game) cược và



chờ đối thủ nhận lời thách đấu. Khi chơi game người chơi có thể sử dụng bảo bối để tăng lợi thế cho mình. Kết thúc ván chơi người dùng có thể lựa chọn chia sẻ kết quả lên mạng xã hội.

x Mua vật phẩm: vật phẩm trong game chính là tài sản của người chơi gồm có bảo bối ngôi sao may mắn, bảo bối sấm sét, bảo bối rút lui, và ngọc. Người chơi có thể mua vật phẩm chính bằng ngọc hoặc thông qua các kênh thanh toán.

x Thanh toán: hệ thống cung cấp các kênh thanh toán tiện lợi như: thẻ nạp điện thoại, thanh toán trong ứng dụng.

x Kết bạn: hiện tại chức năng này đang được phát triển. x Nhận quà: người chơi được tặng quà mỗi ngày một lần, và có thể nhận

quà thông qua giftcode (mã hệ thống tặng quà). Quà tặng có thể là ngọc, hoặc một số lượng bảo bối tăng sự gắn kết người dùng với game.

x Quản lý thông tin cá nhân: người dùng có thể xem thông tin cá nhận, đồng bộ tài khoản với facebook, cập nhật trạng thái.

Thiết kế database cho phần mở rộng Đấu Trí Online

Với phần mở rộng này hệ thống cần có các bảng thể hiện yêu cầu nghiệp vụ của game là:

STT Tên bảng Ý nghĩa

1 question Các câu hỏi của hệ thống

2 challenge Thông tin các lượt thách đấu

3 challenge_question Thông tin câu hỏi được tạo ra cho lượt thách đấu đó

4 user_question Các câu hỏi mà người dùng đã trả lời được, giúp hệ thống sinh các câu hỏi mà người chơi chưa trả lời được

5 shop Cửa hàng của game, thông qua cửa hàng người dùng có thể mua một số tài sản trong game như: bảo bối, ngọc, mua lượt quay may mắn

6 award Danh sách phần thưởng cho các lượt quay may mắn, thuộc tính probably giúp người quản trị có thể dễ dạng thay đổi xác xuất vào các phần thưởng theo mong muốn

7 luckycycle Lược sử các lần quay may mắn

8 gift_code Danh sách mã quà tặng

9 gift_code_log Lược sử các lượt nhận gift code

10 gift Quà tặng hàng ngày của của người chơi khi đăng nhập hệ thống lần đầu tiên trong ngày



11 news Thông tin, tin tức của hệ thống cho toàn bộ user

12 email Hòm thư lưu trư các thông tin riêng được gửi về cho user

13 user_status Đặt các trạng thái của người chơi Bảng 6: Thiết kế database phần mở rộng Đấu Trí Online

Hình 2.7: Mô hình CSDL game Đấu Trí Online



2.2.5. Biểu đồ tuần tự chức năng

2.2.5.1. Chức năng đăng nhập

User Login Screen LoginEventHandler

LoginDeviceAccount

Processor UserModel UserDAO User

chooseQuickPlay() login(String deviceAccount)

getUserModel()

userModel

getUserByDeviceAccount(deviceAccount)

getDAO()

dao

findByDeviceAccount(deviceAccount)

user

user

return success, username

login(username, zoneName)checkUserExists(username);checkZoneExists(zoneName);

suceses

alt

else

user != null

return errorenter username popup

enter(username)register(stirng username, string deviceAccount)

RegisterDeviceAccount

Processor

getUserModel()

userModel

createUser(username, deviceAccount)

getDAO()

dao

createUser(username, deviceAccount)

user

user

return success, username

login(username, zoneName)

checkUserExists(username);checkZoneExists(zoneName);return success

Hình 2.8: Biểu đồ tuần tự chức năng đăng nhập

Để thực hiện đăng nhập, hệ thống cung cấp 2 cách thức cho người dùng lựa chọn thông qua màn hình đăng nhập: chơi ngay (đăng nhập bằng tài khoản máy) và đăng nhập qua facebook.

Khi người dùng lựa chọn đăng nhập qua facebook hệ thống sẽ tự động tạo ra username là định danh của user trong suốt quá trình tương tác với hệ thống dựa trên các thông tin lấy được từ facebook.

Nếu người dùng lựa chọn chơi ngay sẽ tuân theo các bước sau đây (theo biểu đồ trên):



B1: Chọn chức năng chơi ngay trên màn khởi động

B2: Client gửi thông tin của máy lên server kiểm tra tài khoản máy này đã được đăng ký chưa. Tài khoản máy là định danh của máy giúp phân biệt người dùng khác nhau, đối với IOS là GameCenterId, Android là Email, thiết bị khác là DeviceId.

B3,4,5: Server thực hiện gọi các đối tượng thực thi với database lấy thông tin user từ device account mà client gửi lên đó.

B6: Nếu user trả về khác null, tức là người dùng đã đăng ký trả về client username tiến hành gọi phương thức đăng nhập

B7a: Gọi đăng nhập gửi username và zoneName (tên zone để phân biệt các game trong cùng hệ thống, khi hệ thống có nhiều game)

B7b: Yêu cầu người dùng nhập username do tài khoản máy chưa được đăng ký. Hệ thống yêu cầu người dùng đăng ký 1 username cùng với tài khoản máy này, sau khi đăng ký xong thực hiện tiếp theo B8.

B8: Người dùng đăng nhập thành công client chuyển sang màn hình chính



2.2.5.2. Chức năng chọn phòng

HomeScreenUser

List UserSreen

JoinRoomProcessor

DTUserAssetHelper

UserAssetModel

UserAssetBean

chooseGageRoom()

jionRoomRequest(gage)

getDTUserAsset()

dtUserAssetcheckConditionToJoinLobbby(String username)

getRubies(username)

getUserAssetModel()

userAssetModel

UserAssetDAO

getUserAsest(username, applicationId, assetId)getDAO()

find(..)

findUserAsset(username, applicaitonId, assetId)

userAsset

userAsset

rubiesalt

else

rubies >= 20true

false

success

navigate()

showListUsers()

fail

showErrorPopup()

PaApi

addUserToRoom(user)

Hình 2.9: Biểu đồ tuần tự chức năng chọn phòng

Trên giao diện chọn phòng, người chơi có thể lựa chọn “Thách đấu” hoặc “Đấu Trường”, đây là 2 phòng khác nhau vì thế khi 2 người chơi mỗi người ở 1 phòng sẽ không nhìn thấy nhau. Khi tham gia Thách đấu người chơi sẽ phải lựa chọn đối thủ thách đấu gửi lời mời, sau đó chờ chấp nhận lời mời. Khi đối thủ đồng ý mới có thể bắt đầu chơi. Với cơ chế Đấu Trường hệ thống sẽ ngẫu nhiên ghép 2 người chơi để có thể bắt đầu ván đấu nhanh.

Quá trình vào phòng diễn ra như sau:

B1: người sử dụng chọn phòng, trong trường hợp này người dùng lựa chọn “Thách Đấu”

B2: client gửi request lên server yêu cầu join room.

B3: server kiểm tra điều kiện vào phòng, nếu số ngọc của user lớn hơn 20 thì được phép vào phòng.



B4a: Nếu user đủ điều kiện để vào phòng, server gọi api thêm user vào phòng đó

B4b: Nếu user không đủ điều kiện vào phòng, server gửi thông tin về cho client, yêu cầu show popup thông báo “không đủ điều kiện để vào phòng”.

B5: Chuyển màn hình chọn phòng sang màn hình hiện thị danh sách user thách đấu sau khi đã join phòng thành công.

2.2.5.3. Chức năng gửi lời mời thách đấu

List User Sreen

SendBettingProcessorUser1

GetRequireForBettingProcessor

ChallengeDAO

ChallengeBean

chooseUser()

showChallengePopup()

sendBettingToUser(username, betting)

clickSendButton()

getRequireBetting(username1, username2)

ChallengeModel

minRuby

checkBettingVavlid(user1, user2, betting)

getChallengeModel()

challenge

createChallange(user1, user2, betting)

insertChallenge(challenge)

dao

challenge

getDAO()

insert(challenge)

success

success

sendSuccess

PlayScreen User2

sendMessageToUser(user2)

hidePopup()

Hình 2.10: Biểu đồ tuần tự chức năng gửi lời mời thách đấu

Quá trình thách đấu diễn ra như sau:

B1: người chơi lựa chọn đối thủ thách đấu trong danh sách người chơi.

B2: client gửi yêu cầu lấy thông tin về số ngọc tối đa được phép cược giưa 2 người chơi. Số ngọc cược đối đa là số ngọc nhỏ nhất của 2 người chơi hiện tại

B3: Server trả về số ngọc, client hiện thị popup cho phép người chơi điều chỉnh số ngọc cược.

B4: Người chơi chọn “Gửi thách đấu”

B5: client gửi thông tin thách đấu lên server



B6: Server kiểm tra thông tin hợp lệ một lần nưa trước khi báo cho đối thủ biết bạn nhận được 1 lời mời thách đấu.

2.2.5.4. Chức năng chấp nhận lời mời thách đấu

ChallengeModelUser

List User Screen

PlayGameSreen

AcceptBettingProcessor

DTUserAssetHelper

DTChallengeQuestionModel

clickAccpetButton()

acceptBettingFromUser(username2, challengeId)

QuestionModel

UserModel

getChallenge(challngeId)

challenge

createQuestionForUsers(user1, user2)

question

getChallengeModel()

getQuestionModel()

questionModel

getUserById(challenge.getCreatorId())

user

sendMessagePrepareToStart()

showPopup()

sendMessageStartGame(info)

navigate

getUserAsset(user1)

userAsset1

getUserAsset(user2)

userAsset2

guessWord(letter)sendMessageTimeOut()

showPopupResult()

navigate

updateRubies(user1)

updateRubies(user2)

insert(challengeId, questionId)

Hình 2.11: Biểu đồ tuần tự chức năng chấp nhận lời mời

Các bước chấp nhận lời mời thách đâu diễn ra như sau:

B1: Người dùng click button chấpn nhận thách đấu từ danh sách lời mời giao diện của ứng dụng.

B2: Client gửi thông tin thách đấu (challenge id) mà người dùng đã đồng ý

B3: Server thực hiện các bước kiểm tra thông tin thách đấu với database thông qua challenge id mà client gửi lên

B4: Server sinh câu hỏi cho 2 người chơi, câu hỏi phải đảm bảo là 2 người chưa trả lời được.



B5: Server lưu lại thông tin challenge cùng với question

B6: Server thực hiện trừ tiền 2 người chơi, số tiền mà 2 người chơi phải bỏ vào trước khi bắt đầu ván đấu chính là số tiền thách đấu.

B7: Server gửi thông tin báo hiệu trận đấu sắp bắt đấu

B8: Client hiển thị popup đếm ngược 5s trận đấu chuẩn bị bắt đầu.

B9: Sau 5s server trả về thông tin báo hiệu bắt đấu trận đấu, client chuyển màn hình danh sách người chơi sang màn hình chơi game.

B10: Khi trận đấu bắt đầu, người chơi có 60s để trả lời câu hỏi, trong thời gian này người chơi đoán chư bằng việc ấn nút chư cái để tạo đáp án, hoặc sử dụng bảo bối để tăng lợi thế cho mình.

B11: Trận đấu sẽ kết thúc nếu hết thời gian mà không có ai trả lời đúng, server báo về kết thúc thời gian, client hiển thị popup thông báo kết quả rồi chuyển màn hình trở lại màn hình danh sách người chơi.

B12: Người chơi lại tiếp tục thực hiện thách đấu hoặc chờ đợi lượt thách đấu mới.



2.2.5.5. Chức năng chơi game

UserPlayGame

ScreenCheckAnswer

ProcessorQuestion

ModelQuestion

BeanQuestion

DAODTUserAsset

Helper

loop

guessWord(letter)

checkAnswer(answer)

getQuestionModel

getQuestionById(questionId)getDAO()

dao

findById(quetstionId)

quesion

useMagic()

endGame()

alt

true

timeOut()

popup()

getDTUserAssetHeler()

helper

updateRubies

popup()

checkAnswer(question, anwser)

Hình 2.12: Biểu đồ tuần tự chức năng chơi game

Các bước thực hiện chơi game diễn ra như sau:

B1: Trận đấu bất đầu, người dùng muốn giành chiến thắng phải trả lời được câu hỏi, câu trả lại được ghép từ các ô chư gợi ý tạo thành đáp án. Trong suốt quá trình chơi, người chơi liên tục mở các ô chư hoặc sử dụng bảo bối để tìm ra câu trả lời. Khi người chơi tạo được đáp án, client sẽ gửi đáp án này lên server, yêu cầu kiểm tra đáp án.

B2,3,4: Server thực hiện các bước kiểm tra đáp án thông qua các thao tác với database, dư liệu đầu vào của bước kiểm tra là đáp án client gửi lên và questionId mà server đã lưu trước đó liên kết với phòng mà 2 người đang chơi.



B5a: Nếu câu trả lời đúng server sẽ gửi thông tin về cho client đáp án đúng, thông báo người chiến thắng và số ngọc giành được rồi kết thúc ván chơi

B5b: Nếu câu trả lời sai, server trả về thông tin câu trả lời sai, yêu cầu client popup thông báo cho user. Sau đó người dùng tiếp tục trả lời trong thời gian của câu hỏi.

B6. Nếu kết thúc thời gian 60s cho mỗi ván chơi mà không có ai trả lời đúng, server trả về báo hiệu trận đấu kết thúc, không có ai giành chiến thắng 2 người giành lại 80% ngọc.

B7: Người dùng trở về màn hình hiển thị danh sách user, tiếp tục gửi lời mời hoặc chấp nhận thách đấu cho ván tiếp theo.

Kết chương

¾ Trong chương này người viết đồ án đã đưa ra các phân tích thiết kế hệ thống thông qua các kí pháp UML 2.0. Các khâu phân tích thiết kế bao gồm: kiến trúc hệ thống, biểu đồ usecase, thiết kế database, biểu đồ tuần tự

¾ Trong chương tiếp theo người viết đồ án xin trình bày về 3 giải pháp trọng tâm giải quyết bài toán.



Chương 3: CÁC GIẢI PHÁP TRỌNG TÂM

Nội dung chương trình trình bày các vấn đề sau: 9 Cơ sở lý thuyết và cài đặt NIO Network 9 Nghiên cứu hệ thống phân cụm dư liệu và áp dụng giải pháp Hazelcast 9 Nghiên cứu và xây dựng có chế Extension - Plugin

3.1. Cơ chế NIO Network

3.1.1. Giao thức truyền tin TCP/IP và UDP

3.1.1.1. Giao thức TCP/IP

TCP (giao thức điều khiển truyền vận) nằm ở tầng Transport trong mô hình OSI là một trong nhưng giao thức cốt lõi của bộ giao thức TCP/IP, nhằm kết nối các máy tính trong mạng với nhau, nhằm chia sẻ vào trao đổi dư liệu.

Một tiến trình ứng dụng trong một máy tính truy nhập vào các dịch vụ của giao thức TCP thông qua một cổng (port) của TCP. Số hiệu cổng TCP được thể hiện bởi 2 bytes.

Hình 3.1: Cổng truy nhập dịch vụ TCP

Một cổng TCP kết hợp với địa chỉ IP tạo thành một đầu nối TCP/IP (socket) duy nhất trong liên mạng. Dịch vụ TCP được cung cấp nhờ một liên kết logic giưa một cặp đầu nối TCP/IP. Một đầu nối TCP/IP có thể tham gia nhiều liên kết với các đầu nối TCP/IP ở xa khác nhau. Trước khi truyền dư liệu giưa 2 trạm cần phải thiết lập một liên kết TCP giưa chúng và khi không còn nhu cầu truyền dư liệu thì liên kết đó sẽ được giải phóng.



Các thực thể của tầng trên sử dụng giao thức TCP thông qua các hàm gọi (function calls) trong đó có các hàm yêu cầu để yêu cầu, để trả lời. Trong mỗi hàm còn có các tham số dành cho việc trao đổi dư liệu.

Các bước thực hiện để thiết lập một liên kết TCP/IP. Thiết lập một liên kết mới có thể được mở theo một trong 2 phương thức: chủ động (active) hoặc bị động (passive).

Phương thức bị động: người sử dụng yêu cầu TCP chờ đợi một yêu cầu liên kết gửi đến từ xa thông qua một đầu nối TCP/IP (tại chỗ). Người sử dụng dùng hàm passive Open có khai báo cổng TCP và các thông số khác (mức ưu tiên, mức an toàn).

Phương thức chủ động: người sử dụng yêu cầu TCP mở một liên kết với một đầu nối TCP/IP ở xa. Liên kết sẽ được xác lập nếu có một hàm Passive Open tương ứng đã được thực hiện tại đầu nối TCP/IP ở xa đó.

Khi người sử dụng gửi đi một yêu cầu mở liên kết sẽ được nhận hai thông số trả lời từ TCP. Thông số Open ID được TCP trả lời ngay lập tức để gán cho một liên kết cục bộ (local connection name) cho liên kết được yêu cầu. Thông số này về sau được dùng để tham chiếu tới liên kết đó. (Trong trường hợp nếu TCP không thể thiết lập được liên kết yêu cầu thì nó phải gửi tham số Open Failure để thông báo). Khi TCP thiết lập được liên kết yêu cầu nó gửi tham số Open Success được dùng để thông báo liên kết đã được thiết lập thành công. Thông báo này được chuyển đến trong cả hai trường hợp bị động và chủ động. Sau khi một liên kết được mở, việc truyền dư liệu trên liên kết đó có thể được thực hiện.

Các bước thực hiện khi truyền và nhận dư liệu: Sau khi xác lập được liên kết người sử dụng gửi và nhận dư liệu. Việc gửi và nhận dư liệu thông qua các hàm send và receive.

Hàm Send: Dư liệu được gửi xuống TCP theo các khối (block). Khi nhận được một khối dư liệu, TCP sẽ lưu trư trong bộ đệm (buffer). Nếu cờ PUSH được dựng thì toàn bộ dư liệu trong bộ đệm được gửi, kể cả khối dư liệu mới đến sẽ được gửi đi. Ngược lại cờ PUSH không được dựng thì dư liệu được dư lại trong bộ đệm và sẽ gửi đi khi có cơ hội thích hợp (chẳng hạn chờ thêm dư liệu nưa để gửi đi với hiệu quả hơn)

Hàm Receive: ở trạm đích dư liệu sẽ được TCP lưu trong bộ đệm gắn với mỗi liên kết. Nếu dư liệu được đánh dấu với một cờ PUSH thì toàn bộ dư liệu trong bộ đệm (kể cả các dư liệu được lưu từ trước) sẽ được chuyển lên cho người sử dụng. Còn nếu dư liệu đến không được đánh dấu với cờ PUSH thì TCP chờ tới khi thích hợp mới chuyển dư liệu với mục đích tăng hiệu quả hệ thống.

Nói chung việc nhận và giao dư liệu cho người sử dụng đích của TCP phụ thuộc vào việc cài đặt cụ thể. Trường hợp cần chuyển gấp dư liệu cho người sử dụng



đích của TCP phụ thuộc vào việc cài đặt cụ thể. Trường hợp cần chuyển gấp dư liệu cho người sử dụng thì có thể dùng cờ URGENT và đánh dấu dư liệu bằng bit URG để báo cho người sử dụng cần phải xử lý khẩn cấp dư liệu đó.

Các bước thực hiện khi đóng một liên kết: Việc đóng một liên kết khi không cần thiết được thực hiện theo một trong hai cách: dùng hàm Close hoặc dùng hàm Abort.

Hàm Close: yêu cầu đóng liên kết một cách bình thường. Có nghĩa là việc truyền dư liệu trên liên kết đó đã hoàn tất. Khi nhận được một hàm Close TCP sẽ truyền đi tất cả dư liệu còn trong bộ đệm thông báo rằng nó đóng liên kết. Lưu ý rằng khi một người sử dụng đã gửi đi một hàm Close thì nó vẫn phải tiếp tục nhận dư liệu đến trên liên kết đó cho đến khi TCP đã báo cho phía bên kia biết về việc đóng liên kết và chuyển giao hết tất cả dư liệu cho người sử dụng của mình.

Hàm Abort: Người sử dụng có thể đóng một liên kết bất thường và sẽ không chấp nhận dư liệu qua liên kết đó nưa. Do vậy dư liệu có thể bị mất đi khi đang được truyền đi. TCP báo cho TCP ở xa biết rằng liên kết đã được hủy bỏ và TCP ở xa sẽ thông báo cho người sử dụng của mình.

Một số hàm khác của TCP

Hàm Status: cho phép người sử dụng yêu cầu cho biết trạng thái của một liên kết cụ thể, khi đó TCP cung cấp thông tin cho người sử dụng. Hàm Error: thông báo cho người sử dụng TCP về các yêu cầu dịch vụ bất hợp lệ liên quan đến một liên kết có tên cho trước hoặc về các lỗi liên quan đến môi trường. Đơn vị dư liệu sử dụng trong TCP được gọi là segment (đoạn dư liệu), có các tham số với ý nghĩa như sau:

Hình 3.2: Dạng thức Segment của TCP

Source Port (16 bits): số hiệu cổng TCP của trạm nguồn Destination Port (16 bit): số hiệu cổng TCP của trạm đích



Sequence Number (32 bit): số hiệu của byte đầu tiên của segment trừ khi SYN được được thiết lập. Nếu bit SYN được thiết lập thì Sequence Number là số hiệu tuần tự khởi đầu (ISN) và byte dư liệu đầu tiên là ISN + 1. Acknowledgment Number (32 bit): số hiệu của segment tiếp theo mà trạm nguồn đang chờ để nhận. Ngầm ý báo nhận tốt (các) segment mà trạm đích đã gửi cho trạm nguồn. Data offset (4 bit): số lượng bội của 32 bit (32 bit words) trong TCP header (tham số này chỉ ra vị trí bắt đầu của nguồn dư liệu). Reserved (6 bit): dành để dùng trong tương lai. Control bit (các bit điều khiển): URG: Vùng con trỏ khẩn (Ucgent Poiter) có hiệu lực. ACK: Vùng báo nhận (ACK number) có hiệu lực. PSH: chức năng PUSH

RST: Khởi động lại (reset) liên kết. SYN: Đồng bộ hóa số hiệu tuần tự (sequence number). FIN: Không còn dư liệu từ trạm nguồn

Window (16 bit): cấp phát credit để kiểm soát nguồn dư liệu (cơ chế cửa sổ). Đây chính là số lượng các byte dư liệu, bắt đầu từ byte được chỉ ra trong vùng ACK number, mà trạm nguồn đã sẵn sàng để nhận. Checksum (16 bit): mã kiểm soát lỗi cho toàn bộ segment (header + data) Urgemt Poiter (16 bit): con trỏ này trỏ tới số hiệu tuần tự của byte đi theo sau dư liệu khẩn. Vùng này chỉ có hiệu lực khi bit URG được thiết lập. Options (độ dài thay đổi): khai báo các option của TCP, trong đó có độ dài tối đa của vùng TCP data trong một segment. Padding (độ dài thay đổi): phần chèn thêm vào header để đảm bảo phần header luôn kết thúc ở một mốc 32 bit. Phần thêm này gồm toàn số 0. TCP data (độ dài thay đổi): chứa dư liệu của tầng trên, có độ dài tối đa ngầm định là 536 byte. Giá trị này có thể điều chỉnh bằng cách khai báo trong vùng options.

3.1.1.2. Giao thức UDP

UDP (User Datagram Protocol) là giao thức theo phương thức không liên kết được sử dụng thay thế cho TCP ở trên IP theo yêu cầu của từng ứng dụng. Khác với TCP, UDP không có các chức năng thiết lập và kết thúc liên kết. Tương tự như IP, nó cũng không cung cấp cơ chế báo nhận (ackowledgment), không sắp xếp tuần tự các gói tin (datagram) đến và có thể dẫn đến tình trạng mất hoặc trùng dư liệu mà không có cơ chế thông báo lỗi cho người gửi. Qua đó ta thấy UDP cung cấp các dịch vụ vận chuyển không tin cậy như trong TCP. Khuôn dạng UDP datagram được mô tả với các vùng tham số đơn giản hơn nhiều so với TCP segment.



Hình 3.3: Dạng thức gói tin UDP

UDP cũng cung cấp cơ chế gán và quản lý các số hiệu cổng (port number) để định danh duy nhất cho các ứng dụng chạy trên một trạm của mạng. Do ít chức năng phức tạp nên UDP thường có xu thế hoạt động nhanh hơn so với TCP. Nó thường được dùng cho các ứng dụng không đòi hỏi độ tin cậy cao trong giao vận.



Hình 3.4: Mô hình quan hệ họ giao thức TCP/IP

3.1.2. Cơ chế NIO Network

Trong tính toán, IO (Input/Output) là hoạt động giao tiếp giưa các hệ thống xử lý thông tin (như máy tính). Trong hệ điều hành các hành động như đóng mở kết nối mạng, truy xuất file, cấp phát tiến trình, truy xuất bộ nhớ, truy xuất các thiết bị ngoại vi… đều được coi là các hoạt động vào ra. Các hoạt động IO thường tiêu tốn tài



nguyên và thời gian xử lý của hệ thống. Tài nguyên của hệ thống là hưu hạn, thời gian xử lý 1 công việc IO là xác định, do đó muốn tăng hiệu năng xử lý của hệ thống, ta cần phải có cơ chế xử lý song song. Với cơ chế này hệ thống phải giải quyết bài toán đồng bộ các công việc IO khi chúng cùng chia sẻ tài nguyên và đảm bảo các công việc này không tác động sai lệnh đến nhau.

Việc đồng bộ các công việc IO phải đáp ứng yêu cầu:

x Yêu cầu độc quyền truy xuất (Mutal exclusion): tại một thời điểm, chỉ có một tiến trình được quyền truy xuất một tài nguyên không thể chia sẻ

x Yêu cầu phối hợp (Synchronization): các tiến trình cần hợp tác với nhau để hoàn thành công việc.

Non-blocking IO là một tư tưởng tối ưu hóa việc xử lý IO thông qua:

x Hạn chế các xử lý IO đồng thời chiếm quyền sử dụng tài nguyên chia sẻ giưa các hoạt động này

x Hạn chế cấp phát trên tài nguyên hưu hạn x Chia nhỏ các công việc thành nhiều công đoạn

Ví dụ, để giải quyết bài toán xử lý song song, ta sử dụng multi-threading đáp ứng yêu cầu xử lý số lượng lớn các công việc và tăng tốc độ xử lý các công việc IO, do đó hệ thống cần tạo ra nhiều threads thực hiện các yêu cầu trên một cách đồng thời. Bản chất của hành động tạo ra các threads là xin cấp phát tài nguyên hệ thống (không gian địa chỉ tiến trình cha, con trỏ lệnh, tập các thanh ghi và stack) và thực thi đồng thời bằng cách chia sẻ CPU. NIO được áp dụng bằng việc tạo ra thread pool chứa một số lượng thread xác định. Nhờ đó hệ thống được tối ưu, sử dụng lại các threads đã được khởi tạo thay vì khởi tạo mới tiêu tốn tài nguyên hệ thống và thời gian tạo ra chúng.

Khác với Blocking, khi hệ thống cần xử lý n công việc song song, hệ thống tạo ra n tiến trình tương ứng để xử lý. Khi số công việc tăng lên, tài nguyên hệ thống không đủ để đáp ứng, hệ trống trở nên trì trệ khi phải tạo ra các thread mới. Một hệ thống blocking hoàn toàn không có khả năng mở rộng.

Để hạn chế các xử IO đồng thời tác động lên tài nguyên chung, ta áp dụng NIO thông qua việc lưu trư các công việc trong một hàng đợi, sau đó các công việc này được một thread chuyên xử lý IO.

Trong các hệ thống lớn, có rất nhiều yêu cầu từ client, mỗi yêu cầu phải thực hiện nghiệp vụ phức tạp tốn nhiều chi phí về thời gian, điều đó đòi hỏi hệ thống cần phải áp dụng cơ chế chia nhỏ công việc thành nhiều công đoạn để xử lý. Hiệu năng hệ thống được tối ưu khi các công việc được chia nhỏ, mỗi công đoạn lại có một thread pool xử lý, các thread pool này xử lý các công việc trong một hàng đợi.



Như vậy tư tưởng NIO được áp dụng linh hoạt, kết hợp giưa các việc hạn chế quyền truy cập, hạn chế cấp phát tài nguyên và chia nhỏ công việc xuyên suốt mọi nơi trong hệ thống.

Trong hệ thống PIS, NIO được áp dụng thể hiện trong việc chia nhỏ các công việc thành nhiều công đoạn, mỗi công đoạn lại có 1 thread pool để xử lý.

Decode Message Processor

databaseEncode Message

IO Buffer

read

write

client

Workers

request

response

Hình 3.5: Các công đoạn xử lý request của hệ thống

Tầng Connection là cổng vào của hệ thống, có vai trò vô cùng quan trọng trong việc mở rộng hệ thống, tại đây các công việc đóng mở kết nối (IO connection) diễn ra thường xuyên, do đó yêu cầu tầng connection phải có có cơ chế NIO để tăng khả năng chịu tải của hệ thống.

Java hỗ trợ rất tốt việc người lập trình tạo ra các ứng dụng NIO network thông qua các gói nằm trong package java.nio.

Gói Hỗ trợ

java.nio Gói này chứa các lớp buffer cung cấp các kỹ thuật để lưu trư dư liệu ở dạng nguyên thủy trong bộ nhớ trong

java.nio.channels Định nghĩa các kênh thay cho các liên kết tới các thực thể có khả năng thực hiện các thao tác truy xuất. Các thực thể có thể là các tập tin, socket hay các selector

java.nio.channels.spi Chứa các lớp cung cấp các dịch vụ cho gói java.nio.channels java.nio.channels Chứa các charset, mã hóa, giải mã dư liệu, các lớp chuyển

đối dư liệu.



SERVER

Client

Client

Client

SELECTOR

Socket Channel

Socket Channel

Socket Channel

Key Key Key Key Key

Key

message

messagemessage

Message Queue

Thread Poolpick

Request Handler Threads

Hình 3.6: Mô hình NIO Network

Để cài đặt NIO Networking trong Java, ta khởi tạo 1 Selector (java.nio.chanel.Selector) và một ServerSocketChannel đăng ký mở một kết nối trên một cổng xác định. Selector chờ đợi các kết nối trong một vòng lặp vô hạn. Với mỗi client kết nối đến Selector tạo ra 1 key (SelectorKey) cho client, mỗi key đại diện cho cặp ip, port xác định client Trong vòng lặp vô hạn, Selector tìm kiếm trong các selectorKeys, nếu key có trạng thái chấp nhận kết nối thì 1 SocketChannel sẽ được tạo ra nhằm tạo ra một kênh liên lạc client – server độc lập với các client khác. Lớp SocketChannel cung cấp các phương thức đọc, ghi giúp server có thể dễ dàng gửi nhận message với client. Để đảm bảo các message đến từ client đều được xử lý và không bị thất lạc, ta sử dụng 1 hàng đợi lưu trư các message gửi đến, hàng đợi này lại được thread pool điều khiển các thread đến xử lý message. Một công việc từ client yêu cầu được chia nhỏ thành nhiều công đoạn như đã nói trên đảm bảo các thread thực hiện các công việc nhỏ nhất, các message được xử lý nhanh, đảm bảo số lượng message chờ trong queue là nhỏ nhất. Với cơ chế này ta tạo ra được ứng dụng network có khả năng đáp ứng được số lượng kết nối đồng thời lớn dựa trên tài nguyên server cấp phát cho ứng dụng.

Với sự phát triển của cộng đồng mã nguồn mở Java, có rất nhiều framework cài đặt tư tưởng NIO Network để hỗ trợ người phát triển nhanh chóng tạo ra các ứng dụng mạng có hiệu năng cao, dễ dàng mở rộng như Apache Mina, Netty, Grizzly… Các dự án này đều được chứng minh qua một số giải pháp game server cho thấy áp dụng các dự án này vào hệ thống là hoàn toàn đúng đắn.

Người viết đồ án lựa chọn Apache Mina áp dụng vào hệ thống của mình.



Hình 3.7: Kiến trúc Apache Mina

Kiến trúc của Mina đóng gói tầng kết nối, cung cấp các interface giúp người phát triển dễ dàng tạo ra NIO network application.

- IOAcceptor: hỗ trợ các phương thức khởi tạo mở cổng TCP, UDP, cài đặt các handler, filter chain cho server

- IOHandler: nơi xử lý các sự kiện kết nối của client như khởi tạo session, mở session, đóng session, session idle, gửi message, nhận message.

- IOSession: cung cấp các phương thức giúp server truyền gửi message cho client dễ dàng thông qua session id mà không phải quan tâm tới ip, port của client

- IOFilter: cho phép người phát triển tạo ra các bộ lọc message, mỗi bộ lọc đi cùng với 2 class xử lý encode, decode message. Giúp người phát triển tùy ý tạo ra tạo ra các bộ encode, decode message khác nhau.

3.2. Hệ thống phân cụm Clustering

Hệ thống PIS là hệ thống phát triển theo hướng đa phương tiện và wide scale dưới các phần mở rộng của người phát triển. Các dịch vụ được triển khai dưới dạng tương tác trực tuyến luôn thu hút số lượng người sử dụng khổng lồ. Điều đó dẫn đến dư liệu người dùng được sinh ra liên tục, lượng công việc phải truy vấn CSDL rất lớn và đồng thời mà với thiết kế CSDL quan hệ tập trung thông thường không thể đáp ứng được các yêu cầu về mở rộng, chịu tải, chịu lỗi.

Để giải quyết các vấn đề trên người viết đồ án cần có mô hình phân cụm dư liệu và xây dựng một tầng cache hoạt động trung gian giưa tầng server core và



database. Người viết đồ án lựa chọn Hazelcast hỗ trợ xây dựng hệ thống phân cụm tính toán, phân tán dư liệu cache để cài đặt vào hệ thống của mình.

3.2.1. Khái niệm hệ thống phân cụm

Tổng quan về công nghệ Clustering

Clustering là một kiến trúc nhằm đảm bảo nâng cao khả năng sẵn sàng cho các hệ thống mạng máy tính. Clustering cho phép sử dụng nhiều máy chủ kết hợp với nhau tạo thành một cụm (cluster) có khả năng chịu đựng hay chấp nhận sai sót (fault-tolerant) nhằm nâng cao độ sẵn sàng của hệ thống mạng. Cluster là một hệ thống bao gồm nhiều máy chủ được kết nối với nhau theo dạng song song hay phân tán và được sử dụng như một tài nguyên thống nhất. Nếu một máy chủ ngừng hoạt động do bị sự cố hoặc để nâng cấp, bảo trì, thì toàn bộ công việc mà máy chủ này đảm nhận sẽ được tự động chuyển sang cho một máy chủ khác (trong cùng một cluster) mà không làm cho hoạt động của hệ thống bị ngắt hay gián đoạn. Quá trình này gọi là “fail-over” và việc phục hồi tài nguyên của một máy chủ trong hệ thống (cluster) được gọi là “fail-back”.

Việc thiết kế và lắp đặt các cluster cần thoả mãn các yêu cầu sau:

x Yêu cầu về tính sẵn sàng cao (availability): các tài nguyên mạng phải luôn sẵn sàng trong khả năng cao nhất để cung cấp và phục vụ các người dùng cuối và giảm thiểu sự ngưng hoạt động hệ thống ngoài ý muốn.

x Yêu cầu về độ tin cậy cao (reliability): là khả năng giảm thiểu tần số xảy ra các sự cố, và nâng cao khả năng chịu đựng sai sót của hệ thống.

x Yêu cầu về khả năng mở rộng được (scalability): hệ thống phải có khả năng dễ dàng cho việc nâng cấp, mở rộng trong tương lai. Việc nâng cấp mở rộng bao hàm cả việc thêm các thiết bị, máy tính vào hệ thống để nâng cao chất lượng dịch vụ, cũng như việc thêm số lượng người dùng, thêm ứng dụng, dịch vụ và thêm các tài nguyên mạng khác.

Cấu trúc của Cluster

Cluster được tổ chức thành các nhóm gọi là các farm hay pack. Trong hầu hết các trường hợp, các dịch vụ ở tầng trước và giưa (front-end and middle-tiers services) được tổ chức thành các farm sử dụng các clone, trong khi đó các dịch vụ tầng sau (back-end services) được tổ chức thành các pack.

Cluster Farm là một nhóm các máy chủ chạy các dịch vụ giống nhau, nhưng không dùng chung cơ sở dư liệu. Được gọi là farm (trang trại) bởi vì chúng xử lý bất cứ yêu cầu nào gửi đến cho chúng bằng các bản sao cơ sở dư liệu (tài nguyên) giống hệt nhau được lưu giư cục bộ, chứ không dùng chung một bản cơ sở dư liệu. Cũng bởi tính chất này nên các máy chủ thành viên của farm làm việc độc lập và chúng



được gọi là clone (clone là máy tính được thiết kế để mô phỏng chức năng của máy tính khác).

Cluster Pack là một nhóm các máy chủ hoạt động cùng với nhau và chia sẻ với nhau các phần của cơ sở dư liệu. Được gọi là pack (khối) vì sự hoạt động của các máy chủ thành viên của pack có liên hệ chặt chẽ với nhau và chúng làm việc theo một phương thức thống nhất để quản lý và duy trì các dịch vụ.

Chế độ hoạt động của Cluster

Mỗi máy chủ trong cluster được gọi là một nút (cluster node), và có thể được thiết lập ở chế độ chủ động (active) hay thụ động (passive). Khi một nút ở chế dộ chủ động, nó sẽ chủ động xử lý các yêu cầu. Khi một nút là thụ động, nó sẽ nằm ở chế độ dự phòng nóng (stanby) chờ để sẵn sàng thay thế cho một nút khác nếu bị hỏng.

Trong một cluster có nhiều nút có thể kết hợp cả nút chủ động và nút thụ động. Trong nhưng mô hình loại này việc quyết định một nút được cấu hình là chủ động hay thụ động rất quan trọng.

x Nếu một nút chủ động bị sự cố và có một nút thụ động đang sẵn sàng, các ứng dụng và dịch vụ đang chạy trên nút hỏng có thể lập tức được chuyển sang nút thụ động. Vì máy chủ đóng vai trò nút thụ động hiện tại chưa chạy ứng dụng hay dịch vụ gì cả nên nó có thể gánh toàn bộ công việc của máy chủ hỏng mà không ảnh hưởng gì đến các ứng dụng và dịch vụ cung cấp cho người dùng cuối (Ngầm định rằng các các máy chủ trong cluster có cấu trúc phần cứng giống nhau).

x Nếu tất cả các máy chủ trong cluster là chủ động và có một nút bị sự cố, các ứng dụng và dịch vụ đang chạy trên máy chủ hỏng sẽ phải chuyển sang một máy chủ khác cũng đóng vai trò nút chủ động. Vì là nút chủ động nên bình thường máy chủ này cũng phải đảm nhận một số ứng dụng hay dịch vụ gì đó, khi có sự cố xảy ra thì nó sẽ phải gánh thêm công việc của máy chủ hỏng. Do vậy để đảm bảo hệ thống hoạt động bình thường kể cả khi có sự cố thì máy chủ trong cluster cần phải có cấu hình dư ra đủ để có thể gánh thêm khối lượng công việc của máy chủ khác khi cần.

Trong cấu trúc cluster mà mỗi nút chủ động được dự phòng bởi một nút thụ động, các máy chủ cần có cấu hình sao cho với khối lượng công việc trung bình chúng sử dụng hết khoảng 50% CPU và dung lượng bộ nhớ.

Trong cấu trúc cluster mà số nút chủ động nhiều hơn số nút bị động, các máy chủ cần có cấu hình tài nguyên CPU và bộ nhớ mạnh hơn nưa để có thể xử lý được khối lượng công việc cần thiết khi một nút nào đó bị hỏng.



Các nút trong một cluster thường là một bộ phận của cùng một vùng (domain) và có thể được cấu hình là máy điều khiển vùng (domain controllers) hay máy chủ thành viên. Lý tưởng nhất là mỗi cluster nhiều nút có ít nhất hai nút làm máy điều khiển vùng và đảm nhiệm việc failover đối với nhưng dịch vụ vùng thiết yếu. Nếu không như vậy thì khả năng sẵn sàng của các tài nguyên trên cluster sẽ bị phụ thuộc vào khả năng sẵn sàng của các máy điều khiển trong domain.

Cluster nhiều địa điểm phân tán

Với các hệ thống mạng lớn có các người dùng phân bố rải rác, hiệu quả của việc phòng chống sự cố và nâng cao tính sẵn sàng của mạng sẽ được cải thiện hơn nhiều nếu xây dựng hệ thống cluster bố trí tại nhiều địa điểm. Kiến trúc nhiều địa điểm có thể được thiết kế theo rất nhiều cách khác nhau, trong đó phổ biến nhất là có một điểm gốc và một số điểm ở xa.

Với kiểu thiết kế đầy đủ, toàn bộ cấu trúc của điểm gốc được xây dựng lại đầy đủ ở các điểm ở xa. Điều này cho phép các điểm ở xa hoạt động độc lập và có thể xử lý toàn bộ khối lượng công việc của điểm gốc nếu cần. Trong trường hợp này, việc thiết kế phải đảm bảo sao cho cơ sở dư liệu và các ứng dụng giưa điểm gốc và các điểm ở xa phải đồng bộ và được cập nhật sao lặp ở chế độ thời gian thực.

Với kiểu thiết kế thực hiện từng phần thì chỉ có các thành phần cơ bản là được cài đặt ở các điểm ở xa nhằm xử lý các khối lượng công việc quá tải trong các giờ cao điểm, duy trì hoạt động ở mức cơ bản trong trường hợp điểm gốc site bị sự cố, cung cấp một số dịch vụ hạn chế nếu cần.

Cả kiểu thiết kế đầy đủ hay từng phần đều dùng phương cách phân tán các máy chủ rải rác về mặt địa lý. Cluster phân tán về địa lý sử dụng mạng LAN ảo (Virtual LAN) để kết nối các mạng khu vực lưu trư SAN (storage area network) qua nhưng khoảng cách lớn. Để có thể duy trì hoạt động cluster một cách hiệu quả, yêu cầu đối với kết nối trong mạng LAN ảo phải có độ trễ khoảng dưới 500 ms.

3.2.2. Giới thiệu Hazelcast và ứng dụng

Hazelcast là một giải pháp mã nguồn mở, hỗ trợ in-memory data grids. In-memory data grids thường được sử dụng với database để nâng cao hiệu năng của ứng dụng, phân tán dư liệu trên nhiều server với tốc độ tính toán ưu việt và khả năng quản lý khối lượng lớn dư liệu.

Hazelcast được thiết kế theo mô hình phân cụm, trong đó các server chia sẻ dư liệu với nhau theo cấu trúc Cluster Pack. Hazelcast cho phép:

x Scale-out computing: khả năng tính toán mở rộng trên nhiều server mạnh mẽ.

x Resilience (khả năng phục hồi): các node có thể bị lỗi mà không mất đi dư liệu, tối thiểu hóa các yếu tố làm ảnh hưởng tới hiệu năng của ứng



dụng (trên mỗi node lưu trư 1/n real data + 1/n backup data với n là số node).

x Programming Model: tạo ra một mô hình lập trình cho người phát triển dễ dàng tạo ra các cụm máy tính mà vẫn đảm bảo tính thống nhất như một hệ thống máy tính đơn lẻ.

x Fast Application Performance: đẩy nhanh hiệu năng của ứng dụng bằng việc lưu trư dư liệu in-memories, đảm bảo tốc độ đọc ghi nhanh chóng.

x Dynamic Scalability (khả năng mở rộng động): các máy tính có thể kết hợp động với nhau, tự động mở rộng thêm node khi hệ thống scale.

x Elastic Main Memory: Bộ nhớ chính cấp phát sử dụng lưu trư cache có khả năng co giãn, phù hợp với nhu cầu sử dụng, tối ưu nguồn tài nguyên hệ thống.

Hazelcast được viết bằng Java vì thế nó dễ dàng tương thích với các ứng dụng Java. Hazelcast cung cấp cho người phát triển các API làm việc với các đối tượng cache giống như Java (Map, Set, List, Queue) nhưng có khả năng mở rộng tới hàng trăm node. Việc lập trình Hazelcast giống như lập trình trên một máy tính, Hazelcast tự động hóa việc đồng bộ, liên kết các node, cung cấp cho người phát triển một môi trường làm việc trong suốt, rất dễ sử dụng.

Biểu đồ hoạt động dưới đây miêu tả cách cài đặt Hazelcast trong hệ thống PIS.



Game Server Application

requests id = 1

Retrieve id from Hazelcast

Store idin Hazelcast

yes no

Return id to game server application

id already inHazelcast Cache

Retrieve id from database

Hình 3.8: Biểu đồ hoạt động sử dụng Hazelcast

Các dư liệu ít thay đổi như thông tin user, thông tin về application, các loại tài sản của người chơi… các thông tin này ở lần đầu tiên truy xuất từ database sẽ được cache lại, sau đó các lần tiếp theo hệ thống chỉ cần truy xuất vào cache lấy dư liệu một cách nhanh chóng.



Insert toHazelcast cache

Retrieve data from Hazelcast cache

database

Batch insert/ batch updateInterval Loop

Insert toHazelcast cache

Evict cache inHazelcast

Hình 3.9: Biểu đồ hoạt động cài đặt buffer insert (update) Hazelcast

Biểu đồ trên mô tả cách hệ thống làm việc với nhưng bản ghi phải insert (update) nhiều và liên tục vào hệ thống như log transaction, log game, log actity… Với việc áp dụng Hazelcast, hệ thống insert trực tiếp các dư liệu log này vào hệ thống Hazelcast, sau đó cài đặt một khoảng thời gian “interval” định kỳ lấy các bản ghi này trong cache rồi thực hiện batch insert (update) và database. Nhưng dư liệu cache sau khi được insert thành công sẽ được xóa đi giải phóng bộ nhớ của hệ thống. Thông qua cách này hệ thống giảm được số lượng lớn các câu query và giảm thời gian truy vấn database một cách đáng kể.

3.3. Cơ chế Extension (Plugin)

Khái niệm Extension (Plugin)

Extension là cơ chế cho phép chạy các đoạn mã đóng gói từ bên ngoài, cùng với hệ thống, ứng dụng mà không làm ảnh hưởng đến phần lõi của hệ thống, ứng dụng đó. Một hệ thống cho phép cài đặt extension, là một hệ thống có khả năng mềm dẻo, cho phép người phát triển tự do xây dựng các phần mở rộng dựa trên api mà hệ thống cung cấp. Một Extension là tập hợp các file cài đặt, cấu hình để extension có thể chạy được.

Plugin là cũng là các phần mở rộng, cắm thêm vào hệ thống nhưng đảm nhiệm một chức năng, nhiệm vụ cụ thể. Các Plugin có thể được chứa trong Extension. Đặc thù của Plugin là thực hiện một nhiệm vụ cụ thể vì vậy chúng thường gắn với các Class với hành vi và thuộc tính của riêng nó.

Với cơ chế Extension, hệ thống hoàn toàn có thể quản lý bật tắt các phần mở rộng, giảm thiểu và ngăn ngừa lỗi từ các phần mở rộng bằng cách tạo ra các khuôn mẫu đòi hỏi các extension phải cài đặt nếu muốn tích hợp vào hệ thống, đảm bảo hệ



thống vẫn hoạt động bình thường nếu các extension bị lỗi, từ đó tăng khả năng chịu lỗi hệ thống.

Extension xuất hiện ở rất nhiều các hệ thống, ứng dụng, framework khác nhau như: extension trong hệ điều hành, extension với các trình duyệt web (Chorme, Firefox, IE), extension trong các web framework (joomla, wordpress)…

Cơ chế extension trong các game server engine càng trở nên rõ ràng khi người phát triển có thể xây dựng nhiều game logic khác nhau, nghiệp vụ rất đa dạng nhưng đều có đặc điểm chung là quản lý user, quản lý luồng ra vào phòng, giao tiếp giưa user và hệ thống. Do đó các hệ thống game server cần có cơ chế extension, cho phép người phát triển tùy biến, cài đặt các phần mở rộng thông qua API mà hệ thống cung cấp.

Cấu trúc thư mục cài đặt các phần mở rộng

Hình 3.10: Cấu trúc thư mục cài đặt phần mở rộng

Theo cấu trúc thư mục trên các phần mở rộng sau khi đã được đóng gói được đặt trong thư mục extensions. Cấu trúc file của một phần mở rộng bao gồm: thư mục có tên tương ứng với phần mở rộng, thư mục này chứa 2 thư mục con khác là config và lib. Trong thư mục config người phát triển cấu hình các plugin, các đối tượng sử dụng trong file Extension.xml. Thư mục lib chứa các file .jar là các file thực thi và



thư viện của phần mở rộng. Sau đó hệ thống sẽ có cơ chế để duyệt qua các thư mục này, khởi tạo extension và chạy cùng server.

Cơ chế chạy các phần mở rộng

Các chương trình viết bằng Java được các IDE hỗ trợ biên dịch các file .java thành các file .class dưới dạng byte code, sau đó sử dụng JVM để thông dịch các file .class thành mã máy tương ứng, từ đó chương trình được nạp và chạy thông qua CPU.

Để chạy các phần mở rộng ta sử dụng ClassLoader trong Java hỗ trợ nạp các file class từ các file thư viện đóng gói (.jar) vào máy ảo JVM mà không cần phải đặt chúng vào –classpath khi chạy chương trình.

Hình 3.11: Cơ chế load class trong Java

Trong Java có 3 loại Class Loader:

x Bootstrap Class Loader (Bộ nạp Lớp Khởi động): nạp các lớp java căn bản (core class) thuộc các gói như java.lang, java.util, v.v.. Nhưng lớp này là một phần của môi trường thực thi của java (JRE). Bootstrap Class Loader được triển khai riêng cho từng nền tảng nên có thể khác nhau giưa các JVM.

x Extensions Class Loader (Bộ nạp Lớp Mở rộng): nạp các lớp java từ thư mục JRE/lib/ext này hoặc bất cứ thư mục nào được định nghĩa trong biến môi trường java.ext.dirs

x System Class Loader (Application Class Loader): load các lớp được cấu hình trong biến môi trường CLASSPATH, -cp, -classpath hoặc thuộc tính Class-Path trong file Manifest của gói JAR.

Java cung cấp các lớp mở rộng từ java.lang.ClassLoader như: java.net.URLClassLoader, java.security.SecureClassLoader… để LTV có thể sử



dụng để nạp các file class trong lúc chạy chương trình. Ngoài ra, LTV cũng có thể cũng có thể tạo ra các lớp Class Loader của riêng mình bằng cách mở rộng class java.lang.ClassLoader.

Biểu đồ hoạt động sau đây mô tả cách hệ thống chạy các phần mở rộng:

Browse extension folder

Load all file .jar in lib folder

load class by URLClassLoader

Read config/Extension.xml

init and run object by className use URLClassLoader

Hình 3.12: Biểu đồ hoạt động load extension

Hệ thống sẽ duyệt các phần mở rộng trong thư mục extensions, sau đó đọc vào thư mục lib, load tất cả các file .jar. Sau đó, hệ thống sử dụng URLClassLoader để nạp các class trong các file .jar này vào máy ảo JVM. Từ đó hệ thống có thể khởi tạo các class từ class name đọc từ file Extension.xml. Nhờ cơ chế này các đối tượng từ các phần mở rộng được khởi tạo và điều khiển theo logic của người phát triển.

Kết chương

¾ Trong chương này, người viết đồ án đã trình bày về 3 giải pháp trọng tâm giải quyết bài toán là: nghiên cứu và cài đặt cơ chế NIO Network, cơ chế phân cụm dư liệu và áp dụng Hazelcast, cơ chế Extension (Plugin).

¾ Trong chương tiếp theo, người viết đồ án xin trình bày về cách cài đặt hệ thống đồng thời kiểm thử hiệu năng của hệ thống.



Chương 4: Kết quả đạt được

Nội dung chính được trình bày trong chương này: 9 Cài đặt hệ thống trong môi trường thực tế 9 Kiểm thử hiệu năng hệ thống

Qua quá trình nghiên cứu, tìm hiểu dưới sự hướng dẫn của thầy ThS Hoàng Anh Việt và anh Nguyễn Hoàng Bách em đã xây dựng thành công giải pháp tương tác trực tuyến Parrot Interactive Solution.

Được sự hỗ trợ của công ty TapStudio, hệ thống game đã được đưa vào hoạt động được một thời gian.

4.1. Môi trường cài đặt

Hệ thống server được cài đặt trên mội trường:

Máy chủ: 2 máy server vật lý Supermicro X8DTL (8x Intel® Xeno® CPU E506 2.13 GHz), 16 GB RAM

Hệ điều hành: Centos 6.6 x64

Hệ quản trị CSDL: Mysql 5.5

Hệ thống phân cụm tính toán: 3 instance chạy trên 2 server vật lý, trong đó 1 server chạy 2 instance (1 instace độc lập và 1 instance được nhúng trong game server)

Môi trường thực thi: máy ảo JVM sử dụng JRE 1.7

Trong thư mục cài đặt chương trình (Hình 3.10), người viết đồ án xây dựng các file shell script để điều khiển server. Người phát triển có thể dễ dàng khởi động, ngưng tiến trình server bằng thực thi các file start.sh, stop.sh

4.2. Cài đặt và kiểm thử hệ thống

Client Side được xây dựng trên nền tảng Unity hỗ trợ chạy đa nên tảng, trên nhiều thiết bị khác nhau.



Giao diện game client

Hình 4.1: Màn hình trang chủ và thách đấu



Hình 4.2: Màn hình gửi thách đấu và chơi game



Hình 4.3: Màn hình quà tặng, vòng quay may mắn

Hệ thống đã được cài đặt và thử nghiệm thành công cho kết quả chạy khá ổn định, kho dư liệu gồm 1500 câu hỏi đa dạng bước đầu đem lại trải niệm thú vị cho người chơi.

Hệ thống game được đưa vào chạy thử nghiệm từ tháng 11/3/2015 và đã có 924 người đăng ký và sử dụng hệ thống. Nhưng do sản phẩm được phát triển trong mội trường công ty và thời gian phát triển còn hạn chế nên sản phẩm đạt được lượng người dùng rất khiêm tốn.



Để thư nghiệm khả năng chịu tải của hệ thống, người viết đồ án xây dựng client test cho ra nhưng thông số sau:

Test Message Time (ms) CPU (%) RAM (%) 1 12000 817 13 1.3 2 13000 821 20.6 1.3 3 14000 1005 21.6 1.3 4 15000 939 24.3 1.3 5 15000 922 23 1.3 6 15000 970 25 1.3 7 16000 960 27.3 1.3 8 16000 1023 23 1.3 9 17000 1026 26.3 1.3 10 17000 1105 25.3 1.3

Bảng 7: Các kết quả kiểm thử hệ thống

Như vậy hệ thống có thể xử lý trung bình 15000 message/s, với ước tính mỗi máy client thực tế chỉ gửi được 3 message/s thì hệ thống có thể xử lý được 5000 CCUs. Với con số này hệ thống đáp ứng được mục tiêu đề ra và cho thấy sự khả thi của giải pháp.

Kết chương

¾ Trong chương này người viết đồ án đã cài đặt và kiểm thử hệ thống. Hệ thống đã đi vào hoạt động và bước đầu chứng mình được sự khả thi của giải pháp

¾ Trong chương tiếp theo người viết đồ án xin đưa ra kết luận, đánh giá đồ án dựa trên nhưng mục tiêu và kết quả đã đạt được



KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN

Đánh giá kết quả đạt được

Những mục tiêu đề ra

- Xây dựng một giải pháp hệ thống tương tác trực tuyến từ đó xây dựng một game online để demo hệ thống

- Nghiên cứu và cài đặt cơ chế NIO Network đáp ứng số lượng kết nối đồng thời lớn

- Nghiên cứu hệ thống phân cụm dư liệu và áp dụng giải pháp Hazelcast vào hệ thống

- Nghiên cứu và xây dựng cơ chế Extension (Plugin) cho phép các nhà phát triển chạy các đoạn mã dưới phần mở rộng.

Những kết quả đạt được

9 Hệ thống đã được xây dựng và đưa vào chạy thực tế thể hiện qua số lượng người chơi game tương tác với hệ thống

9 Nghiên cứu và cài đặt thành công tư tưởng NIO Network vào trong hệ thống PIS và xử lý được 5000 CCUs

9 Áp dụng thành công Hazelcast vào việc xây dựng hệ thống phân cụm chia sẻ dư liệu in-memories

9 Xây dựng và áp dụng cơ chế Extensions (Plugin) cho phép các nhà phát triển chạy các đoạn mã dưới phần mở rộng.

Những vấn đề còn tồn tại

Do thời gian phát triển ngắn và sản phẩm phụ thuộc vào sự phát triển của công ty nên hệ thống đạt được lượng người dùng còn rất khiêm tốn. Bên cạnh đó, hệ thống còn rất nhiều hạn chế cần phải cải thiện về hiệu năng hệ thống, cơ chế xử lý message cần tối ưu hơn nhằm tăng tốc độ truyền nhận, tư tưởng extensions còn ở mức đơn giản, người phát triển có thể tùy biến với hệ thống nhưng chưa được linh hoạt.

Phương hướng phát triển

Với sự phát triển vũ bão của Internet và mạng di động như hiện nay, sự phát triển của các hệ thống tương tác online đóng vai trò quan trọng trong việc phát triển nền kinh tế nước ta, phương hướng phát triển của hệ thống như sau:

� Tiếp tục tối ưu, cải thiện hiệu năng của hệ thống � Tiếp tục hoàn thiện cơ chế Extension (Plugin). � Cơ chế đóng gói message cần tối ưu hơn để tăng tốc truyền nhận. � Phát triển các hệ thống online, không chỉ game online mà có thể đi tới

xây dựng các hệ thống giáo dục online



TÀI LIỆU THAM KHẢO

[1] “Việt Nam vào top 20 quốc gia có nhiều người dùng Internet nhất,” http://netnam.vn/index.php/en/news/about-netnam/52-bao-chi-noi-v-netnam/328-viet-nam-vao-top-20-quoc-gia-co-nhieu-nguoi-dung-internet-nhat.html.

[2] “Thống kê Việt Nam có 27,5 triệu thuê bao sử dụng 3G,” http://dangky3gmobifone.net/thong-ke-viet-nam-co-27-trieu-thue-bao-su-dung-3g/.

[3] “Thống kê mới nhất về mạng xã hội tại Việt Nam đầu năm 2014,” http://vanmy.net/social-media/thong-ke-moi-nhat-ve-mang-xa-hoi-tai-viet-nam-dau-nam-2014/.

[4] “Bùng nổ dịch vụ OTT,” http://nld.com.vn/khoa-hoc/bung-no-dich-vu-ott-20130313093110579.htm.

[5] A. Leonard, Pro Java 7 NIO.2, 2011.

[6] "SmartFoxServer Shop" http://www.smartfoxserver.com/shop/ index.php?dispatch=categories.view&category_id=2.

[7] "PhotonServer Pricing" https://www.exitgames.com/en/ OnPremise/Pricing.

[8] "Java Extensions" https://docs.oracle.com/javase/tutorial/ext/.

[9] "Hazelcast," http://hazelcast.com/products/hazelcast/.

[10] “Công nghệ Clustering cho các hệ thống máy tính,” http://forum.thegioimaychu.vn/high-avability-failover-clustering/6165-cong-nghe-clustering-cho-cac-he-thong-may-tinh.html.

[11] “Giao thức TCP/IP,” http://sinhvienit.net/@tut/mang-may-tinh/mang-can-ban/131-chuong-7-giao-thuc-tcp-ip.html.

Documents

Đồ án Xây dựng hệ thống tương tác trực tuyến