2020-09-01

如何设计一个用户系统？
功能
注册、登录、查询、用户信息修改
• 支持 100M DAU
• 注册，登录，信息修改 QPS 约
• 100M * 0.1 / 86400 ~ 100
• 0.1 = 平均每个用户每天登录+注册+信息修改
• Peak = 100 * 3 = 300
• 查询的QPS 约
• 100 M * 100 / 86400 ~ 100k
• 100 = 平均每个用户每天与查询用户信息相关的操作次数（查看好友，发信息，更新消息主页）
• Peak = 100k * 3 = 300 k

• Service 服务
• 一个 AuthService 负责登录注册
• 一个 UserService 负责用户信息存储与查询
• 一个 FriendshipService 负责好友关系存储

用户系统的特点，读多写少，一定要用Cache进行优化。

用户是如何实现登陆与保持登陆的？
• 会话表 Session
• 用户 Login 以后
• 创建一个 session 对象
• 并把 session_key 作为 cookie 值返回给浏览器
• 浏览器将该值记录在浏览器的 cookie 中
• 用户每次向服务器发送的访问，都会自动带上该网站所有的 cookie
• 此时服务器检测到cookie中的session_key是有效的，就认为用户登陆了
• 用户 Logout 之后
• 从 session table 里删除对应数据
• 问题：Session Table 存在哪儿？
• 数据库或缓存都可以

对于 User System 而言
• 写很少
• 读很多
• 写操作很少，意味着
• 从QPS的角度来说，一台 MySQL 就可以搞定了
• 读操作很多，意味着
• 可以使用 Memcached 进行读操作优化

• 进一步的问题，如果读写操作都很多，怎么办？
• 方法一：使用更多的数据库服务器分摊流量
• 方法二：使用像 Redis 这样的读写操作都很快的 Cache-through 型 Database
• Memcached 是一个 Cache-aside 型的 Database，Client 需要自己负责管理 Cache-miss 时数据的 loading

Friendship Table适合什么数据库？
SQL 和 NoSQL 的选择标准是什么？

除了QPS，还有什么需要考虑的？
100M 的用户存在一台 MySQL 数据库里也存得下，Storage没问题
通过 Cache 优化读操作后，只有 300QPS 的写，QPS也没问题
还有什么问题？
单点失效
• 数据拆分 Sharding
• 按照一定的规则，将数据拆分成不同的部分，保存在不同的机器上
• 这样就算挂也不会导致网站 100% 不可用
• 数据备份 Replica
• 通常的做法是一式三份（重要的事情“写”三遍）
• Replica 同时还能分摊读请求

数据拆分包括垂直拆分和水平拆分，垂直拆分比如一个服务拆成独立数据库，或者一个数据库里面的字段冷热拆分。
水平拆分，常见的就是分片，一致性哈希算法进行负载均衡。

数据备份，sql一般主从，nosql一般顺时针找三台机器。