《大型网站系统与Java中间件》读书笔记（上）

news/2024/5/20 23:22:45/文章来源:https://blog.csdn.net/wanghao112956/article/details/94430236

前言

只有光头才能变强。

文本已收录至我的GitHub仓库，欢迎Star：github.com/ZhongFuChen…

（想自学习编程的小伙伴请搜索圈T社区，更多行业相关资讯更有行业相关免费视频教程。完全免费哦!）

一、为什么分布式？

在之前的文章也提过为什么要分布式：

模块之间独立，各做各的事，便于扩展，复用性高
高吞吐量。某个任务需要一个机器运行10个小时，将该任务用10台机器的分布式跑(将这个任务拆分成10个小任务)，可能2个小时就跑完了

在书上给出的观点：

升级单机的处理能力的性价比越来越低，单机的处理能力存在瓶颈
分布式系统更加稳定和可用（单机挂了就挂了，分布式挂了一般还有备用/不至于整个链路全挂）

1.1 大型网站架构演进过程

其实在没接触过分布式之前，在逛论坛的时候，经常会出现一些看起来很牛逼的词，诸如”读写分离“、”分库分表“、”主从架构“、”负载均衡“、”单点故障“等等名词，就觉得很高大上。下面我就稍微顺着”大型网站架构演进过程“来讲解一下这些词

在我们最开始接触Java项目的时候，一般来说是单机的（数据库、Web服务器都是同一台机器）
在这里插入图片描述
网站对外开放以后，访问量增大，服务器的压力也随之提高。此时，我们最简单的做法就是可以将数据库和应用分开，这样可以缓解一下当前系统的压力

应用服务器的压力继续增大，我们可以把应用服务器做成集群（说白了，就是加了台机器）
在这里插入图片描述
加了台应用服务器以后，就出现新的问题了：

用户请求的时候，走哪台服务器啊？
Session是依赖单台服务器的，那Session怎么搞？

解决用户走哪台服务器，我们就在用户请求到达应用服务器之前，加了一个”负载均衡器“，这个”负载均衡器“说白了就写了用户请求会到哪台应用服务器的逻辑

比如说，一个用户请求过来，负载均衡器指派这个请求到服务器A。另一个用户请求过来，负载均衡器指派这个请求到服务器B。这样就平摊了请求— 这种方式就叫做轮询
…策略还有很多种，就看你想怎么实现了，反正这个逻辑的代码放在负载均衡器上。

而Session的问题，一般来说我们可以将Session保存在Redis上就行了。
在这里插入图片描述
随着业务的发展，我们的数据量和访问量都在增长，现在有不少的业务都是读多写少的，对于这种业务也是会直接反应到数据库上。

于是，我们可以增加一个读库。写入的操作走服务器C的MySQL，读取的操作走服务器D的MySQL。这样就实现了读写分离。
在这里插入图片描述
一般来说，我们的写库也叫做主库，读库也叫做从库，在互联网架构中，这叫做主从架构，比如常见的架构：一主多从

针对读多写少的业务，我们还有优化策略，引入搜索引擎和缓存。