持久化

Mysql部署 关于持久化部署mysql数据库 mysql数据库如果简单地部署在k8s集群上，当pods重启时，数据可能会造成丢失，经过查找资料，发现通过PV和PVC可以进行一个持久化的部署。 PV、PVC PersistentVolume（持久卷） 和 PersistentVolumeClaim（持久卷申请） PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。 PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV 1.什么是持久化？ 本人找了好多文章都没有找到满意的答案，最后是从孙卫琴写的《精通Hibernate：Java对象持久化技术详解》中，看到如下的解释，感觉还是比较完整的。摘抄如下： 狭义的理解: “持久化”仅仅指把域对象永久保存到数据库中；广义的理解,“持久化”包括和数据库相关的各种操作。 ● 保存：把域对象永久保存到数据库。 ● 更新：更新数据库中域对象的状态。 ● 删除：从数据库中删除一个域对象。 ● 加载：根据特定的OID

Entity Identity 实体标识 一般采用单一值做为entity identity 采用compsite primary key时，必须单独建立一个表示主键的类－primary key class主键类。这样在实体上compsite primary key就可以用一个属性（primary key class类型）表示 持久化框架内部很多地方使用entity identity进行处理，因此primary key class要正确实现equals、hashCode方法 另外应用层需要注意，对persistence context中受管理的对象，不要修改主键值，否则持久化框架无法承诺带来的影响，因为persistence context只能基于entity identity标识实体身份 Accessor of Persistent Fields and Properties 持久化值域和属性的访问器 Persistent state（即需要持久化的fields或properties）的存取分2种类型：field-based和property-based field-based时持久化框架直接存取instance variables，property-based时则通过getter、setter方法存取 使用property-based时，在setter

RabbitMQ一般情况很少丢失，但是不能排除意外，为了保证我们自己系统高可用，我们必须作出更好完善措施，保证系统的稳定性。 下面来介绍下，如何保证消息的绝对不丢失的问题，下面分享的绝对干货，都是在知名互联网产品的产线中使用。 1.消息持久化 2.ACK确认机制 3.设置集群镜像模式 4.消息补偿机制 第一种：消息持久化 RabbitMQ 的消息默认存放在内存上面，如果不特别声明设置，消息不会持久化保存到硬盘上面的，如果节点重启或者意外crash掉，消息就会丢失。 所以就要对消息进行持久化处理。如何持久化，下面具体说明下： 要想做到消息持久化，必须满足以下三个条件，缺一不可。 1） Exchange 设置持久化 2）Queue 设置持久化 3）Message持久化发送：发送消息设置发送模式deliveryMode=2，代表持久化消息 第二种：ACK确认机制 多个消费者同时收取消息，比如消息接收到一半的时候，一个消费者死掉了(逻辑复杂时间太长，超时了或者消费被停机或者网络断开链接)，如何保证消息不丢？ 这个使用就要使用Message acknowledgment 机制，就是消费端消费完成要通知服务端，服务端才把消息从内存删除。 这样就解决了，及时一个消费者出了问题，没有同步消息给服务端，还有其他的消费端去消费，保证了消息不丢的case。 第三种：设置集群镜像模式

「luogu3402」【模板】可持久化并查集 传送门 我们可以用一个可持久化数组来存每个节点的父亲。 单点信息更新和查询就用主席树多花 一个 \(\log\) 的代价来搞。 然后考虑如何合并两个点。 由于我们要做到可持久化，所以我们就考虑用启发式合并。 至于路径压缩，ta好像会因为某些原因而MLE和TLE 其实我也没试过 那么我们在合并的时候就只需要借助主席树完成单点查询和修改就好了。 注意一个地方值得注意，就是在修改时因为我们的线段树是可持久化的，所以会通向之前版本的节点，所以不要覆盖之前的信息，不然就不是可持久化了。 参考代码： #include <cstdio> #define rg register #define file(x) freopen(x".in", "r", stdin), freopen(x".out", "w", stdout) template < class T > inline void swap(T& a, T& b) { T t = a; a = b; b = t; } template < class T > inline void read(T& s) { s = 0; int f = 0; char c = getchar(); while ('0' > c || c > '9') f |= c == '-', c = getchar();

在工作中很多时候，开发工作都是一个人完成的。用过Hibernate、MyBatis，但是个人更倾向于JFinal DB，非常简洁、方便，对小规模团队更加友好。 其实在更早的时候，使用山东一家商用平台，也有类似的持久化功能。一是具有Record的类，可以作为任何SQL执行后的结果集，有点像ResultSet，但可以直接getString，而且其Dao层query的值，都是直接返回List<Record>，过了3年遇到了JFinal，当时版本还是2.2，也有这个功能。 为了移植，首先观摩JFinal的Record思路。 这里有两个重点，一个是getStr方法，一个是getColumns方法。 getStr很好理解，从getColumns这个Map中获取某个特定名称的值。 getColumns，只是获取的一个dataMap的值。这二者具体的数值，都是在Db这个类下面进行SQL操作的时候赋予的。 那么Record移植就简单了，首先应当持有一个dataMap，其次有一个getStr方法。至于Db怎么操作dataMap，则是Db的重点。 Db需要移植的方法有find和update（或者称execute），find可以直接传入一个SQL，返回List<Record>，update则可以执行一条SQL语句。衍生出dialect，用于兼容不同数据库的差别（需要多态支持）。 在JFinal DB中

和线段树类似，每个结点也要打lazy标记 但是lazy标记和线段树不一样 具体区别在于 可持久化后lazy-tag不用往下传递，而是固定在这个区间并不断累加，变成了这个区间固有的性质(有点像分块的标记了) update就按照这么来 int update(int last,int L,int R,int c,int l,int r){ int now=++size; T[now]=T[last]; if(L<=l && R>=r){ T[now].sum+=(r-l+1)*c; T[now].add+=c; return now; } int mid=l+r>>1; if(L<=mid)T[now].lc=update(T[last].lc,L,R,c,l,mid); if(R>mid)T[now].rc=update(T[last].rc,L,R,c,mid+1,r); pushup(l,r,now); return now; } 查询时由于lazytag固定在区间上。所以向下查询的时候要把上层的lazytag的影响都算上，即递归时传递一个上层区间的 影响值（例如add） ll query(int now,int L,int R,int add,int l,int r){ if(L<=l && R>=r) return T[now].sum+(ll)add*(r-l+1); int

题目链接： 模板题 普通的并查集是通过 f a fa f a 数组来实现的（或者说是 p p p 数组） 可持久化并查集，就是用主席树来维护并查集的 f a fa f a 数组（因为主席树可以记录过去的版本），使之能回退到过去的版本，这里的版本指的是某个操作之前的 f a fa f a 数组 可持久化并查集的合并部分使用的不是路径压缩来优化，而是使用启发式合并：两棵树合并时，将树深小的合并到树深大的，这样树的高度增长比较慢。 若合并两棵树，新的树的高度会增长，那么树的 s i z e size s i z e 至少扩大两倍，因此树高至多增长 log ⁡ n \log n lo g n 次，每次增长的值为 1。 主席树部分： 先建一棵初始的主席树，令每个下标 i i i 的 f a [ i ] = i fa[i] = i f a [ i ] = i void build ( int & rt , int l , int r ) { rt = ++ sz ; if ( l == r ) { dep [ rt ] = 1 ; fa [ rt ] = l ; return ; } int mid = l + r >> 1 ; build ( lson [ rt ] , l , mid ) ; build ( rson [ rt ] , mid + 1 , r ) ; } 更新

RabbitMQ简介 RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。 RabbitMQ是一套开源（MPL）的消息队列服务软件，是由LShift提供的一个Advanced Message Queuing Protocol（AMQP）的开源实现，由以高性能、健壮以及可伸缩性出名的Erlang写成。 选择RabbitMQ 市面上有很多MQ可以选择，如：ActiveMQ、ZeroMQ、Apache Qpid及RocketMQ，为什么要选择RabbitMQ呢？ 1. 除了Qpid，RabbitMQ是唯一一个实现了AMQP标准的消息服务器； 2. 可靠性，RabbitMQ的持久化支持，保证了消息的稳定性； 3. 高并发，RabbitMQ使用了Erlang开发语言，Erlang是为电话交换机开发的语言，天生自带高并发光环和高可用特性； 4. 集群部署简单，正是应为Erlang使得RabbitMQ集群部署变的超级简单； 5. 社区活跃度高，从网上资料来看，RabbitMQ也是首选 工作机制 1. 消息模型 生产者、消费者和代理 生产者（producer）：消息的创建者，负责创建和推送数据到消息服务器； 消费者（consumer）：消息的接收方，用于处理数据和确认消息； 代理（proxy）：就是RabbitMQ本身，用于扮演“快递”的角色

简单地来看，将一个游离的对象要被持久化(save)时报错。 我们知道要持久化对象时候，通常Hibernate会根据ID生成策略自动生成ID值，但是这个对象ID已经有值，所有抛错。这个错误会出现在配置如下一对多@OneToMany的关联关系等出现。 // 部门拥有的车辆 @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "assignedDept") @JsonIgnore private List<Vehicle> assignedVehicles; 因为级联关系是CascadeType.ALL，所以save时会保存级联的对象Role，但是Role已经存在，因此就报错了。将cascade改为CascadeType.MERGE或者CascadeType.REFRESH即可，表示级联对象在Role表存在则进行update操作，而不做save操作。 级联操作时谨慎用CascadeType.ALL 改为： @OneToMany(cascade = CascadeType.REFRESH, fetch = FetchType.LAZY, mappedBy = "assignedDept") 来源： https://www.cnblogs.com/nelson-hu/p/7485319.html

每次进行单点修改后，会新增 \(log\ n\) 个新节点，即每次更改的结点数为树的高度 增加的非叶子结点一个儿子是其他版本的节点，另一个儿子是连向新节点 空间复杂度为 \(O(n+m\ log\ n)\) \(code\) ： void build(int L,int R,int &cur) { cur=++tree_cnt; if(L==R) { val[cur]=a[L]; return; } int mid=(L+R)>>1; build(L,mid,ls[cur]); build(mid+1,R,rs[cur]); } void modify(int L,int R,int pos,int v,int pre,int &cur) { cur=++tree_cnt; ls[cur]=ls[pre],rs[cur]=rs[pre]; val[cur]=val[pre]; if(L==R) { val[cur]=v; return; } int mid=(L+R)>>1; if(pos<=mid) modify(L,mid,pos,v,ls[pre],ls[cur]); if(pos>mid) modify(mid+1,R,pos,v,rs[pre],rs[cur]); } int query(int L,int R,int pos,int cur) { if(L==R)