《大型网站技术架构》读书笔记

1.分层: 应用层/服务层/逻辑层

2.应用服务与数据服务分离: 应用服务处理逻辑，所以需要更快CPU，数据库检索与存储，需要更大内存，硬盘

3.大部分业务集中访问一小部分数据: 缓存

4. 数据库读写分离。 主数据库负责写，从数据库负责读。主数据库将更新数据异步写到从数据库中

5. CDN：静态文件部署在网络提供商离用户最近的节点。距离短，读的更快

6. 业务拆分，不同业务拆分成不同的server，独立部署。这样比如用户信息等服务就可以复用

7. 为了增强可用性，访问量很小的分布式应用和服务，也至少要部署两台服务器成为一个集群

8. 缓存的两个条件: 1.数据访问热点不均 2. 数据不会很快过期

9. 伸缩性:

1) 服务器无状态，不保存数据，所有服务器是对等的，所以可以任意添加服务器

2) 数据库伸缩: 通过路由分区，将多个数据库组成一个集群

10. Web前端优化:

1)浏览器相关:

a,减少http请求，css/js合并成一个文件

b.压缩

c.减少cookie传输

d.缓存

2)CDN: 离用户最近

10. 缓存服务器

1)缓存的本质是一个hash表。新启动时需要提前预热。

2) 更新同步（JBOSS）/异步更新(memberCache，互相不通信)

3) memberCache: 根据key拿对应的值。

a. slab-chuck.LRU算法。一个chuck只能存储一个数据

b. 一致性hash，防止新加节点导致数据不均匀。一个圆，然后每台服务器对应几个节点，新加的服务器的节点均匀分布在圆上

11.异步操作: 消息队列具有很好的消峰作用

12.负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时，就将其从集群列表中剔除

13.Session管理:

1)session复制，每台服务器上都有。不适合大集群

2)Session绑定: 负载均衡服务器决定去哪个服务器，一直有对应的sessin,但是服务器挂了就完了

3)利用cookie记录session。将session记录在客户端，每次通过cookie返回。大小受限制

4)Session服务器: 无状态的应用服务器和有状态的session服务器,用member cache与Redius存储

14.应用服务器认为失败，重复调用服务，无法避免，因为它们不关心是否真正成功，只要没有响应，就继续调用。所以必须在服务层保证服务重复调用和调用一次产生的结果相同

15. 发布过程:

1) 发布过程，每次关闭服务器都是一小部分，保证整个发布过程不影响用户使用

2) 灰度发布: 每天只发布一部分服务器，观察，没问题再发布

16.解耦:

1) WS调用

2)消息队列服务器

17. 文本匹配 Trie树

18.反向代理服务器:

1) 正向代理在客户端，通过代理发出去。反向代理在服务器端，与真正的服务器隔着防火墙，更安全

2) 正向代理:代理服务器帮你访问，可以访问一些你本机访问不到的网站。另外可以控制公司内部哪些电脑可以上外网，哪些不可以

3)

19. 故障案例:

1) 日志级别设定错误导致硬盘空间迅速不够。Warn

2) 首页访问数据库，导致直接挂掉。 首页不应该访问数据库，静态页面或者缓存数据

3) 某个单例对象被锁导致超时报警

4) 缓存没有预热，导致数据库服务器崩溃

5) 文件上传慢，大的文件和小的文件混在一起。大文件影响了小文件的读取

二.具体模块实现

1.用户注册信息模块:

1).注册提交将消息放到注册队列中，返回成功信息

2).插入数据库，开放权限，用户注册成功邮件异步从消息队列里读，异步

2.黑名单:如果用hash表的话会很多。用布隆过滤器要一个二进制存储空间，将email映射成8位放到存储空间不同位置.查询时这几个位置都为1才说明有。当然有误判。

3.秒杀系统:

1)独立部署，即使崩溃了，也崩溃它一个

2)秒杀页面为一个静态页面，下单的url为动态的，加上一个js文件引用，秒杀开始时生成一个新的js控制浏览器页面展示，开始秒杀。此js不能被缓存

3)为了减轻服务器的负载压力，少量用户可以进入下单页面，其余用户直接进入秒杀失败页面