标签：icode9 NET 性能优化 内存 磁盘混合 网络存储 数据
其实这个问题比较简单的是吧？Redis其实属于网络存储，我对照下面的这个表格，可以很容易的得出结论，既然网络存储的速度慢，那我们就可以使用内存RAM存储，把放Redis里面的数据给放内存里面就好了。
| 操作 | 速度 |
|---|---|
| 执行指令 | 1/1,000,000,000 秒 = 1 纳秒 |
| 从一级缓存读取数据 | 0.5 纳秒 |
| 分支预测失败 | 5 纳秒 |
| 从二级缓存读取数据 | 7 纳秒 |
| 使用Mutex加锁和解锁 | 25 纳秒 |
| 从主存(RAM内存)中读取数据 | 100 纳秒 |
| 在1Gbps速率的网络上发送2Kbyte的数据 | 20,000 纳秒 |
| 从内存中读取1MB的数据 | 250,000 纳秒 |
| 磁头移动到新的位置(代指机械硬盘) | 8,000,000 纳秒 |
| 从磁盘中读取1MB的数据 | 20,000,000 纳秒 |
| 发送一个数据包从美国到欧洲然后回来 | 150 毫秒 = 150,000,000 纳秒 |
提出这个方案以后，接下来就遇到了另外一个问题：
但是数据比我应用的内存大，这怎么办呢？
在上篇文章中，我们提到了使用FASTER作为内存+磁盘混合缓存的方案，但是由于FASTER的API比较难使用，另外在纯内存场景中表现不如ConcurrentDictionary，所以最后得出的结论也是仅供参考。
经过一段时间的研究，笔者实现了一个基于微软FasterKv封装的进程内混合缓存库(内存+磁盘)，它有着更加易用的API，接下来就和大家讨论讨论它。
FasterKvCache架构
这里需要简单的说一说FasterKvCache的架构，它核心使用的FasterKv，所以架构实际上和FasterKv一致，其原理比较复杂。
FasterKv的热数据会在内存中，而全量的数据会持久化在磁盘中。这中间有一些缓存淘汰算法，所以大家看到这张图就能明白FasterKvCache适用和不适用哪些场景了。
如何使用它
笔者之前给EasyCaching提交了FasterKv的实现，但是由于有一些EasyCaching的高级功能在FasterKv上目前无法高性能的实现，所以单独创建了这个库，提供高性能和最基本的API实现；如果大家已经使用了EasyCaching，那么可以直接使用EasyCaching.FasterKv这个NuGet包。
如果使用需要FasterKvCache的话，只需要安装Nuget包，Nuget包不同的功能如下所示，其中序列化包可以只安装自己需要的即可。
标签：icode9,NET,性能优化,内存,磁盘混合,网络存储,数据 来源：
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。