第一章 分布式系统介绍

分布式系统的定义：组件分布在网络计算机上，组件间仅仅通过消息传递来通信并协调行动。

分布式系统的意义：

• 升级单机处理能力的性价比越来越低
• 单机处理能力存在瓶颈
• 处于稳定性和可用性的考虑

摩尔定律：当价格不变时，每隔18个月，集成电路上可容纳的晶体管数目会增加一倍，性能也将提升一倍。

线程与进程的执行模式

冯诺依曼结构：输入设备、输入设备、运算器、控制器、存储器。

基于共享容器协同的多线程模式：经典如生产者消费者问题，对于存储数据的容器或对象，有线程安全和不安全之分，对于不安全的容器或对象，一般可以通过加锁或者通过Copy On Write的方式控制并发。

通过事件协同的多线程模式：避免死锁

多进程模式：

• 线程是属于进程的，一个进程内的多个线程共享了进程的内存空间；而多个进程间的内存空间是独立的，因此多个进程间通过内存共享、交换数据的方式与多个线程间就有所不同
• 此外，进程间通信、协调，以及通过一些事件通知或者等待一些互斥锁的释放方面也不一样
• 多进程相对于单进程多线程来说，资源控制会更容易实现；多进程中单个进程出现问题，不会造成整体的不可用
• 多进程之间可以共享数据，但其代价较大，会涉及序列化和反序列化的开销

网络通信基础知识

OSI七层模型与TCP/IP模型：

Socket套接字进行网络通信开发时，用到的三种方式：BIO、NIO和AIO

BIO：Blocking IO，采用阻塞的方式实现，一个线程处理一个Socket，发生建立连接、读数据、写数据的操作时，都可能会阻塞。

NIO：Nonblocking IO，基于时间驱动思想，采用Reactor模式，可以在一个线程中处理多个Socket套接字

AIO：AsynchronousIO，异步IO，采用Proactor模式，与NIO的差别是，AIO在进行读写操作时，只需要调用响应的read/write方法，并且需要传入CompletionHandler，在动作完成后会调用。

如何把应用从单机扩展到分布式

输入设备的变化

输出设备的变化

控制器的变化

方式1和2，透明代理：对发起方和处理方都是透明的

• 使用硬件负载均衡
• 使用LVS（或其他软件负载均衡系统）

缺点：

• 会增加网络的开销，一方面指流量，另一方面指延迟
• 这个透明代理处于请求的必经之路，如果代理出现问题，所有请求都会受到影响。我们需要考虑代理服务器的热备份

方式3，采用名称服务器直连的方式：

请求发起方和处理方直接没有代理服务器，而是直接连接。外部多了一个“名称服务”的角色，作用有：

• 收集提供请求处理的服务器的地址信息
• 提供这些地址信息给请求发起方

名称服务只是起到一个地址交换的作用，在发起请求的机器上，需要根据从名称服务得到的地址进行负载均衡的工作。

优点如下：

• 名称服务器出现问题，有办法可以保证处理正常
• 发起方和处理方直连，减少中间路径和带宽小号

缺点就是代码升级较复杂

方式4，采用规则服务器控制路由的请求直连调用

与名称服务器不同的是，规则服务器并不和请求处理的机器交互，只负责把规则提供给请求发起的机器。

方式5，Master+Worker的方式

存在一个Master节点来管理任务，由Master把任务分配给不同的Worker进行处理。

运算器的变化

• 通过DNS服务器进行调度和控制
• 增加负载均衡设备，DNS返回的永远是负载均衡地址

存储器的变化

同控制器的变化，加代理服务器、or名称服务器、or规则服务器

分布式系统的难点

• 缺乏全局时钟
• 面对故障独立性
• 处理单点故障，如果不能把单点变为集群，则需要给单点做好备份，降低单点故障影响范围
• 事务的挑战：2PC、最终一致、BASE、CAP、Paxos等

第二章 大型网站及其架构演进过程

大型网站：访问量（PV）、数据量、业务复杂度

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

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

• 服务器选择问题：DNS、集群前加负载均衡设备
• Session的问题

Session保存会话状态，在Web服务器上，各个会话独立存储，多台服务器不能保证每次请求都落在同一边的服务器上。解决方案如下：

1、Session Sticky：负载均衡根据会话标识进行转发，让同样的Session请求每次都发送到同一个服务器端处理

缺点：

• 如果一台Web服务器宕机或重启，会话数据会丢失，用户要重新登录
• 会话标识是应用层信息，则负载均衡要在应用层进行解析，开销比在第四层大
• 负载均衡变为了有状态的节点，要将会话保存到具体Web服务器的映射。内存消耗会变大，容灾更麻烦

2、Session Replication：会话在多态服务器上复制同步

缺点：

• 同步Session数据造成了网络带宽的开销
• 每台Web服务器都要保存所有的Session数据，数据量容易很大

3、Session数据集中存储

Session数据不再Web服务器上，而是放在另一个集中存储的地方。

缺点：

• 读写Session数据引入了网络操作，存在时延和不稳定性
• 如果集中存储Session的机器或者集群有问题，就会影响我们的应用

4、Cookie Based：把Session数据放在Cookie中

缺点：

• Cookie长度的限制
• 安全性：外部访问和修改
• 带宽消耗
• 性能影响：每次HTTP请求都带有Session数据

数据读压力变大，读写分离

1、采用数据库作为读库

缺点：

• 数据复制问题；
• 应用对于数据源的选择问题：写操作和事务走主库，考虑从库相对主库的延迟

2、搜索引擎其实是一个读库

3、加速数据读取的利器——缓存

• 数据缓存，Key-Value，“热数据”，容量不够时清除缓存
• 页面缓存，ESI标签页面缓存

弥补关系型数据库的不足，引入分布式存储系统

分布式文件系统，解决小文件和大文件的存储问题
分布式key-value系统，提供高性能的半结构化支持
分布式数据库提供一个支持大数据、高并发的数据库系统

读写分离后，数据库又遇到瓶颈

尽管读写分离以及分布式存储系统，能够降低主库的压力，但是交易、商品、用户的数据都还在一个数据库中，压力还在继续增加，我们有数据垂直拆分和水平拆分两种选择；

1、专库专用，数据垂直拆分

垂直拆分即把不同的业务数据分到不同的数据库中。

问题：

• 应用需要多个数据源，带来的是每个数据库连接池的隔离
• 单机跨业务事务，一种方法是使用分布式事务，性能较低；另一种办法就是去掉事务

2、单表达到瓶颈，数据水平拆分

水平拆分就是把同一个表的数据拆到两个数据库中。

问题：

• SQL路由问题，选择哪个数据表
• 主键处理等机制不同，如自增主键
• 一些查询需要从两个数据库中取数据，加上分页操作，比较难处理

数据库问题解决后，应用面对的新挑战

拆分应用

• 根据业务特性，还可以根据用户注册、登陆、用户信息维护等再拆分。
• 走服务化的路，共享代码放在各个服务中心，如商品中心、用户中心、交易中心

初识消息中间件

消息中间件是在分布式系统中完成消息发送和接收的基础软件。两个明显好处：异步、解耦。

第三章 构建Java中间件

三个领域的中间件：