关于访问量，我们在谈些什么？

what about load ?

关于访问量，我们在谈些什么？

读《Design Data-Intensive Applications》, 随想纪录片刻：

1. 可以是每秒的读写访问量，每秒的写访问，每秒的读访问

单独描述读访问，比如一个数据库，只有读访问，那么怎么衡量读的最大访问量？

在什么样的配置下，有多少访问量之后，性能才会有问题。

这还要和访问请求的复杂程度联系起来，如果是热点表访问，数据缓存起来后，就在于网络接口的吞吐量上面，因为数据都在内存里，唯一的瓶颈，在与传输IO有多快，有多大。

单独描述每秒的写访问，访问瓶颈会在内存达到一个满负荷之后，才会显现出来。访问的并发会加剧这种瓶颈的显现。1000个写请求，写入同一个表，或者写入不同的表，等待的时间长短。

1. 用什么度量或者关键指标KPI,可以精确描述目前系统的健壮性？

关于 web server， 我们可以用每秒处理多少请求来衡量；

关于 database, 我们可以用 “读写比率” ，“并发数”，“缓存命中率” 来衡量；

就拿新浪微博来说，如果让你设计发微博，收微博的后台数据库，你会怎么设计，考虑以下的场景：

• 发微博： 假设每秒的平均发微博数量是 4600，每秒的高峰发微博量是12000；（实际不止）

• 收微博：假设你关注了 100 个人，你需要收到他们每个人的微博，并且是按照时间顺序读取。峰值可能是每秒 30万 请求。

第一方法是绝大多数人都会想到的，就是用二维表关联的方法：

设计以下三个表：微博表，人物表，人物关系表。

微博表用来存储发送的微博；

人物表用来存储每个新浪用户的个人信息；

人物关系表就是用来存储用户互相关注的信息。

(书上的例子是用 tweet, 我们这里改为 新浪，更本地化）

这里可见的瓶颈，是：

发微博的这张表，历史记录会非常大。一秒4600，一天就是 4600 * 60 * 60 *24 , 差不多 4亿一天。加上人物表，人物关系表的数量也巨大，10左右的用户都在里面。这种方法对于每秒 4600 的读来说，都将是灾难。

所以很快就产生了下面一种设计方法，而这种设计方法可能大多数人都不会碰到，因为平日的数据库体量不会有那么大的用户群：

每一个人建立一张缓存的微博表，每发一条微博，都按照人物关系表，将新的微博发送到各自的关注者所在的缓存表里面去，所以我们下拉刷微博的时候，直接是从自己的缓存表里拉数据，量就小了很多。这里的挑战是，将一条微博发送到自己的读者列表各自的缓存表里面。如果小V也就算了，但是大V都是千万级的粉丝，一般要在 5秒内发送完毕，这也是一个瓶颈。新浪的大V又很多，如果大V同时发微博，来个共振，你想想微博的架构能支持的了么？

邓超，新浪微博的粉丝有 6000W+ ， 所以他每发一条微博，如果按照 方法 2 来设计的话，写的请求量会巨大，给 6000W+ 粉丝都建立一个 cache 表，肯定也不切实际，有些还有可能是僵尸粉。多说一句，邓超是个演技过关的演员，用心投入他的戏，虽然看着都像是在演戏，但表情到位。《乘风破浪》是韩寒导演，邓超出演的一份好戏，80 后的杰出模范，我们应该用行动给他们鼓励鼓励，虽然是梁家辉和梁朝伟《难兄难弟》的套路，都讲究父子情深，都演的到位。

扯远了，拉回来。如果让你来设计这个架构，你会怎么办呢？

Twitter 的做法是，将 大V 与普通用户区分开来存放。大V 使用第一种方法，小V和普通用户就采用第二种架构。

提几个开放性的问题，以待下次回答：

1 在一个数据库系统中，我们如何获得读和写的请求流量？

2 更深层次的问题是，怎么知道一个数据库系统中，读和写各占的流量比率，从而来获得数据库系统中，到底是读请求占的多，还是写请求占的多？读和写，都是请求操作。一个系统能够在当前配置下，支持的最大访问量，就是他的瓶颈。

3 怎么知道一数据库系统或者数据应用的瓶颈，怎么来测试？

只读，测试；

只写，测试；

读和写，并发测试；

4 怎么才能设计一套灵活的配置来支持线性扩展服务器，满足日益增加的访问量

---

欢迎关注【有关SQL】，入群讨论