mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-16 18:10:13 +08:00
[feat]内容重构，删除无用文章，优化文件名
This commit is contained in:
guide
parent
8f138f2ecf
commit
3dd194a19f
30
README.md
30
README.md
@ -48,15 +48,10 @@
|
||||
|
||||
### 基础
|
||||
|
||||
**知识点/面试题** : (必看:+1: )
|
||||
|
||||
1. **[Java 基础知识](docs/java/basis/Java基础知识.md)**
|
||||
2. [Java 基础知识疑难点/易错点](docs/java/basis/Java基础知识疑难点.md)
|
||||
**知识点/面试题** : (必看:+1: )：[Java 基础知识点/面试题总结](docs/java/basis/Java基础知识.md)
|
||||
|
||||
**重要知识点详解：**
|
||||
|
||||
1. [枚举](docs/java/basis/用好Java中的枚举真的没有那么简单.md) （很重要的一个数据结构，用好枚举真的没有那么简单！）
|
||||
2. [Java 常见关键字总结：final、static、this、super!](docs/java/basis/Java常见关键字总结.md)
|
||||
3. [什么是反射机制？反射机制的应用场景有哪些？](docs/java/basis/反射机制.md)
|
||||
4. [代理模式详解：静态代理+JDK/CGLIB 动态代理实战](docs/java/basis/代理模式详解.md)
|
||||
5. [常见的 IO 模型有哪些？Java 中的 BIO、NIO、AIO 有啥区别?](docs/java/basis/IO模型.md)
|
||||
@ -156,25 +151,24 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle
|
||||
**总结：**
|
||||
|
||||
1. [数据库基础知识总结](docs/database/数据库基础知识.md)
|
||||
2. **[MySQL知识点总结](docs/database/mysql/MySQL总结.md)** (必看 :+1:)
|
||||
3. [阿里巴巴开发手册数据库部分的一些最佳实践](docs/database/mysql/阿里巴巴开发手册数据库部分的一些最佳实践.md)
|
||||
4. [一千行 MySQL 学习笔记](docs/database/mysql/一千行MySQL学习笔记.md)
|
||||
5. [MySQL 高性能优化规范建议](docs/database/mysql/MySQL高性能优化规范建议.md)
|
||||
2. **[MySQL知识点总结](docs/database/mysql/mysql知识点&面试题总结.md)** (必看 :+1:)
|
||||
4. [一千行 MySQL 学习笔记](docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md)
|
||||
5. [MySQL 高性能优化规范建议](docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md)
|
||||
|
||||
**重要知识点：**
|
||||
|
||||
1. [MySQL数据库索引总结](docs/database/mysql/MySQL数据库索引.md)
|
||||
2. [事务隔离级别(图文详解)](docs/database/mysql/事务隔离级别(图文详解).md)
|
||||
3. [MySQL三大日志(binlog、redo log和undo log)详解](docs/database/mysql/MySQL三大日志.md)
|
||||
4. [InnoDB存储引擎对MVCC的实现](docs/database/mysql/InnoDB对MVCC的实现.md)
|
||||
5. [一条 SQL 语句在 MySQL 中如何执行的?](docs/database/mysql/一条sql语句在mysql中如何执行的.md)
|
||||
1. [MySQL数据库索引总结](docs/database/mysql/mysql-index.md)
|
||||
2. [事务隔离级别(图文详解)](docs/database/mysql/transaction-isolation-level.md)
|
||||
3. [MySQL三大日志(binlog、redo log和undo log)详解](docs/database/mysql/mysql-logs.md)
|
||||
4. [InnoDB存储引擎对MVCC的实现](docs/database/mysql/innodb-implementation-of-mvcc.md)
|
||||
5. [一条 SQL 语句在 MySQL 中如何被执行的?](docs/database/mysql/how-sql-executed-in-mysql.md)
|
||||
6. [字符集详解：为什么不建议在MySQL中使用 utf8 ？](docs/database/字符集.md)
|
||||
7. [关于数据库中如何存储时间的一点思考](docs/database/mysql/关于数据库存储时间的一点思考.md)
|
||||
7. [关于数据库中如何存储时间的一点思考](docs/database/mysql/some-thoughts-on-database-storage-time.md)
|
||||
|
||||
### Redis
|
||||
|
||||
2. [Redis 常见问题总结](docs/database/Redis/redis-all.md)
|
||||
3. [面试/工作必备！3种常用的缓存读写策略！](docs/database/Redis/3种常用的缓存读写策略.md)
|
||||
1. [Redis 常见问题总结](docs/database/redis/redis-all.md)
|
||||
2. [3种常用的缓存读写策略](docs/database/redis/3-commonly-used-cache-read-and-write-strategies.md)
|
||||
|
||||
## 搜索引擎
|
||||
|
||||
|
||||
@ -1,111 +0,0 @@
|
||||
|
||||
非常感谢《redis实战》真本书，本文大多内容也参考了书中的内容。非常推荐大家看一下《redis实战》这本书，感觉书中的很多理论性东西还是很不错的。
|
||||
|
||||
为什么本文的名字要加上春夏秋冬又一春，哈哈 ，这是一部韩国的电影，我感觉电影不错，所以就用在文章名字上了，没有什么特别的含义，然后下面的有些配图也是电影相关镜头。
|
||||
|
||||
|
||||
|
||||
**很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后回复数据），或者是为了防止系统故障而将数据备份到一个远程位置。**
|
||||
|
||||
Redis不同于Memcached的很重要一点就是，**Redis支持持久化**，而且支持两种不同的持久化操作。Redis的一种持久化方式叫**快照（snapshotting，RDB）**，另一种方式是**只追加文件（append-only file,AOF）**。这两种方法各有千秋，下面我会详细这两种持久化方法是什么，怎么用，如何选择适合自己的持久化方法。
|
||||
|
||||
## 快照（snapshotting）持久化
|
||||
|
||||
Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），还可以将快照留在原地以便重启服务器的时候使用。
|
||||
|
||||
|
||||
|
||||
**快照持久化是Redis默认采用的持久化方式**，在redis.conf配置文件中默认有此下配置：
|
||||
|
||||
```
|
||||
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
|
||||
|
||||
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
|
||||
|
||||
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
|
||||
```
|
||||
|
||||
根据配置，快照将被写入dbfilename选项指定的文件里面，并存储在dir选项指定的路径上面。如果在新的快照文件创建完毕之前，Redis、系统或者硬件这三者中的任意一个崩溃了，那么Redis将丢失最近一次创建快照写入的所有数据。
|
||||
|
||||
举个例子：假设Redis的上一个快照是2：35开始创建的，并且已经创建成功。下午3：06时，Redis又开始创建新的快照，并且在下午3：08快照创建完毕之前，有35个键进行了更新。如果在下午3：06到3：08期间，系统发生了崩溃，导致Redis无法完成新快照的创建工作，那么Redis将丢失下午2：35之后写入的所有数据。另一方面，如果系统恰好在新的快照文件创建完毕之后崩溃，那么Redis将丢失35个键的更新数据。
|
||||
|
||||
**创建快照的办法有如下几种：**
|
||||
|
||||
- **BGSAVE命令：** 客户端向Redis发送 **BGSAVE命令** 来创建一个快照。对于支持BGSAVE命令的平台来说（基本上所有平台支持，除了Windows平台），Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。
|
||||
- **SAVE命令：** 客户端还可以向Redis发送 **SAVE命令** 来创建一个快照，接到SAVE命令的Redis服务器在快照创建完毕之前不会再响应任何其他命令。SAVE命令不常用，我们通常只会在没有足够内存去执行BGSAVE命令的情况下，又或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令。
|
||||
- **save选项：** 如果用户设置了save选项（一般会默认设置），比如 **save 60 10000**，那么从Redis最近一次创建快照之后开始算起，当“60秒之内有10000次写入”这个条件被满足时，Redis就会自动触发BGSAVE命令。
|
||||
- **SHUTDOWN命令：** 当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在SAVE命令执行完毕之后关闭服务器。
|
||||
- **一个Redis服务器连接到另一个Redis服务器：** 当一个Redis服务器连接到另一个Redis服务器，并向对方发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令
|
||||
|
||||
如果系统真的发生崩溃，用户将丢失最近一次生成快照之后更改的所有数据。因此，快照持久化只适用于即使丢失一部分数据也不会造成一些大问题的应用程序。不能接受这个缺点的话，可以考虑AOF持久化。
|
||||
|
||||
## **AOF（append-only file）持久化**
|
||||
与快照持久化相比，AOF持久化 的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启：
|
||||
|
||||
```
|
||||
appendonly yes
|
||||
```
|
||||
|
||||
开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。
|
||||
|
||||
|
||||
|
||||
**在Redis的配置文件中存在三种同步方式，它们分别是：**
|
||||
|
||||
```
|
||||
appendfsync always #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
|
||||
appendfsync everysec #每秒钟同步一次，显示地将多个写命令同步到硬盘
|
||||
appendfsync no #让操作系统决定何时进行同步
|
||||
```
|
||||
|
||||
**appendfsync always** 可以实现将数据丢失减到最少，不过这种方式需要对硬盘进行大量的写入而且每次只写入一个命令，十分影响Redis的速度。另外使用固态硬盘的用户谨慎使用appendfsync always选项，因为这会明显降低固态硬盘的使用寿命。
|
||||
|
||||
为了兼顾数据和写入性能，用户可以考虑 **appendfsync everysec选项** ，让Redis每秒同步一次AOF文件，Redis性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
|
||||
|
||||
**appendfsync no** 选项一般不推荐，这种方案会使Redis丢失不定量的数据而且如果用户的硬盘处理写入操作的速度不够的话，那么当缓冲区被等待写入的数据填满时，Redis的写入操作将被阻塞，这会导致Redis的请求速度变慢。
|
||||
|
||||
**虽然AOF持久化非常灵活地提供了多种不同的选项来满足不同应用程序对数据安全的不同要求，但AOF持久化也有缺陷——AOF文件的体积太大。**
|
||||
|
||||
## 重写/压缩AOF
|
||||
|
||||
AOF虽然在某个角度可以将数据丢失降低到最小而且对性能影响也很小，但是极端的情况下，体积不断增大的AOF文件很可能会用完硬盘空间。另外，如果AOF体积过大，那么还原操作执行时间就可能会非常长。
|
||||
|
||||
为了解决AOF体积过大的问题，用户可以向Redis发送 **BGREWRITEAOF命令** ，这个命令会通过移除AOF文件中的冗余命令来重写（rewrite）AOF文件来减小AOF文件的体积。BGREWRITEAOF命令和BGSAVE创建快照原理十分相似，所以AOF文件重写也需要用到子进程，这样会导致性能问题和内存占用问题，和快照持久化一样。更糟糕的是，如果不加以控制的话，AOF文件的体积可能会比快照文件大好几倍。
|
||||
|
||||
**文件重写流程：**
|
||||
|
||||
|
||||
和快照持久化可以通过设置save选项来自动执行BGSAVE一样，AOF持久化也可以通过设置
|
||||
|
||||
```
|
||||
auto-aof-rewrite-percentage
|
||||
```
|
||||
|
||||
选项和
|
||||
|
||||
```
|
||||
auto-aof-rewrite-min-size
|
||||
```
|
||||
|
||||
选项自动执行BGREWRITEAOF命令。举例：假设用户对Redis设置了如下配置选项并且启用了AOF持久化。那么当AOF文件体积大于64mb，并且AOF的体积比上一次重写之后的体积大了至少一倍（100%）的时候，Redis将执行BGREWRITEAOF命令。
|
||||
|
||||
```
|
||||
auto-aof-rewrite-percentage 100
|
||||
auto-aof-rewrite-min-size 64mb
|
||||
```
|
||||
|
||||
无论是AOF持久化还是快照持久化，将数据持久化到硬盘上都是非常有必要的，但除了进行持久化外，用户还必须对持久化得到的文件进行备份（最好是备份到不同的地方），这样才能尽量避免数据丢失事故发生。如果条件允许的话，最好能将快照文件和重新重写的AOF文件备份到不同的服务器上面。
|
||||
|
||||
随着负载量的上升，或者数据的完整性变得越来越重要时，用户可能需要使用到复制特性。
|
||||
|
||||
## Redis 4.0 对于持久化机制的优化
|
||||
Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 `aof-use-rdb-preamble` 开启）。
|
||||
|
||||
如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分就是压缩格式不再是 AOF 格式，可读性较差。
|
||||
|
||||
参考：
|
||||
|
||||
《Redis实战》
|
||||
|
||||
[深入学习Redis（2）：持久化](https://www.cnblogs.com/kismetv/p/9137897.html)
|
||||
|
||||
@ -1,47 +0,0 @@
|
||||
这篇文章主要是对 Redis 官方网站刊登的 [Distributed locks with Redis](https://redis.io/topics/distlock) 部分内容的总结和翻译。
|
||||
|
||||
## 什么是 RedLock
|
||||
|
||||
Redis 官方站这篇文章提出了一种权威的基于 Redis 实现分布式锁的方式名叫 *Redlock*，此种方式比原先的单节点的方法更安全。它可以保证以下特性：
|
||||
|
||||
1. 安全特性：互斥访问，即永远只有一个 client 能拿到锁
|
||||
2. 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
|
||||
3. 容错性：只要大部分 Redis 节点存活就可以正常提供服务
|
||||
|
||||
## 怎么在单节点上实现分布式锁
|
||||
|
||||
> SET resource_name my_random_value NX PX 30000
|
||||
|
||||
主要依靠上述命令，该命令仅当 Key 不存在时（NX保证）set 值，并且设置过期时间 3000ms （PX保证），值 my_random_value 必须是所有 client 和所有锁请求发生期间唯一的，释放锁的逻辑是：
|
||||
|
||||
```lua
|
||||
if redis.call("get",KEYS[1]) == ARGV[1] then
|
||||
return redis.call("del",KEYS[1])
|
||||
else
|
||||
return 0
|
||||
end
|
||||
```
|
||||
|
||||
上述实现可以避免释放另一个client创建的锁，如果只有 del 命令的话，那么如果 client1 拿到 lock1 之后因为某些操作阻塞了很长时间，此时 Redis 端 lock1 已经过期了并且已经被重新分配给了 client2，那么 client1 此时再去释放这把锁就会造成 client2 原本获取到的锁被 client1 无故释放了，但现在为每个 client 分配一个 unique 的 string 值可以避免这个问题。至于如何去生成这个 unique string，方法很多随意选择一种就行了。
|
||||
|
||||
## Redlock 算法
|
||||
|
||||
算法很易懂，起 5 个 master 节点，分布在不同的机房尽量保证可用性。为了获得锁，client 会进行如下操作：
|
||||
|
||||
1. 得到当前的时间，微秒单位
|
||||
2. 尝试顺序地在 5 个实例上申请锁，当然需要使用相同的 key 和 random value，这里一个 client 需要合理设置与 master 节点沟通的 timeout 大小，避免长时间和一个 fail 了的节点浪费时间
|
||||
3. 当 client 在大于等于 3 个 master 上成功申请到锁的时候，且它会计算申请锁消耗了多少时间，这部分消耗的时间采用获得锁的当下时间减去第一步获得的时间戳得到，如果锁的持续时长（lock validity time）比流逝的时间多的话，那么锁就真正获取到了。
|
||||
4. 如果锁申请到了，那么锁真正的 lock validity time 应该是 origin（lock validity time） - 申请锁期间流逝的时间
|
||||
5. 如果 client 申请锁失败了，那么它就会在少部分申请成功锁的 master 节点上执行释放锁的操作，重置状态
|
||||
|
||||
## 失败重试
|
||||
|
||||
如果一个 client 申请锁失败了，那么它需要稍等一会在重试避免多个 client 同时申请锁的情况，最好的情况是一个 client 需要几乎同时向 5 个 master 发起锁申请。另外就是如果 client 申请锁失败了它需要尽快在它曾经申请到锁的 master 上执行 unlock 操作，便于其他 client 获得这把锁，避免这些锁过期造成的时间浪费，当然如果这时候网络分区使得 client 无法联系上这些 master，那么这种浪费就是不得不付出的代价了。
|
||||
|
||||
## 放锁
|
||||
|
||||
放锁操作很简单，就是依次释放所有节点上的锁就行了
|
||||
|
||||
## 性能、崩溃恢复和 fsync
|
||||
|
||||
如果我们的节点没有持久化机制，client 从 5 个 master 中的 3 个处获得了锁，然后其中一个重启了，这是注意 **整个环境中又出现了 3 个 master 可供另一个 client 申请同一把锁！** 违反了互斥性。如果我们开启了 AOF 持久化那么情况会稍微好转一些，因为 Redis 的过期机制是语义层面实现的，所以在 server 挂了的时候时间依旧在流逝，重启之后锁状态不会受到污染。但是考虑断电之后呢，AOF部分命令没来得及刷回磁盘直接丢失了，除非我们配置刷回策略为 fsnyc = always，但这会损伤性能。解决这个问题的方法是，当一个节点重启之后，我们规定在 max TTL 期间它是不可用的，这样它就不会干扰原本已经申请到的锁，等到它 crash 前的那部分锁都过期了，环境不存在历史锁了，那么再把这个节点加进来正常工作。
|
||||
@ -1,269 +0,0 @@
|
||||
相关阅读：
|
||||
|
||||
- [史上最全Redis高可用技术解决方案大全](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247484850&idx=1&sn=3238360bfa8105cf758dcf7354af2814&chksm=cea24a79f9d5c36fb2399aafa91d7fb2699b5006d8d037fe8aaf2e5577ff20ae322868b04a87&token=1082669959&lang=zh_CN&scene=21#wechat_redirect)
|
||||
- [Raft协议实战之Redis Sentinel的选举Leader源码解析](http://weizijun.cn/2015/04/30/Raft%E5%8D%8F%E8%AE%AE%E5%AE%9E%E6%88%98%E4%B9%8BRedis%20Sentinel%E7%9A%84%E9%80%89%E4%B8%BELeader%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/)
|
||||
|
||||
目录：
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
- [Redis 集群以及应用](#redis-集群以及应用)
|
||||
- [集群](#集群)
|
||||
- [主从复制](#主从复制)
|
||||
- [主从链(拓扑结构)](#主从链拓扑结构)
|
||||
- [复制模式](#复制模式)
|
||||
- [问题点](#问题点)
|
||||
- [哨兵机制](#哨兵机制)
|
||||
- [拓扑图](#拓扑图)
|
||||
- [节点下线](#节点下线)
|
||||
- [Leader选举](#Leader选举)
|
||||
- [故障转移](#故障转移)
|
||||
- [读写分离](#读写分离)
|
||||
- [定时任务](#定时任务)
|
||||
- [分布式集群(Cluster)](#分布式集群cluster)
|
||||
- [拓扑图](#拓扑图)
|
||||
- [通讯](#通讯)
|
||||
- [集中式](#集中式)
|
||||
- [Gossip](#gossip)
|
||||
- [寻址分片](#寻址分片)
|
||||
- [hash取模](#hash取模)
|
||||
- [一致性hash](#一致性hash)
|
||||
- [hash槽](#hash槽)
|
||||
- [使用场景](#使用场景)
|
||||
- [热点数据](#热点数据)
|
||||
- [会话维持 Session](#会话维持-session)
|
||||
- [分布式锁 SETNX](#分布式锁-setnx)
|
||||
- [表缓存](#表缓存)
|
||||
- [消息队列 list](#消息队列-list)
|
||||
- [计数器 string](#计数器-string)
|
||||
- [缓存设计](#缓存设计)
|
||||
- [更新策略](#更新策略)
|
||||
- [更新一致性](#更新一致性)
|
||||
- [缓存粒度](#缓存粒度)
|
||||
- [缓存穿透](#缓存穿透)
|
||||
- [解决方案](#解决方案)
|
||||
- [缓存雪崩](#缓存雪崩)
|
||||
- [出现后应对](#出现后应对)
|
||||
- [请求过程](#请求过程)
|
||||
|
||||
<!-- /MarkdownTOC -->
|
||||
|
||||
# Redis 集群以及应用
|
||||
|
||||
## 集群
|
||||
|
||||
### 主从复制
|
||||
|
||||
#### 主从链(拓扑结构)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### 复制模式
|
||||
- 全量复制：Master 全部同步到 Slave
|
||||
- 部分复制：Slave 数据丢失进行备份
|
||||
|
||||
#### 问题点
|
||||
- 同步故障
|
||||
- 复制数据延迟(不一致)
|
||||
- 读取过期数据(Slave 不能删除数据)
|
||||
- 从节点故障
|
||||
- 主节点故障
|
||||
- 配置不一致
|
||||
- maxmemory 不一致:丢失数据
|
||||
- 优化参数不一致:内存不一致.
|
||||
- 避免全量复制
|
||||
- 选择小主节点(分片)、低峰期间操作.
|
||||
- 如果节点运行 id 不匹配(如主节点重启、运行 id 发生变化)，此时要执行全量复制，应该配合哨兵和集群解决.
|
||||
- 主从复制挤压缓冲区不足产生的问题(网络中断，部分复制无法满足)，可增大复制缓冲区( rel_backlog_size 参数).
|
||||
- 复制风暴
|
||||
|
||||
### 哨兵机制
|
||||
|
||||
#### 拓扑图
|
||||
|
||||
|
||||
|
||||
#### 节点下线
|
||||
|
||||
- 主观下线
|
||||
- 即 Sentinel 节点对 Redis 节点失败的偏见，超出超时时间认为 Master 已经宕机。
|
||||
- Sentinel 集群的每一个 Sentinel 节点会定时对 Redis 集群的所有节点发心跳包检测节点是否正常。如果一个节点在 `down-after-milliseconds` 时间内没有回复 Sentinel 节点的心跳包，则该 Redis 节点被该 Sentinel 节点主观下线。
|
||||
- 客观下线
|
||||
- 所有 Sentinel 节点对 Redis 节点失败要达成共识，即超过 quorum 个统一。
|
||||
- 当节点被一个 Sentinel 节点记为主观下线时，并不意味着该节点肯定故障了，还需要 Sentinel 集群的其他 Sentinel 节点共同判断为主观下线才行。
|
||||
- 该 Sentinel 节点会询问其它 Sentinel 节点，如果 Sentinel 集群中超过 quorum 数量的 Sentinel 节点认为该 Redis 节点主观下线，则该 Redis 客观下线。
|
||||
|
||||
#### Leader选举
|
||||
|
||||
- 选举出一个 Sentinel 作为 Leader：集群中至少有三个 Sentinel 节点，但只有其中一个节点可完成故障转移.通过以下命令可以进行失败判定或领导者选举。
|
||||
- 选举流程
|
||||
1. 每个主观下线的 Sentinel 节点向其他 Sentinel 节点发送命令，要求设置它为领导者.
|
||||
2. 收到命令的 Sentinel 节点如果没有同意通过其他 Sentinel 节点发送的命令，则同意该请求，否则拒绝。
|
||||
3. 如果该 Sentinel 节点发现自己的票数已经超过 Sentinel 集合半数且超过 quorum，则它成为领导者。
|
||||
4. 如果此过程有多个 Sentinel 节点成为领导者，则等待一段时间再重新进行选举。
|
||||
|
||||
#### 故障转移
|
||||
|
||||
- 转移流程
|
||||
1. Sentinel 选出一个合适的 Slave 作为新的 Master(slaveof no one 命令)。
|
||||
2. 向其余 Slave 发出通知，让它们成为新 Master 的 Slave( parallel-syncs 参数)。
|
||||
3. 等待旧 Master 复活，并使之成为新 Master 的 Slave。
|
||||
4. 向客户端通知 Master 变化。
|
||||
- 从 Slave 中选择新 Master 节点的规则(slave 升级成 master 之后)
|
||||
1. 选择 slave-priority 最高的节点。
|
||||
2. 选择复制偏移量最大的节点(同步数据最多)。
|
||||
3. 选择 runId 最小的节点。
|
||||
|
||||
>Sentinel 集群运行过程中故障转移完成，所有 Sentinel 又会恢复平等。Leader 仅仅是故障转移操作出现的角色。
|
||||
|
||||
#### 读写分离
|
||||
|
||||
#### 定时任务
|
||||
|
||||
- 每 1s 每个 Sentinel 对其他 Sentinel 和 Redis 执行 ping，进行心跳检测。
|
||||
- 每 2s 每个 Sentinel 通过 Master 的 Channel 交换信息(pub - sub)。
|
||||
- 每 10s 每个 Sentinel 对 Master 和 Slave 执行 info，目的是发现 Slave 节点、确定主从关系。
|
||||
|
||||
### 分布式集群(Cluster)
|
||||
|
||||
#### 拓扑图
|
||||
|
||||
|
||||
|
||||
#### 通讯
|
||||
|
||||
##### 集中式
|
||||
|
||||
> 将集群元数据(节点信息、故障等等)集中存储在某个节点上。
|
||||
- 优势
|
||||
1. 元数据的更新读取具有很强的时效性，元数据修改立即更新
|
||||
- 劣势
|
||||
1. 数据集中存储
|
||||
|
||||
##### Gossip
|
||||
|
||||
|
||||
|
||||
- [Gossip 协议](https://www.jianshu.com/p/8279d6fd65bb)
|
||||
|
||||
#### 寻址分片
|
||||
|
||||
##### hash取模
|
||||
|
||||
- hash(key)%机器数量
|
||||
- 问题
|
||||
1. 机器宕机，造成数据丢失，数据读取失败
|
||||
1. 伸缩性
|
||||
|
||||
##### 一致性hash
|
||||
|
||||
- 
|
||||
|
||||
- 问题
|
||||
1. 一致性哈希算法在节点太少时，容易因为节点分布不均匀而造成缓存热点的问题。
|
||||
- 解决方案
|
||||
- 可以通过引入虚拟节点机制解决：即对每一个节点计算多个 hash，每个计算结果位置都放置一个虚拟节点。这样就实现了数据的均匀分布，负载均衡。
|
||||
|
||||
##### hash槽
|
||||
|
||||
- CRC16(key)%16384
|
||||
-
|
||||
|
||||
|
||||
## 使用场景
|
||||
|
||||
### 热点数据
|
||||
|
||||
存取数据优先从 Redis 操作，如果不存在再从文件（例如 MySQL）中操作，从文件操作完后将数据存储到 Redis 中并返回。同时有个定时任务后台定时扫描 Redis 的 key，根据业务规则进行淘汰，防止某些只访问一两次的数据一直存在 Redis 中。
|
||||
>例如使用 Zset 数据结构，存储 Key 的访问次数/最后访问时间作为 Score，最后做排序，来淘汰那些最少访问的 Key。
|
||||
|
||||
如果企业级应用，可以参考：[阿里云的 Redis 混合存储版][1]
|
||||
|
||||
### 会话维持 Session
|
||||
|
||||
会话维持 Session 场景，即使用 Redis 作为分布式场景下的登录中心存储应用。每次不同的服务在登录的时候，都会去统一的 Redis 去验证 Session 是否正确。但是在微服务场景，一般会考虑 Redis + JWT 做 Oauth2 模块。
|
||||
>其中 Redis 存储 JWT 的相关信息主要是留出口子，方便以后做统一的防刷接口，或者做登录设备限制等。
|
||||
|
||||
### 分布式锁 SETNX
|
||||
|
||||
命令格式：`SETNX key value`：当且仅当 key 不存在，将 key 的值设为 value。若给定的 key 已经存在，则 SETNX 不做任何动作。
|
||||
|
||||
1. 超时时间设置：获取锁的同时，启动守护线程，使用 expire 进行定时更新超时时间。如果该业务机器宕机，守护线程也挂掉，这样也会自动过期。如果该业务不是宕机，而是真的需要这么久的操作时间，那么增加超时时间在业务上也是可以接受的，但是肯定有个最大的阈值。
|
||||
2. 但是为了增加高可用，需要使用多台 Redis，就增加了复杂性，就可以参考 Redlock：[Redlock分布式锁](Redlock分布式锁.md#怎么在单节点上实现分布式锁)
|
||||
|
||||
### 表缓存
|
||||
|
||||
Redis 缓存表的场景有黑名单、禁言表等。访问频率较高，即读高。根据业务需求，可以使用后台定时任务定时刷新 Redis 的缓存表数据。
|
||||
|
||||
### 消息队列 list
|
||||
|
||||
主要使用了 List 数据结构。
|
||||
List 支持在头部和尾部操作，因此可以实现简单的消息队列。
|
||||
1. 发消息：在 List 尾部塞入数据。
|
||||
2. 消费消息：在 List 头部拿出数据。
|
||||
|
||||
同时可以使用多个 List，来实现多个队列，根据不同的业务消息，塞入不同的 List，来增加吞吐量。
|
||||
|
||||
### 计数器 string
|
||||
|
||||
主要使用了 INCR、DECR、INCRBY、DECRBY 方法。
|
||||
|
||||
INCR key：给 key 的 value 值增加一
|
||||
DECR key：给 key 的 value 值减去一
|
||||
|
||||
## 缓存设计
|
||||
|
||||
### 更新策略
|
||||
|
||||
- LRU、LFU、FIFO 算法自动清除：一致性最差，维护成本低。
|
||||
- 超时自动清除(key expire)：一致性较差，维护成本低。
|
||||
- 主动更新：代码层面控制生命周期，一致性最好，维护成本高。
|
||||
|
||||
在 Redis 根据在 redis.conf 的参数 `maxmemory` 来做更新淘汰策略：
|
||||
1. noeviction: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息。大多数写命令都会导致占用更多的内存(有极少数会例外, 如 DEL 命令)。
|
||||
2. allkeys-lru: 所有 key 通用; 优先删除最近最少使用(less recently used ,LRU) 的 key。
|
||||
3. volatile-lru: 只限于设置了 expire 的部分; 优先删除最近最少使用(less recently used ,LRU) 的 key。
|
||||
4. allkeys-random: 所有key通用; 随机删除一部分 key。
|
||||
5. volatile-random: 只限于设置了 expire 的部分; 随机删除一部分 key。
|
||||
6. volatile-ttl: 只限于设置了 expire 的部分; 优先删除剩余时间(time to live,TTL) 短的key。
|
||||
|
||||
### 更新一致性
|
||||
|
||||
- 读请求：先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
|
||||
- 写请求：先删除缓存，然后再更新数据库(避免大量地写、却又不经常读的数据导致缓存频繁更新)。
|
||||
|
||||
### 缓存粒度
|
||||
|
||||
- 通用性：全量属性更好。
|
||||
- 占用空间：部分属性更好。
|
||||
- 代码维护成本。
|
||||
|
||||
### 缓存穿透
|
||||
|
||||
> 当大量的请求无命中缓存、直接请求到后端数据库(业务代码的 bug、或恶意攻击)，同时后端数据库也没有查询到相应的记录、无法添加缓存。
|
||||
> 这种状态会一直维持，流量一直打到存储层上，无法利用缓存、还会给存储层带来巨大压力。
|
||||
|
||||
#### 解决方案
|
||||
|
||||
1. 请求无法命中缓存、同时数据库记录为空时在缓存添加该 key 的空对象(设置过期时间)，缺点是可能会在缓存中添加大量的空值键(比如遭到恶意攻击或爬虫)，而且缓存层和存储层数据短期内不一致；
|
||||
2. 使用布隆过滤器在缓存层前拦截非法请求、自动为空值添加黑名单(同时可能要为误判的记录添加白名单).但需要考虑布隆过滤器的维护(离线生成/ 实时生成)。
|
||||
|
||||
### 缓存雪崩
|
||||
|
||||
> 缓存崩溃时请求会直接落到数据库上，很可能由于无法承受大量的并发请求而崩溃，此时如果只重启数据库，或因为缓存重启后没有数据，新的流量进来很快又会把数据库击倒。
|
||||
|
||||
#### 出现后应对
|
||||
|
||||
- 事前：Redis 高可用，主从 + 哨兵，Redis Cluster，避免全盘崩溃。
|
||||
- 事中：本地 ehcache 缓存 + hystrix 限流 & 降级，避免数据库承受太多压力。
|
||||
- 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
|
||||
|
||||
#### 请求过程
|
||||
|
||||
1. 用户请求先访问本地缓存，无命中后再访问 Redis，如果本地缓存和 Redis 都没有再查数据库，并把数据添加到本地缓存和 Redis；
|
||||
2. 由于设置了限流，一段时间范围内超出的请求走降级处理(返回默认值，或给出友情提示)。
|
||||
|
||||
@ -1,91 +0,0 @@
|
||||
本文是对 [Martin Kleppmann](https://martin.kleppmann.com/) 的文章 [How to do distributed locking](https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html) 部分内容的翻译和总结，上次写 Redlock 的原因就是看到了 Martin 的这篇文章，写得很好，特此翻译和总结。感兴趣的同学可以翻看原文，相信会收获良多。
|
||||
|
||||
开篇作者认为现在 Redis 逐渐被使用到数据管理领域，这个领域需要更强的数据一致性和耐久性，这使得他感到担心，因为这不是 Redis 最初设计的初衷（事实上这也是很多业界程序员的误区，越来越把 Redis 当成数据库在使用），其中基于 Redis 的分布式锁就是令人担心的其一。
|
||||
|
||||
Martin 指出首先你要明确你为什么使用分布式锁，为了性能还是正确性？为了帮你区分这二者，在这把锁 fail 了的时候你可以询问自己以下问题：
|
||||
1. **要性能的：** 拥有这把锁使得你不会重复劳动（例如一个 job 做了两次），如果这把锁 fail 了，两个节点同时做了这个 Job，那么这个 Job 增加了你的成本。
|
||||
2. **要正确性的：** 拥有锁可以防止并发操作污染你的系统或者数据，如果这把锁 fail 了两个节点同时操作了一份数据，结果可能是数据不一致、数据丢失、file 冲突等，会导致严重的后果。
|
||||
|
||||
上述二者都是需求锁的正确场景，但是你必须清楚自己是因为什么原因需要分布式锁。
|
||||
|
||||
如果你只是为了性能，那没必要用 Redlock，它成本高且复杂，你只用一个 Redis 实例也够了，最多加个从防止主挂了。当然，你使用单节点的 Redis 那么断电或者一些情况下，你会丢失锁，但是你的目的只是加速性能且断电这种事情不会经常发生，这并不是什么大问题。并且如果你使用了单节点 Redis，那么很显然你这个应用需要的锁粒度是很模糊粗糙的，也不会是什么重要的服务。
|
||||
|
||||
那么是否 Redlock 对于要求正确性的场景就合适呢？Martin 列举了若干场景证明 Redlock 这种算法是不可靠的。
|
||||
|
||||
## 用锁保护资源
|
||||
这节里 Martin 先将 Redlock 放在了一边而是仅讨论总体上一个分布式锁是怎么工作的。在分布式环境下，锁比 mutex 这类复杂，因为涉及到不同节点、网络通信并且他们随时可能无征兆的 fail 。
|
||||
Martin 假设了一个场景，一个 client 要修改一个文件，它先申请得到锁，然后修改文件写回，放锁。另一个 client 再申请锁 ... 代码流程如下：
|
||||
|
||||
```java
|
||||
// THIS CODE IS BROKEN
|
||||
function writeData(filename, data) {
|
||||
var lock = lockService.acquireLock(filename);
|
||||
if (!lock) {
|
||||
throw 'Failed to acquire lock';
|
||||
}
|
||||
|
||||
try {
|
||||
var file = storage.readFile(filename);
|
||||
var updated = updateContents(file, data);
|
||||
storage.writeFile(filename, updated);
|
||||
} finally {
|
||||
lock.release();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
可惜即使你的锁服务非常完美，上述代码还是可能跪，下面的流程图会告诉你为什么：
|
||||
|
||||
|
||||
|
||||
上述图中，得到锁的 client1 在持有锁的期间 pause 了一段时间，例如 GC 停顿。锁有过期时间（一般叫租约，为了防止某个 client 崩溃之后一直占有锁），但是如果 GC 停顿太长超过了锁租约时间，此时锁已经被另一个 client2 所得到，原先的 client1 还没有感知到锁过期，那么奇怪的结果就会发生，曾经 HBase 就发生过这种 Bug。即使你在 client1 写回之前检查一下锁是否过期也无助于解决这个问题，因为 GC 可能在任何时候发生，即使是你非常不便的时候（在最后的检查与写操作期间）。
|
||||
如果你认为自己的程序不会有长时间的 GC 停顿，还有其他原因会导致你的进程 pause。例如进程可能读取尚未进入内存的数据，所以它得到一个 page fault 并且等待 page 被加载进缓存；还有可能你依赖于网络服务；或者其他进程占用 CPU；或者其他人意外发生 SIGSTOP 等。
|
||||
|
||||
... .... 这里 Martin 又增加了一节列举各种进程 pause 的例子，为了证明上面的代码是不安全的，无论你的锁服务多完美。
|
||||
|
||||
## 使用 Fencing （栅栏）使得锁变安全
|
||||
修复问题的方法也很简单：你需要在每次写操作时加入一个 fencing token。这个场景下，fencing token 可以是一个递增的数字（lock service 可以做到），每次有 client 申请锁就递增一次：
|
||||
|
||||
|
||||
|
||||
client1 申请锁同时拿到 token33，然后它进入长时间的停顿锁也过期了。client2 得到锁和 token34 写入数据，紧接着 client1 活过来之后尝试写入数据，自身 token33 比 34 小因此写入操作被拒绝。注意这需要存储层来检查 token，但这并不难实现。如果你使用 Zookeeper 作为 lock service 的话那么你可以使用 zxid 作为递增数字。
|
||||
但是对于 Redlock 你要知道，没什么生成 fencing token 的方式，并且怎么修改 Redlock 算法使其能产生 fencing token 呢？好像并不那么显而易见。因为产生 token 需要单调递增，除非在单节点 Redis 上完成但是这又没有高可靠性，你好像需要引进一致性协议来让 Redlock 产生可靠的 fencing token。
|
||||
|
||||
## 使用时间来解决一致性
|
||||
Redlock 无法产生 fencing token 早该成为在需求正确性的场景下弃用它的理由，但还有一些值得讨论的地方。
|
||||
|
||||
学术界有个说法，算法对时间不做假设：因为进程可能pause一段时间、数据包可能因为网络延迟延后到达、时钟可能根本就是错的。而可靠的算法依旧要在上述假设下做正确的事情。
|
||||
|
||||
对于 failure detector 来说，timeout 只能作为猜测某个节点 fail 的依据，因为网络延迟、本地时钟不正确等其他原因的限制。考虑到 Redis 使用 gettimeofday，而不是单调的时钟，会受到系统时间的影响，可能会突然前进或者后退一段时间，这会导致一个 key 更快或更慢地过期。
|
||||
|
||||
可见，Redlock 依赖于许多时间假设，它假设所有 Redis 节点都能对同一个 Key 在其过期前持有差不多的时间、跟过期时间相比网络延迟很小、跟过期时间相比进程 pause 很短。
|
||||
|
||||
## 用不可靠的时间打破 Redlock
|
||||
这节 Martin 举了个因为时间问题，Redlock 不可靠的例子。
|
||||
|
||||
1. client1 从 ABC 三个节点处申请到锁，DE由于网络原因请求没有到达
|
||||
2. C节点的时钟往前推了，导致 lock 过期
|
||||
3. client2 在CDE处获得了锁，AB由于网络原因请求未到达
|
||||
4. 此时 client1 和 client2 都获得了锁
|
||||
|
||||
**在 Redlock 官方文档中也提到了这个情况，不过是C崩溃的时候，Redlock 官方本身也是知道 Redlock 算法不是完全可靠的，官方为了解决这种问题建议使用延时启动，相关内容可以看之前的[这篇文章](https://zhuanlan.zhihu.com/p/40915772)。但是 Martin 这里分析得更加全面，指出延时启动不也是依赖于时钟的正确性的么？**
|
||||
|
||||
接下来 Martin 又列举了进程 Pause 时而不是时钟不可靠时会发生的问题：
|
||||
|
||||
1. client1 从 ABCDE 处获得了锁
|
||||
2. 当获得锁的 response 还没到达 client1 时 client1 进入 GC 停顿
|
||||
3. 停顿期间锁已经过期了
|
||||
4. client2 在 ABCDE 处获得了锁
|
||||
5. client1 GC 完成收到了获得锁的 response，此时两个 client 又拿到了同一把锁
|
||||
|
||||
**同时长时间的网络延迟也有可能导致同样的问题。**
|
||||
|
||||
## Redlock 的同步性假设
|
||||
这些例子说明了，仅有在你假设了一个同步性系统模型的基础上，Redlock 才能正常工作，也就是系统能满足以下属性：
|
||||
|
||||
1. 网络延时边界，即假设数据包一定能在某个最大延时之内到达
|
||||
2. 进程停顿边界，即进程停顿一定在某个最大时间之内
|
||||
3. 时钟错误边界，即不会从一个坏的 NTP 服务器处取得时间
|
||||
|
||||
## 结论
|
||||
Martin 认为 Redlock 实在不是一个好的选择，对于需求性能的分布式锁应用它太重了且成本高；对于需求正确性的应用来说它不够安全。因为它对高危的时钟或者说其他上述列举的情况进行了不可靠的假设，如果你的应用只需要高性能的分布式锁不要求多高的正确性，那么单节点 Redis 够了；如果你的应用想要保住正确性，那么不建议 Redlock，建议使用一个合适的一致性协调系统，例如 Zookeeper，且保证存在 fencing token。
|
||||
@ -1,41 +0,0 @@
|
||||
# 阿里巴巴Java开发手册数据库部分的一些最佳实践总结
|
||||
|
||||
## 模糊查询
|
||||
|
||||
对于模糊查询阿里巴巴开发手册这样说到：
|
||||
|
||||
> 【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。
|
||||
>
|
||||
> 说明:索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。
|
||||
|
||||
## 外键和级联
|
||||
|
||||
对于外键和级联，阿里巴巴开发手册这样说到：
|
||||
|
||||
>【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
|
||||
>
|
||||
>说明:以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群;级联更新是强阻塞，存在数据库更新风暴的风 险;外键影响数据库的插入速度
|
||||
|
||||
为什么不要用外键呢？大部分人可能会这样回答：
|
||||
|
||||
> 1. **增加了复杂性：** a.每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦,测试数据极为不方便;b.外键的主从关系是定的，假如那天需求有变化，数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦。
|
||||
> 2. **增加了额外工作**： 数据库需要增加维护外键的工作，比如当我们做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，保证数据的的一致性和正确性，这样会不得不消耗资源；（个人觉得这个不是不用外键的原因，因为即使你不使用外键，你在应用层面也还是要保证的。所以，我觉得这个影响可以忽略不计。）
|
||||
> 3. 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；
|
||||
> 4. **对分库分表不友好** ：因为分库分表下外键是无法生效的。
|
||||
> 5. ......
|
||||
|
||||
我个人觉得上面这种回答不是特别的全面，只是说了外键存在的一个常见的问题。实际上，我们知道外键也是有很多好处的，比如：
|
||||
|
||||
1. 保证了数据库数据的一致性和完整性；
|
||||
2. 级联操作方便，减轻了程序代码量；
|
||||
3. ......
|
||||
|
||||
所以说，不要一股脑的就抛弃了外键这个概念，既然它存在就有它存在的道理，如果系统不涉及分库分表，并发量不是很高的情况还是可以考虑使用外键的。
|
||||
|
||||
我个人是不太喜欢外键约束，比较喜欢在应用层去进行相关操作。
|
||||
|
||||
## 关于@Transactional注解
|
||||
|
||||
对于`@Transactional`事务注解，阿里巴巴开发手册这样说到：
|
||||
|
||||
>【参考】@Transactional事务不要滥用。事务会影响数据库的QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。
|
||||
@ -1,38 +1,70 @@
|
||||
数据库知识基础，这部分内容一定要理解记忆。虽然这部分内容只是理论知识，但是非常重要，这是后面学习 MySQL 数据库的基础。PS:这部分内容由于涉及太多概念性内容，所以参考了维基百科和百度百科相应的介绍。
|
||||
---
|
||||
title: 数据库基础知识
|
||||
category: 数据库
|
||||
tag:
|
||||
+ 数据库基础
|
||||
---
|
||||
|
||||
## 什么是数据库,数据库管理系统,数据库系统,数据库管理员?
|
||||
数据库知识基础，这部分内容一定要理解记忆。虽然这部分内容只是理论知识，但是非常重要，这是后面学习 MySQL 数据库的基础。PS: 这部分内容由于涉及太多概念性内容，所以参考了维基百科和百度百科相应的介绍。
|
||||
|
||||
- **数据库** :数据库(DataBase 简称 DB)就是信息的集合或者说数据库是由数据库管理系统管理的数据的集合。
|
||||
- **数据库管理系统** : 数据库管理系统(Database Management System 简称 DBMS)是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护数据库。
|
||||
- **数据库系统** : 数据库系统(Data Base System，简称 DBS)通常由软件、数据库和数据管理员(DBA)组成。
|
||||
- **数据库管理员** : 数据库管理员(Database Administrator,简称 DBA)负责全面管理和控制数据库系统。
|
||||
## 什么是数据库, 数据库管理系统, 数据库系统, 数据库管理员?
|
||||
|
||||
* **数据库** : 数据库(DataBase 简称 DB)就是信息的集合或者说数据库是由数据库管理系统管理的数据的集合。
|
||||
* **数据库管理系统** : 数据库管理系统(Database Management System 简称 DBMS)是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护数据库。
|
||||
* **数据库系统** : 数据库系统(Data Base System，简称 DBS)通常由软件、数据库和数据管理员(DBA)组成。
|
||||
* **数据库管理员** : 数据库管理员(Database Administrator, 简称 DBA)负责全面管理和控制数据库系统。
|
||||
|
||||
数据库系统基本构成如下图所示：
|
||||
|
||||
|
||||
|
||||
## 什么是元组,码,候选码,主码,外码,主属性,非主属性？
|
||||
## 什么是元组, 码, 候选码, 主码, 外码, 主属性, 非主属性？
|
||||
|
||||
- **元组** ： 元组（tuple）是关系数据库中的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。 在二维表里，元组也称为行。
|
||||
- **码** ：码就是能唯一标识实体的属性，对应表中的列。
|
||||
- **候选码** ： 若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何、子集都不能再标识，则称该属性组为候选码。例如：在学生实体中，“学号”是能唯一的区分学生实体的，同时又假设“姓名”、“班级”的属性组合足以区分学生实体，那么{学号}和{姓名，班级}都是候选码。
|
||||
- **主码** : 主码也叫主键。主码是从候选码中选出来的。 一个实体集中只能有一个主码，但可以有多个候选码。
|
||||
- **外码** : 外码也叫外键。如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码。
|
||||
- **主属性** ： 候选码中出现过的属性称为主属性。比如关系 工人（工号，身份证号，姓名，性别，部门）.显然工号和身份证号都能够唯一标示这个关系，所以都是候选码。工号、身份证号这两个属性就是主属性。如果主码是一个属性组，那么属性组中的属性都是主属性。
|
||||
- **非主属性：** 不包含在任何一个候选码中的属性称为非主属性。比如在关系——学生（学号，姓名，年龄，性别，班级）中，主码是“学号”，那么其他的“姓名”、“年龄”、“性别”、“班级”就都可以称为非主属性。
|
||||
* **元组** ： 元组（tuple）是关系数据库中的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。 在二维表里，元组也称为行。
|
||||
* **码** ：码就是能唯一标识实体的属性，对应表中的列。
|
||||
* **候选码** ： 若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何、子集都不能再标识，则称该属性组为候选码。例如：在学生实体中，“学号”是能唯一的区分学生实体的，同时又假设“姓名”、“班级”的属性组合足以区分学生实体，那么{学号}和{姓名，班级}都是候选码。
|
||||
* **主码** : 主码也叫主键。主码是从候选码中选出来的。 一个实体集中只能有一个主码，但可以有多个候选码。
|
||||
* **外码** : 外码也叫外键。如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码。
|
||||
* **主属性** ： 候选码中出现过的属性称为主属性。比如关系 工人（工号，身份证号，姓名，性别，部门）. 显然工号和身份证号都能够唯一标示这个关系，所以都是候选码。工号、身份证号这两个属性就是主属性。如果主码是一个属性组，那么属性组中的属性都是主属性。
|
||||
* **非主属性：** 不包含在任何一个候选码中的属性称为非主属性。比如在关系——学生（学号，姓名，年龄，性别，班级）中，主码是“学号”，那么其他的“姓名”、“年龄”、“性别”、“班级”就都可以称为非主属性。
|
||||
|
||||
## 主键和外键有什么区别?
|
||||
|
||||
- **主键(主码)** ：主键用于唯一标识一个元组，不能有重复，不允许为空。一个表只能有一个主键。
|
||||
- **外键(外码)** ：外键用来和其他表建立联系用，外键是另一表的主键，外键是可以有重复的，可以是空值。一个表可以有多个外键。
|
||||
* **主键(主码)** ：主键用于唯一标识一个元组，不能有重复，不允许为空。一个表只能有一个主键。
|
||||
* **外键(外码)** ：外键用来和其他表建立联系用，外键是另一表的主键，外键是可以有重复的，可以是空值。一个表可以有多个外键。
|
||||
|
||||
## 为什么不推荐使用外键与级联？
|
||||
|
||||
对于外键和级联，阿里巴巴开发手册这样说到：
|
||||
|
||||
> 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
|
||||
>
|
||||
> 说明: 以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群; 级联更新是强阻塞，存在数据库更新风暴的风 险; 外键影响数据库的插入速度
|
||||
|
||||
为什么不要用外键呢？大部分人可能会这样回答：
|
||||
|
||||
> 1. **增加了复杂性：** a. 每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦, 测试数据极为不方便; b. 外键的主从关系是定的，假如那天需求有变化，数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦。
|
||||
> 2. **增加了额外工作**： 数据库需要增加维护外键的工作，比如当我们做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，保证数据的的一致性和正确性，这样会不得不消耗资源；（个人觉得这个不是不用外键的原因，因为即使你不使用外键，你在应用层面也还是要保证的。所以，我觉得这个影响可以忽略不计。）
|
||||
> 3. 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；
|
||||
> 4. **对分库分表不友好** ：因为分库分表下外键是无法生效的。
|
||||
> 5. ......
|
||||
|
||||
我个人觉得上面这种回答不是特别的全面，只是说了外键存在的一个常见的问题。实际上，我们知道外键也是有很多好处的，比如：
|
||||
|
||||
1. 保证了数据库数据的一致性和完整性；
|
||||
2. 级联操作方便，减轻了程序代码量；
|
||||
3. ......
|
||||
|
||||
所以说，不要一股脑的就抛弃了外键这个概念，既然它存在就有它存在的道理，如果系统不涉及分库分表，并发量不是很高的情况还是可以考虑使用外键的。
|
||||
|
||||
|
||||
## 什么是 ER 图？
|
||||
|
||||
> 我们做一个项目的时候一定要试着画 ER 图来捋清数据库设计，这个也是面试官问你项目的时候经常会被问道的。
|
||||
|
||||
**E-R 图**也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。 它是描述现实世界关系概念模型的有效方法。 是表示概念关系模型的一种方式。
|
||||
**E-R 图** 也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。 它是描述现实世界关系概念模型的有效方法。 是表示概念关系模型的一种方式。
|
||||
|
||||
下图是一个学生选课的 ER 图，每个学生可以选若干门课程，同一门课程也可以被若干人选择，所以它们之间的关系是多对多（M:N）。另外，还有其他两种关系是：1 对 1（1:1）、1 对多（1:N）。
|
||||
下图是一个学生选课的 ER 图，每个学生可以选若干门课程，同一门课程也可以被若干人选择，所以它们之间的关系是多对多（M: N）。另外，还有其他两种关系是：1 对 1（1:1）、1 对多（1: N）。
|
||||
|
||||
|
||||
|
||||
@ -54,20 +86,20 @@
|
||||
|
||||
一些重要的概念：
|
||||
|
||||
- **函数依赖（functional dependency）** ：若在一张表中，在属性（或属性组）X 的值确定的情况下，必定能确定属性 Y 的值，那么就可以说 Y 函数依赖于 X，写作 X → Y。
|
||||
- **部分函数依赖（partial functional dependency）** ：如果 X→Y，并且存在 X 的一个真子集 X0，使得 X0→Y，则称 Y 对 X 部分函数依赖。比如学生基本信息表 R 中（学号，身份证号，姓名）当然学号属性取值是唯一的，在 R 关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；
|
||||
- **完全函数依赖(Full functional dependency)** ：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。比如学生基本信息表 R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在 R 关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；
|
||||
- **传递函数依赖** ： 在关系模式 R(U)中，设 X，Y，Z 是 U 的不同的属性子集，如果 X 确定 Y、Y 确定 Z，且有 X 不包含 Y，Y 不确定 X，（X∪Y）∩Z=空集合，则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z 子集往往同属于某一个事物，因此可将其合并放到一个表中。比如在关系 R(学号 ,姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖。。
|
||||
* **函数依赖（functional dependency）** ：若在一张表中，在属性（或属性组）X 的值确定的情况下，必定能确定属性 Y 的值，那么就可以说 Y 函数依赖于 X，写作 X → Y。
|
||||
* **部分函数依赖（partial functional dependency）** ：如果 X→Y，并且存在 X 的一个真子集 X0，使得 X0→Y，则称 Y 对 X 部分函数依赖。比如学生基本信息表 R 中（学号，身份证号，姓名）当然学号属性取值是唯一的，在 R 关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；
|
||||
* **完全函数依赖(Full functional dependency)** ：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。比如学生基本信息表 R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在 R 关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；
|
||||
* **传递函数依赖** ： 在关系模式 R(U)中，设 X，Y，Z 是 U 的不同的属性子集，如果 X 确定 Y、Y 确定 Z，且有 X 不包含 Y，Y 不确定 X，（X∪Y）∩Z=空集合，则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z 子集往往同属于某一个事物，因此可将其合并放到一个表中。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖。。
|
||||
|
||||
**3NF(第三范式)**
|
||||
|
||||
3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。符合 3NF 要求的数据库设计，**基本**上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。比如在关系 R(学号 ,姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖，所以该表的设计，不符合 3NF 的要求。
|
||||
3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。符合 3NF 要求的数据库设计，**基本**上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖，所以该表的设计，不符合 3NF 的要求。
|
||||
|
||||
**总结**
|
||||
|
||||
- 1NF：属性不可再分。
|
||||
- 2NF：1NF 的基础之上，消除了非主属性对于码的部分函数依赖。
|
||||
- 3NF：3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。
|
||||
* 1NF：属性不可再分。
|
||||
* 2NF：1NF 的基础之上，消除了非主属性对于码的部分函数依赖。
|
||||
* 3NF：3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。
|
||||
|
||||
## 什么是存储过程?
|
||||
|
||||
@ -77,15 +109,15 @@
|
||||
|
||||
阿里巴巴 Java 开发手册里要求禁止使用存储过程。
|
||||
|
||||
|
||||
|
||||
|
||||
## drop、delete 与 truncate 区别？
|
||||
|
||||
### 用法不同
|
||||
|
||||
- drop(丢弃数据): `drop table 表名` ，直接将表都删除掉，在删除表的时候使用。
|
||||
- truncate (清空数据) : `truncate table 表名` ，只删除表中的数据，再插入数据的时候自增长 id 又从 1 开始，在清空表中数据的时候使用。
|
||||
- delete（删除数据） : `delete from 表名 where 列名=值`，删除某一列的数据，如果不加 where 子句和`truncate table 表名`作用类似。
|
||||
* drop(丢弃数据): `drop table 表名` ，直接将表都删除掉，在删除表的时候使用。
|
||||
* truncate (清空数据) : `truncate table 表名` ，只删除表中的数据，再插入数据的时候自增长 id 又从 1 开始，在清空表中数据的时候使用。
|
||||
* delete（删除数据） : `delete from 表名 where 列名=值`，删除某一列的数据，如果不加 where 子句和`truncate table 表名`作用类似。
|
||||
|
||||
truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的数据，但是 **truncate 和 delete 只删除数据不删除表的结构(定义)，执行 drop 语句，此表的结构也会删除，也就是执行 drop 之后对应的表不复存在。**
|
||||
|
||||
@ -95,8 +127,8 @@ truncate 和 drop 属于 DDL(数据定义语言)语句，操作立即生效，
|
||||
|
||||
**DML 语句和 DDL 语句区别：**
|
||||
|
||||
- DML 是数据库操作语言（Data Manipulation Language）的缩写，是指对数据库中表记录的操作，主要包括表记录的插入（insert）、更新（update）、删除（delete）和查询（select），是开发人员日常使用最频繁的操作。
|
||||
- DDL （Data Definition Language）是数据定义语言的缩写，简单来说，就是对数据库内部的对象进行创建、删除、修改的操作语言。它和 DML 语言的最大区别是 DML 只是对表内部数据的操作，而不涉及到表的定义、结构的修改，更不会涉及到其他对象。DDL 语句更多的被数据库管理员（DBA）所使用，一般的开发人员很少使用。
|
||||
* DML 是数据库操作语言（Data Manipulation Language）的缩写，是指对数据库中表记录的操作，主要包括表记录的插入（insert）、更新（update）、删除（delete）和查询（select），是开发人员日常使用最频繁的操作。
|
||||
* DDL （Data Definition Language）是数据定义语言的缩写，简单来说，就是对数据库内部的对象进行创建、删除、修改的操作语言。它和 DML 语言的最大区别是 DML 只是对表内部数据的操作，而不涉及到表的定义、结构的修改，更不会涉及到其他对象。DDL 语句更多的被数据库管理员（DBA）所使用，一般的开发人员很少使用。
|
||||
|
||||
### 执行速度不同
|
||||
|
||||
@ -113,6 +145,7 @@ truncate 和 drop 属于 DDL(数据定义语言)语句，操作立即生效，
|
||||
|
||||
## 参考
|
||||
|
||||
- <https://blog.csdn.net/rl529014/article/details/48391465>
|
||||
- <https://www.zhihu.com/question/24696366/answer/29189700>
|
||||
- <https://blog.csdn.net/bieleyang/article/details/77149954>
|
||||
* <https://blog.csdn.net/rl529014/article/details/48391465>
|
||||
* <https://www.zhihu.com/question/24696366/answer/29189700>
|
||||
* <https://blog.csdn.net/bieleyang/article/details/77149954>
|
||||
|
||||
|
||||
@ -1,21 +0,0 @@
|
||||
- 公众号和Github待发文章：[数据库：数据库连接池原理详解与自定义连接池实现](https://www.fangzhipeng.com/javainterview/2019/07/15/mysql-connector-pool.html)
|
||||
- [基于JDBC的数据库连接池技术研究与应用](http://blog.itpub.net/9403012/viewspace-111794/)
|
||||
- [数据库连接池技术详解](https://juejin.im/post/5b7944c6e51d4538c86cf195)
|
||||
|
||||
数据库连接本质就是一个 socket 的连接。数据库服务端还要维护一些缓存和用户权限信息之类的 所以占用了一些内存
|
||||
|
||||
连接池是维护的数据库连接的缓存，以便将来需要对数据库的请求时可以重用这些连接。为每个用户打开和维护数据库连接，尤其是对动态数据库驱动的网站应用程序的请求，既昂贵又浪费资源。**在连接池中，创建连接后，将其放置在池中，并再次使用它，因此不必建立新的连接。如果使用了所有连接，则会建立一个新连接并将其添加到池中。**连接池还减少了用户必须等待建立与数据库的连接的时间。
|
||||
|
||||
操作过数据库的朋友应该都知道数据库连接池这个概念，它几乎每天都在和我们打交道，但是你真的了解 **数据库连接池** 吗？
|
||||
|
||||
### 没有数据库连接池之前
|
||||
|
||||
我相信你一定听过这样一句话：**Java语言中，JDBC（Java DataBase Connection）是应用程序与数据库沟通的桥梁**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
69
docs/java/basis/BigDecimal解决浮点数运算精度丢失问题.md
Normal file
69
docs/java/basis/BigDecimal解决浮点数运算精度丢失问题.md
Normal file
@ -0,0 +1,69 @@
|
||||
## BigDecimal 介绍
|
||||
|
||||
`BigDecimal` 可以实现对浮点数的运算，不会造成精度丢失。
|
||||
|
||||
那为什么浮点数 `float` 或 `double` 运算的时候会有精度丢失的风险呢？
|
||||
|
||||
这是因为计算机是二进制的，浮点数没有办法用二进制精确表示。
|
||||
|
||||
## BigDecimal 的用处
|
||||
|
||||
《阿里巴巴Java开发手册》中提到：**浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用 equals 来判断。** 具体原理和浮点数的编码方式有关，这里就不多提了，我们下面直接上实例：
|
||||
|
||||
```java
|
||||
float a = 1.0f - 0.9f;
|
||||
float b = 0.9f - 0.8f;
|
||||
System.out.println(a);// 0.100000024
|
||||
System.out.println(b);// 0.099999964
|
||||
System.out.println(a == b);// false
|
||||
```
|
||||
具有基本数学知识的我们很清楚的知道输出并不是我们想要的结果（**精度丢失**），我们如何解决这个问题呢？一种很常用的方法是：**使用 BigDecimal 来定义浮点数的值，再进行浮点数的运算操作。**
|
||||
|
||||
```java
|
||||
BigDecimal a = new BigDecimal("1.0");
|
||||
BigDecimal b = new BigDecimal("0.9");
|
||||
BigDecimal c = new BigDecimal("0.8");
|
||||
|
||||
BigDecimal x = a.subtract(b);
|
||||
BigDecimal y = b.subtract(c);
|
||||
|
||||
System.out.println(x); /* 0.1 */
|
||||
System.out.println(y); /* 0.1 */
|
||||
System.out.println(Objects.equals(x, y)); /* true */
|
||||
```
|
||||
|
||||
## BigDecimal 常见方法
|
||||
|
||||
## 大小比较
|
||||
|
||||
`a.compareTo(b)` : 返回 -1 表示 `a` 小于 `b`，0 表示 `a` 等于 `b` ， 1表示 `a` 大于 `b`。
|
||||
|
||||
```java
|
||||
BigDecimal a = new BigDecimal("1.0");
|
||||
BigDecimal b = new BigDecimal("0.9");
|
||||
System.out.println(a.compareTo(b));// 1
|
||||
```
|
||||
### 保留几位小数
|
||||
|
||||
通过 `setScale`方法设置保留几位小数以及保留规则。保留规则有挺多种，不需要记，IDEA会提示。
|
||||
|
||||
```java
|
||||
BigDecimal m = new BigDecimal("1.255433");
|
||||
BigDecimal n = m.setScale(3,BigDecimal.ROUND_HALF_DOWN);
|
||||
System.out.println(n);// 1.255
|
||||
```
|
||||
|
||||
## BigDecimal 的使用注意事项
|
||||
|
||||
注意：我们在使用BigDecimal时，为了防止精度丢失，推荐使用它的 **BigDecimal(String)** 构造方法来创建对象。《阿里巴巴Java开发手册》对这部分内容也有提到如下图所示。
|
||||
|
||||
|
||||
|
||||
## 总结
|
||||
|
||||
BigDecimal 主要用来操作（大）浮点数，BigInteger 主要用来操作大整数（超过 long 类型）。
|
||||
|
||||
BigDecimal 的实现利用到了 BigInteger, 所不同的是 BigDecimal 加入了小数位的概念
|
||||
|
||||
|
||||
|
||||
@ -1,137 +0,0 @@
|
||||
## 正确使用 equals 方法
|
||||
|
||||
Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用 equals。
|
||||
|
||||
举个例子：
|
||||
|
||||
```java
|
||||
// 不能使用一个值为null的引用类型变量来调用非静态方法，否则会抛出异常
|
||||
String str = null;
|
||||
if (str.equals("SnailClimb")) {
|
||||
...
|
||||
} else {
|
||||
..
|
||||
}
|
||||
```
|
||||
|
||||
运行上面的程序会抛出空指针异常，但是我们把第二行的条件判断语句改为下面这样的话，就不会抛出空指针异常，else 语句块得到执行。：
|
||||
|
||||
```java
|
||||
"SnailClimb".equals(str);// false
|
||||
```
|
||||
不过更推荐使用 `java.util.Objects#equals`(JDK7 引入的工具类)。
|
||||
|
||||
```java
|
||||
Objects.equals(null,"SnailClimb");// false
|
||||
```
|
||||
我们看一下`java.util.Objects#equals`的源码就知道原因了。
|
||||
```java
|
||||
public static boolean equals(Object a, Object b) {
|
||||
// 可以避免空指针异常。如果a=null的话此时a.equals(b)就不会得到执行，避免出现空指针异常。
|
||||
return (a == b) || (a != null && a.equals(b));
|
||||
}
|
||||
```
|
||||
|
||||
**注意：**
|
||||
|
||||
Reference:[Java中equals方法造成空指针异常的原因及解决方案](https://blog.csdn.net/tick_tock97/article/details/72824894)
|
||||
|
||||
- 每种原始类型都有默认值一样，如int默认值为 0，boolean 的默认值为 false，null 是任何引用类型的默认值，不严格的说是所有 Object 类型的默认值。
|
||||
- 可以使用 == 或者 != 操作来比较null值，但是不能使用其他算法或者逻辑操作。在Java中`null == null`将返回true。
|
||||
- 不能使用一个值为null的引用类型变量来调用非静态方法，否则会抛出异常
|
||||
|
||||
## 整型包装类值的比较
|
||||
|
||||
所有整型包装类对象值的比较必须使用equals方法。
|
||||
|
||||
先看下面这个例子：
|
||||
|
||||
```java
|
||||
Integer i1 = 40;
|
||||
Integer i2 = new Integer(40);
|
||||
System.out.println(i1==i2);//false
|
||||
```
|
||||
|
||||
`Integer i1=40` 这一行代码会发生装箱，也就是说这行代码等价于 `Integer i1=Integer.valueOf(40)` 。因此，`i1` 直接使用的是常量池中的对象。而`Integer i1 = new Integer(40)` 会直接创建新的对象。因此，输出 false 。
|
||||
|
||||
记住：**所有整型包装类对象之间值的比较，全部使用 `equals()` 方法比较**。
|
||||
|
||||
|
||||
|
||||
**注意：** 如果你的IDE(IDEA/Eclipse)上安装了阿里巴巴的p3c插件，这个插件如果检测到你用 ==的话会报错提示，推荐安装一个这个插件，很不错。
|
||||
|
||||
## BigDecimal
|
||||
|
||||
### BigDecimal 的用处
|
||||
|
||||
《阿里巴巴Java开发手册》中提到：**浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用 equals 来判断。** 具体原理和浮点数的编码方式有关，这里就不多提了，我们下面直接上实例：
|
||||
|
||||
```java
|
||||
float a = 1.0f - 0.9f;
|
||||
float b = 0.9f - 0.8f;
|
||||
System.out.println(a);// 0.100000024
|
||||
System.out.println(b);// 0.099999964
|
||||
System.out.println(a == b);// false
|
||||
```
|
||||
具有基本数学知识的我们很清楚的知道输出并不是我们想要的结果（**精度丢失**），我们如何解决这个问题呢？一种很常用的方法是：**使用 BigDecimal 来定义浮点数的值，再进行浮点数的运算操作。**
|
||||
|
||||
```java
|
||||
BigDecimal a = new BigDecimal("1.0");
|
||||
BigDecimal b = new BigDecimal("0.9");
|
||||
BigDecimal c = new BigDecimal("0.8");
|
||||
|
||||
BigDecimal x = a.subtract(b);
|
||||
BigDecimal y = b.subtract(c);
|
||||
|
||||
System.out.println(x); /* 0.1 */
|
||||
System.out.println(y); /* 0.1 */
|
||||
System.out.println(Objects.equals(x, y)); /* true */
|
||||
```
|
||||
|
||||
### BigDecimal 的大小比较
|
||||
|
||||
`a.compareTo(b)` : 返回 -1 表示 `a` 小于 `b`，0 表示 `a` 等于 `b` ， 1表示 `a` 大于 `b`。
|
||||
|
||||
```java
|
||||
BigDecimal a = new BigDecimal("1.0");
|
||||
BigDecimal b = new BigDecimal("0.9");
|
||||
System.out.println(a.compareTo(b));// 1
|
||||
```
|
||||
### BigDecimal 保留几位小数
|
||||
|
||||
通过 `setScale`方法设置保留几位小数以及保留规则。保留规则有挺多种，不需要记，IDEA会提示。
|
||||
|
||||
```java
|
||||
BigDecimal m = new BigDecimal("1.255433");
|
||||
BigDecimal n = m.setScale(3,BigDecimal.ROUND_HALF_DOWN);
|
||||
System.out.println(n);// 1.255
|
||||
```
|
||||
|
||||
### BigDecimal 的使用注意事项
|
||||
|
||||
注意：我们在使用BigDecimal时，为了防止精度丢失，推荐使用它的 **BigDecimal(String)** 构造方法来创建对象。《阿里巴巴Java开发手册》对这部分内容也有提到如下图所示。
|
||||
|
||||
|
||||
|
||||
### 总结
|
||||
|
||||
BigDecimal 主要用来操作（大）浮点数，BigInteger 主要用来操作大整数（超过 long 类型）。
|
||||
|
||||
BigDecimal 的实现利用到了 BigInteger, 所不同的是 BigDecimal 加入了小数位的概念
|
||||
|
||||
## 基本数据类型与包装数据类型的使用标准
|
||||
|
||||
Reference:《阿里巴巴Java开发手册》
|
||||
|
||||
- 【强制】所有的 POJO 类属性必须使用包装数据类型。
|
||||
- 【强制】RPC 方法的返回值和参数必须使用包装数据类型。
|
||||
- 【推荐】所有的局部变量使用基本数据类型。
|
||||
|
||||
比如我们如果自定义了一个Student类,其中有一个属性是成绩score,如果用Integer而不用int定义,一次考试,学生可能没考,值是null,也可能考了,但考了0分,值是0,这两个表达的状态明显不一样.
|
||||
|
||||
**说明** :POJO 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何 NPE 问题，或者入库检查，都由使用者来保证。
|
||||
|
||||
**正例** : 数据库的查询结果可能是 null，因为自动拆箱，用基本数据类型接收有 NPE 风险。
|
||||
|
||||
**反例** : 比如显示成交总额涨跌情况，即正负 x%，x 为基本数据类型，调用的 RPC 服务，调用不成功时，返回的是默认值，页面显示为 0%，这是不合理的，应该显示成中划线。所以包装数据类型的 null 值，能够表示额外的信息，如:远程调用失败，异常退出。
|
||||
|
||||
@ -19,19 +19,19 @@
|
||||
|
||||
<!-- /MarkdownTOC -->
|
||||
|
||||
# final,static,this,super 关键字总结
|
||||
|
||||
## final 关键字
|
||||
|
||||
**final 关键字，意思是最终的、不可修改的，最见不得变化 ，用来修饰类、方法和变量，具有以下特点：**
|
||||
`final` 关键字，意思是最终的、不可修改的，最见不得变化 ，用来修饰类、方法和变量，具有以下特点：
|
||||
|
||||
1. **final 修饰的类不能被继承，final 类中的所有成员方法都会被隐式的指定为 final 方法；**
|
||||
1. `final` 修饰的类不能被继承，final 类中的所有成员方法都会被隐式的指定为 final 方法；
|
||||
|
||||
2. **final 修饰的方法不能被重写；**
|
||||
2. `final` 修饰的方法不能被重写；
|
||||
|
||||
3. **final 修饰的变量是常量，如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；如果是引用类型的变量，则在对其初始化之后便不能让其指向另一个对象。**
|
||||
3. `final` 修饰的变量是常量，如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；如果是引用类型的变量，则在对其初始化之后便不能让其指向另一个对象。
|
||||
|
||||
说明：使用 final 方法的原因有两个。第一个原因是把方法锁定，以防任何继承类修改它的含义；第二个原因是效率。在早期的 Java 实现版本中，会将 final 方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升（现在的 Java 版本已经不需要使用 final 方法进行这些优化了）。类中所有的 private 方法都隐式地指定为 final。
|
||||
使用 final 方法的原因有两个:
|
||||
|
||||
第一个原因是把方法锁定，以防任何继承类修改它的含义；第二个原因是效率。在早期的 Java 实现版本中，会将 final 方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升（现在的 Java 版本已经不需要使用 final 方法进行这些优化了）。类中所有的 private 方法都隐式地指定为 final。
|
||||
|
||||
## static 关键字
|
||||
|
||||
|
||||
@ -87,8 +87,6 @@ Class clazz = ClassLoader.loadClass("cn.javaguide.TargetObject");
|
||||
|
||||
### 反射的一些基本操作
|
||||
|
||||
**简单用代码演示一下反射的一些操作!**
|
||||
|
||||
1.创建一个我们要使用反射操作的类 `TargetObject`。
|
||||
|
||||
```java
|
||||
|
||||
@ -1,557 +0,0 @@
|
||||
> 最近重看 Java 枚举，看到这篇觉得还不错的文章，于是简单翻译和完善了一些内容，分享给大家，希望你们也能有所收获。另外，不要忘了文末还有补充哦！
|
||||
>
|
||||
> ps: 这里发一篇枚举的文章，也是因为后面要发一篇非常实用的关于 SpringBoot 全局异常处理的比较好的实践，里面就用到了枚举。
|
||||
>
|
||||
> 这篇文章由 JavaGuide 翻译，公众号: JavaGuide,原文地址：https://www.baeldung.com/a-guide-to-java-enums 。
|
||||
>
|
||||
> 转载请注明上面这段文字。
|
||||
|
||||
## 1.概览
|
||||
|
||||
在本文中，我们将看到什么是 Java 枚举，它们解决了哪些问题以及如何在实践中使用 Java 枚举实现一些设计模式。
|
||||
|
||||
enum关键字在 java5 中引入，表示一种特殊类型的类，其总是继承java.lang.Enum类，更多内容可以自行查看其[官方文档](https://docs.oracle.com/javase/6/docs/api/java/lang/Enum.html)。
|
||||
|
||||
枚举在很多时候会和常量拿来对比，可能因为本身我们大量实际使用枚举的地方就是为了替代常量。那么这种方式有什么优势呢？
|
||||
|
||||
**以这种方式定义的常量使代码更具可读性，允许进行编译时检查，预先记录可接受值的列表，并避免由于传入无效值而引起的意外行为。**
|
||||
|
||||
下面示例定义一个简单的枚举类型 pizza 订单的状态，共有三种 ORDERED, READY, DELIVERED状态:
|
||||
|
||||
```java
|
||||
package shuang.kou.enumdemo.enumtest;
|
||||
|
||||
public enum PizzaStatus {
|
||||
ORDERED,
|
||||
READY,
|
||||
DELIVERED;
|
||||
}
|
||||
```
|
||||
|
||||
**简单来说，我们通过上面的代码避免了定义常量，我们将所有和 pizza 订单的状态的常量都统一放到了一个枚举类型里面。**
|
||||
|
||||
```java
|
||||
System.out.println(PizzaStatus.ORDERED.name());//ORDERED
|
||||
System.out.println(PizzaStatus.ORDERED);//ORDERED
|
||||
System.out.println(PizzaStatus.ORDERED.name().getClass());//class java.lang.String
|
||||
System.out.println(PizzaStatus.ORDERED.getClass());//class shuang.kou.enumdemo.enumtest.PizzaStatus
|
||||
```
|
||||
|
||||
## 2.自定义枚举方法
|
||||
|
||||
现在我们对枚举是什么以及如何使用它们有了基本的了解，让我们通过在枚举上定义一些额外的API方法，将上一个示例提升到一个新的水平：
|
||||
|
||||
```java
|
||||
public class Pizza {
|
||||
private PizzaStatus status;
|
||||
public enum PizzaStatus {
|
||||
ORDERED,
|
||||
READY,
|
||||
DELIVERED;
|
||||
}
|
||||
|
||||
public boolean isDeliverable() {
|
||||
return getStatus() == PizzaStatus.READY;
|
||||
}
|
||||
|
||||
// Methods that set and get the status variable.
|
||||
}
|
||||
```
|
||||
|
||||
## 3.使用 == 比较枚举类型
|
||||
|
||||
由于枚举类型确保JVM中仅存在一个常量实例，因此我们可以安全地使用 `==` 运算符比较两个变量，如上例所示；此外，`==` 运算符可提供编译时和运行时的安全性。
|
||||
|
||||
首先，让我们看一下以下代码段中的运行时安全性，其中 `==` 运算符用于比较状态，并且如果两个值均为null 都不会引发 NullPointerException。相反，如果使用equals方法，将抛出 NullPointerException：
|
||||
|
||||
```java
|
||||
Pizza.PizzaStatus pizza = null;
|
||||
System.out.println(pizza.equals(Pizza.PizzaStatus.DELIVERED));//空指针异常
|
||||
System.out.println(pizza == Pizza.PizzaStatus.DELIVERED);//正常运行
|
||||
```
|
||||
|
||||
对于编译时安全性，我们看另一个示例，两个不同枚举类型进行比较：
|
||||
|
||||
```java
|
||||
if (Pizza.PizzaStatus.DELIVERED.equals(TestColor.GREEN)); // 编译正常
|
||||
if (Pizza.PizzaStatus.DELIVERED == TestColor.GREEN); // 编译失败，类型不匹配
|
||||
```
|
||||
|
||||
## 4.在 switch 语句中使用枚举类型
|
||||
|
||||
```java
|
||||
public int getDeliveryTimeInDays() {
|
||||
switch (status) {
|
||||
case ORDERED:
|
||||
return 5;
|
||||
case READY:
|
||||
return 2;
|
||||
case DELIVERED:
|
||||
return 0;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
## 5.枚举类型的属性,方法和构造函数
|
||||
|
||||
> 文末有我(JavaGuide)的补充。
|
||||
|
||||
你可以通过在枚举类型中定义属性,方法和构造函数让它变得更加强大。
|
||||
|
||||
下面，让我们扩展上面的示例，实现从比萨的一个阶段到另一个阶段的过渡，并了解如何摆脱之前使用的if语句和switch语句：
|
||||
|
||||
```java
|
||||
public class Pizza {
|
||||
|
||||
private PizzaStatus status;
|
||||
public enum PizzaStatus {
|
||||
ORDERED (5){
|
||||
@Override
|
||||
public boolean isOrdered() {
|
||||
return true;
|
||||
}
|
||||
},
|
||||
READY (2){
|
||||
@Override
|
||||
public boolean isReady() {
|
||||
return true;
|
||||
}
|
||||
},
|
||||
DELIVERED (0){
|
||||
@Override
|
||||
public boolean isDelivered() {
|
||||
return true;
|
||||
}
|
||||
};
|
||||
|
||||
private int timeToDelivery;
|
||||
|
||||
public boolean isOrdered() {return false;}
|
||||
|
||||
public boolean isReady() {return false;}
|
||||
|
||||
public boolean isDelivered(){return false;}
|
||||
|
||||
public int getTimeToDelivery() {
|
||||
return timeToDelivery;
|
||||
}
|
||||
|
||||
PizzaStatus (int timeToDelivery) {
|
||||
this.timeToDelivery = timeToDelivery;
|
||||
}
|
||||
}
|
||||
|
||||
public boolean isDeliverable() {
|
||||
return this.status.isReady();
|
||||
}
|
||||
|
||||
public void printTimeToDeliver() {
|
||||
System.out.println("Time to delivery is " +
|
||||
this.getStatus().getTimeToDelivery());
|
||||
}
|
||||
|
||||
// Methods that set and get the status variable.
|
||||
}
|
||||
```
|
||||
|
||||
下面这段代码展示它是如何 work 的：
|
||||
|
||||
```java
|
||||
@Test
|
||||
public void givenPizaOrder_whenReady_thenDeliverable() {
|
||||
Pizza testPz = new Pizza();
|
||||
testPz.setStatus(Pizza.PizzaStatus.READY);
|
||||
assertTrue(testPz.isDeliverable());
|
||||
}
|
||||
```
|
||||
|
||||
## 6.EnumSet and EnumMap
|
||||
|
||||
### 6.1. EnumSet
|
||||
|
||||
`EnumSet` 是一种专门为枚举类型所设计的 `Set` 类型。
|
||||
|
||||
与`HashSet`相比，由于使用了内部位向量表示，因此它是特定 `Enum` 常量集的非常有效且紧凑的表示形式。
|
||||
|
||||
它提供了类型安全的替代方法，以替代传统的基于int的“位标志”，使我们能够编写更易读和易于维护的简洁代码。
|
||||
|
||||
`EnumSet` 是抽象类，其有两个实现：`RegularEnumSet` 、`JumboEnumSet`，选择哪一个取决于实例化时枚举中常量的数量。
|
||||
|
||||
在很多场景中的枚举常量集合操作（如：取子集、增加、删除、`containsAll`和`removeAll`批操作）使用`EnumSet`非常合适；如果需要迭代所有可能的常量则使用`Enum.values()`。
|
||||
|
||||
```java
|
||||
public class Pizza {
|
||||
|
||||
private static EnumSet<PizzaStatus> undeliveredPizzaStatuses =
|
||||
EnumSet.of(PizzaStatus.ORDERED, PizzaStatus.READY);
|
||||
|
||||
private PizzaStatus status;
|
||||
|
||||
public enum PizzaStatus {
|
||||
...
|
||||
}
|
||||
|
||||
public boolean isDeliverable() {
|
||||
return this.status.isReady();
|
||||
}
|
||||
|
||||
public void printTimeToDeliver() {
|
||||
System.out.println("Time to delivery is " +
|
||||
this.getStatus().getTimeToDelivery() + " days");
|
||||
}
|
||||
|
||||
public static List<Pizza> getAllUndeliveredPizzas(List<Pizza> input) {
|
||||
return input.stream().filter(
|
||||
(s) -> undeliveredPizzaStatuses.contains(s.getStatus()))
|
||||
.collect(Collectors.toList());
|
||||
}
|
||||
|
||||
public void deliver() {
|
||||
if (isDeliverable()) {
|
||||
PizzaDeliverySystemConfiguration.getInstance().getDeliveryStrategy()
|
||||
.deliver(this);
|
||||
this.setStatus(PizzaStatus.DELIVERED);
|
||||
}
|
||||
}
|
||||
|
||||
// Methods that set and get the status variable.
|
||||
}
|
||||
```
|
||||
|
||||
下面的测试展示了 `EnumSet` 在某些场景下的强大功能：
|
||||
|
||||
```java
|
||||
@Test
|
||||
public void givenPizaOrders_whenRetrievingUnDeliveredPzs_thenCorrectlyRetrieved() {
|
||||
List<Pizza> pzList = new ArrayList<>();
|
||||
Pizza pz1 = new Pizza();
|
||||
pz1.setStatus(Pizza.PizzaStatus.DELIVERED);
|
||||
|
||||
Pizza pz2 = new Pizza();
|
||||
pz2.setStatus(Pizza.PizzaStatus.ORDERED);
|
||||
|
||||
Pizza pz3 = new Pizza();
|
||||
pz3.setStatus(Pizza.PizzaStatus.ORDERED);
|
||||
|
||||
Pizza pz4 = new Pizza();
|
||||
pz4.setStatus(Pizza.PizzaStatus.READY);
|
||||
|
||||
pzList.add(pz1);
|
||||
pzList.add(pz2);
|
||||
pzList.add(pz3);
|
||||
pzList.add(pz4);
|
||||
|
||||
List<Pizza> undeliveredPzs = Pizza.getAllUndeliveredPizzas(pzList);
|
||||
assertTrue(undeliveredPzs.size() == 3);
|
||||
}
|
||||
```
|
||||
|
||||
### 6.2. EnumMap
|
||||
|
||||
`EnumMap`是一个专门化的映射实现，用于将枚举常量用作键。与对应的 `HashMap` 相比，它是一个高效紧凑的实现，并且在内部表示为一个数组:
|
||||
|
||||
```java
|
||||
EnumMap<Pizza.PizzaStatus, Pizza> map;
|
||||
```
|
||||
|
||||
让我们快速看一个真实的示例，该示例演示如何在实践中使用它：
|
||||
|
||||
```java
|
||||
Iterator<Pizza> iterator = pizzaList.iterator();
|
||||
while (iterator.hasNext()) {
|
||||
Pizza pz = iterator.next();
|
||||
PizzaStatus status = pz.getStatus();
|
||||
if (pzByStatus.containsKey(status)) {
|
||||
pzByStatus.get(status).add(pz);
|
||||
} else {
|
||||
List<Pizza> newPzList = new ArrayList<>();
|
||||
newPzList.add(pz);
|
||||
pzByStatus.put(status, newPzList);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
下面的测试展示了 `EnumMap` 在某些场景下的强大功能：
|
||||
|
||||
```java
|
||||
@Test
|
||||
public void givenPizaOrders_whenGroupByStatusCalled_thenCorrectlyGrouped() {
|
||||
List<Pizza> pzList = new ArrayList<>();
|
||||
Pizza pz1 = new Pizza();
|
||||
pz1.setStatus(Pizza.PizzaStatus.DELIVERED);
|
||||
|
||||
Pizza pz2 = new Pizza();
|
||||
pz2.setStatus(Pizza.PizzaStatus.ORDERED);
|
||||
|
||||
Pizza pz3 = new Pizza();
|
||||
pz3.setStatus(Pizza.PizzaStatus.ORDERED);
|
||||
|
||||
Pizza pz4 = new Pizza();
|
||||
pz4.setStatus(Pizza.PizzaStatus.READY);
|
||||
|
||||
pzList.add(pz1);
|
||||
pzList.add(pz2);
|
||||
pzList.add(pz3);
|
||||
pzList.add(pz4);
|
||||
|
||||
EnumMap<Pizza.PizzaStatus,List<Pizza>> map = Pizza.groupPizzaByStatus(pzList);
|
||||
assertTrue(map.get(Pizza.PizzaStatus.DELIVERED).size() == 1);
|
||||
assertTrue(map.get(Pizza.PizzaStatus.ORDERED).size() == 2);
|
||||
assertTrue(map.get(Pizza.PizzaStatus.READY).size() == 1);
|
||||
}
|
||||
```
|
||||
|
||||
## 7. 通过枚举实现一些设计模式
|
||||
|
||||
### 7.1 单例模式
|
||||
|
||||
通常，使用类实现 Singleton 模式并非易事，枚举提供了一种实现单例的简便方法。
|
||||
|
||||
《Effective Java 》和《Java与模式》都非常推荐这种方式，使用这种方式实现枚举可以有什么好处呢？
|
||||
|
||||
《Effective Java》
|
||||
|
||||
> 这种方法在功能上与公有域方法相近，但是它更加简洁，无偿提供了序列化机制，绝对防止多次实例化，即使是在面对复杂序列化或者反射攻击的时候。虽然这种方法还没有广泛采用，但是单元素的枚举类型已经成为实现 Singleton的最佳方法。 —-《Effective Java 中文版 第二版》
|
||||
|
||||
《Java与模式》
|
||||
|
||||
> 《Java与模式》中，作者这样写道，使用枚举来实现单实例控制会更加简洁，而且无偿地提供了序列化机制，并由JVM从根本上提供保障，绝对防止多次实例化，是更简洁、高效、安全的实现单例的方式。
|
||||
|
||||
下面的代码段显示了如何使用枚举实现单例模式：
|
||||
|
||||
```java
|
||||
public enum PizzaDeliverySystemConfiguration {
|
||||
INSTANCE;
|
||||
PizzaDeliverySystemConfiguration() {
|
||||
// Initialization configuration which involves
|
||||
// overriding defaults like delivery strategy
|
||||
}
|
||||
|
||||
private PizzaDeliveryStrategy deliveryStrategy = PizzaDeliveryStrategy.NORMAL;
|
||||
|
||||
public static PizzaDeliverySystemConfiguration getInstance() {
|
||||
return INSTANCE;
|
||||
}
|
||||
|
||||
public PizzaDeliveryStrategy getDeliveryStrategy() {
|
||||
return deliveryStrategy;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
如何使用呢？请看下面的代码：
|
||||
|
||||
```java
|
||||
PizzaDeliveryStrategy deliveryStrategy = PizzaDeliverySystemConfiguration.getInstance().getDeliveryStrategy();
|
||||
```
|
||||
|
||||
通过 `PizzaDeliverySystemConfiguration.getInstance()` 获取的就是单例的 `PizzaDeliverySystemConfiguration`
|
||||
|
||||
### 7.2 策略模式
|
||||
|
||||
通常，策略模式由不同类实现同一个接口来实现的。
|
||||
|
||||
这也就意味着添加新策略意味着添加新的实现类。使用枚举，可以轻松完成此任务，添加新的实现意味着只定义具有某个实现的另一个实例。
|
||||
|
||||
下面的代码段显示了如何使用枚举实现策略模式：
|
||||
|
||||
```java
|
||||
public enum PizzaDeliveryStrategy {
|
||||
EXPRESS {
|
||||
@Override
|
||||
public void deliver(Pizza pz) {
|
||||
System.out.println("Pizza will be delivered in express mode");
|
||||
}
|
||||
},
|
||||
NORMAL {
|
||||
@Override
|
||||
public void deliver(Pizza pz) {
|
||||
System.out.println("Pizza will be delivered in normal mode");
|
||||
}
|
||||
};
|
||||
|
||||
public abstract void deliver(Pizza pz);
|
||||
}
|
||||
```
|
||||
|
||||
给 `Pizza `增加下面的方法：
|
||||
|
||||
```java
|
||||
public void deliver() {
|
||||
if (isDeliverable()) {
|
||||
PizzaDeliverySystemConfiguration.getInstance().getDeliveryStrategy()
|
||||
.deliver(this);
|
||||
this.setStatus(PizzaStatus.DELIVERED);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
如何使用呢？请看下面的代码：
|
||||
|
||||
```java
|
||||
@Test
|
||||
public void givenPizaOrder_whenDelivered_thenPizzaGetsDeliveredAndStatusChanges() {
|
||||
Pizza pz = new Pizza();
|
||||
pz.setStatus(Pizza.PizzaStatus.READY);
|
||||
pz.deliver();
|
||||
assertTrue(pz.getStatus() == Pizza.PizzaStatus.DELIVERED);
|
||||
}
|
||||
```
|
||||
|
||||
## 8. Java 8 与枚举
|
||||
|
||||
Pizza 类可以用Java 8重写，您可以看到方法 lambda 和Stream API如何使 `getAllUndeliveredPizzas()`和`groupPizzaByStatus()`方法变得如此简洁：
|
||||
|
||||
`getAllUndeliveredPizzas()`:
|
||||
|
||||
```java
|
||||
public static List<Pizza> getAllUndeliveredPizzas(List<Pizza> input) {
|
||||
return input.stream().filter(
|
||||
(s) -> !deliveredPizzaStatuses.contains(s.getStatus()))
|
||||
.collect(Collectors.toList());
|
||||
}
|
||||
```
|
||||
|
||||
`groupPizzaByStatus()` :
|
||||
|
||||
```java
|
||||
public static EnumMap<PizzaStatus, List<Pizza>>
|
||||
groupPizzaByStatus(List<Pizza> pzList) {
|
||||
EnumMap<PizzaStatus, List<Pizza>> map = pzList.stream().collect(
|
||||
Collectors.groupingBy(Pizza::getStatus,
|
||||
() -> new EnumMap<>(PizzaStatus.class), Collectors.toList()));
|
||||
return map;
|
||||
}
|
||||
```
|
||||
|
||||
## 9. Enum 类型的 JSON 表现形式
|
||||
|
||||
使用Jackson库，可以将枚举类型的JSON表示为POJO。下面的代码段显示了可以用于同一目的的Jackson批注：
|
||||
|
||||
```java
|
||||
@JsonFormat(shape = JsonFormat.Shape.OBJECT)
|
||||
public enum PizzaStatus {
|
||||
ORDERED (5){
|
||||
@Override
|
||||
public boolean isOrdered() {
|
||||
return true;
|
||||
}
|
||||
},
|
||||
READY (2){
|
||||
@Override
|
||||
public boolean isReady() {
|
||||
return true;
|
||||
}
|
||||
},
|
||||
DELIVERED (0){
|
||||
@Override
|
||||
public boolean isDelivered() {
|
||||
return true;
|
||||
}
|
||||
};
|
||||
|
||||
private int timeToDelivery;
|
||||
|
||||
public boolean isOrdered() {return false;}
|
||||
|
||||
public boolean isReady() {return false;}
|
||||
|
||||
public boolean isDelivered(){return false;}
|
||||
|
||||
@JsonProperty("timeToDelivery")
|
||||
public int getTimeToDelivery() {
|
||||
return timeToDelivery;
|
||||
}
|
||||
|
||||
private PizzaStatus (int timeToDelivery) {
|
||||
this.timeToDelivery = timeToDelivery;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
我们可以按如下方式使用 `Pizza` 和 `PizzaStatus`：
|
||||
|
||||
```java
|
||||
Pizza pz = new Pizza();
|
||||
pz.setStatus(Pizza.PizzaStatus.READY);
|
||||
System.out.println(Pizza.getJsonString(pz));
|
||||
```
|
||||
|
||||
生成 Pizza 状态以以下JSON展示：
|
||||
|
||||
```json
|
||||
{
|
||||
"status" : {
|
||||
"timeToDelivery" : 2,
|
||||
"ready" : true,
|
||||
"ordered" : false,
|
||||
"delivered" : false
|
||||
},
|
||||
"deliverable" : true
|
||||
}
|
||||
```
|
||||
|
||||
有关枚举类型的JSON序列化/反序列化（包括自定义）的更多信息，请参阅[Jackson-将枚举序列化为JSON对象。](https://www.baeldung.com/jackson-serialize-enums)
|
||||
|
||||
## 10.总结
|
||||
|
||||
本文我们讨论了Java枚举类型，从基础知识到高级应用以及实际应用场景，让我们感受到枚举的强大功能。
|
||||
|
||||
## 11. 补充
|
||||
|
||||
我们在上面讲到了，我们可以通过在枚举类型中定义属性,方法和构造函数让它变得更加强大。
|
||||
|
||||
下面我通过一个实际的例子展示一下，当我们调用短信验证码的时候可能有几种不同的用途，我们在下面这样定义：
|
||||
|
||||
```java
|
||||
|
||||
public enum PinType {
|
||||
|
||||
REGISTER(100000, "注册使用"),
|
||||
FORGET_PASSWORD(100001, "忘记密码使用"),
|
||||
UPDATE_PHONE_NUMBER(100002, "更新手机号码使用");
|
||||
|
||||
private final int code;
|
||||
private final String message;
|
||||
|
||||
PinType(int code, String message) {
|
||||
this.code = code;
|
||||
this.message = message;
|
||||
}
|
||||
|
||||
public int getCode() {
|
||||
return code;
|
||||
}
|
||||
|
||||
public String getMessage() {
|
||||
return message;
|
||||
}
|
||||
|
||||
@Override
|
||||
public String toString() {
|
||||
return "PinType{" +
|
||||
"code=" + code +
|
||||
", message='" + message + '\'' +
|
||||
'}';
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
实际使用：
|
||||
|
||||
```java
|
||||
System.out.println(PinType.FORGET_PASSWORD.getCode());
|
||||
System.out.println(PinType.FORGET_PASSWORD.getMessage());
|
||||
System.out.println(PinType.FORGET_PASSWORD.toString());
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
```java
|
||||
100001
|
||||
忘记密码使用
|
||||
PinType{code=100001, message='忘记密码使用'}
|
||||
```
|
||||
|
||||
这样的话，在实际使用起来就会非常灵活方便！
|
||||
157
index.html
157
index.html
@ -1,77 +1,92 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<title>JavaGuide</title>
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
|
||||
<meta name="description" content="Description" />
|
||||
<meta
|
||||
name="viewport"
|
||||
content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0"
|
||||
/>
|
||||
<link rel="stylesheet" href="//unpkg.com/docsify/lib/themes/prism.css" />
|
||||
<!--主题-->
|
||||
<link rel="stylesheet" href="//unpkg.com/docsify/lib/themes/vue.css" />
|
||||
</head>
|
||||
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>JavaGuide</title>
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
|
||||
<meta name="description" content="Description">
|
||||
<meta name="viewport"
|
||||
content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
|
||||
<link rel="stylesheet" href="//unpkg.com/docsify/lib/themes/prism.css">
|
||||
<!--主题-->
|
||||
<link rel="stylesheet" href="//unpkg.com/docsify/lib/themes/vue.css">
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<nav>
|
||||
<a href="https://cowtransfer.com/s/fbed14f0c22a4d">图解计算机基础</a>
|
||||
<a href="https://wx.zsxq.com/dweb2/index/group/48418884588288">知识星球</a>
|
||||
</nav>
|
||||
<div id="app"></div>
|
||||
<!-- docsify-edit-on-github -->
|
||||
<script src="//unpkg.com/docsify-edit-on-github/index.js"></script>
|
||||
<script>
|
||||
// 离线支持
|
||||
if (typeof navigator.serviceWorker !== 'undefined') {
|
||||
navigator.serviceWorker.register('sw.js')
|
||||
}
|
||||
window.$docsify = {
|
||||
name: 'JavaGuide',
|
||||
repo: 'https://github.com/Snailclimb/JavaGuide',
|
||||
maxLevel: 4,//最大支持渲染的标题层级
|
||||
//封面,_coverpage.md
|
||||
//coverpage: true,
|
||||
auto2top: true,//切换页面后是否自动跳转到页面顶部
|
||||
//ga: 'UA-138586553-1',
|
||||
//logo: 'https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-3logo-透明.png' ,
|
||||
search: {
|
||||
//maxAge: 86400000, // 过期时间，单位毫秒，默认一天
|
||||
paths: 'auto',
|
||||
placeholder: '搜索',
|
||||
noData: '找不到结果',
|
||||
// 搜索标题的最大程级, 1 - 6
|
||||
depth: 3,
|
||||
},
|
||||
// 字数统计
|
||||
count: {
|
||||
countable: true,
|
||||
fontsize: '0.9em',
|
||||
color: 'rgb(90,90,90)',
|
||||
language: 'chinese'
|
||||
},
|
||||
plugins: [
|
||||
EditOnGithubPlugin.create('https://github.com/Snailclimb/JavaGuide/blob/master/')
|
||||
],
|
||||
}
|
||||
</script>
|
||||
<script src="//unpkg.com/docsify/lib/docsify.min.js"></script>
|
||||
<!--Java代码高亮-->
|
||||
<script src="//unpkg.com/prismjs/components/prism-java.js"></script>
|
||||
<!--全文搜索,直接用官方提供的无法生效-->
|
||||
<script src="https://cdn.bootcss.com/docsify/4.5.9/plugins/search.min.js"></script>
|
||||
<!--谷歌统计
|
||||
<body>
|
||||
<nav>
|
||||
<a href="https://cowtransfer.com/s/fbed14f0c22a4d">图解计算机基础</a>
|
||||
<a href="https://wx.zsxq.com/dweb2/index/group/48418884588288"
|
||||
>知识星球</a
|
||||
>
|
||||
</nav>
|
||||
<div id="app"></div>
|
||||
<!-- docsify-edit-on-github -->
|
||||
<script src="//unpkg.com/docsify-edit-on-github/index.js"></script>
|
||||
<script>
|
||||
// 离线支持
|
||||
if (typeof navigator.serviceWorker !== "undefined") {
|
||||
navigator.serviceWorker.register("sw.js");
|
||||
}
|
||||
window.$docsify = {
|
||||
name: "JavaGuide",
|
||||
repo: "https://github.com/Snailclimb/JavaGuide",
|
||||
maxLevel: 4, //最大支持渲染的标题层级
|
||||
//封面,_coverpage.md
|
||||
//coverpage: true,
|
||||
auto2top: true, //切换页面后是否自动跳转到页面顶部
|
||||
//ga: 'UA-138586553-1',
|
||||
//logo: 'https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-3logo-透明.png' ,
|
||||
search: {
|
||||
//maxAge: 86400000, // 过期时间，单位毫秒，默认一天
|
||||
paths: "auto",
|
||||
placeholder: "搜索",
|
||||
noData: "找不到结果",
|
||||
// 搜索标题的最大程级, 1 - 6
|
||||
depth: 3,
|
||||
},
|
||||
// 备案
|
||||
beian: {
|
||||
ICP: "鄂ICP备2020015769号",
|
||||
NISMSP: {
|
||||
number: "",
|
||||
url: "",
|
||||
id: "",
|
||||
},
|
||||
},
|
||||
// 字数统计
|
||||
count: {
|
||||
countable: true,
|
||||
fontsize: "0.9em",
|
||||
color: "rgb(90,90,90)",
|
||||
language: "chinese",
|
||||
},
|
||||
plugins: [
|
||||
EditOnGithubPlugin.create(
|
||||
"https://github.com/Snailclimb/JavaGuide/blob/master/"
|
||||
),
|
||||
],
|
||||
};
|
||||
</script>
|
||||
<script src="//unpkg.com/docsify/lib/docsify.min.js"></script>
|
||||
<!--Java代码高亮-->
|
||||
<script src="//unpkg.com/prismjs/components/prism-java.js"></script>
|
||||
<!--全文搜索,直接用官方提供的无法生效-->
|
||||
<script src="https://cdn.bootcss.com/docsify/4.5.9/plugins/search.min.js"></script>
|
||||
<!--谷歌统计
|
||||
<script src="//unpkg.com/docsify" data-ga="UA-138586553-1"></script>
|
||||
<script src="//unpkg.com/docsify/lib/plugins/ga.js"></script>
|
||||
-->
|
||||
<!-- 复制到剪贴板 -->
|
||||
<script src="//unpkg.com/docsify-copy-code"></script>
|
||||
<!-- 图片缩放 -->
|
||||
<script src="//unpkg.com/docsify/lib/plugins/zoom-image.js"></script>
|
||||
<!-- 表情 -->
|
||||
<script src="//unpkg.com/docsify/lib/plugins/emoji.js"></script>
|
||||
<!-- 字数统计 -->
|
||||
<script src="//unpkg.com/docsify-count/dist/countable.js"></script>
|
||||
</body>
|
||||
|
||||
</html>
|
||||
<!-- 复制到剪贴板 -->
|
||||
<script src="//unpkg.com/docsify-copy-code"></script>
|
||||
<!-- 图片缩放 -->
|
||||
<script src="//unpkg.com/docsify/lib/plugins/zoom-image.js"></script>
|
||||
<!-- 表情 -->
|
||||
<script src="//unpkg.com/docsify/lib/plugins/emoji.js"></script>
|
||||
<!-- 字数统计 -->
|
||||
<script src="//unpkg.com/docsify-count/dist/countable.js"></script>
|
||||
<!-- 备案 -->
|
||||
<script src="https://cdn.jsdelivr.net/npm/docsify-beian@latest/dist/beian.min.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 67 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 67 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Loading…
x
Reference in New Issue
Block a user