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. 持久存儲是什麼意思
將內存中的數據以文件的形式存儲到各種盤中。統稱「持久化存儲」。