Nghiên cứu xây dựng hệ thống notification cho ứng dụng lotus và các app tin tức khác

ĐẠI HỌC QUỐC GIA TP. HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
KHOA CÔNG NGHỆ PHẦN MỀM

BÁO CÁO ĐỒ ÁN 2

Nghiên cứu xây dựng hệ thống notification
cho ứng dụng Lotus và các app tin tức khác

GVHD: TS. Huỳnh Ngọc Tín
Sinh viên:
16520549 Trần Hồng Kha


LỜI CẢM ƠN
Trong quá trình học tập và rèn luyện tại khoa Kĩ thuật phần mềm
trường Đại học Công nghệ thông tin TP.HCM, em đã được trang bị
các kiến thức cơ bản, các kỹ năng thực tế để có thể hồn thành đồ
án mơn học của mình.
Em xin gửi lời cảm ơn chân thành tới thầy “Huỳnh Ngọc Tín” vì
đã quan tâm, hướng dẫn truyền đạt những kiến thức và kinh nghiệm
cho em trong suốt thời gian học tập và thực hiện mơn Đồ án 2
Trong q trình làm đồ án mơn học, mặc dù đã cố gắng hồn
thành các mục tiêu nghiên cứu, tuy nhiên không tránh khỏi được
những sai sót, hạn chế. Em mong nhận được sự góp ý của thầy để
được hoàn thiện hơn.
Em xin chân thành cảm ơn

TP. HỒ CHÍ MINH, THÁNG 6 NĂM 2021

2

GVHD: TS. Huỳnh Ngọc Tín


MỤC LỤC
LỜI CẢM ƠN ................................................................................................... 2
MỤC LỤC ........................................................................................................ 3
DANH SÁCH HÌNH VẼ .................................................................................... 5
BỐ CỤC BÁO CÁO.......................................................................................... 6
CHƯƠNG 1: TỔNG QUAN ĐỀ TÀI ................................................................. 7
1. Lý do chọn đề tài ...................................................................................... 7
2. Giải pháp .................................................................................................. 8
3. Mục tiêu đề tài .......................................................................................... 9
4. Đối tượng và phạm vi nghiên cứu ............................................................ 9
5. Ý nghĩa khoa học và thực tiễn của đề tài.................................................. 9
CHƯƠNG 2: CÁC NGHIÊN CỨU LIÊN QUAN ............................................. 11
1. DESIGN A SYSTEM NOTIFICATION..................................................... 11
1.1 Hiểu vấn đề và thiết lập phạm vi thiết kế ........................................... 12
1.2 Đề xuất thiết kế high-level và cách buy-in .......................................... 13
1.3 Design deep dive (Chi tiết thiết kế) .................................................... 19
2. APACHE KAFKA .................................................................................... 23
2.1 Kafka là gì? ........................................................................................ 23
2.2 Tại sao sử dụng Kafka? ..................................................................... 24
2.3 Cấu trúc Kafka chi tiết ........................................................................ 25
2.4 Workflow ............................................................................................ 27
2.5 Use cases .......................................................................................... 28
3. MySQL Replication ................................................................................. 30
3.1 Replication là gì? ............................................................................... 30
3.2 Vậy Replication hoạt động như thế nào trong MySQL ....................... 31
3.3 Nên dùng lúc nào? Và ứng dụng thực tiễn ........................................ 31
4. Java – Spring Boot ................................................................................. 34

4.1 Giới thiệu svề Spring Boot ................................................................. 34
4.2 Vậy Spring Boot là gì? Tại sao phát triển nhanh đến như thế? ......... 35
4.3 Những lợi thế của Spring Boot........................................................... 35
4.4 Tại sao nên sử dụng Spring Boot? .................................................... 36
CHƯƠNG 3. HƯỚNG TIẾP CẬN.................................................................. 37

3
GVHD: TS. Huỳnh Ngọc Tín


1. Quy trình thu thập thơng tin .................................................................... 37
2. Chi tiết luồng đi notification trong hệ thống ............................................. 38
3. Bổ sung các giải pháp đã nêu ra trong quá trình nghiên cứu. ................ 39
CHƯƠNG 4: HIỆN THỰC ĐỒ ÁN ................................................................. 40
CHƯƠNG 5: THỰC NGHIỆM, ĐÁNH GIÁ .................................................... 41
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN .......................................................... 42
1. Kết luận .................................................................................................. 42
2. Hướng phát triển .................................................................................... 42
TÀI LIỆU THAM KHẢO .................................................................................. 43

4
GVHD: TS. Huỳnh Ngọc Tín


DANH SÁCH HÌNH VẼ
Hình ảnh 1: Ảnh minh họa notification trên điện thoại...................................... 8
Hình ảnh 2: Ảnh minh họa các loại notification .............................................. 11
Hình ảnh 3: Ảnh minh họa các loại notification hoạt động ............................. 13
Hình ảnh 4: Ảnh minh họa quy trình thu thập thơng tin .................................. 15
Hình ảnh 5: Ảnh minh họa table database ..................................................... 15

Hình ảnh 6: Ảnh minh họa HIGH-LEVEL DESIGN ........................................ 16
Hình ảnh 7: Ảnh minh họa HIGH-LEVEL DESGIN (Đã được cải thiện)......... 17
Hình ảnh 8: Ảnh minh họa notification system duy trì notification data trong 1
database ........................................................................................................ 19
Hình ảnh 9: Ảnh minh họa event tracking ...................................................... 21
Hình ảnh 10: Ảnh minh họa Updated Design ................................................. 22
Hình ảnh 11: Ảnh minh họa cấu trúc Kafka đơn giản .................................... 23
Hình ảnh 12: Ảnh minh họa cấu trúc Kafka chi tiết ........................................ 25
Hình ảnh 13: Ảnh minh họa Consumer Group cùng nhau hoạt động ............ 26
Hình ảnh 14: Ảnh minh họa luồng đi của Message trong Kafka .................... 27
Hình ảnh 15: Ảnh minh họa về mơ hình Master-Slave thơng thường ............ 30
Hình ảnh 16: Ảnh minh họa MySQL hoạt động ............................................. 31
Hình ảnh 17: Ảnh minh họa số liệu thống kê Top Java Web Frameworks..... 34
Hình ảnh 18: Ảnh minh họa Lợi thế Spring Boot............................................ 35

5
GVHD: TS. Huỳnh Ngọc Tín


BỐ CỤC BÁO CÁO
CHƯƠNG 1: TỔNG QUAN ĐỀ TÀI
Nội dung chương này giới thiệu tổng quan về lý do chọn đề tài,
mục tiêu đề tài, đối tượng và phạm vi, ý nghĩa khoa học và thực
tiễn của đề tài

CHƯƠNG 2: CÁC NGHIÊN CỨU LIÊN QUAN
Nội dung chương này trình bày các nghiên cứu và kiến thức liên
quan tới đề tài

CHƯƠNG 3: HƯỚNG TIẾP CẬN

Nội dung chương này trình bày hướng tiếp cận đề tài một cách
khách quan và nêu lên các vấn đề thực tế gặp phải

CHƯƠNG 4: HIỆN THỰC ĐỒ ÁN
Nội dung chương này trình bày quá trình cài đặt và triển khai hệ
thống

CHƯƠNG 5: THỰC NGHIỆM, ĐÁNH GIÁ
Nội dung chương này trình bày quá trình thực nghiệm từ đó đưa
ra các nhận xét, kết luận và đánh giá

6
GVHD: TS. Huỳnh Ngọc Tín


CHƯƠNG 1: TỔNG QUAN ĐỀ TÀI
1. Lý do chọn đề tài
Khi mọi người sử dụng điện thoại, chắc hẳn đã có một hoặc vài lần
phải gỡ bỏ ứng dụng chỉ vì lượng thơng báo ứng dụng đó gửi tới
q phiền và khơng đủ kiên nhẫn để có thể đi tới phần Setting và
“turn off” thông báo của ứng dụng.
Không giống như Text Message hay gửi email chỉ link tới địa chỉ cụ
thể mà Push Notification (bắn thông báo như trên) sẽ link thẳng tới
thiết bị có cài ứng dụng đó. Việc gửi Push Notification thái quá có
thể dẫn tới phản tác dụng nếu như người dùng cảm thấy phiền nên
chìa khóa cho việc sử dụng Push Notification hiệu quả, đúng cách
là làm sao để Notification của bản thân luôn được chào đón.

7
GVHD: TS. Huỳnh Ngọc Tín

Hình ảnh 1: Ảnh minh họa notification trên điện thoại

Nếu như được sử dụng đúng cách, Push Notification sẽ trở nên cực
kì giá trị, vì có những đặc trưng riêng mà các cách thức khác khơng
có. Đầu tiên là khơng giống với email hay text message, Push
Notification không sử dụng hộp thư đến, đây cũng là 1 yếu tố ít gây
phiền tối cho người dùng hơn. Ngồi ra chúng khơng thể vơ tình
chui vào hịm thư rác giống như cái bạn thường gặp khi sử dụng
email. Và điều cuối cùng nhưng cũng rất quan trọng, đó là phải cần
có 1 số điện thoại hay địa chỉ email thì mới có thể gửi Push
Notification.
Đối với các ứng dụng tin tức, rất khó để đạt được tỉ lệ tương tác
mạnh mẽ của người dùng. Người đọc khơng có dành riêng tương
tác cho một nguồn nào nữa – họ thích cập nhật từ các phương tiện
truyền thông xã hội, người đưa tin và tổng hợp tin tức. Thế nên làm
cách nào để các biên tập viên và tiếp thị ứng dụng tin tức có thể giữ
chân được khán giả?
Câu trả lời là sử dụng Push Notification cho app tin tức của họ, đặc
biệt nhất là các “Breaking news” cho người đọc nhanh nhất có thể.
Nhận biết được sự cần thiết về việc thiết kế một hệ thống Push
Notification trên, em đã vận dụng những kiến thức chuyên môn của
bản thân và với những kiến thức được thầy hướng dẫn để xây dựng
nên một hệ thống Notification có thể bắn thơng báo cho các ứng
dụng tin tức từ đó tăng được trải nghiệm người dùng, kéo được
lượng lớn người đọc, hỗ trợ việc marketing,…

2. Giải pháp
Ngoài việc xây dựng hệ thống Notification phục vụ cho các ứng

dụng tin tức trên, còn phải sử dụng chúng đúng cách
✓ Notification phải đặc trưng, phải riêng biệt:
Nội dung phải khiến người đọc có lý do muốn xem chứ
không phải nhận chúng một cách miễn cưỡng
✓ Custom alert sound (Tùy chọn):
Một điểm cộng để gây sự chú ý đối với người đọc, tạo ra sự
khác biệt với các ứng dụng khác

8
GVHD: TS. Huỳnh Ngọc Tín


✓ Khoanh vùng người đọc muốn hướng đến:
Giúp tránh trường hợp người nhận notification khơng có bất
kì lợi ích về tin tức nhận được từ notification. Thậm chí cịn
cần xác định thời gian gửi notification trong ngày để phù hợp
với thời gian hay là lúc sử dụng điện thoại của người dùng
✓ Lựa chọn gửi notification dựa trên tần xuất người đọc truy
cập ứng dụng:
Cân nhắc gửi notification chỉ đến những người đã không mở
ứng dụng để đọc trong 1 tuần, 2 tuần,…

3. Mục tiêu đề tài
Sau khi dựa vào lý do chọn đề tài và giải pháp trên, em hiểu được
việc xây dựng một hệ thống Notification tốt là quan trọng như thế
nào. Đề tài mà em sẽ thực hiện:
✓ Nghiên cứu các ảnh hưởng của Notification tới người dùng
✓ Tìm hiểu cách thiết kế về một hệ thống Notification cho ứng
dụng di động và các công nghệ liên quan.
✓ Xây dựng hệ thống và tích hợp các giải pháp đã nêu trên ,

so sánh hiệu quả thực tế và rút ra nhận xét, kết luận.

4. Đối tượng và phạm vi nghiên cứu
Đối tượng hướng tới là các app tin tức cần gia tăng, phân loại
người đọc, tăng tốc độ các tin tức quan trọng tới người đọc.
Nghiên cứu thực tế về các thông báo từ các ứng dụng tin tức phổ
biến, từ đó phân tích nội dung của các thơng báo đó
Hành vi người dùng, các thơng tin phân tích và dự đốn trên sẽ
dùng để phân tích làm tăng trải nghiệm người dùng

5. Ý nghĩa khoa học và thực tiễn của đề tài
Việc xây dựng một hệ thống Notification cho các ứng dụng tin tức,
giúp hình thành được một kho dữ liệu về hành vi người dùng,
phân tích văn bản, phân tích cảm xúc người dùng. Từ đó có thể
đưa ra các thuật tốn phù hợp với độ chính xác và tối ưu nhất.
Ngồi ra cũng có thể tăng được hiệu quả hoạt động của một số
doanh nghiệp

9
GVHD: TS. Huỳnh Ngọc Tín


10
GVHD: TS. Huỳnh Ngọc Tín


CHƯƠNG 2: CÁC NGHIÊN CỨU LIÊN QUAN
1. DESIGN A SYSTEM NOTIFICATION
Notification (thơng báo) system đã trở thành tính năng rất phổ biến
trong hầu như tất cả các app suốt bao nhiêu năm nay. Một

notification báo với người dùng các thông tin quan trọng như là tin
nóng, update app, sự kiện, … Việc này trở thành không thể thiếu
trong cuộc sống thường nhật của người sử dụng.
Notification thì có nhiều loại chứ không chỉ là bắn notification trên
điện thoại (việc hiện ra notification ở màn hình lock của điện thoại
thì khơng lạ nữa). Có 3 loại chính đó là:
✓ Mobile Push Notification (Bắn thơng báo cho các app)
✓ SMS message
✓ Email

Hình ảnh 2: Ảnh minh họa các loại notification

11
GVHD: TS. Huỳnh Ngọc Tín


1.1 Hiểu vấn đề và thiết lập phạm vi thiết kế
Khơng có gì là dễ dàng để xây dựng một hệ thống có thể gửi hàng
triệu notification hằng ngày. Nó đòi hỏi khả năng hiểu biết về
notification ecosystem (hệ sinh thái). Các Q&A sẽ giúp mọi người
hiểu rõ hơn
1. Loại notification nào mà hệ thống sẽ hỗ trợ?
Push notification, SMS message, and email.
2. Đây có phải là hệ thống real-time?
Nói một ít vệ hệ thống real-time. Mục tiêu của việc bắn
notification là tới người dùng càng nhanh càng tốt. Tuy
nhiên, nếu hệ thống có khối lượng cơng việc cao, thì chút
chậm trễ là có thể chấp nhận được
3. Những thiết bị được hỗ trợ?
Iphone, điện thoại Android, Laptop/Desktop

4. Điều kiện kích hoạt notification?
Các ứng dụng ngay trên client có thể kích hoạt được thơng
báo, ngồi ra cũng có được lên lịch kích hoạt thơng báo ở
phía server
5. User có thể từ chối nhận notification?
Tất nhiên ai từng sử dụng điện thoại đều có option lựa chọn
nhận thơng báo từ một app, hoặc nhận từ chối mail, chặn tin
nhắn, …
6. Có bao nhiêu notification được gửi đi hàng ngày?
Tầm 10 triệu mobile push notification, 1 triệu SMS
messages, và khoảng 5 triệu emails

12
GVHD: TS. Huỳnh Ngọc Tín


1.2 Đề xuất thiết kế high-level và cách buy-in
Trước tiên hãy xem các loại notification hoạt động

Hình ảnh 3: Ảnh minh họa các loại notification hoạt động

13
GVHD: TS. Huỳnh Ngọc Tín


✓ IOS push notification
Cần 3 component để có thể gửi 1 ios push notification:
- Provider: Kiến tạo (Device token + Payload) và gửi các
requests tới Apple Push Notification Service (APNS).
▪ Device token: Số nhận dạng duy nhất được sử

dụng để gửi push notification
▪ Payload: Json dictionary lưu trữ notification’s
payload. Ví dụ:
{
"app": {
"arlet": {
"title": "Game requests",
"body": "Bob wants to play chess",
"action-loc-key": "PLAY"
},
"badge": 5
}
}
- APNS: Đây là một dịch vụ từ xa do Apple cung cấp để
truyền push notification cho Iphone
- Iphone: Nơi cuối của client sẽ nhận push notification
✓ Android push notification
Android cũng áp dụng tương tự nhưng thay vì sử dụng
APNS, Fireabase Cloud Messaging (FCM) thường được sử
dụng để gửi push notification tới thiết bị android
✓ SMS message
Với SMS message, sử dụng dịch vụ bên thứ 3 như là Twilio,
Nexmo, và nhiều dịch vụ khác thường được sử dụng. Hầu
hết là dịch vụ thương mại
✓ Email
Mặc dù các công ty có thể thiết lập server email của bản
thân nhưng mà vẫn chọn sử dụng dịch vụ email thương mại.
Sendgrid và Mailchimp là một trong những dịch vụ phổ biến
nhất, cung cấp tỷ lệ phân phối và phân tích dữ liệu tốt hơn

14
GVHD: TS. Huỳnh Ngọc Tín


1.2.1 Quy trình thu thập thơng tin
Để gửi notification, cần phải thu thập mã thiết bị di động, SĐT
hoặc email. Như hình dưới khi người dùng cài đặt ứng dụng hoặc
đăng ký lần đầu tiên, API servers sẽ thu thập thơng tin của người
dùng và lưu nó ở database

Hình ảnh 4: Ảnh minh họa quy trình thu thập thơng tin

Các table database cho thấy dữ liệu được đơn giản hóa để lưu trữ
thông tin. Email và SĐT được lưu vào user table, trong khi mã
thiết bị di động được lưu vào device table. 1 người dùng có thể có
nhiều thiết bị, nên có nghĩa là phải push notification tới tất cả các
thiết bị của người dùng

Hình ảnh 5: Ảnh minh họa table database

15
GVHD: TS. Huỳnh Ngọc Tín


1.2.2 Notification sending/receiving flow
Đầu tiên sẽ trình bày thiết kế ban đầu sau đó đề xuất tối ưu hóa

HIGH-LEVEL DESIGN

Hình ảnh 6: Ảnh minh họa HIGH-LEVEL DESIGN

✓ Service 1 to N: 1 service có thể là micro-service, hoặc là 1
distributed system dùng để kích hoạt sự kiện gửi notification.
Ví dụ như một dịch vụ thanh toán gửi email để nhắc nhở
khách hàng đến hạn thanh toán hoặc một trang web mua
sắm gửi cho khách hàng biết rằng các gói hàng của họ sẽ
được gửi tới vào ngày mai qua SMS
✓ Notification system: Trung tâm của việc sending/receiving
notification.
✓ Dịch vụ bên thứ 3: Có trách nhiệm gửi notification tới người
dùng. Trong khi tích hợp với các dịch vụ bên thứ 3, cần phải
chú ý đến khả năng mở rộng, khả năng mở rộng tốt có nghĩa
là một hệ thống linh hoạt có thể dễ dàng tắt mở dễ dàng dịch
vụ bên thứ 3.
✓ IOS, Android, SMS, Email: Người dùng nhận được thơng
báo trên thiết bị của họ.
16
GVHD: TS. Huỳnh Ngọc Tín


Xuất hiện 3 vấn đề trong việc thiết kế này:
✓ Một điểm lỗi (SPOF – single point of failture):
Chỉ có một notification system
✓ Khó mở rộng:
Notification system xử lý mọi thứ liên quan đến push
notification trong 1 server nên khá là khó khăn cho việc mở
rộng database, caches, và xử lý các thành phần khác một
cách độc lập
✓ Nút cổ chai về hiệu suất:
Việc xử lý và gửi các notification có thể tốn rất nhiều tài

nguyên.
VD như build các trang html và chờ phản hồi từ bên thứ 3 rất
có thể mất thời gian. Xử lý mọi thứ trong một hệ thống rất dễ
dẫn tới quá tải, nhất là giờ cao điểm.

HIGH-LEVEL DESIGN (Đã được cải thiện)
Sau khi liệt kê các vấn đề ở trên, chúng ta sẽ có thể cải thiện thiết
kế như sau:
✓ Di chuyển database và cache ra khỏi notification server
✓ Thêm nhiều notification server và thiết lập automatic
horizontal scaling
✓ Giới thiệu hàng chờ message để tách các system
components.

Hình ảnh 7: Ảnh minh họa HIGH-LEVEL DESGIN (Đã được cải thiện)

17
GVHD: TS. Huỳnh Ngọc Tín


✓ Service 1 to N: Đại diện cho các service khác nhau gửi
notification thông qua API được cung cấp bởi notification
server
✓ Notification servers:
Cung cấp các chức năng:
- Provie APIs cho các services để gửi notification. Các
API này chỉ có thể truy cập nội bộ hoặc bởi khách hàng
đã được xác minh để tránh spam
- Thực hiện các xác thực cơ bản để xác minh email,
SĐT,..

- Truy vấn tới database hoặc cache để tìm dữ liệu cần
thiết cho việc hiển thị notification
✓ Cache: Thông tin người dùng, thông tin thiết bị, mẫu
notification được lưu vào cache
✓ DB: Lưu trữ dữ liệu về người dùng, notification, các cài
đặt,…
✓ Message queues (Hàng chờ): Loại bỏ sự phụ thuộc giữa các
components. Message queues đóng vài trò là đệm khi quá
nhiều notification được gửi đi. Mỗi notification được chỉ định
với một message queues riêng, do đó sự cố ngừng hoạt
động trong một dịch vụ bên thứ 3 sẽ không ảnh hưởng tới
các thông báo khác.
✓ Workers: Là một list các servers pull notification event từ
hàng chờ trên và gửi tới dịch vụ bên thứ 3 tương ứng.
✓ Third-party services: Đã được giải thích ở trên
✓ IOS, Android, SMS, Email: Người dùng nhận được thông
báo trên thiết bị của họ.
Kiểm tra lại cách mọi components làm việc với nhau và gửi
notification:
✓ 1 service gọi APIs do notification server cung cấp để gửi
notification.
✓ Notification server tìm dữ liệu như thông tin người dùng, mã
thiết bị, và cài đặt thông báo từ cache hoặc database
✓ 1 notification event được gửi tới hàng đợi tương để xử lý.
✓ Workers pull notification events từ hàng đợi tin nhắn
✓ Workers gửi notification đến các dịch vụ bên thứ 3
✓ Dịch vụ bên thứ 3 gửi notification tới thiết bị của người dùng.

18
GVHD: TS. Huỳnh Ngọc Tín

1.3 Design deep dive (Chi tiết thiết kế)
1.3.1. Reliability
Các Q&A cần biết khi thiết kế notification system trong môi trường
phân tán (distributed environments)
✓ How to prevent data loss?
Một trong những điều quan trọng nhất trong notification
system đó là khơng được mất dữ liệu. Notification thường
có thể bị trì hỗn hoặc sắp xếp lại nhưng không bao giờ bị
mất. Để đáp ứng yêu cầu trên, notification system duy trì
notification data trong 1 database và thực hiện thử lại cơ
chế.

Hình ảnh 8: Ảnh minh họa notification system duy trì notification data trong 1
database

19
GVHD: TS. Huỳnh Ngọc Tín


✓ Will recipients receive a notification exactly once?
Câu trả lời là khơng. Mặc dù notification được gửi chính xác
một lần trong hầu hết thời gian, bản chất phân tán có thể
khiến notification bị trùng lặp. Để giảm sự trùng lặp nói trên,
có cơ chế khấu trừ và xử lý từng trường hợp lỗi một cách
cẩn thận. Đây là một logic loại trừ đơn giản:
Khi notification event tới lần đầu, ta có thể kiểm tra xem
notification có thể được đọc trước đó hay khơng bằng cách
kiểm tra id event, nếu được đọc trước đó thì sẽ bị loại bỏ.

Nếu khơng sẽ gửi thông báo cho readers với lý do tại sao
chúng ta khơng thể có chính xác một lần giao hàng (Ví dụ
về notification giao hàng)

1.3.2 Additional components and considerations
Chúng ta đã thảo luận về việc thu thập thông tin người dùng, gửi
và nhận 1 notification. Một notification system thường là phức tạp
hơn thế.
✓ Notification template
Một notification system lớn gửi hàng triệu notification mỗi
ngày và có nhiều notification tương tự nhau. Nên các
notification template được sinh ra để tránh build notification
lại từ đầu. Một notification template được định dạng trước để
tạo ra một thông báo đặc biệt bằng cách tùy chỉnh các thông
số, styling, tracking links, …
✓ Notification setting
Người dùng thường nhận được nhiều notification hàng ngày
và dễ nhận thấy ngộp. Do đó nhiều trang web và app cung
cấp cho người dùng quyền kiểm soát chi tiết đối với
notification.
user_id bigInt
channel varchar
# push notification,
email or SMS
opt_in boolean
# opt-in to receive
✓ Rate limiting
Để tránh người dùng ngộp với nhiều notification, chúng ta có
thể giới hạn số lượng notification mà người dùng có thể nhận
được. Điều này rất quan trọng vì receivers có thể tắt thơng

báo hồn tồn nếu chúng ta gửi q thường xuyên

20
GVHD: TS. Huỳnh Ngọc Tín


✓ Retry mechanism
Khi dịch vụ bên thứ 3 không gửi được notification,
notification này sẽ được thêm vào hàng đợi tin nhắn để thử
lại (Đã nói ở trên). Nếu vẫn khơng gửi được, một cảnh báo
sẽ được gửi tới devs
✓ Security in push notification
Đối với IOS hoặc Android app, appKey và appSecret được
sử dụng để bảo mật các notification API. Chỉ có những
khách hàng đã xác thực mới được phép gửi push notification
sử dụng APIs trên.
✓ Monitor queued notification
Một chỉ số chính xác cần theo dõi là tổng số lượng notification
bị xếp hàng đợi. Nếu quá lớn, các notification event sẽ không
được xử lý đủ nhanh. Để tránh sự chậm trễ trên, chúng ta cần
thêm các workers
✓ Event tracking
Các chỉ số notification như là tỷ lệ mở, tỷ lệ click, mức độ
tương tác rất là quan trọng trong việc thu thập các hành vi
của khách hàng.

Hình ảnh 9: Ảnh minh họa event tracking

21
GVHD: TS. Huỳnh Ngọc Tín

1.3.3 Updated Design

Hình ảnh 10: Ảnh minh họa Updated Design

Trong thiết kế này thì nhiều components mới được bổ sung so với
thiết kế trước đó:
✓ Notification server được thêm 2 tính năng quan trọng: Xác
thực và giới hạn tỉ lệ
✓ Thêm cơ chế thử lại để xử lí các lỗi notification nếu system
không gửi được notification, chúng sẽ được đưa trở lại hàng
đợi và workers sẽ thử lại số lần xác định trước khi gửi cảnh
cáo lỗi
✓ Hơn nữa, các notification templates cung cấp một
notification nhất quán và hiệu quả được quá trình sáng tạo
✓ Cuối cùng, hệ thống giám sát và theo dõi được thêm vào để
kiểm tra hiệu suất hệ thống và có thể cải tiến trong tương lai

22
GVHD: TS. Huỳnh Ngọc Tín


2. APACHE KAFKA
2.1 Kafka là gì?
Chắc ai cũng biết tới hệ thống Subscribe của Youtube nhỉ? Đó là
khi mình subscribe một kênh nào đó thì hành động của kênh mình
subscribe như là đăng video mới, đăng status mới trên youtube,..
sau đó sẽ phân loại việc hiển thị video mới sẽ hiện lên chỗ khác,
status, story sẽ hiện lên chỗ khác. Và người dùng là mình chỉ cần

đọc/xem status, story/video đó thôi.
Kafka là một hệ thống Message Publish/Subscribe tương tự vậy mà
trong đó hệ thống này có 4 thành phần chính

Hình ảnh 11: Ảnh minh họa cấu trúc Kafka đơn giản

Cấu trúc Kafka đơn giản:
✓ Producer: Là các thành phần tạo ra message cần gửi đi, sử
dụng producer để publish message vào Broker
✓ Broker: Một server Kafka nhận được message từ Producer
(Một set các server Kafka sẽ hình thành Cluster)
✓ Zookeeper: Được sử dụng để quản lý và điều phối các Kafka
Broker
✓ Consumer (Subscriber): Subscribe tới topic (có thể là nhiều
topics) nhận và đọc message từ Topic (Topic trong Broker)

23
GVHD: TS. Huỳnh Ngọc Tín


2.2 Tại sao sử dụng Kafka?
✓ Multiple Producers
Kafka có thể xử lý liền mạch nhiều producers, cho dù clients
đó đang sử dụng nhiều topic hoặc cùng một topic (như là bấm
vào button, đăng status, nhắn tin,...), việc này tạo nên một hệ
thống lý tưởng để tổng hợp dữ liệu từ nhiều frontend.
✓ Multiple Consumers
Kafka được thiết kế cho nhiều consumers để đọc bất kỳ
message nào trong mà không ảnh hưởng lẫn nhau. Multiple
Kafka consumers có thể chọn hoạt động như một phần của

nhóm và chia sẻ một stream, đảm bảo rằng tồn bộ nhóm xử
lý message đã cho chỉ trong một lần.
✓ Disk-Based Retention
Kafka cịn có có thể lưu giữ message khá lâu ( duy trì bền ) lý
do bởi vì consumer khơng phải lúc nào cũng cần làm việc theo
thời gian thực. Messages được commit vào ổ cứng với các
quy tắc nhất định. Các tùy chọn này có thể là được chọn trên
cơ sở từng topic, cho phép các luồng message khác nhau có
sự khác biệt về số lượng duy trì phụ thuộc vào nhu cầu của
consumer. (Có nghĩa là có thể cấu hình)
Nếu consumer tụt lại phía sau (do xử lý chậm hay bị rối loạn
trong khi truyền) cũng khơng có nguy cơ bị mất dữ liệu điều
này cũng có nghĩa là bảo trì cũng có thể được thực hiện trên
consumer.
Các ứng dụng offline trong một khoảng thời gian ngắn, không
quan tâm về các message được sao lưu hay bị mất, consumer
có thể được dừng lại và các message sẽ vẫn được giữ lại ở
Kafka từ đó cho phép consumer khởi động lại và tiếp tục xử
lý message còn đang dang dở
✓ Scalable
Khả năng mở rộng linh hoạt của Kafka sẽ giúp bạn dễ dàng
xử lý bất kỳ lượng dữ liệu nào. Người dùng có thể bắt đầu với
một broker duy nhất như một proof of concept, bắt đầu từ
cluster nhỏ có 3 brokers rồi chuyển sang với cluster lớn hơn
cùng hàng trăm ngàn broker
(tăng lên theo lượng data phải xử lí)
Scale có thể được thực hiện bên trong khi cluster đang online
mà khơng ảnh hưởng đến tính khả dụng của tồn bộ hệ thống
nghĩa là một nhóm nhiều broker có thể xử lý ln phần việc
của broker hỏng và tiếp tục phục vụ clients

24
GVHD: TS. Huỳnh Ngọc Tín


✓ High Performance
Tất cả các tính năng trên kết hợp với nhau để biến Apache
Kafka thành một hệ thống publish/subscribe messaging với
hiệu suất tuyệt vời dưới tải trọng cao

2.3 Cấu trúc Kafka chi tiết

Hình ảnh 12: Ảnh minh họa cấu trúc Kafka chi tiết

✓ Message: Đơn giản là một mảng byte, thường có dạng keyvalue (Các key được sử dụng khi message được ghi vào các
phân vùng - để đảm bảo các message có cùng key ln được
ghi vào các phân vùng giống nhau)
✓ Topic: Message được phân loại thành các Topic theo chủ đề
gần giống nhau (Ví dụ dễ hiểu là floder trong cả một hệ thống
hệ điều hành)
✓ Partition (Phân vùng): Các Topic được chia nhỏ thành các
partitions nhỏ (Có thể cấu hình) Mỗi message được lưu trên
partition sẽ được gán một giá trị theo thứ tự tăng dần được
gọi là offset (Có thể hiểu là số thứ tự lưu message trên
message). Ngồi ra các partition có thể replicate ra nhiều bản,
vẫn là tuân theo master-slave, khi mà master hỏng thì slave
lên thay thế
Mục đích của việc chia partition là để nhiều Consumer có thể
đọc song song dữ liệu của một topic.

25

GVHD: TS. Huỳnh Ngọc Tín