Things about IT development – Talk about IT technology and project management

以数据库为中心进行架构设计

互联网项目，除了数据库组建，还经常会用到Cache(如：redis or memcache)，MQ（如：kafka or RocketMQ）。无论有多少个组件，一定要以数据库为中心，提供数据访问。所有的Cache数据，都是数据库内数据的拷贝。

核心就两条：

1.以数据库的数据为准

2.如果数据跟数据库不一样，参考第一条

切忌：有时候写数据库，有时候写Cache，有的以db为准，有的读Cache为准。后果是：会经常性出现数据不一致。

程序读取数据的规则：

1.先从Cache读取，如果存在，直接返回；如果不存在，就从db中读取，并写入Cache。
2.如果数据更新，通常是直接更新数据库，然后让缓存失效（也可以直接更新Cache）
3.极少数业务需求（例如：秒杀活动）时间短，并发量极大，可以直接读写Cache，然后等活动结束再写回db。

内部项目的数据分享策略：通过从库+视图+权限控制，提供有限的数据访问权限。从库是独立于主业务之外的从库，只提供内部其它项目使用，所以不会影响主业务的性能；用视图可以控制哪些字段可以被访问，也方便对数据进行过滤和排序。

对外提供数据的策略：通过Rest API+权限控制提供数据访问。外部应用通过参数请求API获取需要的数据，加上白名单机制，以及鉴权规则来对访问进行记录和监控。

如果担心数据库的性能问题，请参考：

支撑10亿用户的技术方案（思路篇）

支撑10亿用户的技术方案（细节篇）

technology|技术中文

程序员的进阶思维

这篇文章写给有1年以上工作经验的开发人员。

检验每一个输入参数的合法性

考虑逻辑判断的边界条件

对代码进行合理的封装，提高代码的复用性

站在用户的角度考虑问题

对于游戏产品中出现的兑换码，用户输入兑换码可以领取奖励。为了方便用户的识别，兑换码中，我们需要去掉哪些容易混淆的字符，如：数字1和字母I, 数字9和字母g。

对于脚本代码，重复执行也不会出现问题

在线上运行时间足够久，我们可能会遇到需要批量修复线上数据的需求。通常我们需要写脚本来进行处理，这个时候一定要考虑到这样的问题：脚本执行可能会中断，或者运维不小心多次执行这个脚本。

学会异常情况：异常情况可考虑加入日志跟踪

对于上线运营的产品，对于异常情况进行汇总分析&重要异常的报警，可以让开发团队先于客服团队发现问题，避免问题上报到高层领导并由高层施压处理问题。高层频繁收到问题的汇报，是研发团队失信的开始。

站在运维部署的角度思考问题

举个最简单的例子：数据库的配置需要放在运维控制的配置文件里，生产环境的数据库配置信息是不能放在代码的配置文件中。

要想成为一名优秀的后端开发工程师，必须是要熟悉运维的，从熟悉linux系统开始，学会用户权限、磁盘管理、网络配置、防火墙、端口等基础知识，然后在单台服务器上下载、编译、按照各种工具，搭建数据库、缓存、web server等基础设置，最后还需要懂得如何搭建集群、监控、备份、安全等。

对新老版本的兼容性

例如：对于某个API，需要调整它的参数格式。这个时候通常是新加一个API，前端的老版本还是访问老的API，新版本访问新的API，等到确认所有的用户都更新到老版本，才可以把老的API下线。

安全性

API中只返回必要的信息，非必要信息不必返回，更不能向他人暴露用户的隐私信息。

对于代码执行结果的线上跟踪方案

笔者在实际工作中遇到了一个需求：原来的用户表的主键是username，其它用户相关的信息都是用username进行关联的。后来发现用户有修改username的需求，这样就需要加入数字uid，并对关联的表数据用id进行重新关联。

分支用途详解

dev 分支是开发用的
qa分支是测试用的
uat是的在发布之前给内部人员（运营人员，或者老板们）使用的
staging是用于压测的环境，上线前的最后验证
master是用于生产环境部署的，是稳定的版本；部署的时候可以打tag，如：V0.1
还有两个目录： feature, bugfix。 feature是用于新功能开发，bugfix是修复bug的分支。

开发的流程描述

从dev拉取代码分支进行开发，开发完以后要merge request到dev，这个时候，会进行代码的code view
dev是开发的前后端联调用的，开发者自己测试没问题了之后，就可以由前后端的lead merge到qa，qa人员就可以基于qa分支测试（转测）
qa测试如果发现问题了，提交bug单给开发人员，开发人员在自己的feature分支开发修改（或者是创建bugfix分支修改），最后还是要回到第1步的流程；如果qa测试没问题，就继续
把qa测试成功的代码merge到uat供内部体验（可以省略本步骤）。如uat测试有问题，则反馈到产品，产品完善需求再从头开始开发流程。
把uat验证过的代码merge到staging，可以进行压力测试，也可以作为production环境上线的预演。
如果staging环境预演成功，就可以把代码merge到master进行上线了。这时候可以基于master分支打tag，如：V0.1.2

CICD

CICD的意思是：持续集成，持续部署。一般来最好做到自动部署：dev代码有更新，自动部署到dev环境；qa有更新，自动部署到qa；uat和stagingg都是如此；prodcution环境需要devops手动部署。

版本定义的规则

可以在开发之前加一下产品需求的定义和版本的规划，在打tag的时候，就是对应的版本号了

产品版本号的管理建议：

1.一个完整的版本定义为V1.0，前面阶段性的版本用V0.1, V0.2这样的；

2. 线上版本的bug修复版本定义为: V0.1.1, V0.1.2 这样的。

3.版本号跟jira上的版本定义一致，跟发布版本的tag一致

management|管理中文

开发流程细节解读

1.蓝色部分主要是产品团队负责细化，但在技术评估环节，需要开发团队的lead参与。产品团队需要定义好版本计划、开发细节、时间点，负责人，这是整个流程中最重要的环节。

2.对于功能需求的细化，产品团队最好能提供完整的需求文档以及线框图。有了线框图之后，开发团队就可以进行开发了，等到UI完成了再进行替换即可。

3. 按照4W1H标准进行需求安排。

4.工作安排要用统一的方式，例如：可以邮件为准，或者jira为准，明确一个就行。假设以jira为标准，就可以用jira的版本控制来安排工作，每个版本里的tickets都明确好具体的需求，负责人，时间点等。用jira也很容易做好开发部分（图中绿色部分）的整个流程，让版本的开发标准化。

5.如果有的需求当前无法评估时间，那么就把评估时间当做一项任务拆分出来，按照4W1H进行安排；如果需求当前无法安排负责人，那么就把确定负责人这个事情当做一个单独的任务来进行安排。以此类推，让所有的任务都符合4W1H标准，做到每项开发的工作任务都可控。

6.每项任务，PM或者Team Lead最好是每天都跟进一下相关的进度，一方面及时跟进每项任务的进度；另一方面发现有遇到阻碍的情况，可以很快调整。

7.有效提高会议效率：以小团队为单位开需求小会，为了解决具体的问题，一天可以有很多小会；尽量少开大会，大会汇报大的进度，以及整体计划的跟进和调整，不讨论具体细节。会议请提前安排，明确会议主题，明确会议参与者，明确会议时间（尽可能不要超时），做好会议记录和总结，并落实会议决议。

4W1H标准

工作的安排需要明确why（为什么有这个需求？or 谁提出的需求？），what（需求及其验收标准），who（负责人）、when（完成的时间点）、how（执行方案）。why是需求的来源，如果在细化需求的时候遇到问题，可以追本溯源来重新分析；what让执行人知道具体的执行细节；who是确定了谁对需求的执行结果（质量和时间）负责；when是让每个需求都有时间节点，也能让团队的人明确每个需求的优先级；how是用来记录这个需求的执行策略。

总体来说，整个流程中，蓝色部分的需求定义和工作安排是最重要的，参考4W1H标准进行，可以让整个项目要做的事情，时间点，准确可控。另外，需求的定义者要学会对工作任务进行拆解，建议让每个最小的任务的工作时间控制在1周以内，这样即便某个任务出现特殊情况延期，也容易快速调整并进行修正，整体进度不会受到太大的影响。

management|管理中文

开发团队人员组织结构、工作要求和职责

如图所示，开发团队主要分为两个部门：一是产品管理，而是研发管理。产品部负责产品功能、UI和体验的整理和设计，研发部负责对产品进行实现。

产品管理部门

一个产品的需求，除了产品人员本身对于产品目标的设计，还会收集到用户、市场、法务等各方的需求反馈。产品部把需求主要分为：新功能开发、已有功能的bug修复、用户体验的优化，然后综合衡量，制定出研发的版本计划。所以，开发的版本计划主要是产品部来指定，当然开发部的负责人会一起参与讨论，让计划更加合理。

产品部门的人员包括：商业分析人员，负责产品市场分析、竞争对手分析等，并提出产品需求；需求设计人员，输出产品需求文档和线框图；UI设计人员，根据设计文档输出漂亮的UI设计图并进行切图；QA人员，负责对研发实现的产品进行验收，让产品部门的人验收研发结果，会更加准确高效。在团队小的时候，商业分析、需求设计和QA可以同一批人。

开发管理部门

开发部主要对产品的需求进行实现，常见的划分为：前端开发和后端开发。在团队不同的阶段，devops可以独立，也可以放到后端开发。前端开发现在一般包含web和app，通常两个端由同一个人来领导会比较好，因为有大量的工作是可以重用的。

两个部门的工作，有一些模糊的地方，可以根据具体的情况协商来解决。例如：对数据结构的设计，可以是产品部门来设计，也可以是开发部门来设计。这个要看团队负责人的能力和经验了。很多产品部门的lead是有研发背景的，研发的lead也可能参与过多个成功的产品设计。

两个部门的人相互合作，相互促进，共同决定着产品研发的速度、质量和用户体验度。

补充一点：把产品部和研发部分开，还可以适用于使用外包开发团队的场景。公司内部做好产品需求、UI的设计以及最终产品的验收，是可以把工作外包给专业的外包公司的。这种情况下，把devops人员放到公司内部即可。

各个岗位lead的职责和要求

要求：

1.能够在相关的专业领域有足够的项目经验，以及快速学习的能力

2.能够识别下属的能力，合理的安排工作需求

职责：

1.对职责范围内的事情进行全面负责

2.安排、验收需求（why, what, who, when, how）

3.定期评估组内人员表现（做了哪些事情，是否按时完成，质量是否满足要求，有哪些突出的贡献），提交给Hr部门进行评估，给升值、加薪，或者淘汰做参考。

BA Lead

管理BA团队，把市场、商务、法务等方面的需求，转化为产品需求

Design Lead

管理产品设计团队，把需求细化，转化为详细的产品需求文档，以及线框图

QA Lead

管理测试团队，负责对研发开发完的功能进行验收

Backend Lead

管理后端研发团队，负责后端功能的实现，数据储存、安全性以及高并发性能问题

Frontend Lead

管理前端开发团队，负责用户端的产品实现

Devops Lead

管理Devops团队，负责开发环境、测试环境，以及生成环境的搭建，环境的安全性，代码的部署。

technology|技术中文

支撑10亿用户的技术方案（实战篇）

项目简述

总体需求：实现一个类Twitter的网站（仅实现网页版）

功能列表：

帐号系统 (account)
个人资料页 (profile)
设置 (settings)
帮助 (help)
主页时间线 (home page, a.k.a., home timeline)
帖子 (post)
关注者，正在关注 (followers & following)
搜索 (search)
趋势 – 热门标签 (trending – popular hashtags)
热门用户 (popular users)
标签页 (搜索页的一种) – hashtags
通知 – notification

团队人员配置：

产品：1人，设计：1人，前端：1人，后端：2人

技术架构

参考文章：支撑10亿用户的技术方案（思路篇）

Twitter架构图

开发实现

开发节奏

1. 产品需求细化

对每个功能模块做具体的描述，画出产品的线框图

2. 前后端基础框架选择和制定标准的通讯接口

前后端都有成熟的框架可用，根据团队人员的经验进行选择即可。标准的通讯接口通常包括：1)正常代码和错误代码；2)返回的数据结构; 3)通讯安全策略

3. 数据库结构设计

根据需求文档定义数据库结构。在这个产品需求里，很容易整理出来，需要的数据表如下：user, post, reply, like, user_relationship。更详细的表结构定义在后面。

4. 数据接口（API）设计

有了线框图，就有了页面，根据页面元素，就可以整理出需要的数据，API就能定义出来了。

5. 前端页面实现（根据API，用模拟数据）

6. 后端API实现（常规实现，不包括高并发的方案）

7. 前后端联调

8. 后端支持分库分表，应对高并发

9. 部署方案

10. 功能测试 & 安全测试

11. 高并发测试

时间评估

第一周：完成1和2

第二周：完成3和4

第三周~第五周：完成5、6、7

第六~第七周：完成8和9

第八~第十周：完成10和11，通过测试后就可以准备上线了

补充说明：时间的评估，要根据团队成员的经验和能力来，以上评估可以作为参考。由于产品有完全可参考的对象，无需原创；如果再机上团队成员能力很强，并且有丰富的高并发处理经验，以上评估是合理的。

数据库表结构设计

Mysql Database table structures
—
— Table structure for table tb_user
—
CREATE TABLE tb_user (
id bigint unsigned NOT NULL AUTO_INCREMENT,
username varchar(15) COLLATE utf8mb4_general_ci NOT NULL,
email varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
password varchar(64) COLLATE utf8mb4_general_ci NOT NULL,
display_name varchar(64) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
banner_url varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
avatar_url varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
phone varchar(32) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
description text COLLATE utf8mb4_general_ci NOT NULL,
website varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
language varchar(8) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
time_zone varchar(8) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
location varchar(16) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
verified tinyint unsigned NOT NULL DEFAULT ‘0’,
suspended tinyint unsigned NOT NULL DEFAULT ‘0’,
dob_day tinyint unsigned NOT NULL DEFAULT ‘0’,
is_visible_dob_day tinyint unsigned NOT NULL DEFAULT ‘0’,
dob_month tinyint unsigned NOT NULL DEFAULT ‘0’,
is_visible_dob_month tinyint unsigned NOT NULL DEFAULT ‘0’,
dob_year smallint unsigned NOT NULL DEFAULT ‘0’,
is_visible_dob_year tinyint unsigned NOT NULL DEFAULT ‘0’,
activate_code varchar(6) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
is_activated tinyint unsigned NOT NULL DEFAULT ‘0’,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id),
UNIQUE KEY uiq_username (username),
UNIQUE KEY uiq_email (email)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_user_extended
—
CREATE TABLE tb_user_extended (
user_id bigint unsigned NOT NULL,
count_followers int unsigned NOT NULL DEFAULT ‘0’,
count_followings int unsigned NOT NULL DEFAULT ‘0’,
count_posts int unsigned NOT NULL DEFAULT ‘0’,
count_likes int unsigned NOT NULL DEFAULT ‘0’,
pinned_post_id bigint unsigned NOT NULL DEFAULT ‘0’,
last_login bigint NOT NULL DEFAULT ‘0’,
timeline_updated_at bigint NOT NULL DEFAULT ‘0’,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_user_reset
—
CREATE TABLE tb_user_reset (
id bigint unsigned NOT NULL AUTO_INCREMENT,
user_id bigint unsigned NOT NULL,
username varchar(16) COLLATE utf8mb4_general_ci NOT NULL,
email varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
reset_code varchar(64) COLLATE utf8mb4_general_ci NOT NULL,
created_at bigint NOT NULL,
updated_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id),
KEY idx_email (email),
KEY idx_username (username)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_reserved_username
—
CREATE TABLE tb_reserved_username (
id bigint unsigned NOT NULL AUTO_INCREMENT,
reserved_username varchar(16) COLLATE utf8mb4_general_ci NOT NULL,
notes text COLLATE utf8mb4_general_ci NOT NULL,
created_by int unsigned NOT NULL,
created_at bigint unsigned NOT NULL,
updated_at bigint unsigned NOT NULL,
PRIMARY KEY (id),
UNIQUE KEY reserved_username (reserved_username)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_post
—
CREATE TABLE tb_post (
id bigint unsigned NOT NULL AUTO_INCREMENT,
user_id bigint unsigned NOT NULL,
post_type tinyint unsigned NOT NULL COMMENT ‘0: original post; 1: repost; 2: quoted repost; 3: comment (or reply)’,
original_type tinyint DEFAULT ‘0’,
original_id bigint unsigned NOT NULL,
content_text varchar(300) COLLATE utf8mb4_general_ci NOT NULL COMMENT ‘Text content; Max length 280’,
image_url varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
video_url varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
hashtags text COLLATE utf8mb4_general_ci NOT NULL,
location varchar(64) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
place varchar(64) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
source tinyint unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘The source label of this post, e.g., iPhone, Android, Web, Default 0’,
reply_settings tinyint unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘Shows you who can reply to a given Tweet. Fields returned are “everyone”, “mentioned_users”, and “followers”. default 0 “reply_settings”: “everyone” ‘,
is_deleted tinyint unsigned NOT NULL DEFAULT ‘0’,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
deleted_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_post_extended
—
CREATE TABLE tb_post_extended (
post_id bigint unsigned NOT NULL,
user_id bigint unsigned NOT NULL,
count_comments int unsigned NOT NULL DEFAULT ‘0’,
count_likes int unsigned NOT NULL DEFAULT ‘0’,
count_reposts bigint NOT NULL DEFAULT ‘0’,
count_quote int unsigned NOT NULL DEFAULT ‘0’,
count_shares int unsigned NOT NULL DEFAULT ‘0’,
count_reported bigint NOT NULL DEFAULT ‘0’,
is_deleted tinyint unsigned NOT NULL DEFAULT ‘0’,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
deleted_at bigint NOT NULL DEFAULT ‘0’ ,
PRIMARY KEY (post_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_post_like
—
CREATE TABLE tb_post_like (
id bigint unsigned NOT NULL AUTO_INCREMENT,
content_type tinyint DEFAULT ‘0’ COMMENT ‘0 post, 1 reply’,
record_id bigint unsigned NOT NULL,
liker_id bigint unsigned NOT NULL,
is_like tinyint unsigned NOT NULL DEFAULT ‘0’,
created_at bigint unsigned NOT NULL DEFAULT ‘0’,
updated_at bigint unsigned NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_post_reply
—
CREATE TABLE tb_post_reply (
id bigint unsigned NOT NULL AUTO_INCREMENT,
user_id bigint unsigned NOT NULL,
post_id bigint unsigned NOT NULL,
content_text varchar(300) COLLATE utf8mb4_general_ci NOT NULL COMMENT ‘Text content; Max length 280’,
image_url varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
video_url varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
hashtags text COLLATE utf8mb4_general_ci NOT NULL,
location varchar(64) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
place varchar(64) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ”,
source tinyint unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘The source label of this post, e.g., iPhone, Android, Web, Default 0’,
is_deleted tinyint unsigned NOT NULL DEFAULT ‘0’,
created_at bigint NOT NULL DEFAULT ‘0’,
deleted_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_post_reply_extended
—
CREATE TABLE tb_post_reply_extended (
post_reply_id bigint unsigned NOT NULL,
user_id bigint unsigned NOT NULL,
post_id bigint unsigned NOT NULL,
count_comments int unsigned NOT NULL DEFAULT ‘0’,
count_likes int unsigned NOT NULL DEFAULT ‘0’,
count_reposts bigint NOT NULL DEFAULT ‘0’,
count_quote int unsigned NOT NULL DEFAULT ‘0’,
count_shares int unsigned NOT NULL DEFAULT ‘0’,
count_reported bigint NOT NULL DEFAULT ‘0’,
is_deleted tinyint unsigned NOT NULL DEFAULT ‘0’,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
deleted_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (post_reply_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_post_reply_hashtag
—
CREATE TABLE tb_post_reply_hashtag (
id bigint unsigned NOT NULL AUTO_INCREMENT,
content_type tinyint DEFAULT NULL COMMENT ‘0 post, 1 reply’,
record_id bigint unsigned NOT NULL,
hashtag_id bigint unsigned NOT NULL,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_recommended_hashtag
—
CREATE TABLE tb_recommended_hashtag (
id int NOT NULL AUTO_INCREMENT,
hashtag_id int NOT NULL,
rank int NOT NULL DEFAULT ‘0’,
created_at bigint unsigned DEFAULT ‘0’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

—
— Table structure for table tb_recommended_user
—
CREATE TABLE tb_recommended_user (
id int NOT NULL AUTO_INCREMENT,
user_id bigint unsigned DEFAULT NULL,
rank int DEFAULT ‘0’,
created_at bigint unsigned DEFAULT ‘0’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

—
— Table structure for table tb_reported_content
—
CREATE TABLE tb_reported_content (
id bigint unsigned NOT NULL AUTO_INCREMENT,
content_type tinyint DEFAULT ‘0’ COMMENT ‘0 post, 1 reply’,
record_id bigint unsigned NOT NULL,
post_user_id bigint unsigned NOT NULL,
reporter_id bigint unsigned NOT NULL,
report_reason tinyint unsigned NOT NULL,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id),
KEY idx_post_id (record_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_reported_user
—
CREATE TABLE tb_reported_user (
id bigint unsigned NOT NULL AUTO_INCREMENT,
user_id bigint unsigned NOT NULL,
reporter_id bigint unsigned NOT NULL,
report_reason tinyint unsigned NOT NULL,
created_at bigint unsigned NOT NULL DEFAULT ‘0’,
updated_at bigint unsigned NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id),
KEY idx_user_id_reporter_id (user_id,reporter_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_user_relationship
—
CREATE TABLE tb_user_relationship (
id bigint unsigned NOT NULL AUTO_INCREMENT,
user_id bigint unsigned NOT NULL,
target_user bigint unsigned NOT NULL,
status_follow tinyint unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘0: unfollow; 1: follow; 2: block’,
status_mute tinyint unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘0: unmute; 1: mute’,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id),
UNIQUE KEY uiq_user_id_follwer_id (user_id,target_user),
KEY idx_follower_id (target_user)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_user_relationship_reversed
—
CREATE TABLE tb_user_relationship_reversed (
id bigint NOT NULL AUTO_INCREMENT,
user_id bigint DEFAULT NULL,
follower_id bigint DEFAULT NULL,
created_at bigint DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

—
— Table structure for table tb_hashtag
—
CREATE TABLE tb_hashtag (
id bigint unsigned NOT NULL AUTO_INCREMENT,
tag_name varchar(128) COLLATE utf8mb4_general_ci NOT NULL,
user_id bigint unsigned NOT NULL,
count_mentions int unsigned NOT NULL DEFAULT ‘0’,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

—
— Table structure for table tb_parsed_url
—
CREATE TABLE tb_parsed_url (
id bigint NOT NULL AUTO_INCREMENT,
url varchar(256) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
title varchar(512) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
description varchar(45) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
created_at bigint DEFAULT NULL,
updated_at bigint DEFAULT NULL,
PRIMARY KEY (id),
UNIQUE KEY id_UNIQUE (id),
UNIQUE KEY url_UNIQUE (url)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

API设计

基本约定：
1.获取数据用get,提交数据用post
2.返回的数据格式：{“code”: 0, “message”:”ok”, “data”:{} }, 成功的时候code为0,否则为非0

Account部分
1.创建账户 account/create
Method：POST
Params:
{“username”:”yourname”, “email”:”you@email.com”,”password”:”yourpwd”}
Response:
{
“code”: 0,
“data”: {
“activeCode”: “147849”,
“avatarUrl”: “”,
“bannerUrl”: “”,
“countFollowers”: “0”,
“countFollowings”: “0”,
“countLikes”: “0”,
“countPosts”: “0”,
“createdAt”: “1624266544”,
“description”: “”,
“displayName”: “”,
“dobDay”: “0”,
“dobMonth”: “0”,
“dobYear”: “0”,
“email”: “youremail@gmail.com”,
“iD”: “100000003”,
“isActived”: “0”,
“isVisibleDobDay”: “0”,
“isVisibleDobMonth”: “0”,
“isVisibleDobYear”: “0”,
“language”: “”,
“lastLogin”: “0”,
“location”: “”,
“password”: “123456”,
“phone”: “”,
“pinnedPostId”: “0”,
“suspended”: “0”,
“timeZone”: “”,
“updatedAt”: “1624266544”,
“username”: “myname”,
“verified”: “0”,
“website”: “”
},
“message”: “ok”
}

2.激活账户 account/activate (通过email里面的链接进行激活)
Method：POST
Params:
{“username”:”yourname”, “activate_code”:”toatciveyouraction”}
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}

3.发送重置密码代码 account/send_reset_code
Method：POST
Params:
{“email”:”you@email.com”}
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}
校验代码： account/verify_code
Method：POST
Params:
{“email”:”youremail@google.com”,”code”:”resetcode123″}
重置密码： account/reset_password
Method：POST
Params:
{“email”:”youremail@google.com”, “reset_code”:”restcode123″,”password”}
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}

User 部分

1.用户登陆 user/login
Method：POST
Params:
{“name”:”yourname”,”password”:”yourpwd”}
Notes: name是username或者email
Response:
{
“code”: 0,
“data”: {
“token”: “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MjQ4NzA4MDAsImp0aSI6IjEwMDAwMDAwMyIsImlhdCI6MTYyNDI2NjAwMCwibmJmIjoxNjI0MjY2MDAwfQ.Hs2LTfG47Q1IDOhr9lY15usqyDPP1r7wKLk3l9nd4LQ”
},
“message”: “ok”
}

2.用户登出 user/logout(前端直接清理token)
Method:POST

3.修改语言 user/change_language
Method:POST
Params: {“language”:”en”}
Notes: 参数的值是options（目前只有en,zh）,不能随意填写
Response:
{
“code”: 0,
“data”: {},
“message”: “ok”
}

4.修改密码 user/change_password
Method:POST
Params: {“password”:”newpasswd”,”old_password”:”oldpasswd”}
Notes: 密码有要求,最少8位,最少包含字母和数字
Response:
{
“code”: 0,
“data”: {},
“message”: “ok”
}
5.修改其它信息 user/save_info
Method:POST
Params:
{
“display_name”: “name1”,
“banner_url”: “”,
“avatar_url”: “”,
“location”: “bg”,
“website”: “http://www.mysite.com”,

“dob_year”: “2001”,
“dob_month”: “12”,
“dob_day”: “12”
}
Response:
{
“code”: 0,
“data”: {},
“message”: “ok”
}

6.查看用户页面（该页面有3个tab,所以一起有4个api）
6.1 user/profile
Method:GET
Params: {“username”:”yourname”}
Response:
{
“code”: 0,
“data”: {
“avatarUrl”: “”,
“bannelUrl”: “”,
“countFollowers”: “0”,
“countFollowings”: “0”,
“createdAt”: “1624266544”,
“description”: “”,
“displayName”: “name1”,
“dobDay”: “12”,
“dobMonth”: “12”,
“dobYear”: “2001”,
“email”: “youremail@gmail.com”,
“id”: “100000003”,
“isVisibleDobDay”: “0”,
“isVisibleDobMonth”: “0”,
“isVisibleDobYear”: “0”
},
“message”: “ok”
}

6.2 user/posts
Params: {“username”:”yourname”, “cursor”:101}
Notes: cursor初始不传,每次返回的结果中会带上新的cursor,下次请求的时候用这个值即可(后续所有的cursor都是一样的逻辑)
如果没有新的内容可加载,cursor会返回 -1

6.3 user/replies
Params: {“username”:”yourname”, “cursor”:101}

6.4 user/likes
Params: {“username”:”yourname”, “cursor”:101}

7.查看用户关注的人 user/following
Method：GET
Params: {“username”:”yourname”, “cursor”:101}
Response:
{
“code”: 0,
“data”: {
“cursor”: “0”,
“users”: [
{
“avatarUrl”: “”,
“description”: “”,
“displayName”: “”,
“id”: “100000001”
},
{
“avatarUrl”: “”,
“description”: “”,
“displayName”: “”,
“id”: “100000002”
},
{
“avatarUrl”: “”,
“description”: “”,
“displayName”: “name1”,
“id”: “100000003”
}
]
},
“message”: “ok”
}

8.查看关注该用户的人 user/followers
Method：GET
Params: {“username”:”yourname”,”cursor”:101}
用户部分2（在他人页面操作,登陆后可操作）
Response:
{
“code”: 0,
“data”: {
“cursor”: “0”,
“users”: [
{
“avatarUrl”: “”,
“description”: “”,
“displayName”: “”,
“id”: “100000001”
},
{
“avatarUrl”: “”,

“description”: “”,
“displayName”: “”,
“id”: “100000002”
},
{
“avatarUrl”: “”,
“description”: “”,
“displayName”: “name1”,
“id”: “100000003”
}
]
},
“message”: “ok”
}

——– 以下API需要用户登陆认证 ———

9.查看自己block的用户 user/blocked
Method：GET
Params: {“cursor”:101}

10.查看自己mute的用户 user/muted
Method：GET
Params: {“cursor”:101}

11.follow某个用户 user/follow
Method：POST
Params: {“target_username”:”tusername”, “flag”:1}
Notes: flag1表示follow, 0表示unfollow
database operation：在tb_user_relationship增加或者修改记录,具体参看表的定义
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}

12.block某个用户 user/block
Method：POST
Params: {“target_username”:”tusername”, “flag”:1}
Notes: flag 1表示block, 0表示unblock
database operation：在tb_user_relationship增加或者修改记录,具体参看表的定义
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}

13.mute某个用户 user/mute
Method：POST
Params: {“target_username”:”tusername”, “flag”:1}
Notes: flag1表示mute, 0表示unmute
database operation：在tb_user_relationship增加或者修改记录,具体参看表的定义
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}

14.report某个用户 user/report
Method：POST
Params: {“target_username”:”tusername”, “report_reason”:1}
database operation：在tb_reported_user表里增加记录
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}

15.获取上传图片签名地址：upload/sign_image
Method: GET
Params: {“ext”:”jpg”} jpg|png|jpeg|gif
Response:
{
“code”: 0,
“data”: {
“url”: “https://twitter6-dev-bucket.s3.ap-northeast-1.amazonaws.com/images/20210622/cca1yk47jcsg92508.jpg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIATWAJJDEPJQWRB524%2F20210622%2Fap-northeast-1%2Fs3%2Faws4_request&X-Amz-Date=20210622T095116Z&X-Amz-Expires=1800&X-Amz-SignedHeaders=host&X-Amz-Signature=fb349171cd2d3cb5e49b711d9bf1950bba154081ad55534a3fcada33fcd0700a”
},
“message”: “ok”
}

16.获取上传视频签名地址：upload/sign_video
Method: GET
Params: {“ext”:”mp4″}
Response:
{
“code”: 0,
“data”: {
“url”: “https://twitter6-dev-bucket.s3.ap-northeast-1.amazonaws.com/videos/20210622/cca1yk47jcsg92508.mp4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIATWAJJDEPJQWRB524%2F20210622%2Fap-northeast-1%2Fs3%2Faws4_request&X-Amz-Date=20210622T095116Z&X-Amz-Expires=1800&X-Amz-SignedHeaders=host&X-Amz-Signature=fb349171cd2d3cb5e49b711d9bf1950bba154081ad55534a3fcada33fcd0700a”
},
“message”: “ok”
}

Post部分

1.发布推特 post/create
Method：POST
Params: {“content_text”:”text”, “media”: “image or video”}
Response:
{
“code”: 0,
“data”: {id: “a”},
“message”: “ok”
}

2.回复推特 post/reply
Method：POST
Params: {“content_text”:”text”, “media”: “image or video”,”original_post_id”:11122,”usename”:”namename”}
Response:
{
“code”: 0,
“data”: {id: “a”},
“message”: “ok”
}

3.转发推特
3.1 post/repost
Method：POST
Params: {“original_post_id”:11122, “usename”:”namename”,”content_text”:”repost content”}
Notes: 转推的时候也可以补充内容，原贴的repost数量要+1
Response:
{
“code”: 0,
“data”: {id: “a”},
“message”: “ok”
}
3.2 post/undo_repost 取消转推
Method：POST
Params: {“post_id”:11122}
Notes:这个记录可以直接删除了，另外原贴的repost数量要-1

4.点赞推特/取消点赞 post/like
Method：POST
Params: {“islike”:”1″,”post_id”:11122, “usename”:”namename”}
Notes: islike 1表示点赞,0表示取消点赞
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}

5.举报推特 post/report
Method：POST
Params: {“post_id”:123123, “usename”:”namename”,”report_reason”:1}
database operation：在tb_reported_post表里增加记录
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}

6.推特详情
6.1 post/detail
Method: GET
Params: {“post_id”:123456, “usename”:”namename”}
Response:
{
“code”: 0,
“data”: {
“contentText”: “us is sb”,
“countComments”: “2”,
“countLikes”: “1”,
“countRepots”: “1”,
“id”: “b”,
“imageUrl”: “”,
“originalPostId”: “0”,
“userId”: “100000003”,
“videoUrl”: “”
},
“message”: “ok”
}
6.2 post/replies
Method: GET
Params: {“post_id”:123456, “usename”:”namename”,”cursor”:101}
Response:

7.删除推特 post/delete
Method: POST
Params: {“post_id”:123456}
database operation：把tb_post对应的记录is_deleted设置为1,并设置deleted_at
Response:
{
“code”: 0,
“data”: null,
“message”: “ok”
}

8.内容置顶 post/pin
Method: POST
Params: {“post_id”:123456, “ispin”:1}
Notes: ispin 1表示置顶,0表示取消置顶,默认是1
database operation：设置tb_user对应的记录pinned_post_id
Response:
{
“code”: 0,
“data”: {},
“message”: “ok”
}

数据表和API设计的细节

分库分表策略：设计了tb_user_relationship和tb_user_relationship_reversed两个表，都按照user_id进行分库分表，这样不管是获取follower list还是following list，都是一次查询即可查到。
数据归档策略：由于Twitter访问最多的是最新几天的post数据，可以对post按照一定的时间（如：一个月或者一周）进行归档，这样可以保证最新的post表数据不会过大。
对于查询的优化：考虑数据的更新频率，把不会更新的数据放在一个表（如：tb_post），充分利用缓存；把经常更新的数据放在另外一个表（如：tb_post_extended），经常更新的字段是定长字段，mysql的查询性能也会非常高。

体验上的优化：API设计的时候，把获取帖子内容和帖子统计数据（评论数、点赞数）也分开了。前端先获取帖子的内容，并立即显示给用户；然后再异步请求统计数据。这样还可以做到定时更新列表的统计数据，特别是大V可以不用刷新页面，也能看到点赞数和评论数在增加，获得良好的用户体验感。
Timeline处理细节：1.在cache中存放timeline的post id list，每次直接从cache中获取；2.用户如果是登陆后进入首页，登陆后异步生成timeline（生成时间小于3s），然后进入首页后再请求timeline，就可以直接从缓存获取到；3.用户如果已经是登陆状态，打开首页，前端从浏览器缓存中获取老的timeline数据先进行显示，同时异步请求timeline进行刷新。4.对于重要的用户，发了推之后，利用kafka的异步机制，主动刷新在线的关注者的timeline，以方便重要的post可以第一时间发出。

technology|技术中文

支撑10亿用户的技术方案（细节篇）

在思路篇中，我们谈到了解决海量用户的两个基本思路：1.化整为零，逐个击破；2.抽丝剥茧，直达核心。在这篇文章中，我们会对这两个策略中遇到的技术细节问题，进行详细的分析。

何为化整为零？其中有哪些需要注意的技术细节？

用技术的语言来解释化整为零，就是：分库分表。在思路篇中，我们谈到可以把10亿用户分成100份1000万的，那么分表就是解决1份1000万用户访问效率的问题，而分库就是对10亿用户进行的100份拆分。

分表是解决慢查询的一个非常实用的方案，分表一定要根据实际的使用场景来进行，最核心的原则就是：保证面向用户端的业务只需要查1~2次表（大部分1次，少量2次），就可以获取到所有的数据，而不需要查询所有相关的表做并集（内部的统计数据多查一些表，慢一些，是无所谓的，因为查出来后就可以存到新的数据表里）。

举例说明，抛砖引玉：Twitter这样的应用，1000万用户，平均每个用户follow 200个人，那么follow表的数据量将高达20亿条，那么从这样一个巨大的表中查询某个用户的数据，必然是很耗时的，这就是“慢查询”。

按照分表的思路，我们把这个follow关系表定义如下，以mysql数据库来举例:

_{CREATE TABLE tb_follow ( id bigint unsigned NOT NULL AUTO_INCREMENT, user_id bigint unsigned NOT NULL, target_user bigint unsigned NOT NULL, created_at bigint NOT NULL DEFAULT '0', updated_at bigint NOT NULL DEFAULT '0', PRIMARY KEY (id), UNIQUE KEY uiq_user_id_follwer_id (user_id,target_user), KEY idx_follower_id (target_user) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;}
_{CREATE TABLE tb_follower (
id bigint NOT NULL AUTO_INCREMENT,
user_id bigint NOT NULL DEFAULT ‘0’,
follower_id bigint NOT NULL DEFAULT ‘0’,
created_at bigint NOT NULL DEFAULT ‘0’,
updated_at bigint NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;}

上面我定义了两个表，通过user_id可以从tb_follow查到follow list，通过user_id可以从tb_follower查到follower list，User A关注User B，将会在tb_follow中插入user_id=A_uid, target_user=B_uid，会在tb_follower中插入user_id=B_uid, follower_id=A_uid，即：1个follow关系，2条数据。

然后对tb_follow和tb_follower表都按照user_id拆分成10000个表，那么每个表的数据就变成了20万个，这样的数据量就很小了，查询起来就不会有慢查询了。

同理，在整个架构中的cache，kafka，也可以根据实际的需求进行拆分，避免单个实例的压力超出可承受的范围。

如何抽丝剥茧，找到性能瓶颈的核心所在？

在压测之后，我们通常会收到一份报告，类似下面这样的：

通过这份报告，可以看到正常请求几十毫秒的API，在压测的情况下，有的平均时间居然达到了100秒以上，是不是惊呆了？就问你慌不慌？

先来对压测的请求做第一层分解：

压测机器发起请求，通过网络链路达到应用的机器的网卡（中间通常会有load balancer进行流量分发）；网卡把命令发送给web service再转发给应用程序执行请求，并获取结果；结果通过网卡传输到网络返回到压测机器。

这里跟应用程序相关的：

一是网络，网络流量是否会占满带宽或者网卡？现在的服务器网卡基本上千兆级别，一般不会遇到网卡占满的情况，但是带宽被占满是有可能的，例如：压测的时候是通过外网访问的，而外网的带宽会有限制，而通过内网访问通常不会有这个问题。

二是应用服务器，需要查看下应用服务器的cpu占用是否过高，内存是否占满，磁盘空间是否足够？另外，还有一个新手不了解的细节：文件描述符与并发tcp连接数的关系及限制。这个细节，可以通过google查相关的关键字，以及ulimit去做详细的了解，当你了解清楚之后，就会知道服务器上的相关参数是否限制了并发数。

第二层分解，主要针对应用服务器内部执行的细节进行：

Web service把请求分发给应用程序进行执行，执行通常会有的操作：判断参数执行代码逻辑，读写cache，读写db，有的会包含写日志文件。

代码本身逻辑的问题需要具体问题具体分析，这里不做论述。关于Cache需要注意几点：1.命中率是否足够高（高访问量的情况下通常应该超过99%）；2.单个实例是否被用满了（单实例250 million objects）；3.实例的带宽、CPU等使用情况。

当然，最最重要的还是要分析db了。通常db出现性能问题，可以从错误日志中得到信息，例如：connect out of time。对于db的优化需要关注以下几点：

1.慢查询：可以通过优化查询、建立索引，来减少慢查询；当然，最最核心的还是通过分表来减少单表的数据量，以提升查询效率

2.实例的连接数：db instance都是有连接数限制的，通过调整相关参数，可以提高连接数，还可以通过建立连接池来提高连接的复用性；在参数都优化到极致之后，cpu和内存都耗尽，无法再提高上限，那么就需要用到分库的策略了，增加多个db instances来分担应用的连接。分库的规则可以参考分表的原则，基本上是一致的。

technology|技术中文