Commit on 2025/06/20 周五 11:57:50.59
This commit is contained in:
parent
f39c9be12e
commit
cc6ad7039f
3
.gitignore
vendored
3
.gitignore
vendored
@ -1 +1,2 @@
|
||||
output/
|
||||
output/
|
||||
自学/本地记录.md
|
||||
|
||||
@ -141,18 +141,39 @@ private static final long serialVersionUID = -1321880859645675653L;
|
||||
|
||||
|
||||
|
||||
## 多级缓存
|
||||
## 收获
|
||||
|
||||
### 胡图工具类hutool
|
||||
|
||||
`ObjUtil.isNotNull(Object obj)`，仅判断对象是否 **不为 `null`**，不关心对象内容是否为空，比如空字符串 `""`、空集合 `[]`、数字 `0` 等都算是“非 null”。
|
||||
|
||||
`ObjUtil.isNotEmpty(Object obj)` 判断对象是否 **不为 null 且非“空”**
|
||||
|
||||
- 对不同类型的对象判断逻辑不同：
|
||||
- `CharSequence`（String）：长度大于 0
|
||||
- `Collection`：size > 0
|
||||
- `Map`：非空
|
||||
- `Array`：长度 > 0
|
||||
- 其它对象：只判断是否为 null（默认不认为“空”）
|
||||
|
||||
|
||||
|
||||
`StrUtil.isNotEmpty(String str) `只要不是 `null` 且长度大于 0 就算“非空”。
|
||||
|
||||
`StrUtil.isNotBlank(String str)` 不仅要非 `null`，还要**不能只包含空格、换行、Tab 等空白字符**
|
||||
|
||||
`StrUtil.hasBlank(CharSequence... strs)`只要 **至少一个字符串是 blank（空或纯空格）**就返回 `true`，底层其实就是对每个参数调用 `StrUtil.isBlank(...)`
|
||||
|
||||
|
||||
|
||||
`CollUtil.isNotEmpty(Collection<?> coll)`用于判断 **集合（Collection）是否非空**，功能类似于 `ObjUtil.isNotEmpty(...)`
|
||||
|
||||
### 多级缓存
|
||||
|
||||
|
||||
|
||||
目前貌似没有使用缓存、@deprecated
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 收获
|
||||
|
||||
### Redis+Session
|
||||
|
||||
之前我们每次重启服务器都要重新登陆，既然已经整合了 `Redis`，不妨使用 `Redis` 管理` Session`，更好地维护登录态。
|
||||
@ -236,3 +257,63 @@ server:
|
||||
- B 在锁里执行 `exists`：因为 A 的改动还在 A 的未提交事务里，**默认隔离级别（READ_COMMITTED）下看不到**，所以 `exists` 会返回 `false`
|
||||
- B 就继续 `save`，结果就可能插入重复记录，或者引发唯一索引冲突
|
||||
|
||||
|
||||
|
||||
### RBAC模型
|
||||
|
||||
团队空间：
|
||||
|
||||
|
||||
|
||||
一般来说，标准的` RBAC` 实现需要 5 张表：用户表、角色表、权限表、用户角色关联表、角色权限关联表，还是有一定开发成本的。由于我们的项目中，团队空间不需要那么多角色，可以简化`RBAC` 的实现方式，比如将角色和权限直接定义到配置文件中。
|
||||
|
||||
本项目角色：
|
||||
|
||||
| 角色 | 描述 |
|
||||
| ------ | ---------------------------- |
|
||||
| 浏览者 | 仅可查看空间中的图片内容 |
|
||||
| 编辑者 | 可查看、上传和编辑图片内容 |
|
||||
| 管理员 | 拥有管理空间和成员的所有权限 |
|
||||
|
||||
本项目权限：
|
||||
|
||||
| 权限键 | 功能名称 | 描述 |
|
||||
| -------------- | -------- | ---------------------------- |
|
||||
| spaceUsername | 成员管理 | 管理空间成员，添加或移除成员 |
|
||||
| picture:view | 查看图片 | 查看空间中的图片内容 |
|
||||
| picture:upload | 上传图片 | 上传图片到空间中 |
|
||||
| picture:edit | 修改图片 | 编辑已上传的图片信息 |
|
||||
| picture:delete | 删除图片 | 删除空间中的图片 |
|
||||
|
||||
角色权限映射：
|
||||
|
||||
| 角色 | 对应权限键 | 可执行功能 |
|
||||
| ------ | ------------------------------------------------------------ | ------------------------------------------------ |
|
||||
| 浏览者 | picture:view | 查看图片 |
|
||||
| 编辑者 | picture:view, picture:upload, picture:edit, picture:delete | 查看图片、上传图片、修改图片、删除图片 |
|
||||
| 管理员 | spaceUsername, picture:view, picture:upload, picture:edit, picture:delete | 成员管理、查看图片、上传图片、修改图片、删除图片 |
|
||||
|
||||
|
||||
|
||||
RBAC 只是一种权限设计模型，我们在 Java 代码中如何实现权限校验呢？
|
||||
|
||||
1）最直接的方案是像之前校验私有空间权限一样，封装个团队空间的权限校验方法；或者类似用户权限校验一样，写个注解 + AOP 切面。
|
||||
|
||||
2）对于复杂的角色和权限管理，可以选用现成的第三方权限校验框架来实现，编写一套权限校验规则代码后，就能整体管理系统的权限校验逻辑了。（ Sa-Token）
|
||||
|
||||
|
||||
|
||||
### 分库分表
|
||||
|
||||
如果某团队空间的图片数量比较多，可以对其数据进行单独的管理。
|
||||
|
||||
1、图片信息数据
|
||||
可以给每个团队空间单独创建一张图片表 picture_{spaceId}，也就是分库分表中的分表，而不是和公共图库、私有空间的图片混在一起。这样不仅查询空间内的图片效率更高，还便于整体管理和清理空间。但是要注意，仅对**旗舰版**空间生效，**否则分表的数量会特别多**，反而可能影响性能。
|
||||
|
||||
要实现的是会随着新增空间不断增加分表数量的**动态分表**，会使用分库分表框架 **Apache ShardingSphere** 带大家实现。
|
||||
2、图片文件数据
|
||||
|
||||
已经实现隔离，存到COS上的不同桶内。
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user