一、需求背景

1、最近项目要求高频次地读写数据，数据量也不是很大，多表总共加起来在百万条上下。

单表最大的也在25万左右，历史数据表因为不涉及所以不用考虑，

难点在于这个规模的热点数据，变化非常频繁。

数据来源于一些检测设备的采集数据，一些大表，有可能在极短时间内（如几秒钟）可能大部分都会变化，

而且主程序也有一些后台服务需要不断轮询、读写某种类型的设备，所以要求信息交互时间尽可能短。

2、之前的解决方案是把所有热点数据，统一加载到共享内存里边，到也能够支撑的住（毫秒级的），但是由于系统架构升级，之前的程序（20年前的）不能兼容。

只能重新写一个，最先想到的是用redis，当时把所有API重写完成后，测试发现效率不行，是的，你没有看错，redis也是有使用范围的。

3、redis读写非常快，但是对于大批量读写操作我觉得支持不够，虽然redis支持批量读写，但是效率还是不够快，

对于字符串（string）类型的批量读写，我测试过；效率比较好的在每批次200 至 250条之间，处理20万条数据耗时5秒左右, (PC机，8G，4核)

而对于有序集合（sorted set）类型，批量写的操作用起来非常别扭，而且没有修改API（如有其他方式请指教），我测试过，效率没string类型那么高

其他类型不适合我的业务场景，就没考虑使用了

4、所以项目组最后决定还是用回共享内存，先决定在.net环境下使用c#的共享内存，这个功能可能使用的人不多，其实在.net4.0版本就已经集成进来了

在System.IO.MemoryMappedFile命名空间下。这个类库让人很无语，因为里边能用的只有Write、Read这2种方法，而且只是针对字节的操作，

需要非常多的类型转换，非常麻烦！想想，只能以字节为单位去构建一个需要存放百万级数据的内存数据库，得多麻烦？

需要手动搞定索引功能，因为要支持各种查询，最后花了一天的时间写完DEMO，最后测试后发现效率并没有很大提高，因为当时加了互斥量测试，

但是离毫秒级差得远。

二、没错，第一节写的太多了

1、最后分析，这应该是c#语言的瓶颈，c#对于这种骚操作是不那么成熟的。

2、最后瞄来瞄去，决定使用VC开发一个dll，在里边封装对内存数据的读写功能，然后c#调用

3、本人的C、C++不那么熟、参考了一些实例

4、是的，你没有看错，2008年的，我还看到一篇更早的，看来底层开发C、C++那么经久不衰不是没有道理的，很多技术现在都在用

5、看看什么是共享内存

三、开始写代码了

1、首先建2个控制台项目，支持MFC，

2、先这样：一个负责创建共享内存，初始化数据

3、再这样：一个读写数据测试，最后修改

4、最后修改下图片细节，测试一下，看看效果