A. 在Vue中，怎样实现持久化存储数据
在开发过程中，大家可能会有一个困惑，在使用vuex的时候，每当浏览器刷新页面的时候，数据都会消失，还要重新去请求，那我们怎样去持久化存储我们所需要重复用到的数据呢？
举个栗子，假设有这样的情景，有一个登录界面，我们需要点击登录之后存储用户名和密码，该用户的用户名和密码在以后的操作中都需要用到，
比如：
1、在显示用户信息的时候需要用到用户名
2、在修改密码的时候，我们需要比对密码是否正确需要用到密码
那下面就介绍一个使用的方法：
借助于 vuex-persist 插件
使用 npm install vuex-persist -D 安装依赖
我们可以通过 commit 提交并写入我们需要持久化存储数据
在 login.vue 中
这个是我的 vuex 存储的目录结构
在 index.js 中
在 user.js 中
B. 持久化存储之 PV、PVC、StorageClass
容器化一个应用比较麻烦的地方，就是对于有状态的服务的管理，最常见的状态就是 存储状态 。
创建的PVC只有和对应的PV绑定才可以使用
绑定条件：
成功绑定之后，Pod 就是声明PVC绑定的持久化存储了，使用方法如下:
Pod 只需要在 volumes 字段里声明要使用的 PVC 的name，等Pod创建后，Kubelet会将 PVC 绑定的 PV， 例如上面的 NFS 类型的 volume 挂载到容器内目录。
PVC 和 PV 的设计，其实跟“面向对象”的思想完全一致
当每次创建 PVC 声明使用存储时，都需要去手动的创建 PV，来满足 PVC 的使用。
可以用一种机制来根据用户声明的存储使用量（PVC）来动态的创建对应的持久化存储卷（PV）。k8s 用 StorageClass 来实现动态创建 持久化存储。
存储控制器 Volume Controller，是用来专门处理持久化存储的控制器，其一个子控制循环 PersistentVolumeController 负责实现 PV 和 PVC 的绑定。
PersistentVolumeController 会 watch kube-apiserver 的 PVC 对象。如果发现有 PVC对象创建，则会查看所有可用的 PV， 如果有则绑定，若没有，则会使用 StorageClass 的配置和 PVC 的描述创建 PV 进行绑定。
所谓将一个 PV 与 PVC 进行“绑定”，其实就是将这个PV对象的名字，填在了 PVC 对象的 spec.volumeName 字段上
C. 数据持久化方案解析（八） —— UIDocument的数据存储（一）
首先看下框架基本信息
使用 UIDocument 及其底层架构的应用程序可为其文档带来许多好处：
在 Model-View-Controller 设计模式中， UIDocument 对象是模型对象或模型控制器对象 - 它管理文档的数据或共同构成文档数据的聚合模型对象。您通常将其与视图控制器配对，该视图控制器管理显示文档内容的视图。 UIDocument 不支持管理文档视图。
基于文档的应用程序包括可以生成多个文档的应用程序，每个文档都有自己的文件系统位置。基于文档的应用程序必须为其文档创建 UIDocument 的子类。有关详细信息，请参阅下面的 Subclassing Notes 。
UIDocument 体系结构中文档的主要属性是其文件URL。 通过调用 initWithFileURL: 初始化文档子类的实例时，必须传递在应用程序沙箱中查找文档文件的文件 URL 。 UIDocument 从文件URL确定文件类型（与文件扩展名关联的统一类型标识符）和文档名称（文件名组件）。 您可以覆盖 fileType 和 localizedName 属性的访问器方法以提供不同的值。
以下概述了典型 document 的生命周期（有关实现细节，请参阅 Subclassing Notes ）：
典型的基于文档的应用程序在主线程上调用 openWithCompletionHandler: ， closeWithCompletionHandler: 和 saveToURL:forSaveOperation:completionHandler: 。当这些方法启动的读取或保存操作结束时，完成处理程序块在调用该方法的同一调度队列上执行，允许您根据读取或保存操作完成任何任务。如果操作不成功，则将 NO 传递到完成 - 处理 (completion-hander) 程序块。
UIDocument 类采用 NSFilePresenter 协议。当另一个客户端尝试读取基于 UIDocument 的应用程序的文档时，该读取将暂停，直到 UIDocument 对象有机会保存对该文档所做的任何更改。
虽然有些实现什么都不做，但 UIDocument 实现了所有 NSFilePresenter 方法。具体来说， UIDocument ：
在您的 UIDocument 子类中，如果重写 NSFilePresenter 方法，则始终可以调用超类实现 （super） 。
每个基于文档的应用程序必须创建 UIDocument 的子类，其实例表示其文档。大多数应用程序的子类化要求很简单：
contentsForType：error： 和 loadFromContents：ofType：error： 通常在主队列上调用方法。进一步来说：
如果您对读取和写入 contentsForType：error： 和 loadFromContents：ofType：error： 方法的文档数据有特殊要求，则可以重写 UIDocument 类的其他方法。有关这些要求和方法的讨论，请参阅 Advanced Overrides 。
要启用 UIDocument 的自动保存功能，您必须在用户更改文档时通知它。 UIDocument 定期检查 hasUnsavedChanges 方法是否返回 YES ; 如果是，则启动文档的保存操作。
在 UIDocument 子类中实现更改跟踪有两种主要方法：
UIDocument 对象在其生命周期中的任何时刻都具有特定状态。您可以通过查询 documentState 属性来检查当前状态，并通过观察 通知获得有关更改的通知。
如果为 iCloud 启用了文档，则检查是否存在冲突版本并尝试解决冲突非常重要。通过侦听 通知然后检查文档状态是否为 UIDocumentStateInConflict 来执行此操作。此状态表示文档存在冲突版本，您可以通过调用 NSFileVersion 类方法 ： 来访问该文档，并传入文档的文件URL。如果您无需用户交互即可正确解决冲突，请执行此操作。否则，离散地通知用户存在冲突并让他们选择如何解决冲突。可能的方法包括：
除了指示文件间冲突之外，文档状态可以指示错误。例如， UIDocumentStateClosed 表示读取时出错， UIDocumentStateSavingError 表示保存或还原文档时出错。通过传递给 openWithCompletionHandler： ， closeWithCompletionHandler： ， revertToContentsOfURL：completionHandler： 和 saveToURL：forSaveOperation：completionHandler： 方法的完成处理程序的 success 参数，通知您的应用程序读取和写入错误。
您可以通过调用或实现 handleError:userInteractionPermitted: 方法来处理错误；此方法由 openWithCompletionHandler 的默认实现调用和 saveToURL：forSaveOperation：completionHandler： 分别在 UIDocument 对象遇到读取或写入错误时的方法。您可以通过通知用户来处理读取，保存和还原错误，如果情况允许，则尝试从错误中恢复。
请务必阅读 contentsForType：error： 方法的说明，以获取有关处理文档保存期间遇到的错误的指导。
如果应用程序对读取或写入文档数据有特殊要求，它可以覆盖除 loadFromContents:ofType:error: 和 contentsForType:error: 之外的 UIDocument 方法。这些要求通常包括以下内容：
如果覆盖大多数这些方法，请注意所有文档数据的读取和写入必须在后台队列上完成，并且必须与其他尝试读取和写入同一文档文件相协调。因此，您通常应该将超类实现 （super） 作为覆盖的一部分来调用，如果调用其他 UIDocument 方法，则通常应该在传入 ： 方法调用的块中调用它们。阅读方法描述以获取详细信息。
如果通过覆盖相关的访问器方法来覆盖任何文档属性属性（在 Accessing Document Attributes 下列出），请注意 UIKit 框架可以在后台线程上调用这些访问器方法。 因此，您的重写实现必须是线程安全的。
返回使用其文件系统位置初始化的文档对象。
一、配置：
环境：
CentOS7
VMware
笔者配置了四台虚拟机：
K8S-Master节点: 3GB内存 2核CPU 20GB硬盘空间
K8S-node1节点: 2GB内存 2核CPU 30GB硬盘空间
K8S-node2节点: 2GB内存 2核CPU 30GB硬盘空间
镜像仓库节点: 2GB内存 2核CPU 50GB硬盘空间
二、节点规划：
使用三台虚拟机搭建K8S集群，使用一台虚拟机搭建镜像仓库。
每台虚拟机配置两块网卡，其中一块为“NAT模式”，用于拉取镜像等功能。
另外一块网卡为“仅主机模式”，用于集群节点间的通信。归划如下：
K8s-master节点:
仅主机模式：10.10.10.200
NAT模式： 192.168.200.130
K8S-node1节点:
仅主机模式：10.10.10.201
NAT模式： 192.168.200.131
K8S-node2节点:
仅主机模式：10.10.10.202
NAT模式： 192.168.200.132
镜像仓库节点:
仅主机模式：10.10.10.101
NAT模式： 192.168.200.150
三、版本信息
Linux内核版本：
Linux version 3.10.0-862.el7.x86_64 ([email protected])
(gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) )
#1 SMP Fri Apr 20 16:44:24 UTC 2018
K8s集群版本为1.15.0版本：
四、基于StatefulSet与PV/PVC的MySql持久化存储实验
1. 在每个节点安装nfs服务
在“镜像仓库”节点，执行以下命令：
yum install -y nfs-common nfs-utils rpcbind
在k8s集群，执行以下命令：
yum install -y nfs-utils rpcbind
2. 在“镜像仓库”节点下，配置nfs服务器
mkdir /nfs_mysql
Chmod 777 /nfs_mysql/
(在测试环境中，为了不考虑用户属性，暂时赋予777权限，但在生产环境不推荐这样做)
Chown nfsnobody /nfs_mysql/
echo “/nfs_mysql *(rw,no_root_squash,no_all_squash,sync)” >> /etc/exports
cat /etc/exports
/nfs_mysql *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind
systemctl start nfs
3. 测试nfs服务是否可用
mkdir /test
showmount -e 10.10.10.101
可见/nfs_mysql *已暴露于共享目录，接下来测试挂载是否可用：
在master节点下执行：
mount -t nfs 10.10.10.101:/nfs_mysql /test/
echo "hello-world">>/test/1.txt
在镜像仓库节点下查看1.txt是否存在，若存在则挂载成功：
可见nfs服务可以正常使用，接下来删除test目录和1.txt
在镜像仓库下：
[root@hub nfs_mysql]# rm -f 1.txt
在Master节点下:
[root@k8s-master ~]# umount /test/
[root@k8s-master ~]# rm -rf /test/
同理,依照以上步骤同时创建：（提供多个mysql副本进行挂载）
nfs_mysql1
nfs_mysql2
完成后需要重启nfs服务
systemctl restart rpcbind
systemctl restart nfs
最终效果：
4. 将nfs封装成pv
创建mysql_test文件夹，将yaml文件统一保存在此目录下
mkdir mysql_test
cd mysql_test
vim mysql-pv.yml
mysql-pv.yml配置如下：
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs_mysql
server: 10.10.10.101
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv1
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs_mysql1
server: 10.10.10.101
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv2
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs_mysql2
server: 10.10.10.101
注意：
在k8s集群15版本中recycle回收策略已被删除，只能用retain策略或者Delete策略。这里我们使用 persistentVolumeReclaimPolicy: Retain
执行命令：
kubectl create -f mysql-pv.yml
kubectl get pv
如图所示，即为Pv创建成功。
5. 部署MySQL，在mysql_test目录下编写mysql.yml，配置文件如下
apiVersion: v1
kind: Service
metadata:
name: mysql
labels:
app: mysql
spec:
ports:
- port: 3306
name: mysql
clusterIP: None
selector:
app: mysql
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
serviceName: "mysql"
replicas: 3
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.6
env:
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumeClaimTemplates:
- metadata:
name: mysql-persistent-storage
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: "nfs"
resources:
requests:
storage: 1Gi
执行以下命令，部署mysql服务：
kubectl create -f mysql.yml
如图可知，mysql按StatefulSet依次创建了mysql-0 mysql-1 mysql-2
查看各个Pod部在哪个节点：
6. 通过创建临时容器，使用MySQL客户端发送测试请求给MySQL master节点
注意：
主机名为mysql-0.mysql；跨命名空间的话，主机名请使用mysql-0.mysql. [NAMESPACE_NAME].如果没有指定命名空间，默认为default，即 mysql-0.mysql. default。
这里笔者打算关闭node2节点来模拟node2宕机，来测试是否实现数据的持久化存储，
所以我们向node2上的mysql1写入数据。
执行以下命令，访问mysql1：
kubectl run mysql-client --image=mysql:5.6 -it --rm --restart=Never -- mysql -h mysql-1.mysql.default -p password
创建数据库demo,并向messages表中写入hello-world
CREATE DATABASE demo;
CREATE TABLE demo.messages (message VARCHAR(250));
INSERT INTO demo.messages VALUES ('hello-world');
如图所示
接下来我们来关闭k8s-node2虚拟机，模拟宕机
查看nodes的运行状态，可知node2的状态已转变为NotReady
一段时间后，k8s将Pod MySql -1迁移到节点k8s-node1
由于时间过长，笔者把三个Pod都删除重启后，验证数据：
MySQL服务恢复，数据完好无损！
E. K8s持久化存储
Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。
要使用 Volume，Pod 必须事先知道如下信息：
Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息：
要么询问管理员。
要么自己就是管理员。
这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。
Kubernetes 给出的解决方案是什么 PersistentVolume （PV）和 PersistentVolumeClaim（PVC）。
PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。
PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 查找并提供满足条件的 PV。
有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。
1、配置nfs
需要安装
k8s-master：nfs-server
k8s-node1：nfs-client
k8s-node2：nfs-client
所有节点安装nfs
在master节点创建共享目录
编辑exports文件
启动rpc和nfs（注意顺序）
作为准备工作，我们已经在 k8s-master 节点上搭建了一个 NFS 服务器，目录为 /nfsdata：
2、创建PV
下面创建一个 PV mypv，配置文件 nfs-pv.yml 如下：
① capacity 指定 PV 的容量为 1G。
② accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：
ReadWriteOnce：PV 能以 read-write 模式 mount 到单个节点。
ReadOnlyMany：PV 能以 read-only 模式 mount 到多个节点。
ReadWriteMany ：PV 能以 read-write 模式 mount 到多个节点。
③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
Retain： 需要管理员手工回收。
Recycle：清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
Delete： 删除 Storage Provider 上面的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、- OpenStack Cinder Volume 等。
④ storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。
⑤ 指定 PV 在 NFS 服务器上对应的目录。
创建 mypv：
STATUS 为 Available，表示 mypv 就绪，可以被 PVC 申请。
3、创建PVC
接下来创建 PVC mypvc，配置文件 nfs-pvc.yml 如下：
部署pvc
4、创建pod
上面已经创建好了pv和pvc，pod中直接使用这个pvc即可
与使用普通 Volume 的格式类似，在 volumes 中通过 persistentVolumeClaim 指定使用 mypvc 申请的 Volume。
通过命令创建mypod：
在这里，可以尝试在任何一方删除文件，文件在两端都会消失；
当 PV 不再需要时，可通过删除 PVC 回收。未删除pvc之前 pv的状态是Bound
删除pod
删除pvc
再次查看pv的状态
删除pvc之后pv的状态变为Available，，此时解除绑定后则可以被新的 PVC 申请。
/nfsdata文件中的文件被删除了
因为 PV 的回收策略设置为 Recycle，所以数据会被清除，
但这可能不是我们想要的结果。如果我们希望保留数据，可以将策略设置为 Retain
虽然 mypv 中的数据得到了保留，但其 PV 状态会一直处于 Released，不能被其他 PVC 申请。为了重新使用存储资源，可以删除并重新创建 mypv。删除操作只是删除了 PV 对象，存储空间中的数据并不会被删除。
PV 还支持 Delete 的回收策略，会删除 PV 在 Storage Provider 上对应存储空间。NFS 的 PV 不支持 Delete，支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。
前面的例子中，我们提前创建了 PV，然后通过 PVC 申请 PV 并在 Pod 中使用，这种方式叫做静态供给（Static Provision）。
与之对应的是动态供给（Dynamical Provision），即如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。
基于NFS的PV动态供给(StorageClass)
静态：pod-->pvc-->pv
动态：pod -->pvc-->storageclass
去官网下载三个文件
这三个文件去网上下载 https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy
使用脚本批量下载：
其中deployment.yaml需要修改一下挂载的地址,目录,镜像版本
然后分别去应用这三个文件
创建pod进行测试
查看pv和pvc
在部署 statefulset 类型的工作负载时，动态创建 PV/PVC 是一种比较常用的配置方式，动态创建 PV/PVC 的方法基本如下：
一直启动不起来，查看 pvc 和 pods 信息如下：
从上边的现象来看，是 PVC 没有创建成功，动态 PVC 中，是 provisioner 中来负责创建，查看其日志，看到如下错误信息：
Google 之后，找到主要原因是，官方在 k8s 1.20 中基于对性能和统一 apiserver 调用方式的初衷，移除了对 SelfLink 的支持，而 nfs-provisioner 需要 SelfLink 该项功能。具体计划和原因可查看这个 issue[2] 和 KEP[3] 。
K3S 为兼容 K8S 应该也继承了该项修改，按 K8S 的方式修改测试了下，完美解决。
解决问题主要有下边两种方式：
1、修改 apiserver 的配置文件，重新启用 SelfLink 功能。针对 K8S，可添加如下配置：
K3S 中没有 apiserver 的配置文件，可通过 systemd 的启动文件添加该参数，如下：
若为新安装，可如下启用：
2、使用新的不基于 SelfLink 功能的 provisioner 镜像，重新创建 provisioner 容器。
若你能科学上网，可使用这个镜像：
国内可使用这个镜像【若不可用自己查找】：
F. k8s etcd 与持久化存储
1、是什么
2、etcd架构及工作原理
(1) 数据流程
一个用户的请求发送过来，会经过HTTP Server转发给store进行具体事务处理，如果涉及到节点的修改，则需要交给raft模块进行状态的变更，日志的记录，然后再同步给别的etcd节点确认数据提交，最后进行数据提交，再次同步
(2)工作原理
Etcd使用 Raft协议 来维护集群内各个节点状态的 一致性 。简单说，ETCD集群是一个分布式系统，由多个节点相互通信构成整体对外服务， 每个节点都存储了完整的数据 ，并且通过Raft协议保证每个节点维护的数据是一致的
(3) 主要组成部分
(4)etcd集群中的术语
3、k8s中的etcd
(1)etcd在k8s中的作用： etcd在kubernetes集群是用来存放数据并通知变动的
(2)为什么k8s选择etcd：
PV 目前支持的类型包括：gcePersistentDisk 、AWSElasticBlockStore 、AzureFile 、AzureDisk 、FC ( Fibre Channel ） 、Flocker、NFS 、iSCSI 、RBD (Rados Block Device ）、CephFS 、Cinder、GlusterFS 、V sphere Volume 、Quobyte Volumes 、VMware Photon 、Portwonc
Volumes 、ScaleIO Volumes 和HostPath （仅供单机测试）。
如果某个Pod 想申请某种类型的PY ，则首先需要定义一个PersistentVolurneClaim ( PVC )对象，然后，在Pod 的Volume 定义中引用上述PVC 即可：
G. 对象存储、文件存储和块存储有什么区别
区别如下：
1、速度不同
块存储：低延迟（10ms），热点突出；
文件存储：不同技术各有不同；
对象存储：100ms-1s，冷数据；
2、可分步性不同
块存储：异地不现实；
文件存储：可分布式，但有瓶颈；
对象存储：分步并发能力高；
3、文件大小不同
块存储：大小都可以，热点突出；
文件存储：适合大文件；
对象存储：适合各种大小；
4、接口不同
块存储：Driver，kernel mole ；
文件存储：POSIX；
对象存储：Restful API ；
5、典型技术不同
块存储：SAN；
文件存储：HDFS，GFS；
对象存储：Swift，Amazon S3；
6、适合场景不同
块存储：银行；
文件存储：数据中心；
对象存储：网络媒体文件存储；
(7)持久化块存储扩展阅读：
文件存储的优缺点：
优点
（1）、造价低：随便一台机器就可以，另外普通的以太网就可以，根本不需要专用的SAN网络，所以造价低。
（2）、方便文件共享。
缺点
（1）、读写速率低，传输速率慢：以太网，上传下载速度较慢，另外所有读写都要1台服务器里面的硬盘来承受，相比起磁盘阵列动不动就十几上百块硬盘同时读写，速率慢了许多。
H. ios数据的持久化存储方式有哪些
对于数据的持久化存储，ios中一般提供了4种不同的机制。
1.属性列表
2.对象归档
3.数据库存储（SQLite3）
4.苹果公司提供的持久性工具Core
Data。
其实储存的形式无非就这么几种，而我们还必须要关心的是，这些文件会被放置在那个文件下，然后如何读取。
也就是说：IOS上数据存储，我们要了解的两点，数据存储格式（也就是存储机制），数据存储位置。
1》文件如何存储（如上面4点）
2》文件存储在哪里。
对于数据的操作，其实我们关心的是操作的速率。
就好比在Adnroid中偏好存储，数据库存储，io存储一样。
I. iOS中常用的几种持久化存储
1、偏好设置(NSUserDefaults)
2、plist文件存储
3、归档
4、SQLite
5、Core Data
我们首先需要了解下沙盒（Sandbox）
Application ：存放程序源文件，上架前经过数字签名，上架后不可修改
Documents : 保存应⽤运行时生成的需要持久化的数据,iTunes同步设备时会备份该目录。例如,游戏应用可将游戏存档保存在该目录
tmp : 保存应⽤运行时所需的临时数据,使⽤完毕后再将相应的文件从该目录删除。应用 没有运行时,系统也可能会清除该目录下的文件。iTunes同步设备时不会备份该目录。
Library/Caches : 保存应用运行时⽣成的需要持久化的数据,iTunes同步设备时不会备份 该目录。⼀一般存储体积大、不需要备份的非重要数据，比如网络数据缓存存储到Caches下
Library/Preference : 保存应用的所有偏好设置，如iOS的Settings(设置) 应⽤会在该目录中查找应⽤的设置信息。iTunes同步设备时会备份该目录
NSUserDefaults是个单例类，用于存储少量数据。NSUserDefaults实际上对plist文件操作的封装，更方便我们直接操作，一般用于存储系统级别的偏好设置。比如我们经常将登录后的用户的一些设置通过NSUserDefaults存储到plist文件中。
NSUserDefaults使用起来非常简单，例如将用户的账号和密码存储起来：
J. 持久存储是什么意思
将内存中的数据以文件的形式存储到各种盘中。统称“持久化存储”。