CÁC NGHIÊN CỨU LIÊN QUAN
DESIGN A SYSTEM NOTIFICATION
Hệ thống thông báo đã trở thành một tính năng thiết yếu trong hầu hết các ứng dụng hiện nay, cung cấp cho người dùng thông tin quan trọng như tin tức nóng, cập nhật ứng dụng và sự kiện Điều này giúp người dùng luôn được cập nhật và không thể thiếu trong cuộc sống hàng ngày.
Notification không chỉ đơn thuần là thông báo trên điện thoại, mà còn có nhiều loại khác nhau Có ba loại chính của notification mà người dùng cần biết.
✓ Mobile Push Notification (Bắn thông báo cho các app)
Hình ảnh 2: Ảnh minh họa các loại notification
1.1 Hiểu vấn đề và thiết lập phạm vi thiết kế
Xây dựng một hệ thống gửi hàng triệu thông báo mỗi ngày không phải là điều dễ dàng, mà đòi hỏi sự hiểu biết sâu sắc về hệ sinh thái thông báo Các câu hỏi và câu trả lời sẽ giúp mọi người có cái nhìn rõ ràng hơn về quy trình này.
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?
Hệ thống real-time nhằm mục đích gửi thông báo đến người dùng nhanh nhất có thể Tuy nhiên, trong trường hợp khối lượng công việc lớn, một chút chậm trễ có thể được chấp nhận.
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, ngoà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
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
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"
- 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 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
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
Mặc dù các công ty có khả năng thiết lập máy chủ email riêng, họ vẫn thường chọn sử dụng dịch vụ email thương mại Sendgrid và Mailchimp là hai trong số những dịch vụ phổ biến nhất, cung cấp tỷ lệ phân phối cao và phân tích dữ liệu hiệu quả hơ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 bảng cơ sở dữ liệu giúp đơn giản hóa việc lưu trữ thông tin Email và số điện thoại được lưu trong bảng người dùng, trong khi mã thiết bị di động được lưu trong bảng thiết bị Một người dùng có thể sở hữu nhiều thiết bị, do đó cần gửi thông báo đến tất cả các thiết bị của người dùng.
Hình ảnh 5: Ảnh minh họa table database
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
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
Dịch vụ thanh toán có thể gửi email nhắc nhở khách hàng về hạn thanh toán, trong khi các trang web mua sắm thông báo cho khách hàng qua SMS về việc giao hàng của họ sẽ diễn ra vào ngày mai.
✓ Notification system: Trung tâm của việc sending/receiving notification
Dịch vụ bên thứ ba đóng vai trò quan trọng trong việc gửi thông báo đến người dùng Khi tích hợp với các dịch vụ này, cần chú ý đến khả năng mở rộng của hệ thống Một hệ thống linh hoạt và dễ dàng điều chỉnh sẽ đảm bảo hiệu quả trong việc quản lý thông báo.
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
Hệ thống thông báo xử lý tất cả các yếu tố liên quan đến thông báo đẩy trong một máy chủ, điều này tạo ra thách thức cho việc mở rộng cơ sở dữ liệu, bộ nhớ đệm và quản 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
Việc xây dựng các trang HTML và chờ phản hồi từ bên thứ ba có thể tốn nhiều thời gian Xử lý mọi thứ trong một hệ thống có nguy cơ gây quá tải, đặc biệt trong 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
✓ 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
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,…
Hàng chờ tin nhắn (Message queues) giúp loại bỏ sự phụ thuộc giữa các thành phần trong hệ thống Chúng hoạt động như một đệm khi có quá nhiều thông báo được gửi đi, với mỗi thông báo được gán cho một hàng chờ riêng biệt Nhờ đó, sự cố ngừng hoạt động của một dịch vụ bên thứ ba sẽ không ảnh hưởng đến các thông báo khác trong hệ thống.
✓ 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
1.3 Design deep dive (Chi tiết thiết kế)
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 yếu tố quan trọng trong hệ thống thông báo là đảm bảo không mất dữ liệu Dù thông báo có thể bị trì hoãn hoặc sắp xếp lại, nhưng không bao giờ được phép mất đi Để đáp ứng yêu cầu này, hệ thống thông báo duy trì dữ liệu thông báo trong cơ sở dữ liệu và thực hiện cơ chế thử lại.
Hình ảnh 8: Ảnh minh họa notification system duy trì notification data trong 1 database
✓ Will recipients receive a notification exactly once?
Câu trả lời là không, vì mặc dù notification thường được gửi chính xác một lần, nhưng bản chất phân tán có thể dẫn đến tình trạng trùng lặp Để giảm thiểu sự trùng lặp này, cầ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, dựa trên một logic loại trừ đơn giản.
Khi nhận thông báo sự kiện lần đầu, cần kiểm tra xem thông báo đó đã được đọc trước đó hay chưa thông qua việc kiểm tra ID sự kiện Nếu đã được đọc, thông báo sẽ bị loại bỏ Ngược lại, nếu chưa đọc, chúng ta sẽ gửi thông báo cho người đọc, giải thích lý do tại sao không thể đảm bảo giao hàng chính xác một lần, chẳng hạn như trong trường hợp thông báo giao hàng.
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ế
APACHE KAFKA
Hệ thống Subscribe của YouTube cho phép người dùng theo dõi các kênh yêu thích Khi bạn subscribe một kênh, mọi hoạt động mới như video hay trạng thái sẽ được phân loại và hiển thị ở những vị trí khác nhau Người dùng chỉ cần xem hoặc đọc các nội dung mới này một cách dễ dàng.
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)
2.2 Tại sao sử dụng Kafka?
Kafka có khả năng xử lý đồng thời nhiều producers, bất kể các clients sử dụng nhiều topic khác nhau hay cùng một topic (như bấm nút, đăng trạng thái, nhắn tin, ) Điều này tạo ra một hệ thống lý tưởng để tổng hợp dữ liệu từ nhiều frontend.
Kafka cho phép nhiều consumer đọc các message mà không gây ảnh hưởng lẫn nhau Nhiều consumer trong Kafka có thể hoạt động như một nhóm, chia sẻ một stream và đảm bảo rằng toàn bộ nhóm xử lý mỗi message chỉ một lần.
Kafka có khả năng lưu trữ tin nhắn lâu dài, cho phép consumer không cần phải hoạt động theo thời gian thực Các tin nhắn được ghi vào ổ cứng theo các quy tắc nhất định, và các tùy chọn này có thể được cấu hình theo từng topic Điều này cho phép các luồng tin nhắn khác nhau có thời gian lưu giữ khác nhau, tùy thuộc vào nhu cầu của consumer.
Nếu consumer bị chậm hoặc gặp rối loạn trong quá trình truyền, dữ liệu sẽ không bị mất, điều này cho phép thực hiện bảo trì trên consumer mà không lo ngại về việc mất mát thông tin.
Các ứng dụng offline có thể tạm dừng mà không lo lắng về việc mất mát hay sao lưu tin nhắn Consumer vẫn có thể dừng lại và các tin nhắn sẽ được lưu trữ trong Kafka, cho phép họ khởi động lại và tiếp tục xử lý các tin nhắn đang dang dở.
Khả năng mở rộng linh hoạt của Kafka cho phép xử lý hiệu quả mọi khối lượng dữ liệu Người dùng có thể khởi đầu với một broker duy nhất như một thử nghiệm, sau đó tiến tới một cluster nhỏ với 3 brokers, và cuối cùng mở rộng lên một cluster lớn hơn với hàng trăm ngàn brokers.
(tăng lên theo lượng data phải xử lí)
Tất cả các tính năng kết hợp của Apache Kafka tạo nên một hệ thống messaging theo mô hình publish/subscribe với hiệu suất xuất sắc, đặc biệt khi phải xử lý 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
Đơn giản, một message được biểu diễn dưới dạng mảng byte với cấu trúc key-value Các key này đóng vai trò quan trọng khi ghi message vào các phân vùng, đảm bảo rằng những message có cùng key sẽ luôn được lưu trữ trong các phân vùng tương tự 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)
Partitions are segments into which topics are divided, allowing for configurable sizes Each message stored in a partition is assigned a sequential value known as an offset, which indicates its order within the partition Additionally, partitions can be replicated across multiple copies, adhering to a master-slave architecture; if the master fails, a slave can take over seamlessly.
✓ Consumer Group: Được tạo ra bằng cách thêm thuộc tính
Mỗi consumer trong một Consumer Group có cùng "group.id" để đảm bảo rằng mỗi consumer chỉ đọc message từ một partition, từ đó tránh tình trạng hai consumer xử lý cùng một message hai lần Điều này giúp toàn bộ group xử lý tất cả message từ toàn bộ topic một cách hiệu quả.
Hình ảnh 13: Ảnh minh họa Consumer Group cùng nhau hoạt động
Group A có 2 consumer nên mỗi consumer đọc message từ 2 partitions
Group B có 4 consumer nên mỗi consumer chỉ đọc message từ 1 partititon
Hình ảnh 14: Ảnh minh họa luồng đi của Message trong Kafka
✓ Producer publish message vào Topic
Broker lưu trữ tất cả các tin nhắn trong các partition được cấu hình cho một topic cụ thể, đảm bảo rằng các tin nhắn được phân phối một cách cân bằng giữa các partition.
When a user with ID 1 clicks, their action is automatically recorded in partition 1, which is configured for user IDs 1 to 500, and assigned an offset Conversely, a user with ID 501 will have their click recorded in partition 2, designated for user IDs 501 to 1000, and also assigned an offset.
Vậy thì giả sử user id 2 click trước user id 1 thì sao?
Hành động click của user id 2 sẽ được gán offset (0), trong khi hành động click của user id 1 sẽ được gán offset (1) trong partition 1.
When a consumer subscribes to a topic in Kafka, the current offset is provided to that consumer and stored in Zookeeper The message corresponding to this offset is then pulled by the consumer.
✓ Ngoài ra consumer sẽ gửi liên tục request đến Kafka (ví dụ như là 100ms) để pull các về các message mới
✓ Sau khi consumer nhận được message thì sẽ xử lý nó
Phía trên là ứng với single-consumer nhưng thực tế thì Kafka phổ biến hơn với consumer group Và sau đây là Workflow với consumer group:
✓ Producer publish message vào Topic
✓ Tương tự Broker lưu trữ tất cả các message và chia đều cho các partition
MySQL Replication
3.1 Replication là gì? Đầu tiên Replication có nghĩa là “nhân bản" , nghĩa là có một phiên bản giống hệt phiên bản đang tồn tại, đang sử dụng
MySQL Replication là quá trình nhân bản dữ liệu MySQL qua việc sao chép tự động từ một máy chủ master sang một cơ sở dữ liệu slave Quá trình này rất hữu ích cho việc sao lưu dữ liệu, phân tích mà không làm ảnh hưởng đến cơ sở dữ liệu chính, hoặc đơn giản là để mở rộng quy mô Một mô hình phổ biến là cấu trúc master-slave, trong đó có một máy chủ master và nhiều máy chủ slave.
Hình ảnh 15: Ảnh minh họa về mô hình Master-Slave thông thường
Trong đó các request write được thực thi ở Master, server Slave sẽ chỉ được phép thực hiện các request read (read-only replica)
3.2 Vậy Replication hoạt động như thế nào trong
Hình ảnh 16: Ảnh minh họa MySQL hoạt động
Khi cơ sở dữ liệu ở master được sửa đổi, mọi thay đổi sẽ được ghi lại vào tệp Binary Log (Binlog), do luồng client thực hiện các truy vấn sửa đổi cơ sở dữ liệu.
✓ Slave có 1 luồng được gọi là I/O thread có nhiệm vụ đọc Binary log từ đó ghi nó vào một tệp - Replay Log
✓ Ngoài ra Slave cũng có một luồng khác gọi là SQL thread có nhiệm vụ liên tục đọc Replay Log và áp dụng nó cho các slave server
3.3 Nên dùng lúc nào? Và ứng dụng thực tiễn
MySQL Replication là giải pháp hiệu quả để xử lý tình trạng quá tải của hệ thống cơ sở dữ liệu Tuy nhiên, để mở rộng hệ thống một cách toàn diện, cần xem xét các phương pháp khác nhau.
Có 2 phương pháp chính đó là scale up và scale out
Để xây dựng một máy chủ có khả năng phục vụ nhiều kết nối và truy vấn hơn, giá trị 1/(số kết nối phục vụ) cần phải được tối ưu hóa, với mục tiêu là càng nhỏ càng tốt Có hai phương pháp chính để đạt được điều này.
Để tối ưu hóa hiệu suất máy chủ, việc nâng cấp phần cứng là cần thiết Cụ thể, nếu máy chủ hiện tại sử dụng CPU 4 core và RAM 8GB chỉ có thể xử lý một câu truy vấn, thì nâng cấp lên CPU 8 core sẽ giúp cải thiện khả năng phục vụ Gấp đôi tài nguyên phần cứng sẽ mang lại hiệu quả tốt hơn trong việc xử lý nhiều yêu cầu cùng lúc.
- 16 core , RAM 16GB - 32GB thì có thể phục vụ 2a - 4a câu truy vấn
Để tối ưu hóa ứng dụng và câu truy vấn, chúng ta có thể giảm thời gian lấy dữ liệu từ 5 giây xuống chỉ còn 1 giây, giúp trả lại tài nguyên cho hệ thống nhanh chóng hơn.
Để tối ưu hóa hệ thống, giải pháp hiệu quả là tăng số lượng server và sử dụng các giải pháp cân bằng tải (load balancer) để phân phối truy vấn đến nhiều server Cụ thể, nếu một server có khả năng phục vụ a truy vấn, việc bổ sung thêm 5 server có cấu hình tương tự sẽ cho phép phục vụ đồng thời 5a truy vấn.
Như đã nói trên thì MySQL Replication là một giải pháp giải quyết các bài toán về quá tải hệ thống vậy nó thuộc cách nào trong 2 cách trên?
Scale out, tại sao? Bởi vì với mỗi nhân bản (slave) thì ứng với mỗi server giống với khái niệm scale out đã nêu trên
Sau đây là các bài toán và các ứng dụng thực tế mà MySQL Replication sẽ áp dụng tốt:
✓ Scale Read (Áp dụng cho đồ án)
Thường gặp ở các ứng dụng mà số truy vấn read nhiều hơn write, tỉ lệ tầm 80/20 hoặc hơn
Với Scale Read thì sẽ chỉ có 1 Master instance phục vụ cho read/write Có thể có một hoặc nhiều Slave instance phục vụ cho read
Thường gặp nhất là các trang báo, tin tức, các ứng dụng thương mại điện tử
Một số hệ thống chỉ cho phép một số người như lãnh đạo, quản lý, người làm báo cáo, thống kê và phân tích dữ liệu truy cập vào thông tin, điều này có thể gây ra rủi ro lớn.
• Vô tình chỉnh sửa làm sai dữ liệu ( Có quyền insert, update)
• Vô tình thực thi các truy vấn tốn tài nguyên, thời gian truy vấn làm treo hệ thống
Nên việc làm một máy chủ data report sẽ làm giảm thiểu 2 rủi ro trên
Với kích thước khổng lồ của các cơ sở dữ liệu, việc sao lưu thường xuyên (hàng giờ, hàng phút hoặc thậm chí hàng giây) trở nên khó khăn Do đó, sao lưu theo thời gian thực là một giải pháp bổ sung hiệu quả cho sao lưu offline, cho phép cả hai phương pháp này hoạt động song song nhằm đảm bảo an toàn tối đa cho dữ liệu.
Các ứng dụng thường và nên sử dụng phương pháp này: Các ứng dụng giao dịch tài chính, thanh toán, thương mại điện tử
Replication và backups (sao lưu) có những điểm khác biệt quan trọng Replication thường được coi là tốt hơn một chút so với backups Trong khi backups chỉ cung cấp một “snapshot” của cơ sở dữ liệu tại một thời điểm nhất định, replication duy trì bản sao theo thời gian thực và giúp giảm tải cho các hoạt động đọc và ghi của client Tùy thuộc vào hoàn cảnh, chúng ta có thể lựa chọn sử dụng replication, backups, hoặc kết hợp cả hai để giải quyết các vấn đề liên quan.
Java – Spring Boot
4.1 Giới thiệu svề Spring Boot
Theo số liệu thống kê Top Java Web Frameworks được sử dụng nhiều nhất tính đến năm 2016 từ LZEBELLABS:
Hình ảnh 17: Ảnh minh họa số liệu thống kê Top Java Web Frameworks
Mặc dù chỉ mới ra mắt phiên bản chính thức v1.0 vào năm 2014, Spring Boot đã phát triển mạnh mẽ và hiện đang đứng thứ 2 trong bảng xếp hạng, chỉ sau Framework Spring MVC.
4.2 Vậy Spring Boot là gì? Tại sao phát triển nhanh đến như thế?
✓ Spring Boot là 1 sự sáng kiến lớn trên sự tồn tại của Spring
Framework đến từ nhóm Spring Team
Spring Boot là một framework được phát triển dựa trên nền tảng Spring, giúp đơn giản hóa cấu hình và tăng tốc độ phát triển ứng dụng một cách đáng kể.
✓ Spring Boot cung cấp mặc định các đoạn code và annotation configuration để phát triển dự án Spring trong thời gian ngắn.
4.3 Những lợi thế của Spring Boot
✓ Nó dễ dàng cho việc phát triển ứng dụng dựa trên Spring với Java hoặc Groovy
✓ Nó giảm thiểu thời gian phát triển, tăng năng suất phát triển
✓ Tránh việc phải viết nhiều bản mẫu code, cấu hình Annotaion hoặc XML
✓ Dễ dàng trong việc tích hợp với hệ sinh thái của Spring như: Spring JDBC, Spring ORM, Spring Data, Spring Security
✓ Nó theo cách tiếp cận "Opinionated Defaults Configuration" để giảm effort trong quá trình phát triển
✓ Nó cung cấp các Embedded HTTP servers như Tomcat, Jetty để phát triển và test một cách dễ dàng,
✓ Nó cung cấp công cụ CLI (command Line Interface) cho việc phát triển và test ứng dụng nhanh chóng và dễ dàng từ command line
✓ Nó cung cấp rất nhiều các plugins để phát triển và test các ứng dụng Spring Boot nhanh chóng sử dụng các công cụ Build như Maven và Gradle
✓ Cung cấp nhiều plugins để làm việc với các embedded and in-memory databases
4.4 Tại sao nên sử dụng Spring Boot?
Việc sử dụng Spring Boot giúp lập trình viên tập trung vào việc viết mã hiệu quả hơn, giảm bớt lo lắng về các kỹ thuật lập trình phức tạp như khi sử dụng Node.js.
Spring Boot tích hợp nhiều thư viện và cấu trúc mã nguồn chuẩn mực, giúp lập trình viên không cần lo lắng quá nhiều về chất lượng mã Nhờ đó, họ có thêm thời gian để tập trung vào logic và tính năng của sản phẩm.
Spring Boot là một phiên bản cải tiến đáng kể của Spring, giúp đơn giản hóa nhiều quy trình phức tạp Hơn nữa, việc học và nắm bắt Spring Boot trở nên dễ dàng hơn rất nhiều.
Sau khi nghiên cứu và tìm hiểu các công nghệ liên quan, thì ở chương 3 này sẽ trình bày nội dung cách tiếp cận như thế nào.
Quy trình thu thập thông tin
Để gửi thông báo, cần thu thập mã thiết bị di động, số điện thoại hoặc email của người dùng Khi người dùng cài đặt ứng dụng hoặc lần đầu đăng ký, các máy chủ API sẽ thu thập thông tin và lưu trữ vào cơ sở dữ liệu.
Các bảng cơ sở dữ liệu giúp đơn giản hóa việc lưu trữ thông tin Địa chỉ email và số điện thoại được lưu trong bảng người dùng, trong khi mã thiết bị di động được lưu trong bảng thiết bị Một người dùng có thể sở hữu nhiều thiết bị, do đó cần gửi thông báo đẩy tới tất cả các thiết bị của họ.
Chi tiết luồng đi notification trong hệ thống
(5) APNs or Fireabase Cloud Messaging (FCM)
Khi cần gửi thông báo, server thông báo trong Kafka sẽ truy vấn cơ sở dữ liệu hoặc bộ nhớ cache để lấy thông tin cần thiết như email, số điện thoại và mã thiết bị Sau đó, nó sẽ thiết lập nội dung thông báo và gửi vào hàng chờ cùng với dữ liệu người dùng.
Tiếp theo sẽ có các workers (Consumer của Kafka) pull message liên tục về để xử lý notification (Validate dữ liệu, processing format,…)
Tiếp đến mới bắn lên APNs hoặc là FCM rồi mới tới màn hình thông báo của thiết bị của người dùng.
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
THỰC NGHIỆM, ĐÁNH GIÁ
Kết luận
Sau quá trình thực hiện đề tài, mặc dù chưa hoàn thiện hết, em đã đạt được các kết quả sau:
✓ Hiểu được cách notification system hoạt động như thế nào
✓ Hiểu được về các công nghệ liên quan tới thực tế như là Kafka
✓ Trau dồi được thêm các kiến thức cơ bản chuẩn bị hành trang cho việc làm sau này
Hướng phát triển
Trong quá trình thực hiện đề tài, mặc dù chưa đạt được tất cả các mục tiêu đề ra, tôi nhận thấy hệ thống vẫn còn nhiều thiếu sót và tồn tại nhiều vấn đề thực tiễn Tuy nhiên, tôi tin rằng hệ thống có tiềm năng để phát triển và hoàn thiện hơn nữa.
✓ Tăng trải nghiệm người dùng qua các template chứ không chỉ là tiết kiệm thời gian hay là đặc trưng của notification như là custom alert
✓ Lựa chọn khung giờ sử dụng của người dùng để gửi, tránh việc gửi vào giờ người dùng không thể đọc hay là đang ngủ
✓ Có một hệ thống giám sát quá trình notification hoạt động tránh các rủi ro không đáng có
Thu thập các thông báo mà người dùng yêu thích và thường xuyên sử dụng để cung cấp phân tích chính xác cho các chủ doanh nghiệp sở hữu ứng dụng tin tức.