Video học lập trình mỗi ngày

Đây là bài viết thứ 3 trong Series: Xây dựng SA cho app xxxx_CHAT

Hãy nhìn vào thực tế một Group có 10.000 thành viên thì việc khi userX gửi một tin nhắn đến GROUP này, lúc này giả sử có 80% đang online giờ cao điểm có nghĩa rằng một tin nhắn sẽ được lưu vào box của mỗi thành viên, đồng nghĩa với việc là lưu 8.000 lần với một tin nhắn đến.

Vậy có cách nào giảm I/O trong MySQL hay không nếu bạn là một SA. Hãy xem cách một...

Ý tưởng xây dựng xxxx_CHAT

Đây là bài viết thứ 3 trong Series: Xây dựng SA cho app xxxx_CHAT thay thế cho Telegram vì Telegram sẽ cấm ở Việt Nam.

Tất nhiên chỉ là ý tưởng, rất khó có thể thay thế tượng đài như Telegram, nhưng cốt lõi chúng ta cần phải xây dựng được những chức năng cần thiết nhất ví dụ, đảm bảo tin nhắn tới mục tiêu nhanh nhất,message không bị mất, message không bị duplicate, message được lưu trữ tối ưu và mã hoá e2e tốt nhất có thể.

Nói chung chúng ta chỉ làm cách tốt nhất có thể trong năng lực của TEAM.

Đó chính là mục tiêu của Series lần này. Bạn có thể xem qua các bài viết trước liệt kê dưới đây.

1 - UserX Online và Offline làm sao bạn bè và Groups có thể thấy status nhanh nhất có thể

2 - UserX login thành công làm sao lấy dữ liệu Friends và Groups một cách NHANH NHẤT

3 - Group có N thành viên, khi UserX nhắn tin thì nên save một table hay mỗi thành viên có Box riêng?

4 - Kịch bản mỗi thành viên đều có Box riêng làm sao tối ưu dung lượng lưu trữ và write ratio trong MySQL - Bài viết này.

Kịch bản nhắn tin GROUP - Dung lượng lưu trữ MySQL

Như ở bài trước khi có hai kịch bản khi một User (X) nhắn tin đến một GROUP (A). Tạm thời tôi sẽ ký hiệu là X -> msg -> A chính là UserX nhắn tin tới Group A. Trong đó A có 6 members bao gồm [X, 1, 2, 3, 4, 5] với X là người tạo GROUP. OK.

Với 2 kịch bản ở bài trước về cách lưu trữ tin nhắn khi X send msg.

1 - Kịch bản một đó chính là 6 members trên sẽ sử dụng chung một BOX.

2 - Kịch bản hai chính là 6 members trên sẽ sử dụng riêng mỗi người một BOX.

Ở đây sẽ có hai luồng chính kiến trong MEMBER mà chúng ta đã xem. Hai kịch bản đều có ưu và nhược, nhưng chúng ta sẽ chọn kịch bản hai như thống nhất ở bài trước.

Vì vậy hôm nay bài viết này sẽ nói về tối ưu kịch bản hai về IO và Lưu trữ tin nhắn GROUP

Mỗi thành viên trong GROUP có Box riêng

Trước tiên kịch bản mỗi member có Box riêng thì đã chuyển hoá thành một kịch bản thực tế trong bài này : Solution Architecture: LƯU TỐI ƯU dữ liệu Messages CHAT GROUP với 10.000 member trong Group thế nào? tôi khuyến khích bạn xem nó, mặc dù nó mất 20 phút của các bạn, nhưng tôi đã mất 3 tiếng để hoàn thành nó.

Tiếp thepo hãy xem và suy nghĩ: X -> msg = 'Hey everyone, who is up for a beer tonight?' -> Athì lúc này, trong A có 2 user2 đang Offline đó là 4, 5. Về nguyên tắc tại thời điểm này, những User online thì sẽ chưa cần thiết lưu tin nhắn trong box của họ, và chỉ những user đang offline sẽ lưu tin nhắn.

Và khi họ online trở lại thì sẽ PULL data và khi PULL thành công thì sẽ xoá dữ liệu trong Box đi... Thì như vậy chúng ta có như sau khi X nhắn tin.

Xem thêm về PULL vs PUSH công nghệ cốt lõi: Push or Pull ngăn xếp công nghệ nào được FACEBOOK và INSTAGRAM lựa chọn phát triển NEWS FEED?

-- Update the member count in the G tbale
UPDATE `xxxx_groups` SET `grp_member_count` = 5 WHERE grp_id = 1;


-- user_1 send msg: "Hey everyone, who is up for a beer tonight?"

INSERT INTO `xxxx_offline_msgs` (`om_user_id`, `om_group_id`, `om_msg_id`, `om_sender_id`, `om_msg_detail`) VALUES
(4, 1, 'uuid-abc-123', 1, 'Hey everyone, who is up for a beer tonight?'),
(5, 1, 'uuid-abc-123', 1, 'Hey everyone, who is up for a beer tonight?');

Ta thấy User4, và User5 sẽ được write tin nhắn vào box.... Giả sử mỗi tin nhắn là 2kb và nhóm đó có N thành viên đang Offline, như vậy chúng ta có 2 kb * N = Dung lượng lưu trữ.

Quá nhiều vấn đề được nói ở trường hợp này, và đã để cập ở bài viết này LƯU TỐI ƯU dữ liệu Messages CHAT GROUP với 10.000 member trong Group thế nào?. Bạn hãy xem nó.

Việc WR (Write Ratio) tỷ lệ ghi quá cao là một điểm trừ khi lập trình trong DBS - MYSQL. Và thứ hai là Dung lượng lưu trữ không tốt dẫn đến data phình to ra nhanh chóng. Cách này không ổn.

Chúng ta sẽ đi cách thứ 2...