从小白到架构师：万字长文 | 社交媒体应用系统设计

移动互联网时代，社交媒体应用彻底改变了我们联系和共享信息的方式。这些平台在幕后处理庞大的用户群、数据存储和实时交互。

在本文中，我们将深入探讨如何设计一个可扩展且高性能的社交媒体应用系统。我们将探讨关键组件、流程图、功能需求以及容量规划策略，这些都是构建成功社交媒体平台所必需的。

上图是整个系统的架构图，每个服务或模块这里先简单介绍：

1. API Gateway：作为客户端流量通往后端服务的入口，处理所有的API请求，路由请求到相应的服务、身份验证、负载均衡。
2. Follower Service：处理用户关注和被关注的关系。
3. Profile Service：管理用户的个人信息和资料。
4. Post Service：处理用户发布内容（帖子）。
5. URL Shortener：缩短URL地址，可能用于分享帖子链接。
6. User Feed Service：：生成和管理用户的动态（feed），包括用户关注的人的新帖通知。
7. Comment & Like Service：管理用户对帖子进行的评论和点赞。
8. Chat Service：处理用户之间的实时聊天功能。
9. Search Service：提供搜索功能，允许用户搜索其他用户或内容。
10. Load Balancer (LB)：分发请求到多个后端服务，确保系统的高可用性和负载均衡。
11. CloudFront (CDN)：用于缓存和快速访问存储在S3中的媒体文件。

要求

功能要求

功能需求定义了系统或软件应用程序应该做什么来满足用户的需求。以下是基于社交媒体系统的功能需求：

• 发布帖子
• 点赞、评论他人帖子
• 关注/取消关注其他用户
• 搜索用户
• 用户Feed流
• 聊天功能

非功能性需求

非功能需求指定了系统的质量，而不是具体的功能。以下是一些非功能需求：

• 低延迟
• 高可用性

数据模型设计

用户管理

用户数据表(user_data)

该表将存储每个用户的基本信息，例如其姓名、生日、描述、用户名、电话号码和个人资料图片。“id”属性作为主键，用于唯一标识表中的每个用户。

CREATE TABLE user_data (
    user_id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    password VARCHAR(255) NOT NULL,
    user_bday DATE,
    user_desc TEXT,
    user_name VARCHAR(255) NOT NULL,
    user_phone VARCHAR(20),
    user_pic VARCHAR(255)
);

* user_id：每个用户的唯一标识符（主键）。
* name：用户的全名。
* user_bday：用户的出生日期。
* user_desc：用户的描述或简历。
* user_name：用户选择的用户名（应该是唯一的）。
* user_phone：用户的联系电话。
* user_pic：用户个人资料图片的文件路径或引用。  

用户-关注者表(user_follower)

对于“user_follower”表，它表示用户和他的粉丝/关注者之间的关系，它主要有以下字段：

CREATE TABLE User_Followers (
    id INT AUTO_INCREMENT PRIMARY KEY,
    follower INT,
    following INT,
    FOREIGN KEY (follower) REFERENCES user_data(user_id),
    FOREIGN KEY (following) REFERENCES user_data(user_id)
);


* id：表中每个条目的唯一标识符（主键）。
* follower：引用关注者的用户的外键（引用 user.id）。
* following：引用被关注用户的外键（引用 user.id）。

“user_follower”表中的每条记录代表一个用户关注另一个用户。“follower”字段引用正在关注的用户(粉丝)，“following”字段引用被关注的用户。“id”字段作为主键，唯一标识表中的每条记录。

帖子管理

帖子表(post_data)

对于帖子管理，“帖子”表代表用户发布的帖子，具有以下属性：

CREATE TABLE post_data (
    post_id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT,
    content TEXT,
    date_posted DATE,
    media VARCHAR(255),
    likes INT,
    FOREIGN KEY (user_id) REFERENCES user_data(user_id)
);

* post_id：每个 帖子的唯一标识符。
* content：帖子文本内容。
* media：FileField，允许用户上传与帖子相关的媒体（例如图像、视频）。
* user_id：引用发布帖子的用户的 ForeignKey。这在 user_data 和 post_data 表之间建立了一对多关系，其中一个用户可以发布多篇帖子。这意味着单个 user_id 可以与多篇帖子相关联，但单个 post_id 不能与多个 user_id 相关联。
* likes：一个 ManyToManyField，表示对帖子的喜欢。它在 Post 和 User 表之间建立多对多关系，允许多个用户喜欢一个帖子，并且一个用户可以喜欢多个帖子。

评论表(comment)

“评论”表代表用户对特定帖子发表的评论，评论表一般具有以下字段：

CREATE TABLE Comment (
    comment_id INT AUTO_INCREMENT PRIMARY KEY,
    post_id INT,
    user_id INT,
    comment TEXT,
    created_date DATE,
    FOREIGN KEY (post_id) REFERENCES post_data(post_id),
    FOREIGN KEY (user_id) REFERENCES user_data(user_id)
);

* comment_id：每个评论的主键。
* comment：评论内容。
* created_id：一个 DateTimeField，表示评论创建的日期和时间。
* user_id：引用发表评论的用户的外键。User 表和 Comment 表之间存在一对多关系，其中一个用户可以有多条评论。这里，单个 user_id 可以与多条评论相关联，但单个 commet_id 不能与多个用户相关联。
* post：与评论相关联的帖子，引用帖子表的主键（foreign_key）。这在帖子和评论表之间建立了一对多的关系，其中一个帖子可以有多条评论。

聊天管理

聊天消息(chat_message)

对于聊天管理，“chat_message”表代表对话线程内的单个消息，其主要字段如下：

CREATE TABLE chat_message (
    id INT AUTO_INCREMENT PRIMARY KEY,
    thread_id INT,
    user_id INT,
    message TEXT,
    timestamp DATE,
    FOREIGN KEY (thread_id) REFERENCES Thread(thread_id),
    FOREIGN KEY (user_id) REFERENCES User_Data(user_id)
);

* id ：每个聊天消息的主键。
* thread_id：引用 thread 模型的 ForeignKey。它表示消息所属的线程。 
* user_id：引用 user_data 的 ForeignKey。它代表发送消息的用户。
* message：存储消息文本内容的 CharField。
* timestamp： 存储消息创建日期和时间的 DateField

线程表(thread)

“thread”表代表两个用户之间的对话线程：

CREATE TABLE thread (
    thread_id INT AUTO_INCREMENT PRIMARY KEY,
    user1 INT,
    user2 INT,
    timestamp DATE,
    FOREIGN KEY (user1) REFERENCES User_Data(user_id),
    FOREIGN KEY (user2) REFERENCES User_Data(user_id)
);

* thread_id：每个线程的主键。
* user1：引用 User 模型并代表参与对话的用户之一的 ForeignKey。
* user2：引用 User 模型并代表参与对话的其他用户的 ForeignKey。 
*