前言

这本书买了一段时间，之前在杭州没带过去。最近读完了第三章，整理一下笔记。

前三章主要科普和回顾中间件/分布式的基础，讲得非常通俗易懂。这里把核心内容梳理出来，算是给自己的沉淀。

一、为什么分布式？

为什么要分布式？可以从几个角度来理解：

• 模块之间独立，各做各的事，便于扩展，复用性高。
• 高吞吐量：一台机器跑10小时的任务，用10台机器拆分成小任务，可能2小时就跑完了。
• 从单机升级角度看，升级单机处理能力的性价比越来越低，而且单机存在瓶颈。
• 分布式系统更稳定、更可用——单机挂了就全挂了，分布式挂了还有备用，不至于整个链路瘫痪。

1.1 大型网站架构演进过程

在没接触过分布式之前，常看到一些看起来很牛的词：“读写分离”“分库分表”“主从架构”“负载均衡”“单点故障”……下面顺着“大型网站架构演进过程”来拆解这些概念。

最初接触Ja va项目时，通常是单机架构：数据库和Web服务器都在同一台机器上。

网站对外开放后，访问量增大，服务器压力随之提高。最简单的做法是把数据库和应用分开，缓解系统压力。

应用服务器压力继续增大，可以把应用服务器做成集群——说白了就是加了一台机器。

加了台应用服务器后，新问题出现了：用户请求该走哪台服务器？Session依赖单台服务器，Session怎么处理？

解决用户请求的分配问题，需要在请求到达应用服务器之前加一个“负载均衡器”。负载均衡器里写的是用户请求分发到哪台服务器的逻辑——比如轮询，一个请求去服务器A，下一个去服务器B，平摊请求。策略很多，就看怎么实现，代码都放在负载均衡器上。

Session的问题，之前讲单点登录时已经讨论过：通常的做法是把Session保存在Redis上。

随着业务发展，数据量和访问量都在增长，很多业务是读多写少的，这种压力直接反应到数据库上。

于是可以增加一个读库：写入操作走服务器C的MySQL，读取操作走服务器D的MySQL，实现读写分离。

通常写库也叫主库，读库也叫从库，互联网架构中叫主从架构，常见的有“一主多从”。

针对读多写少的业务，还有更多优化策略：引入搜索引擎和缓存。搜索引擎相当于一个读库，利用倒排表大幅提升检索速度；缓存则将热数据放入内存，命中则直接返回。

需要说明的是，这里的搜索引擎和缓存未必特指ES和Redis，缓存也可以用本地缓存。这里用Redis和ES只是画图方便。

继读写分离之后，数据库仍然可能遇到瓶颈，此时可以采用分库分表策略：

• 垂直拆分——不同业务数据分到不同数据库。
• 水平拆分——同一张表的数据拆分到不同数据库（因为这张表数据量或更新量太大）。

根据《阿里巴巴 Ja va 开发手册》，单表行数超过500万行或单表容量超过2GB才推荐分库分表——如果预计三年都达不到这个量，不要在建表时就分库分表。

数据存储方面，除了关系型数据库，还可能引入分布式存储系统，比如分布式文件系统、分布式 Key-Value 系统、分布式数据库。

数据库问题解决之后，应用也面临挑战：功能越做越多，应用越来越大。为了避免应用持续膨胀，需要把应用拆开，从一个变成两个或多个。

不同功能/模块之间的调用不再单纯通过本机调用，引入了远程服务调用。

某个应用只在一台机器上运行，如果这台机器出现问题导致应用无法运行，这就是单点故障。

最后

《大型网站系统与Ja va中间件》的前三章主要铺垫：什么是中间件、什么是分布式（从单机演进到分布式的过程），以及网站的架构演进过程。剩下的章节回顾了一些基础，比如BIO/NIO/AIO、HTTP/Session、JVM、Ja va多线程及并发基础、JUC包下的常见类。

总的来说，读得很过瘾。后面读完下面的章节，会继续分享。