ch1

现如今应用程序的性能瓶颈主要在处理密集数据上，对于数据密集型应用，需要提供一些通用功能：

• 存储数据（MySql..db）
• 记住昂贵的操作结果，以加快下次读取速度（Redis..cache）
• 搜索数据，对数据进行过滤（Es..）
• 向其他进程发送消息，进行异步处理（Stream processing）
• 定期批处理（batch processing）

本书着重讨论三个性质

• 可靠性
• 可伸缩性
• 可维护性

对于应对负载的伸缩：

• 纵向伸缩：对于性能较好的机器来说，单机设计实现较为简单，但是一般比较贵
• 横向伸缩：将负载分布到小机器上

优秀的架构是两者混合，因为使用几台足够强大的机器可能比使用大量的小型虚拟机更简单也更便宜。

大规模的系统架构通常是应用特定的 —— 没有一招鲜吃遍天的通用可伸缩架构 。应用的问题可能是读取量、写入量、要存储的数据量、数据的复杂度、响应时间要求、访问模式或者所有问题的大杂烩。

对于本章可靠性中推特例子的看法：

背景：推特中用户发布推文时，该用户粉丝可以查阅他们关注的人发布的推文。推特就此功能设计了两种方案

• 发布推文时，只需将新推文插入全局推文集合即可。当一个用户请求自己的主页时间线时，首先查找他关注的所有人，查询这些被关注用户发布的推文并按时间顺序合并。

• 为每个用户的主页时间线维护一个缓存，就像每个用户的推文收件箱。 当一个用户发布推文时，查找所有关注该用户的人，并将新的推文插入到每个主页时间线缓存中。因此读取主页时间线的请求开销很小，因为结果已经提前计算好了。

对于第一种方案，每个用户都需要去全局推文集合中查询数据，如果使用mysql这种关系型数据库，所能接受的并发是比较小的。第二种方式则是利用缓存比如redis的zset数据结构，即可实现该功能，但是缺点是如果一个大v有百万千万级粉丝，他发布一个推文所需要的异步操作消耗则过大。所以推特最终选择了两种方式混合，对于不同粉丝量的用户发布推文有不一样的方式处理。