#tranquochuy #wecommit #wecommit100x
Thiết kế hệ thống mạng xã hội 200tr Users – System Design | Trần Quốc Huy – Wecommit
Các nội dung chính trong Video này:
0. Mở đầu.
0,5. Mục tiêu
1. Tối ưu thiết kế hệ thống cho Mạng xã hội.
1.1. Mô tả hệ thống đang xử lý.
1.2. Các bước tư duy và tối ưu thiết kế hệ thống.
1.2.1. Khó khăn lớn nhất cần xử lý.
1.2.2. Phân loại người dùng.
1.2.3. Tối ưu tiến trình Timeline Service.
1.2.4. Giảm tải cho Database.
1.2.5. Tóm tắt thiết kế & phân tích trường hợp 200M USERS ONLINE.
1.2.6. Thiết kế mới.
1.2.7. Tối ưu hơn nữa.
2. Đúc kết công thức thiết kế hệ thống.
3. Kết thúc và phần System Design tiếp theo.
Ghi chú: Bạn có thể tham gia hành trình trở thành Top 1% những lập trình viên thành công nhất cùng tôi bằng cách đăng ký tham dự chương trình Từ điển tối ưu 100x hiệu năng.
Trong chương trình này, bạn sẽ thu được các giá trị như sau:
Cực kỳ tự tin dù ở bất kỳ công ty nào.
Nổi bật, có năng lực (không phải chỉ ở mỗi chuyên môn mà nhiều khía cạnh)
Tăng kinh nghiệm vù vù từ nhiều bài toán thực tế (cách đặc biệt của tôi).
Trở thành con người quyết liệt trong hành động, làm việc có chiến lược.
Năng lực tối ưu cơ sở dữ liệu của bạn sẽ vượt trội so với hàng nghìn lập trình viên khác. Bạn sẽ thuộc Top 1% những người giỏi nhất.
Xem chi tiết chương trình của tôi ở đây:
Bạn có thể xem các dự án mà tôi đã trực tiếp thực hiện tại đây:
🎯 Một số Video khác bạn có thể xem
Bí mật TOP 1% những lập trình viên giỏi nhất | Trần Quốc Huy Wecommit :
Thiết kế hệ thống Search Engine xử lý 100 tỷ Web Page (Google, Bing…) | System Design Wecommit:
Cách Quora thiết kế cơ sở dữ liệu để đáp ứng 400 triệu người dùng:
Bí quyết tìm lái xe của Uber:
Hiểu toàn bộ kiến thức về PostgreSQL trong 1h30 phút:
Học SQL Server trong 60 phút :
Học MongoDB trọn vẹn trong 1 giờ 30 phút:
Tìm hiểu về Vector Database – loại Database giúp Generative AI bùng nổ:
⭐️N️ội dung⭐️
⌨️ (00:00:00) 0. Mở đầu.
⌨️ (00:02:13) 0,5. Mục tiêu
⌨️ (00:04:16) 1. Tối ưu thiết kế hệ thống cho Mạng xã hội.
⌨️ (00:04:22) 1.1. Mô tả hệ thống đang xử lý.
⌨️ (00:11:00) 1.2. Các bước tư duy và tối ưu thiết kế hệ thống.
⌨️ (00:11:05) 1.2.1. Khó khăn lớn nhất cần xử lý.
⌨️ (00:13:17) 1.2.2. Phân loại người dùng.
⌨️ (00:18:09) 1.2.3. Tối ưu tiến trình Timeline Service.
⌨️ (00:26:13) 1.2.4. Giảm tải cho Database.
⌨️ (00:30:13) 1.2.5. Tóm tắt thiết kế & phân tích trường hợp 200M USERS ONLINE.
⌨️ (00:36:47) 1.2.6. Thiết kế mới.
⌨️ (00:47:23) 1.2.7. Tối ưu hơn nữa.
⌨️ (00:59:17) 2. Đúc kết công thức thiết kế hệ thống.
⌨️ (01:09:27) 3. Kết thúc và phần System Design tiếp theo.
📱 Nếu bạn muốn liên hệ với tôi:
Linkedin:
Facebook:
#wecommitxtop1percent #mysql #toiuu100x #tranquochuy #wecommit #databasedesign #databaseperformance #databasetutorial #algorithm #datastructureandalgorithm #systemdesignwecommit #toiuucosodulieu #thietkecosodulieu #thietkehethong #toiuusql #cautrucdulieuvagiaithuat #postgresql #postgres #postgresqltutorial #databasetutorial #databasetutorials #laptrinhvien #cntt #systemdesignwecommit #systemdesign #system #twitter #socialmedia #mangxahoi
đỉnh quá 2 anh ơi
bài hay a ơi
có 1 vấn đề mình không rõ lắm. Secondary database lưu trữ những dữ liệu gì, khác biệt gì với primary database, nó dc cập nhật lúc nào với tần suất ra sao. Nếu nó cập nhật cùng tần suất với primary database thì chẳng phải nó cũng sẽ trở thành điểm nghẽn chồng chéo đọc ghi hay sao.
quá hay anh ơi, thanks
2ông toàn giả sử – thực tế là phải đặt log cho flow activities của system. Rồi off. Cache…. Toàn giả xử thế. Đặt log thực tế để biết chính xác tải nhiều chổ nào 2 ông ạ. Làm 1 lần ăn mãi thì đói ấy. 2 shop bán hàng luxury và tạp hóa hành vi người dùng khác nhau ạ
Bảo anh H nổ bộ 4T anh ấy mần cho
Bài toán hơi thiếu thực tế:
– KOL post bài. -> noti đến user. 30% user vào xem thay vì gen async để scale stable thì query trực tiếp tải tăng vọt. hmzz
– Interval gen feed 5p. Gặp issue y hệt bên trên nếu ng dùng không online nhận đc noti vào xem. 5p quá ít. rất ít người tắt fb dưới 5p mở lại liên tục cả
– Consistency user vừa xem thoát ra nhận noti vào xem -> không gen lại -> không thấy bài KOL. hmzz
– Social platform: Tỉ lệ inactive -> rất lâu hoặc còn lâu mới vào rất nhiều so với online. chia theo active time để xử lý sẽ tốt hơn nhiều. priority queue
– Cassandra dùng LSM-tree nên performance write tốt. nhưng điểm yếu là gì – schema design ntn – query cho các case ra làm sao. Tỉ lệ read lớn hơn write rất nhiều ở social platform.
– Platform ăn tiền chính là thuật toán gen feed và quảng cáo. 🙁 Không thể làm là người dùng đi query KOL để lấy feed đc.
…..
Idea của mình khi làm phần này:
– Priority gen feed cho người dùng. rất ít người dùng active có thể phần lớn là die user
– Sharding và apply cluster cho các phần khi scale ( database / cache … )
…..
Video cũng rất công phu. Liệt kê các keyword những người học về design nên note lại và research. Xem thêm các video interview system design.
Cảm thấy cách thiết kế gôm nhóm on/off, inactive và phân loại user KOL và user thường ko thực tế cho lắm. MXH lớn không thể nào ưu tiên số lượng ít user KOL hơn phần đông là user thường
Phân loại theo điểm tương tác thực tế hơn là on/off.
Bài toán này vẫn phải xem coi những social platform lớn họ làm như thế nào. Còn kiểu đoán mò kiểu này thì khó có thực tế.
Em rất thích xem video thiết kế hệ thống kiểu này, nhưng mà không biết từ thiết kế ra code thực tế như thế nào, mong anh Huy làm chi tiết thêm.. ❤❤
Tks anh 🎉🎉🎉
em thấy đi từ functional/non-functional -> high level design sẽ dể hiểu hơn ạ.
càng làm nhiều big data, xong càng tìm hiểu càng thấy nó hay.
Cảm ơn 2 ae, video hay quá❤
Hay quá Nam ơi ❤
Video hay quá bạn ơii ❤❤