Design User Service
Scenario
注册，登录，查询，用户信息修改
DAU：100m
- Register, login, update QPS: 100M * 0.1 / 10^5 = 100
- Query: 100m * 10 / 10^5 = 10k;
- Pick Query QPS: 10k * 3 = 30k
Service 服务
- AuthenticationService 负责用户注册
- UserService 负责用户信息储存与查询
- FriendshipService 负责好友关系存储
用户系统的特点：读非常多，写非常少。因此，需要对读进行优化
Authentifaction service
Session 会话
- 用户login后，为他创建一个session 对象
- 把session_key 返回给浏览器，让浏览器存起来
- 浏览器将该值存在浏览器的cookie中
- Cookie: 可以理解为一个client端的hash table。服务器会把一些用于标记的用户信息传递给浏览器
Storage - Cache
常见的Cache 软件
- Memcached (不支持数据持久化)：负责帮助cache在内存里的软件
- Redis (支持数据持久化)
Cache 不一定需要在内存中，file system也可以做cache，CPU也有cache。Frontend，client，browser都可以有cache。
Cahce 的结构：
- Cache Aside: Cache <-> Web Server <-> DB
- Cache Through: Web Server <-> Cache <-> DB
- 典型代表：Redis，可以理解为Redis包含了一个Cache和一个DB
- Redis支持单纯的key-value存储结构，无法适应复杂的应用场景
- 业界大多使用cache aside，benefit是cache和DB可以自由搭配
Storage - Cassandra NoSQL 数据结构
Cassamdra是一个三层结构的NoSQL数据库
- 第一层: row_key
- 第二层: column_key
- 第三层: value
Cassandra的key = row_key + column_key；同一个key只对应一个value
Rowkey：又称为Hash Key, Partition Key；Cassandra会根据这个key算一个hash值。
然后决定整条数据存在哪里
ColumnKey: insert(row_key, column_key, value)任何一条数据，都包含上面部分。
Cassandra这样做是为了支持范围查询, e.g. query(row_key, column_start, column_end)