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

文中作者说明观点“山寨与创新的最大区别不在于抄袭，不在于模仿，而在于对于问题和需求是否真正理解与把握”的时候举了新浪微博中的例子，当大V发布微博的时候会存在大量的写数据库操作。为了避免数据库负担，可以只写并推送那些在线的用户的部分，而那写不在线的，等他们上线的时候会去主动查询。其实也是通过业务而改进设计，避免不必要操作节约资源的一个例子。

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

PV(page view)，一般会以日为单位计算

QPS（TPS）：每秒钟request/事务 数量

并发数：系统同时处理的request/事务数

响应时间：一般取平均响应时间

上面四个关系QPS（TPS）= 并发数/平均响应时间

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

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

第一类大的系统级别的分离，例如数据库系统，缓存系统，文件管理系统（静态资源），演化过程为：为单一服务器->数据库分离->缓存分离->静态资源分离。

第二类业务流程的抽象分离，从下到上的模块为：数据库->基础技术服务->可复用业务服务->具体的产品。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已经支持伸缩性。