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

Sau khi một user login thành công, để người dùng có sự trải nghiệm mượt mà (như PULL list Friends, Groups) thì các lập trình viên luôn phải tối ưu hiệu suất thông qua nhiều cách, trong đó thuật toán mà họ trải nghiệm đóng góp rất quan trọng cho việc cải thiện song song với đó là cơ sở hạ tầng luôn hỗ trợ đắc lực. Hôm nay chúng ta nói về điều đó.

Xem thêm: Tối ưu hoá hiệu suất 10.000.000 dữ liệu MYSQL Phân Trang từ 7s còn 1s

Bạn có biết rằng khi open APP lên thì dữ liệu đã có ở đó, hầu như latency rất thấp, và có thể không truy vấn server để lấy các dữ liệu như danh sách bạn bè, danh sách chat Group. Để hình dung cho dễ thì kịch bản sẽ như thế này.

Kịch bản khi User login

Nếu user A có 5000 người bạn, và có 200 Groups chat. Hãy tượng tượng rằng khi A -> Login -> Success thì trong quá trình login dưới Backend thì nếu là bạn thì bạn sẽ hành động thế nào? Ở đây sẽ có một vài tình huống.

Lấy dữ liệu khi login thành công rồi return về cho Client A

Ví dụ:

public List<ResponseUserLoginSuccessDTO> login(){
    // 1. loggin sucess

    // 2. List Friends
    List<Friends> friends = zuserRepository.findAll();

    // 3. List Groups
    List<Groups> groups = zGroupRepository.findAll();
}

Xem thêm: Thiết kế triển khai APP CHAT MESSAGE với cấp triệu USERs thay thế Telegram với hiệu suất khả thi

Làm như vậy nhìn vào không sai, sự khác biệt ở code này đó chính là khi dữ liệu x1000 lần thì sẽ nhận ra nhược điểm cần phải điều chỉnh. Không ai cho phép những dữ liệu NÓNG luôn được lục lọi trong layer database. Vì vậy khi nâng cấp họ sẽ tiến hành những bước sau đây.

A -> Login -> Success -> isCache(userA) -> Yes -> getCache() -> Append To Mobile | Browser
                                        |
                                        -> No -> getFriends() -> getGroups() -> setCache() -> Append To Mobile | Browser

Như vậy lần sau khi User A login lại thì sẽ không cần thiết xuống backend để lục lọi dữ liệu nữa mà vẫn có dữ liệu hiện thì. Điều này vừa tiết kiệm ThroughPut cho server vừa giúp UX mượt mà hơn. NHƯNG, sự phức tạp trong khâu lập trình đang đến. Hãy nhìn xem mô hình này sai sót gì, tôi sẽ chỉ ra cái đầu tiên.

Khi đã có Cache thì bạn phải hiểu rằng dữ liệu NÓNG là dữ liệu luôn thay đổi, Vì vậy nếu sử dụng dữ liệu từ Cache thì việc một user thay đổi avt, slogan, status liên tục thì nếu sử dụng bạn sẽ SAI. Ví dụ

List Friends -> userA 

u1 -> slogan -> love you 0
u2 -> slogan -> love you 1
u3 -> slogan -> love you 2
u4 -> slogan -> love you 3
...
u5000 -> slogan -> love you 5000

Khi Cache thì ok, nhưng nếu u4999 -> changeStatus() -> hate you 4999 thì làm sao user A làm sao biết u4999 đã bị thay đổi mà cập nhật...

Nếu bạn chưa hình dung được kịch bản trên cũng như chưa biết có bao nhiêu cách tối ưu hoá thì có thể dừng tại đây... Câu trả lời ngay dưới bài viết này

Tối ưu hoá tiết kiệm dung lượng thế nào?

Như thường lệ đây là kịch bản + thực hành + tối ưu: Giải mã lưu lượng PULL hàng tỷ dữ liệu khi user LOGIN trong app Tiktok, Instagram với BackEnd