PMem 在 2018 年的时候还仅限于学术界的探讨，而如今已经来到了工业界。Intel 在 2019 年 4 月份发布了第一款 Intel Optane DC Persistent Memory（内部产品代号 Apache Pass），可以说是一个划时代的事件。如果你完全没有听说过 PMem，那么可以先通过我之前的文章了解一下。
我们先来看一下实物的样子
2020
存储技术热点与趋势分析
是的，DIMM 接口，看起来就像内存。所以很多人会把 Optane PMem 和 Optane SSD 弄混，因为都叫 Optane。实际上 Optane SSD 是 NVMe 接口，走 PCIe 总线。由于接口和总线不同，Optane PMem 和 Optane SSD 的使用方式也完全不同的。
目前单条（因为长得像内存，所以就用“条”来做量词了）容量一共有三种选择：128G、256G、512G，价格还是相当贵的。
这里我想强调的是：PMem 并不是更慢的内存，也不是更快的 SSD，PMem 就是 PMem，他有大量属于自己的特性。为了使用好 PMem，我们还需要对 PMem 了解更多。
首先，由于 PMem 是 DIMM 接口，可以直接通过 CPU 指令访问数据。读取 PMem 的时候，和读取一个普通的内存地址没有区别，CPU Cache 会做数据缓存，所有关于内存相关的知识，例如 Cache Line 优化，Memory Order 等等在这里都是适用的。而写入就更复杂了，除了要理解内存相关的特性以外，还需要理解一个重要的概念：Power-Fail Protected Domains。这是因为，尽管 PMem 设备本身是非易失的，但是由于有 CPU Cache 和 Memory Controller 的存在，以及 PMem 设备本身也有缓存，所以当设备掉电时，Data in-flight 还是会丢失。
2020 存储技术热点与趋势分析
针对掉电保护，Intel 提出了 Asynchronous DRAM Refresh（ADR）的概念，负责在掉电时把 Data in-flight 回写到 PMem 上，保证数据持久性。目前 ADR 只能保护 iMC 里的 Write Pending Queue（WPQ）和 PMem 的缓存中的数据，但无法保护 CPU Cache 中的数据。在 Intel 下一代的产品中，将推出 Enhanced ADR（eADR），可以进一步做到对 CPU Cache 中数据的保护。
由于 ADR 概念的存在，所以简单的 MOV 指令并不能保证数据持久化，因为指令结束时，数据很可能还停留在 CPU Cache 中。为了保证数据持久化，我们必须调用 CLFLUSH 指令，保证 CPU Cache Line 里的数据写回到 PMem 中。
然而 CLFLUSH 并不是为 PMem 设计的。CLFLUSH 指令一次只能 Flush 一个 Cache Line，且只能串行执行，所以执行效率非常低。为了解决 CLFLUSH 效率低的问题，Intel 推出了一个新的指令 CLFLUSHOPT，从字面意思上看就是 CLFLUSH 的优化版本。CLFLUSHOPT 和 CLFLUSH 相比，多个 CLFLUSHOPT 指令可以并发执行。可以大大提高 Cache Line Flush 的效率。当然，CLFLUSHOPT 后面还需要跟随一个 SFENCE 指令，以保证 Flush 执行完成。
和 CLFLUSHOPT 对应的，是 CLWB 指令，CLWB 和 CLFLUSHOPT 的区别是，CLWB 指令执行完成后，数据还保持在 CPU Cache 里，如果再次访问数据，就可以保证 Cache Hit，而 CLFLUSHOPT 则相反，指令执行完成后，CPU Cache 中将不再保存数据。
此外 Non-temporal stores（NTSTORE）指令（经专家更提醒，这是一个 SSE2 里面就添加的指令，并不是一个新指令）可以做到数据写入的时候 bypass CPU Cache，这样就不需要额外的 Flush 操作了。NTSTORE 后面也要跟随一个 SFENCE 指令，以保证数据真正可以到达持久化区域。
看起来很复杂对吧，这还只是个入门呢，在 PMem 上写程序的复杂度相当之高。Intel 最近出了一本书 “Programming Persistent Memory”，专门介绍如何在 PMem 上进行编程，一共有 400 多页，有兴趣的小伙伴可以读一读。
为了简化使用 PMem 的复杂度，Intel 成立了 PMDK 项目，提供了大量的封装好的接口和数据结构，这里我就不一一介绍了。
PMem 发布以后，不少的机构都对它的实际性能做了测试，因为毕竟之前大家都是用内存来模拟 PMem 的，得到的实验结果并不准确。其中 UCSD 发表的 “Basic Performance Measurements of the Intel Optane DC Persistent Memory Module” 是比较有代表性的。这篇文章帮我们总结了 23 个 Observation，其中比较重要的几点如下：
The read latency of random Optane DC memory loads is 305 ns This latency is about 3× slower than local DRAM
Optane DC memory latency is significantly better （2×） when accessed in a sequenTIal pattern. This result indicates that Optane DC PMMs merge adjacent requests into a single 256 byte access
Our six interleaved Optane DC PMMs’ maximum read bandwidth is 39.4 GB/sec， and their maximum write bandwidth is 13.9 GB/sec. This experiment uTIlizes our six interleaved Optane DC PMMs， so accesses are spread across the devices
Optane DC reads scale with thread count; whereas writes do not. Optane DC memory bandwidth scales with thread count， achieving maximum throughput at 17 threads. However， four threads are enough to saturate Optane DC memory write bandwidth
The applicaTIon-level Optane DC bandwidth is affected by access size. To fully uTIlize the Optane DC device bandwidth， 256 byte or larger accesses are preferred
Optane DC is more affected than DRAM by access patterns. Optane DC memory is vulnerable to workloads with mixed reads and writes
Optane DC bandwidth is significantly higher （4×） when accessed in a sequential pattern. This result indicates that Optane DC PMMs contain access to merging logic to merge overlapping memory requests — merged， sequential， accesses do not pay the write amplification cost associated with the NVDIMM’s 256 byte access size
如果你正在开发针对 PMem 的程序，一定要仔细理解。
PMem 的好处当然很多，延迟低、峰值带宽高、按字节访问，这没什么好说的，毕竟是 DIMM 接口，价格也在那里摆着。
这里我想给大家提几个 PMem 的坑，这可能是很多测试报告里面不会提到的，而是我们亲身经历过的，供大家参考：
尽管峰值带宽高，但单线程吞吐率低，甚至远比不上通过 SPDK 访问 NVMe 设备。举例来说，Intel 曾发布过一个报告，利用 SPDK，在 Block Size 为 4KB 的情况下，单线程可以达到 10 Million 的 IOPS。而根据我们测试的结果，在 PMem 上，在 Block Size 为 4KB 时，单线程只能达到 1 Million 的 IOPS。这是由于目前 PMDK 统一采用同步的方式访问数据，所有内存拷贝都由 CPU 来完成，导致 CPU 成为了性能瓶颈。为了解决这个问题，我们采用了 DMA 的方式进行访问，极大的提高了单线程访问的效率。关于这块信息，我们将在未来用单独的文章进行讲解。
另一个坑就是，跨 NUMA Node 访问时，效率受到比较大的影响。在我们的测试中发现，跨 NUMA Node 的访问，单线程只提供不到 1GB/s 的带宽。所以一定要注意保证数据访问是 Local 的。
关于 PMem 的使用场景，其实有很多，例如：
作为容量更大，价格更便宜的主存，在这种情况下，PMem 实际上并不 Persitent。这里又有两种模式：
OS 不感知，由硬件负责将 DRAM 作为 Cache，PMem 作为主存
OS 感知，将 PMem 作为一个独立的 memory-only NUMA Node，目前已经被 Linux Kernel 支持，Patchset
作为真正的 PMem，提供可持久化存储能力
关于 PMem 的其他部分，我们后续还会有专门的文章介绍。
顺便剧透一下，我们即将在今年上半年发布的 SMTX ZBS 4.5 版本中，包含了针对 PMem 的大量优化工作，和上一个版本相比，整体延迟可以降低超过 80%~
Distributed Consensus and Consistency
Distributed Consensus 在过去十年已经被大家研究的比较透彻了，目前各种 Paxos，Raft 已经的实现已经被广泛应用在各种生产环境了，各种细节的优化也层出不穷。
如果你想系统性的学习一下 Distributed Consensus 的话，那么推荐你看一篇剑桥女博士 Heidi Howard 的毕业论文“Distributed consensus revised”。这篇论文可以说是把过去几十年大家在 Distributed Consensus 上的工作做了一个大而全总结。通过总结前人的工作，整理出了一个 Distributed Consensus 的模型，并且逐个调节模型中的约束条件，从而遍历了几乎所有可能的优化算法，可以说是庖丁解牛，非常适合作为 Distributed Consensus 的入门文章。
说到 Distributed Consensus，就离不开 Consistency。Distributed Consensus 是实现 Strong Consistency 的非常经典的做法，但是，并不是唯一的做法。
Distributed Consensus 只是手段，Strong Consistency 才是目的。
实现 Strong Consistency 的方法还有很多。在过去一段时间里面，我认为最经典的要数 Amazon 的 Aurora。
Amazon Aurora 目前共发表了两篇文章。第一篇是 2017 年在 SIGMOD 上发表的 “Amazon Aurora： Design Considerations for High Throughput Cloud-Native Relational Databases”，另一篇是在 2018 年的 SIGMOD 上发表了一篇论文 “Amazon Aurora： On Avoiding Distributed Consensus for I/Os， Commits， and Membership Changes”。第二篇论文主要讲述了他们如何在不使用 Distributed Consensus 的情况下，达到 Strong Consistency 的效果。
为了介绍 Aurora，我们先来简单看一下通常 Distributed Consensus 是如何做到 Strong Consistency 的。
关键词标签：海量存储 文件存储 分布式存储 国产存储 私有云 企业级存储 软件定义存储
