大型网站系统与Java中间件实践第二章的笔记

我本身不是很了解这方面的知识，看了本章之后从理论上收获颇多，很希望能够阅读其他章节，并且很希望其他章节给出具体的实现方案，用实际中的例子详细讲解，最好是能够附带详细的代码。

• 分布式系统的难点？

分布式系统的搭建涉及到了很多方面的知识，比如硬件 系统 各种中间件等等

性能的测试很难

• 大型网站及其架构演进过程？

1.服务器

1.1 数据库服务器独立和集群

1.2应用服务器独立和集群

 2.数据库(或存储)

2.1对于数据库，除了独立的数据库服务器和服务器集群，还有垂直分表 水平分表 主库和读库

2.2添加分布式文件系统

2.3添加缓存功能

3.对应用的拆分

4.把系统设计成中间件的，即服务的方式

• 谈谈你对这本书试读章节的看法。

大型网站系统(分布式系统)与Java中间件实践第二章首先讲解了大型网站在发展过程中系统架构的发展过程，在讲解到应用层面架构发展时适时引出了中间件，从大型网站的架构演进过程入手，先从整体上了解这个变化过程，再阐明为什么中间件会诞生确实是很不错的思路。

下面是学习笔记：

1.什么是大型网站

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

访问量很大不是成为大型网站的一个充分条件

访问量和数据量二者缺一不可

2.大型网站中，最核心的功能就是计算和存储

3.单机负载告警，数据库与应用分离

4.应用服务器负载告警，让应用服务器走向集群

4.1最终用户对多个应用服务器访问的选择问题

通过 DNS来解决，也可以通过在应用服务器集群前增加负载均衡设备来解决

4.2 Session 的问题

4.2.1 Session Sticky

保证同一个会话的请求都在同一个 Web 服务器上处理

需要负载均衡器能够根据每次请求的会话标识来进行请求转发

4.2.1.1问题

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

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

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

4.2.2 Session Replication

Web服务器之间增加了会话数据的同步，通过同步就保证了不同 Web 服务器之间的 Session 数据的一致

4.2.2.1 问题

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

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

这个方案是靠应用容器来完成 Session 的复制从而使得应用解决Session 问题的，应用本身并不用关心这个事情。

这个方案不适合集群机器数多的场景。如果只有几台机器，用这个方案是可以的。

4.2.3 Session 数据集中存储 

4.2.4 Cookie Based 

对于同一个会话的不同请求也是不限制具体处理机器的。 和Session Replication 以及 Session 数据集中管理的方案不同，这个方案是通过 Cookie 来传递 Session 数据的。

Session数据放在Cookie中， 然后在Web服务器上从Cookie中生成对应的 Session 数据

 

相对于集中存储，这个方案不会依赖外部的一个存储系统，也就不存在从外部系统获取、写入 Session 数据的网络时延、不稳定性了。

4.2.4.1 问题

Cookie 长度的限制。Cookie是有长度限制的，而这也会限制 Session 数据的长度。

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

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

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

4.2.5 四种方式的对比

对于大型网站来说，Session Sticky和 Session 数据集中存储是比较好的方案，而这两个方案又各有优劣，需要在具体的场景中做出选择和权衡。

5.数据库

5.1采用数据库作为读库

对于大型网站来说，有不少业务是读多写少的，这个状况也会直接反应到数据库上。那么对于这样的情况，可以考虑使用读写分离的方式。

5.1.1问题

5.1.1.1数据复制问题

数据复制时延问题，以及复制过程中数据的源和目标之间的映射关系及过滤条件的支持问题

数据库系统的数据复制的功能

数据库系统层面提供的对数据复制的支持是相对有限的

5.1.1.2应用对于数据源的选择问题。 

写操作要走主库，事务中的读也要走主库

 5.2搜索引擎其实是一个读库

需要根据被搜索的数据来构建索引

搜索集群（Search Cluster）的使用方式和读库的使用方式是一样的。只是构建索引的过程基本都是需要我们自己来实现的。

5.2.1搜索系统构建索引的方式

5.2.1.1 按照全量/增量划分

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

5.2.1.2按照实时/非实时划分

实时/非实时的划分方式体现在索引更新的时间上了

5.3 缓存

5.3.1.数据缓存

大型系统中的数据缓存主要用于分担数据库的读的压力

缓存系统一般是用来保存和查询键值（Key-Value）对的

缓存中数据的填充方式会有不同， 一般在缓存中放的是“热”数据而不是全部数据，那么填充方式就是通过应用完成的，即应用访问缓存，如果数据不存在，则从数据库读出数据后放入缓存。随着时间的推移，当缓存容量不够需要清除数据时，最近不被访问的数据就被清除了。

在数据库的数据发生变化后，主动把数据放入缓存系统中。这样的好处是，在数据变化时能够及时更新缓存中数据，不会造成读取失效。这种方式一般会用于全数据缓存的情况。使用这种方式有一个要求，即根据数据库记录的变化去更新缓存的代码要能够理解业务逻辑。

 

5.3.2.页面缓存

数据缓存可以加速应用在响应请求时的数据读取速度，但是最终应用返回给用户的主要还是页面，有些动态产生的页面或页面的一部分特别热，可以对这些内容进行缓存。ESI就是针对这种情况的一个规范。从具体的实现上来说，可以采用 ESI或者类似的思路来做，也可以把页面缓存与页面渲染放在一起处理

 

缓存命中率 数据的分布与更新策略。从分布上来说，我们主要考虑的问题是需要有机制去避免局部的热点， 并且缓存服务器扩容或者缩容要尽量平滑 （一致性 Hash 会是不错的选择） 。而在缓存的数据的更新上，会有定时失效、数据变更时失效和数据变更时更新的不同选择。

5.4.分布式存储系统 

分布式文件系统就是在分布式环境中由多个节点组成的功能与单机文件系统一样的文件系统，它是弱格式的，内容的格式需要使用者自己来组织；而分布式Key-Value系统相对分布式文件系统会更加格式化一些；分布式数据库则是最格式化的方式了

 

分布式存储系统自身起到了存储的作用，也就是提供数据的读写支持。相对于读写分离中的读“源” ，分布式存储系统更多的是直接代替了主库。分布式存储系统通过集群提供了一个高容量、高并发访问、数据冗余容灾的支持。通过分布式文件系统来解决小文件和大文件的存储问题，通过分布式 Key-Value 系统提供高性能的半结构化的支持，通过分布式数据库提供一个支持大数据、高并发的数据库系统。

5.5.垂直分库

把数据库中不同的业务数据拆分到不同的数据库中

跨业务的事务：一种办法是使用分布式事务，其性能要明显低于之前的单机事务；而另一种办法就是去掉事务或者不去追求强事务支持，则原来在单库中可以使用的表关联的查询也就需要改变实现了。

5.5.水平分库

把同一个表的数据拆到两个数据库中。 产生数据水平拆分的原因是某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈，这时就可以把这个表拆到两个或者多个数据库中。数据水平拆分与读写分离的区别是， 读写分离解决的是读压力大的问题， 对于数据量大或者更新量的情况并不起作用。数据水平拆分与数据垂直拆分的区别是，垂直拆分是把不同的表拆到不同的数据库中，而水平拆分是把同一个表拆到不同的数据库中。

5.5.1.问题

首先，访问用户信息的应用系统需要解决 SQL 路由的问题，因为现在用户信息分在了两个数据库中，需要在进行数据库操作时了解需要操作的数据在哪里。

 

  此外，主键的处理也会变得不同。原来依赖单个数据库的一些机制需要变化，例如原来使用 Oracle 的 Sequence 或者 MySQL 表上的自增字段的，现在不能简单地继续使用了。并且在不同的数据库中也不能直接使用一些数据库的限制来保证主键不重复了。

  最后，由于同一个业务的数据被拆分到了不同的数据库中，因此一些查询需要从两个数据库中取数据，如果数据量太大而需要分页，就会比较难处理了。 

 

 6.应用

第一种方式，根据业务的特性把应用拆开

第二种方式，走服务化的路

首先，业务功能之间的访问不仅是单机内部的方法调用了，还引入了远程的服务调用。其次，共享的代码不再是散落在不同的应用中了，这些实现被放在了各个服务中心。第三，数据库的连接也发生了一些变化，我们把与数据库的交互工作放到了服务中心，让前端的 Web 应用更加注重与浏览器交互的工作，而不必过多关注业务逻辑的事情。连接数据库的任务交给相应的业务服务中心了，这样可以降低数据库的连接数。 而服务中心不仅把一些可以共用的之前散落在各个业务的代码集中了起来，并且能够使这些代码得到更好的维护。第四，通过服务化，无论是前端 Web 应用还是服务中心，都可以是由固定小团队来维护的系统，这样能够更好地保持稳定性，并能更好地控制系统本身的发展，况且稳定的服务中心日常发布的次数也远小于前端 Web 应用，因此这个方式也减小了不稳定的风险。 

7.消息中间件 

面向消息的系统（消息中间件）是在分布式系统中完成消息的发送和接收的基础软件。

 

 7.1好处

异步和解耦