《大型网站技术架构：核心原理与案例分析》读书笔记

1. 由于网站的访问流量是缓慢增长的（PS除了垄断的12306），所以一般网站的架构也是不断的演化的，没有一开始就搞出个支持大并发的网站。无论从开发到发布的时间、消耗的资源上来看，或者是说从开发、维护的难度上看，或者从开发的防止“过度设计”的维度思考，绝大多数网站设计是一个演化的过程。这也是植根于需求的表现。

2. 分析目前大型互联网可以从两个维度，用户需求、结构框架。当然是前者决定后者。从用户需求特点分析，大型网站要求高可用、高性能两个最“简单”的要求。从设计的角度讲还要满足可扩展（主要是业务上）、伸缩性（性能上）、安全性（开放导致很多攻击）。基于以上五个方面，在设计网站的架构，就形成了目前的模式，横向的实现逻辑分层、纵向的业务功能分割、分布式、集群、缓存、异步、冗余、自动化、安全设计等通用的模式与思想。

3. 技术并不代表一切。很多情况下，理解业务才是最重要的，现在技术很开放，而且分享的人也很多，从社区上看技术大牛很多，但大家很少关心业务，可能是因为有共同语言的少。但是，如果不理解自己的业务可能会走很多弯路。为什么企业开发自己云上的应用的过程如此漫长？很多情况下不是缺少技术大牛，而是缺少懂技术的业务大牛。文中作者所举得12306例子是此问题很好的印证，一开始12306是一个时间点集中售所有车辆的票，结果可以想象，一秒内可能有上亿的访问。后来最大的改进可能不是技术上的，而是业务上的，有必要同一个时间卖所有的票么？最后业务模型是，一天内分了很多个时段卖票，业务上的负载均衡。论坛上还看过另外一种说法，对于这种稀缺资源，为了不失公正性，可以摇号。也是一种思路，但是在中国，什么的都有后门，到时候可能就不是技术上的问题了，人的猜疑心与不信任对此方案压力山大。
   文中作者说明观点“山寨与创新的最大区别不在于抄袭，不在于模仿，而在于对于问题和需求是否真正理解与把握”的时候举了新浪微博中的例子，当大V发布微博的时候会存在大量的写数据库操作。为了避免数据库负担，可以只写并推送那些在线的用户的部分，而那写不在线的，等他们上线的时候会去主动查询。其实也是通过业务而改进设计，避免不必要操作节约资源的一个例子。

4. CPU变快不仅是因为核心多、频率高，更重要的一个原因是有缓存。这么看来，cpu设计与网站也有相同道理，核心多（分布式），多级缓存（对应网站的各种资源缓存），频率上CPU现代没有明显提高，与网站设计上没有一味的追求高性能机器一样。但从长远角度看，CPU频率主要是物理学制约，早晚会有突破。

5. 缓存不仅能够提高速度，也能够避免后端的压力。缓存对于速度的提升是非常明显的，在目前的架构中很多地方用到缓存，从业务流程看，缓存有IE缓存、CND、反向代理、应用服务器本地缓存、分布式缓存最后实在没有了才去数据库，数据库本身也有缓存配置，如果数据库还没有命中，甚至到了操作系统层面也有很多缓存，内存中缓存着硬盘热信息，而硬盘也有自己的缓存。

   缓存对读取速度有很大提升，在很多情况下对写操作性能也有很大提高，例如硬盘的缓存。但写操作在宕机和断电时缓存可能会导致数据的不一致，很多情况下比较麻烦。所以又有一种变通的做法，提高处理消息持久化的速度，怎么提高呢？来了消息顺序写磁盘，消息可能没有处理完成就直接返回给客户了，即时断电了我在处理我已经持久化了的消息，保证一致性。这也是消息队列的一个重要作用。

6. 性能的几个指标
   PV(page view)，一般会以日为单位计算
   QPS（TPS）：每秒钟request/事务 数量
   并发数：系统同时处理的request/事务数
   响应时间：一般取平均响应时间

   上面四个关系QPS（TPS）= 并发数/平均响应时间
   “淘宝的TPS和PV之间的关系通常为 最高TPS：PV大约为 1 : 11*3600 （相当于按最高TPS访问11个小时，这个是商品详情的场景，不同的应用场景会有一些不同）”

7. “网站优化第一定利率——优先使用缓存优化性能。”

8. 与读写锁一样，缓存也有一样限制，读的次数多于写的次数。因为一次写缓存的操作不仅仅是简单的写缓存，还要做持久化工作。一个读写为1:1的情景，写入缓存后，先把缓存置为无效（一致性要求较高），然后写入数据库，这个时候读操作发现缓存无效，在去读取数据库，这样缓存数据库命中率就很低，加上那些维护的复杂操作，反而可能会减少系统的性能。如果对一致性要求不高，这个时候很大概率读到的数据都是有延时的不正确的数据。

   换一句话说，缓存主要是对“慢数据”。互联网中多数为这种情况，例如发表博客、商品更新。还有动环中的温湿度，缓存一份，一段时间同步下一就ok了。

9. 缓存的作用是加快响应速度，不可以作为可靠的数据来源。所以对缓存的热备份，意义不大。

10. Hadoop为了实现文件磁盘的可靠性和速度，搞了自己的HDFS（可以理解为Hadoop File System）。一份数据，三个服务器存储，这样，有了RAID0的快速存储（应该是三倍的存储速度），也有了RAID1的可靠性（三份数据）。

11. 书中的第四章主要是“高性能”，一方面是利用各种缓存，另一方面就是解决存储上的速度与可靠性。

12. Session服务器？

13. “CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼”百科上的解释，对于大型的系统，一般会弱化一致性从而实现更好的可用性与分区容错性，弱化并不是不保证，而是延迟的完成一致性的需求。

14. “关系数据库的热备份机制就是通常所说的Master-Slave同步机制，此机制不仅解决了数据库备份问题，还改善了数据库系统的性能，实践中，通常使用读写分离的方法访问Master与Slave，写操作只访问Master库，读操作只读取Slave库。”

15. 第五章讲的主要是“高可用”，而实现高可用主要是负载均衡，数据库备份等基本方法，辅以运行监控手段。

16. 第六章伸缩性，网站的演化分离过程可以分为三类，
    第一类大的系统级别的分离，例如数据库系统，缓存系统，文件管理系统（静态资源），演化过程为：为单一服务器->数据库分离->缓存分离->静态资源分离。
    第二类业务流程的抽象分离，从下到上的模块为：数据库->基础技术服务->可复用业务服务->具体的产品。PS，这里分离的最大好处不仅在于可以分布式，还有设计中的“复用”能够带来的好处。
    第三类，业务层面的分离：订单、商品系统、用户信息等。（不能进行Join操作）

    负载均衡问题可以通过Http重定向、DNS、反向代理、负载均衡服务器IP方式、数据链路层（直接修改IP头）方式解决，算法有轮询、加权轮询、随机、源地址散列（hash）、最少连接等方式。

    伸缩性问题中，缓存的伸缩性设计与应用服务器的伸缩性设计不同，通常应用服务器的负载均衡会使用hash取余的算法实现，但是这种方法并不适合于缓存的。如采用取余算法，新增一个缓存服务器后，以前缓存在缓存服务器中的数据“命中率”会很低，这样在新增缓存服务器后由于命中不高会大大增加数据库的压力，甚至崩溃。例如以前有三个Node，为Node0、Node1、Node2，如果新增一个Node3，那么以前数据4对3取余在Node1中，但是增加后，4对4取余会在Node0中，这样，Node3的增加对其他Node中的命中会产生很大的影响，使命中率大大下降。对此问题，分布式缓存的额伸缩性中可以使用hash环的算法。

    伸缩性问题在数据库上，可以分为关系数据库与NoSql数据库考虑，关系数据库可以使用Cobar访问代理，NoSql中HBase已经支持伸缩性。

17. 第七章讲的是可扩展，目前主要有消息队列与分布式服务框架。webservice能够提供远程的服务，但无法满足大企业的需求，分布式的服务框架有Facebook的Thrift和阿里的Dubbo。

18. Spring Jetty JBoss Servlet Struts

19. wiki使用免费开源的软件实现如此高的访问量，很大程度上是业务上的简化，例如使用CDN并要求尽可能少的动态页面。有点类似价值工程，只实现最必要的功能。

20. 磁盘也有竞争！这可以解释当进行大量IO操作的时候，为什么系统会卡顿的问题。如果进行一个大文件的读取，这时候可能会占用长时间的磁盘操作，而会影响到其他的业务。这也要求大文件与小文件需要分开放置，以免突然的大文件操作，打乱读取小文件的节奏。