前言
只有光头才能变强.
文本已收录至我的 GitHub 仓库, 欢迎 Star: https://github.com/ZhongFuCheng3y/3y
这本书买了一段时间了, 之前在杭州没带过去, 现在读完第三章, 来做做笔记
外行人都能看懂的 SpringCloud, 错过了血亏!
什么是 ZooKeeper?
什么是消息队列?
什么是单点登录(SSO)
一, 为什么分布式?
在之前的文章 (外行人都能看懂的 SpringCloud, 错过了血亏!) 也提过为什么要分布式:
模块之间独立, 各做各的事, 便于扩展, 复用性高
高吞吐量. 某个任务需要一个机器运行 10 个小时, 将该任务用 10 台机器的分布式跑(将这个任务拆分成 10 个小任务), 可能 2 个小时就跑完了
在书上给出的观点:
升级单机的处理能力的性价比越来越低, 单机的处理能力存在瓶颈
分布式系统更加稳定和可用(单机挂了就挂了, 分布式挂了一般还有备用 / 不至于整个链路全挂)
1.1 大型网站架构演进过程
其实在没接触过分布式之前, 在逛论坛的时候, 经常会出现一些看起来很牛逼的词, 诸如 "读写分离","分库分表","主从架构","负载均衡","单点故障" 等等名词, 就觉得很高大上. 下面我就稍微顺着 "大型网站架构演进过程" 来讲解一下这些词
在我们最开始接触 Java 项目的时候, 一般来说是单机的(数据库, web 服务器都是同一台机器)
网站对外开放以后, 访问量增大, 服务器的压力也随之提高. 此时, 我们最简单的做法就是可以将数据库和应用分开, 这样可以缓解一下当前系统的压力
应用服务器的压力继续增大, 我们可以把应用服务器做成集群(说白了, 就是加了台机器)
加了台应用服务器以后, 就出现新的问题了:
用户请求的时候, 走哪台服务器啊?
Session 是依赖单台服务器的, 那 Session 怎么搞?
解决用户走哪台服务器, 我们就在用户请求到达应用服务器之前, 加了一个 "负载均衡器", 这个 "负载均衡器" 说白了就写了用户请求会到哪台应用服务器的逻辑
比如说, 一个用户请求过来, 负载均衡器指派这个请求到服务器 A. 另一个用户请求过来, 负载均衡器指派这个请求到服务器 B. 这样就平摊了请求 - 这种方式就叫做轮询
... 策略还有很多种, 就看你想怎么实现了, 反正这个逻辑的代码放在负载均衡器上.
而 Session 的问题, 我之前写什么是单点登录 (SSO) 已经讲过了, 一般来说我们可以将 Session 保存在 Redis 上就行了.
随着业务的发展, 我们的数据量和访问量都在增长, 现在有不少的业务都是读多写少的, 对于这种业务也是会直接反应到数据库上.
于是, 我们可以增加一个读库. 写入的操作走服务器 C 的 MySQL, 读取的操作走服务器 D 的 MySQL. 这样就实现了读写分离.
一般来说, 我们的写库也叫做主库, 读库也叫做从库, 在互联网架构中, 这叫做主从架构, 比如常见的架构: 一主多从(详细的参考资料: 如何给老婆解释什么是 Master-Slave https://mp.weixin.qq.com/s/VF1_Ehat8GXkb9EqLUn6lg )
针对读多写少的业务, 我们还有优化策略, 引入搜索引擎和缓存.
搜索引擎也相当于一个读库, 使用搜索引擎的倒排表方式, 能够大大提升检索的速度
缓存则将热数据放入内存中, 如果查询的数据在缓存中存在, 则直接返回
搜索引擎和缓存的参考资料:
Redis 合集 https://mp.weixin.qq.com/s/3Fmv7h5p2QDtLxc9n1dp5A
什么是 Lucene https://mp.weixin.qq.com/s/PaVymD_93afWM5XVB3nGfA
Elasticsearch 入门 https://mp.weixin.qq.com/s/3IIRObB6BAIJnnGXhnPM3Q
注: 这里说的索引和缓存就未必特指 ES 和 Redis, 比如缓存我也可以用本地缓存而不一定是 Redis 的. 这里用 Redis 和 ES 只是我画图方便.
继读写分离之后, 数据库还是遇到了瓶颈, 此时我们就可以采用分库分表策略了:
垂直拆分 - 不同的业务数据分到不同的数据库
水平拆分 - 将同一张表的数据拆分到不同的数据库中(原因是这张表的数据量 / 更新量太大了)
注: 单表行数超过 500 万行或者单表容量超过 2GB 才推荐进行分库分表(如果预计三年都达不到这个数据量, 不要在创建表的时候就分库分表!) -《阿里巴巴 Java 开发手册》
在数据存储方面, 除了关系型数据库之外, 如果有别的业务场景, 可能还需要引入分布式存储系统
分布式文件系统
分布式 Key-Value 系统
分布式数据库
数据库问题解决之后, 应用也面临着挑战(应用的功能会越做越多, 应用也随之越做越大), 为了不让应用持续变大, 这就需要把应用拆开, 从一个应用变为两个 / 多个应用.
不同功能 / 模块之间的调用不再单纯通过本机调用, 引入了远程的服务调用.
某个应用只有一台机器上运行着, 如果这台机器上出现了问题, 导致这个应用无法运行, 这就叫单点故障.
最后
这本书《大型网站系统与 Java 中间件》的前三章主要是铺垫什么是中间件, 什么是分布式 (从单机演进到分布式的过程) 以及讲述了网站的架构演进过程, 剩下的是回顾一些基础. 比如说:
- bio/nio/aio
- HTTP/Session
- JVM
Java 多线程以及并发的基础知识
JUC 包下的常见类
这些我都曾经多多少少都做过笔记, 不妨在我的公众号下找找相关的文章. 总的来说, 还是读得很过瘾的! 后面读完下面的章节, 我会继续分享, 敬请期待.
乐于输出干货的 Java 技术公众号: Java3y. 公众号内有 200 多篇原创技术文章, 海量视频资源, 精美脑图, 关注即可获取!
觉得我的文章写得不错, 点赞!
来源: https://www.cnblogs.com/Java3y/p/10996156.html