搜索[持久化]结果-低调大师优秀个人博客

SpringBoot2整合Thymeleaf，官方推荐html解决方案

使其不受技术细节的打扰 4、为Web准备在模板语言中内建处理典型Web相关任务(如HTML转义)的结构能够集成到Mode2Web应用框架中作为JsP的支持JSP标记库为MVC模式设计:分离可视化设计和应用程序逻辑

2025-09-05

CentOS8编译安装MySQL8.0.19

mysql用户 sh 复制代码 chown -Rf mysql:mysql /data0/mysql && chown -Rf mysql:mysql /data1/mysql 7.初始化MySQL

2025-09-05

Spark RDD算子进阶（转换算子、行动算子、缓存、持久化）

持久化 4. persist()的两个坑 0xFF 总结 0x00 教程内容转换算子与行动算子的进阶操作 RDD的缓存与持久化 0x01 进阶算子操作 1.

2021-06-10

工作流引擎Activiti集成JPA持久化保存流程数据

BigDecimal java.util.Date java.sql.Date JPA配置引擎必须有一个对EntityManagerFactory的引用才能够使用JPA的实体,这样可以通过配置引用或者提供一个持久化单元名称

2021-04-28

Smart Retry 1.3.7 发布，声明式的异步持久化重试框架

和 Guava Retry、Spring Retry 相比，Smart Retry 最大的特点是异步重试，支持持久化，系统重启之后可以继续重试。

2020-05-11

Smart Retry 1.3.5 发布，声明式的异步持久化重试框架

和Guava Retry、Spring Retry相比，Smart Retry最大的特点是异步重试，支持持久化，系统重启之后可以继续重试。

2020-04-08

Smart Retry 1.3.4 发布，声明式的异步持久化重试框架

和Guava Retry、Spring Retry相比，Smart Retry最大的特点是异步重试，支持持久化，系统重启之后可以继续重试。

2020-03-27

nsq (三) 消息传输的可靠性和持久化[一]

看上去这个流程是没有问题的，我们来思考几个问题网络传输的不确定性，比如超时；客户端处理消息时崩溃等，消息如何重传；如何标识消息被客户端成功处理完毕；消息的持久化，nsq服务端重新启动时消息不丢失；

2019-10-30

从RocketMQ消息持久化设计看磁盘性能瓶颈的突破

从RocketMQ消息持久化设计看磁盘性能瓶颈的突破微信公众号：IT一刻钟。大型现实非严肃主义现场，一刻钟与你分享优质技术架构与见闻，做一个有剧情的程序员。

2019-05-16

本文是从0到1使用Kubernetes系列第六篇，上一篇《从0到1使用Kubernetes系列（五）：Kubernetes Scheduling》介绍了Kubernetes调度器如何进行资源调度，本文将为大家介绍几种常用储存类型。默认情况下Pod挂载在磁盘上的文件生命周期与Pod生命周期是一致的，若Pod出现崩溃的情况，kubelet 将会重启它，这将会造成Pod中的文件将丢失，因为Pod会以镜像最初的状态重新启动。在实际应用当中，开发者有很多时候需要将容器中的数据保留下来，比如在Kubernetes中部署了MySql，不能因为MySql容器挂掉重启而上面的数据全部丢失；其次，在 Pod 中同时运行多个容器时，这些容器之间可能需要共享文件。也有的时候，开发者需要预置配置文件，使其在容器中生效，例如自定义了mysql.cnf文件在MySql启动时就需要加载此配置文件。这些都将是今天将要实战解决的问题。今天这篇文将讲解下面几种常用存储类型： secret configMap emptyDir hostPath nfs persistentVolumeClaim SECRET Secret对象允许您存储和管理敏感信息，例如密码，OAuth令牌和ssh密钥。将此类信息放入一个secret中可以更好地控制它的用途，并降低意外暴露的风险。 ▌使用场景鉴权配置文件挂载 ▌使用示例在CI中push构建好的镜像就可以将docker鉴权的config.json文件存入secret对象中，再挂载到CI的Pod中，从而进行权限认证。首先创建secret $ kubectl create secret docker-registry docker-config --docker-server=https://hub.docker.com --docker-username=username --docker-password=password secret/docker-config created 新建docker-pod.yaml文件，粘贴以下信息： apiVersion: v1 kind: Pod metadata: name: docker spec: containers: - name: docker image: docker command: - sleep - "3600" volumeMounts: - name: config mountPath: /root/.docker/ volumes: - name: config secret: secretName: docker-config items: - key: .dockerconfigjson path: config.json mode: 0644 Docker Pod挂载secret $ kubectl apply -f docker-pod.yaml pod/docker created 查看挂载效果 $ kubectl exec docker -- cat /root/.docker/config.json {"auths":{"https://hub.docker.com":{"username":"username","password":"password","auth":"dXNlcm5hbWU6cGFzc3dvcmQ="}}} 清理环境 $ kubectl delete pod docker $ kubectl delete secret docker-config ConfigMap 许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。这些配置信息需要与docker image解耦ConfigMap API给我们提供了向容器中注入配置信息的机制，ConfigMap可以被用来保存单个属性，也可以用来保存整个配置文件。 ▌使用场景配置信息文件挂载 ▌使用示例使用ConfigMap中的数据来配置Redis缓存创建example-redis-config.yaml文件，粘贴以下信息： apiVersion: v1 kind: ConfigMap metadata: name: example-redis-config data: redis-config: | maxmemory 2b maxmemory-policy allkeys-lru 创建ConfigMap $ kubectl apply -f example-redis-config.yaml configmap/example-redis-config created 创建example-redis.yaml文件，粘贴以下信息： apiVersion: v1 kind: Pod metadata: name: redis spec: containers: - name: redis image: kubernetes/redis:v1 env: - name: MASTER value: "true" ports: - containerPort: 6379 resources: limits: cpu: "0.1" volumeMounts: - mountPath: /redis-master-data name: data - mountPath: /redis-master name: config volumes: - name: data emptyDir: {} - name: config configMap: name: example-redis-config items: - key: redis-config path: redis.conf Redis Pod挂载ConfigMap测试 $ kubectl apply -f example-redis.yaml pod/redis created 查看挂载效果 $ kubectl exec -it redis redis-cli $ 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" $ 127.0.0.1:6379> CONFIG GET maxmemory-policy 1) "maxmemory-policy" 2) "allkeys-lru" 清理环境 $ kubectl delete pod redis $ kubectl delete configmap example-redis-config EmptyDir 当使用emptyDir卷的Pod在节点创建时，会在该节点创建一个新的空目录，只要该Pod运行在该节点，该目录会一直存在，Pod内的所有容器可以将改目录挂载到不同的挂载点，但都可以读写emptyDir内的文件。当Pod不论什么原因被删除，emptyDir的数据都会永远被删除（一个Container Crash 并不会在该节点删除Pod，因此在Container crash时，数据不会丢失）。默认情况下，emptyDir支持任何类型的后端存储：disk、ssd、网络存储。也可以通过设置 emptyDir.medium 为Memory，kubernetes会默认mount一个tmpfs（RAM-backed filesystem），因为是RAM Backed,因此 tmpfs 通常很快。但是会在容器重启或者crash时，数据丢失。 ▌使用场景同一Pod内各容器共享存储 ▌使用示例在容器a中生成hello文件，通过容器b输出文件内容创建test-emptydir.yaml文件，粘贴以下信息： apiVersion: v1 kind: Pod metadata: name: test-emptydir spec: containers: - image: alpine name: container-a command: - /bin/sh args: - -c - echo 'I am container-a' >> /cache-a/hello && sleep 3600 volumeMounts: - mountPath: /cache-a name: cache-volume - image: alpine name: container-b command: - sleep - "3600" volumeMounts: - mountPath: /cache-b name: cache-volume volumes: - name: cache-volume emptyDir: {} 创建Pod kubectl apply -f test-emptydir.yaml pod/test-emptydir created 测试 $ kubectl exec test-emptydir -c container-b -- cat /cache-b/hello I am container-a 清理环境 $ kubectl delete pod test-emptydir HostPath 将宿主机对应目录直接挂载到运行在该节点的容器中。使用该类型的卷，需要注意以下几个方面：使用同一个模板创建的Pod，由于不同的节点有不同的目录信息，可能会导致不同的结果如果kubernetes增加了已知资源的调度，该调度不会考虑hostPath使用的资源如果宿主机目录上已经存在的目录，只可以被root可以写，所以容器需要root权限访问该目录，或者修改目录权限 ▌使用场景运行的容器需要访问宿主机的信息，比如Docker内部信息/var/lib/docker目录，容器内运行cadvisor，需要访问/dev/cgroups ▌使用示例使用Docker socket binding模式在列出宿主机镜像列表。创建test-hostpath.yaml文件，粘贴以下信息： apiVersion: v1 kind: Pod metadata: name: test-hostpath spec: containers: - image: docker name: test-hostpath command: - sleep - "3600" volumeMounts: - mountPath: /var/run/docker.sock name: docker-sock volumes: - name: docker-sock hostPath: path: /var/run/docker.sock type: Socket 创建test-hostpath Pod $ kubectl apply -f test-hostpath.yaml pod/test-hostpath created 测试是否成功 $ kubectl exec test-hostpath docker images REPOSITORY IMAGE ID CREATED SIZE docker 639de9917ae1 13 days ago 171MB ... NFS存储卷 NFS 卷允许将现有的 NFS（网络文件系统）共享挂载到您的容器中。不像 emptyDir，当删除 Pod 时，nfs 卷的内容被保留，卷仅仅是被卸载。这意味着 nfs 卷可以预填充数据，并且可以在 pod 之间共享数据。 NFS 可以被多个写入者同时挂载。重要提示：您必须先拥有自己的 NFS 服务器然后才能使用它。 ▌使用场景不同节点Pod使用统一nfs共享目录 ▌使用示例创建test-nfs.yaml文件，粘贴以下信息： apiVersion: apps/v1 kind: Deployment metadata: name: test-nfs spec: selector: matchLabels: app: store replicas: 2 template: metadata: labels: app: store spec: volumes: - name: data nfs: server: nfs.server.com path: / affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: "kubernetes.io/hostname" containers: - name: alpine image: alpine command: - sleep - "3600" volumeMounts: - mountPath: /data name: data 创建测试deployment $ kubectl apply -f test-nfs.yaml deployment/test-nfs created 查看pod运行情况 $ kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE test-nfs-859ccfdf55-kkgxj 1/1 Running 0 1m 10.233.68.245 uat05 <none> test-nfs-859ccfdf55-aewf8 1/1 Running 0 1m 10.233.67.209 uat06 <none> 进入Pod中进行测试 # 进入uat05节点的pod中 $ kubectl exec -it test-nfs-859ccfdf55-kkgxj sh # 创建文件 $ echo "uat05" > /data/uat05 # 退出uat05节点的pod $ edit # 进入uat06节点的pod中 $ kubectl exec -it test-nfs-859ccfdf55-aewf8 sh # 查看文件内容 $ cat /data/uat05 uat05 清理环境 $ kubectl delete deployment test-nfs PersistentVolumeClaim 上面所有例子中我们都是直接将存储挂载到的pod中，那么在kubernetes中如何管理这些存储资源呢？这就是Persistent Volume和Persistent Volume Claims所提供的功能。 ● PersistentVolume 子系统为用户和管理员提供了一个 API，该 API 将如何提供存储的细节抽象了出来。为此，我们引入两个新的 API 资源：PersistentVolume 和 PersistentVolumeClaim。 PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含 Volume 的实现，即 NFS、iSCSI 或特定于云供应商的存储系统。 PersistentVolumeClaim（PVC）是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或只读多次模式挂载）。虽然 PersistentVolumeClaims 允许用户使用抽象存储资源，但用户需要具有不同性质（例如性能）的 PersistentVolume 来解决不同的问题。集群管理员需要能够提供各种各样的 PersistentVolume，这些PersistentVolume 的大小和访问模式可以各有不同，但不需要向用户公开实现这些卷的细节。对于这些需求，StorageClass 资源可以实现。 ● 在实际使用场景里，PV 的创建和使用通常不是同一个人。这里有一个典型的应用场景：管理员创建一个 PV 池，开发人员创建 Pod 和 PVC，PVC 里定义了Pod所需存储的大小和访问模式，然后 PVC 会到 PV 池里自动匹配最合适的 PV 给 Pod 使用。 ▌使用示例创建PersistentVolume apiVersion: v1 kind: PersistentVolume metadata: name: mypv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: slow mountOptions: - hard - nfsvers=4.0 nfs: path: /tmp server: 172.17.0.2 创建PersistentVolumeClaim kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 5Gi volumeName: mypv 创建Pod绑定PVC kind: Pod apiVersion: v1 metadata: name: mypod spec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: myclaim 查看pod运行情况验证绑定结果 $ kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE mypod 1/1 Running 0 1m 10.233.68.249 uat05 <none> $ kubectl exec -it mypod sh $ ls /var/www/html 清理环境 $ kubectl delete pv mypv $ kubectl delete pvc myclaim $ kubectl delete po mypod 总结本次实战中使用了secret存储docker认证凭据，更好地控制它的用途，并降低意外暴露的风险。使用configMap对redis进行缓存配置，这样即使redis容器挂掉重启configMap中的配置依然会生效。接着又使用emptyDir来使得同一Pod中多个容器的目录共享，在实际应用中开发者通常使用initContainers来进行预处理文件，然后通过emptyDir传递给Containers。然后再使用hostPath来访问宿主机的资源，当网路io达不到文件读写要求时，可考虑固定应用只运行在一个节点上然后使用hostPath来解决文件读写速度的要求。 NFS和PersistentVolumeClaim的例子实质上都是试容器挂载的nfs服务器共享目录，但这些资源一般都只掌握在了管理员手中，开发人员想要获取这部分资源那么就不是这么友好了，动态存储类（StorageClass）就能很好的解决此类问题。更多关于Kubernetes系列的文章：从0到1使用Kubernetes系列（五）：Kubernetes Scheduling 从0到1使用Kubernetes系列（四）：搭建第一个应用程序从0到1使用Kubernetes系列（三）：使用Ansible安装Kubernetes集群从0到1使用Kubernetes系列（二）——安装工具介绍从0到1使用Kubernetes系列——Kubernetes入门关于Choerodon猪齿鱼 Choerodon猪齿鱼开源多云集成平台，基于开源技术Kubernetes，Istio，knative，Gitlab和Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：官网：http://choerodon.io 论坛：http://forum.choerodon.io Github：https://github.com/choerodon 微信公众号：Choerodon猪齿鱼微博：Choerodon猪齿鱼

2019-04-10