大型网站系统与Java中间件实践 试读

阅读更多

试读章节:第2章 大型网站及其架构演进过程 

大型网站的特质

海量数据、高并发的访问量、本身业务和系统的复杂度

作者(淘宝技术总监)精炼地诠释了大型网站的特质,很到位

 

Session共享解决方案

这是分布式系统的第一个坑,作者给出了4种解决方案,听过和做过的区别就是后者可以回忆式地娓娓道来

1. Session Sticky:负载均衡器能够根据每次请求的会话标识来进行请求转发

缺点:

如果有一台 Web 服务器宕机或者重启,那么这台机器上的会话数据会丢失。如果会话中有登录状态数据,那么用户就要重新登录了。 

会话标识是应用层的信息,那么负载均衡器要将同一个会话的请求都保存到同一个 Web服务器上的话,就需要进行应用层(第 7 层)的解析,这个开销比第 4 层的交换要大。 

负载均衡器变为了一个有状态的节点,要将会话保存到具体 Web 服务器的映射。和无状态的节点相比,内存消耗会更大,容灾方面会更麻烦。 

 

2. Session Replication:Web服务器之间则增加了会话数据的同步

缺点:

同步 Session 数据造成了网络带宽的开销。只要 Session 数据有变化,就需要将数据同步到所有其他机器上,机器数越多,同步带来的网络带宽开销就越大。 

每台 Web 服务器都要保存所有的 Session 数据,如果整个集群的 Session 数很多(很多人在同时访问网站)的话,每台机器用于保存 Session 数据的内容占用会很严重。 

 

3. Session 数据集中存储:把 Session 数据集中存储起来,然后不同 Web 服务器从同样的地方来获取 Session

缺点:

读写 Session 数据引入了网络操作,这相对于本机的数据读取来说,问题就在于存在时延和不稳定性,不过我们的通信基本都是发生在内网,问题不大。 

如果集中存储 Session 的机器或者集群有问题,就会影响我们的应用。 

 

4. Cookie Based:通过 Cookie 来传递 Session 数据

Cookie 长度的限制。我们知道 Cookie是有长度限制的,而这也会限制 Session 数据的长度。 

安全性。Session 数据本来都是服务端数据,而这个方案是让这些服务端数据到了外部网络及客户端,因此存在安全性上的问题。我们可以对写入 Cookie 的 Session 数据做加密,不过对于安全来说,物理上不能接触才是安全的。 

带宽消耗。这里指的不是内部 Web 服务器之间的带宽消耗,而是我们数据中心的整体外部带宽的消耗。 

性能影响。每次 HTTP请求和响应都带有 Session 数据,对 Web 服务器来说,在同样的处理情况下,响应的结果输出越少,支持的并发请求就会越多。 

 

环节数据读压力

读写分离、索引、缓存,都不陌生,倒要看看此书里是怎个实现

采用数据库作为读库:读写分离、主从复制:主库写、从库读

搜索集群(Search Cluster):一种是按照全量/增量划分,一种是按照实时/非实时划分

全量方式用于第一次建立索引(可能是新建,也可能是重建),而增量方式用于在全量的基础上持续更新索引。当然,增量构建索引的挑战非常大,一般会加入每日的全量作为补充。

这个办法确实不错 应该是不断实践和群体智慧

数据缓存 Key-Value

页面缓存 把渲染与缓存的工作结合在一起

讲到页面缓存,我很疑惑为什么作者没有提到varnish

 

数据库分离

这项淘宝的人总分享 烂大街了 不过确实是淘宝的法宝

专库专用,数据垂直拆分:把数据库中不同的业务数据拆分到不同的数据库中

不同业务的数据从原来的一个数据库中拆分到了多个数据库中,那么就需要考虑如何处理原来单机中跨业务的事务。一种办法是使用分布式事务,其性能要明显低于之前的单机事务;而另一种办法就是去掉事务或者不去追求强事务支持,则原来在单库中可以使用的表关联的查询也就需要改变实现了。 

 

垂直拆分后的单机遇到瓶颈,数据水平拆分:把同一个表的数据拆到两个数据库中

应用系统需要解决 SQL 路由的问题

主键的处理

一些查询需要从两个数据库中取数据,如果数据量太大而需要分页,就会比较难处理了

 

又一套淘宝特色的分布式道路

服务化和消息中间件解决分布式系统的通信问题

你可能感兴趣的:(大型网站系统与Java中间件实践 试读)