【学习分享】应用架构之持久化数据状态管理
- [一 数据持久化](#一 数据持久化)
- [二 状态管理](#二 状态管理)
- [三 伪代码实现](#三 伪代码实现)
- [三 数据库实现](#三 数据库实现)
一 数据持久化
在应用中会将产生的数据永久保存留存，应用在运行时会产生若干的数据，这些数据使用范围不同，对于一个web应用来说我们会把数据以应用层级的不同分为Request Object，Business Object，Persistent Object，View Object，不严格按照领域模型定义，具体数据层级在领域模型中讲述。Persistent Object（持久化对象），是持久化数据对象的最终存储形态，更具数据不同，可能存放在关系数据库中也可能存放在文件中，或者是其他持久化存储介质中。
二 状态管理
在程序实现的CRUD，U（Update）时会对Persistent Object的状态进行修改。Persistent Object的状态在应用中是无状态的。这里的状态是指数据的独一标识，即他包含他就是他（主键），他的运行空间与生命周期，以及数据实际状态（软删除时需要考虑）。
第一点可以通过数据主键实现，第二点存在的意义在与假设一个数据他的数据实际状态都是可用。那么在高并发场景下对同一条数据多次处理会出现怎样的情况呢？A和B请求同时获取数据的状态，此时获取的Persistent Object（简称po）都对应于版本1，B请求率先对po状态更新，A请求在更新po状态你就会发现实则A请求应该对po的版本2进行修改但是现在的情况是直接对版本1进行修改，抹杀了A请求存在的意义，如果是类金融场景那么用户数据会出现循环滚动的场景。
再说说第三点常规的D操作（Delete）或彻底的从存储介质上删除po无法对数据再次处理或当D操作错误时无法追溯本身。这点比较好理解。
三 伪代码实现
java
//po对象
class A {
String pk;
String value；
int vesion;
int dr;
}
// 持久化处理
Class B {
// 更新
// opo --目标更新的数据 npo --更新后的数据
update（opo，npo）{
if（!opo.version=npo.version） {
// 抛出异常
}
// 持久化
save(npo)
}
//删除
delete（po） {
// 这里不调用dao的delete操作
// 将po的dr调整为1 表示数据不可用已被删除
po.dr = 1;
update（opo，npo）
}
// 读取
read（pk）{
// 调用dao
// 在调用dao的read时只查找dr=0的数据
read（pk,0）
}
// 创建
create(po) {
po.version = 1;
po.dr = 0;
// 调用dao的create
create(po)
}
}上面是一个简单的CRUD操作思路，实际上我们会在dao层处理，mybatis plus就已经在dao层对上述version和dr处理具体参考mp相关配置。
三 数据库实现
在数据库实现中对于第二点的生命周期可简单利用数据库锁for update，深入的去说这个不是业务程序应该考虑的问题，笔者不推荐使用数据库实现的方法实现数据的生命周期，因为会存在死锁。