一、分布式缓存简图

二、为什么使用 Memcached 分布式缓存呢？

三、Memcached 基础原理

四、Memcache 下载与安装

五、MencacheHelper.cs 示例使用 结合 Session 与项目配置缓存

六、Redis 和 Memcache 的区别总结

一、分布式缓存简图

二、为什么使用 Memcached 分布式缓存呢？

首先先讲讲为何要缓存，在数据驱动的 web 开发中，经常要重复从数据库中取出相同的数据，这种重复极大的增加了数据库负载。缓存是解决这个问题的好办法。但是 ASP.NET 中的虽然已经可以实现对页面局部进行缓存，但还是不够灵活。 Memcached 应运而生。

1 、高并发访问数据库的痛楚：死锁！

2 、磁盘 IO 之痛，数据库读写说白了就是跟磁盘打交道，磁盘读取速度是有限制的，一般高点也就 7200 转

3 、多客户端共享缓存

4 、 Net+Memory  >> IO

5 、读写性能完美  1s  读取可以达到 1w 次 写： 10w 次

6 、超简单集群搭建  Clister

7 、开源  Open Source

8 、没有提供主从赋值功能，也没提供容灾等功能（容灾：即数据备份能使意外发生后恢复数据， Memcached 不会进行备份，由于是缓存在内存中的，一断电就会失去数据

），所以所有的代码基本都只考虑性能最佳。如要考虑容灾，则可使用 Redis 分布式缓存

9 、学习成本非常低，入门非常容易

10 、丰富的成功的案例。很多大型公司都是用这个来做分布式缓存

注： Memcached 在企业中一般都是在 linux 下跑，才能达到性能最佳。

三、Memcached 基础原理

底层通信是使用 Socket

可以将缓存服务器理解为 Socket 服务端，将 WEB 服务器理解为客户端。

四、Memcache 下载与安装

下载，百度一下或者直接在 csdn 上搜一下 windows Memcache 稳定版就行， 0 积分。

1 、下载完后，就这么个 exe

2 、安装，敲几行 cmd 命令就行，截图如下，左边是我们计算机服务列表，可以看到，已经启动了我们的 Memcached （ Memcache 是这个开源项目的名称，加个 d ， Memcached 是具体这个应用程序，也就是这个 exe 的名称）

3、现在已经启动服务了，且将其安装到 windows 服务上了，这样一来，就不用每次手动去启动了，随电脑而启动。

现在来测试下，随便新建个控制台应用程序

这样就将我们的从数据库中取出的系统邮件地址存储到了Memcache中，很方便吧。取的话就是：

这里由于存取的数据均为字符串，不存在序列化的问题，如果存取的对象类型不是字符串，如某个表Model，那么就得通过序列化来进行操作，对于序列化，本人是使用Json.Net来操作。

再来个辅助类吧。

8.0.0.0是当前这个dll的版本，估计是版本更新通知吧。具体为何这样做是有点迷糊的。谁能指点下呢，感激~~~

六、 Redis 和 Memcache 的区别总结（摘自百度知道）

1. Redis 是什么

这个问题的结果影响了我们怎么用 Redis 。如果你认为 Redis 是一个 key value store,  那可能会用它来代替 MySQL ；如果认为它是一个可以持久化的 cache,  可能只是它保存一些频繁访问的临时数据。 Redis 是 REmote DIctionary Server 的缩写，在 Redis 在官方网站的的副标题是 A persistent key-value database with built-in net interface written in ANSI-C for Posix systems ，这个定义偏向 key value store 。还有一些看法则认为 Redis 是一个 memory database ，因为它的高性能都是基于内存操作的基础。另外一些人则认为 Redis 是一个 data structure server ，因为 Redis 支持复杂的数据特性，比如 List, Set 等。对 Redis 的作用的不同解读决定了你对 Redis 的使用方式。

互联网数据目前基本使用两种方式来存储，关系数据库或者 key value 。但是这些互联网业务本身并不属于这两种数据类型，比如用户在社会化平台中的关系，它是一个 list ，如果要用关系数据库存储就需要转换成一种多行记录的形式，这种形式存在很多冗余数据，每一行需要存储一些重复信息。如果用 key value 存储则修改和删除比较麻烦，需要将全部数据读出再写入。 Redis 在内存中设计了各种数据类型，让业务能够高速原子的访问这些数据结构，并且不需要关心持久存储的问题，从架构上解决了前面两种存储需要走一些弯路的问题。

2. Redis 不可能比 Memcache 快

很多开发者都认为 Redis 不可能比 Memcached 快， Memcached 完全基于内存，而 Redis 具有持久化保存特性，即使是异步的， Redis 也不可能比 Memcached 快。但是测试结果基本是 Redis 占绝对优势。一直在思考这个原因，目前想到的原因有这几方面。

Libevent 。和 Memcached 不同， Redis 并没有选择 libevent 。 Libevent 为了迎合通用性造成代码庞大 ( 目前 Redis 代码还不到 libevent 的 1/3) 及牺牲了在特定平台的不少性能。 Redis 用 libevent 中两个文件修改实现了自己的 epoll event loop(4) 。业界不少开发者也建议 Redis 使用另外一个 libevent 高性能替代 libev ，但是作者还是坚持 Redis 应该小巧并去依赖的思路。一个印象深刻的细节是编译 Redis 之前并不需要执行 ./configure 。

CAS 问题。 CAS 是 Memcached 中比较方便的一种防止竞争修改资源的方法。 CAS 实现需要为每个 cache key 设置一个隐藏的 cas token ， cas 相当 value 版本号，每次 set 会 token 需要递增，因此带来 CPU 和内存的双重开销，虽然这些开销很小，但是到单机 10G+ cache 以及 QPS 上万之后这些开销就会给双方相对带来一些细微性能差别 (5) 。

3. 单台 Redis 的存放数据必须比物理内存小

Redis 的数据全部放在内存带来了高速的性能，但是也带来一些不合理之处。比如一个中型网站有 100 万注册用户，如果这些资料要用 Redis 来存储，内存的容量必须能够容纳这 100 万用户。但是业务实际情况是 100 万用户只有 5 万活跃用户， 1 周来访问过 1 次的也只有 15 万用户，因此全部 100 万用户的数据都放在内存有不合理之处， RAM 需要为冷数据买单。

这跟操作系统非常相似，操作系统所有应用访问的数据都在内存，但是如果物理内存容纳不下新的数据，操作系统会智能将部分长期没有访问的数据交换到磁盘，为新的应用留出空间。现代操作系统给应用提供的并不是物理内存，而是虚拟内存 (Virtual Memory) 的概念。

基于相同的考虑， Redis 2.0 也增加了 VM 特性。让 Redis 数据容量突破了物理内存的限制。并实现了数据冷热分离。

4. Redis 的 VM 实现是重复造轮子

Redis 的 VM 依照之前的 epoll 实现思路依旧是自己实现。但是在前面操作系统的介绍提到 OS 也可以自动帮程序实现冷热数据分离， Redis 只需要 OS 申请一块大内存， OS 会自动将热数据放入物理内存，冷数据交换到硬盘，另外一个知名的“理解了现代操作系统 (3) ”的 Varnish 就是这样实现，也取得了非常成功的效果。

作者 antirez 在解释为什么要自己实现 VM 中提到几个原因 (6) 。主要 OS 的 VM 换入换出是基于 Page 概念，比如 OS VM1 个 Page 是 4K, 4K 中只要还有一个元素即使只有 1 个字节被访问，这个页也不会被 SWAP,  换入也同样道理，读到一个字节可能会换入 4K 无用的内存。而 Redis 自己实现则可以达到控制换入的粒度。另外访问操作系统 SWAP 内存区域时 block 进程，也是导致 Redis 要自己实现 VM 原因之一。

5. 用 get/set 方式使用 Redis

作为一个 key value 存在，很多开发者自然的使用 set/get 方式来使用 Redis ，实际上这并不是最优化的使用方法。尤其在未启用 VM 情况下， Redis 全部数据需要放入内存，节约内存尤其重要。

假如一个 key-value 单元需要最小占用 512 字节，即使只存一个字节也占了 512 字节。这时候就有一个设计模式，可以把 key 复用，几个 key-value 放入一个 key 中， value 再作为一个 set 存入，这样同样 512 字节就会存放 10-100 倍的容量。

这就是为了节约内存，建议使用 hashset 而不是 set/get 的方式来使用 Redis ，详细方法见参考文献 (7) 。

6. 使用 aof 代替 snapshot

Redis 有两种存储方式，默认是 snapshot 方式，实现方法是定时将内存的快照 (snapshot) 持久化到硬盘，这种方法缺点是持久化之后如果出现 crash 则会丢失一段数据。因此在完美主义者的推动下作者增加了 aof 方式。 aof 即 append only mode ，在写入内存数据的同时将操作命令保存到日志文件，在一个并发更改上万的系统中，命令日志是一个非常庞大的数据，管理维护成本非常高，恢复重建时间会非常长，这样导致失去 aof 高可用性本意。另外更重要的是 Redis 是一个内存数据结构模型，所有的优势都是建立在对内存复杂数据结构高效的原子操作上，这样就看出 aof 是一个非常不协调的部分。

其实 aof 目的主要是数据可靠性及高可用性，在 Redis 中有另外一种方法来达到目的： Replication 。由于 Redis 的高性能，复制基本没有延迟。这样达到了防止单点故障及实现了高可用。

小结

要想成功使用一种产品，我们需要深入了解它的特性。 Redis 性能突出，如果能够熟练的驾驭，对国内很多大型应用具有很大帮助。

</div>

一、分布式缓存简图

二、为什么使用 Memcached 分布式缓存呢？

三、Memcached 基础原理

四、Memcache 下载与安装

五、MencacheHelper.cs 示例使用 结合 Session 与项目配置缓存

六、Redis 和 Memcache 的区别总结

一、分布式缓存简图

二、为什么使用 Memcached 分布式缓存呢？

首先先讲讲为何要缓存，在数据驱动的 web 开发中，经常要重复从数据库中取出相同的数据，这种重复极大的增加了数据库负载。缓存是解决这个问题的好办法。但是 ASP.NET 中的虽然已经可以实现对页面局部进行缓存，但还是不够灵活。 Memcached 应运而生。

1 、高并发访问数据库的痛楚：死锁！

2 、磁盘 IO 之痛，数据库读写说白了就是跟磁盘打交道，磁盘读取速度是有限制的，一般高点也就 7200 转

3 、多客户端共享缓存

4 、 Net+Memory  >> IO

5 、读写性能完美  1s  读取可以达到 1w 次 写： 10w 次

6 、超简单集群搭建  Clister

7 、开源  Open Source

8 、没有提供主从赋值功能，也没提供容灾等功能（容灾：即数据备份能使意外发生后恢复数据， Memcached 不会进行备份，由于是缓存在内存中的，一断电就会失去数据

），所以所有的代码基本都只考虑性能最佳。如要考虑容灾，则可使用 Redis 分布式缓存

9 、学习成本非常低，入门非常容易

10 、丰富的成功的案例。很多大型公司都是用这个来做分布式缓存

注： Memcached 在企业中一般都是在 linux 下跑，才能达到性能最佳。

三、Memcached 基础原理

底层通信是使用 Socket

可以将缓存服务器理解为 Socket 服务端，将 WEB 服务器理解为客户端。

四、Memcache 下载与安装

下载，百度一下或者直接在 csdn 上搜一下 windows Memcache 稳定版就行， 0 积分。

1 、下载完后，就这么个 exe

2 、安装，敲几行 cmd 命令就行，截图如下，左边是我们计算机服务列表，可以看到，已经启动了我们的 Memcached （ Memcache 是这个开源项目的名称，加个 d ， Memcached 是具体这个应用程序，也就是这个 exe 的名称）

3、现在已经启动服务了，且将其安装到 windows 服务上了，这样一来，就不用每次手动去启动了，随电脑而启动。

现在来测试下，随便新建个控制台应用程序

这样就将我们的从数据库中取出的系统邮件地址存储到了Memcache中，很方便吧。取的话就是：

这里由于存取的数据均为字符串，不存在序列化的问题，如果存取的对象类型不是字符串，如某个表Model，那么就得通过序列化来进行操作，对于序列化，本人是使用Json.Net来操作。

再来个辅助类吧。

8.0.0.0是当前这个dll的版本，估计是版本更新通知吧。具体为何这样做是有点迷糊的。谁能指点下呢，感激~~~

六、 Redis 和 Memcache 的区别总结（摘自百度知道）

1. Redis 是什么

这个问题的结果影响了我们怎么用 Redis 。如果你认为 Redis 是一个 key value store,  那可能会用它来代替 MySQL ；如果认为它是一个可以持久化的 cache,  可能只是它保存一些频繁访问的临时数据。 Redis 是 REmote DIctionary Server 的缩写，在 Redis 在官方网站的的副标题是 A persistent key-value database with built-in net interface written in ANSI-C for Posix systems ，这个定义偏向 key value store 。还有一些看法则认为 Redis 是一个 memory database ，因为它的高性能都是基于内存操作的基础。另外一些人则认为 Redis 是一个 data structure server ，因为 Redis 支持复杂的数据特性，比如 List, Set 等。对 Redis 的作用的不同解读决定了你对 Redis 的使用方式。

互联网数据目前基本使用两种方式来存储，关系数据库或者 key value 。但是这些互联网业务本身并不属于这两种数据类型，比如用户在社会化平台中的关系，它是一个 list ，如果要用关系数据库存储就需要转换成一种多行记录的形式，这种形式存在很多冗余数据，每一行需要存储一些重复信息。如果用 key value 存储则修改和删除比较麻烦，需要将全部数据读出再写入。 Redis 在内存中设计了各种数据类型，让业务能够高速原子的访问这些数据结构，并且不需要关心持久存储的问题，从架构上解决了前面两种存储需要走一些弯路的问题。

2. Redis 不可能比 Memcache 快

很多开发者都认为 Redis 不可能比 Memcached 快， Memcached 完全基于内存，而 Redis 具有持久化保存特性，即使是异步的， Redis 也不可能比 Memcached 快。但是测试结果基本是 Redis 占绝对优势。一直在思考这个原因，目前想到的原因有这几方面。

Libevent 。和 Memcached 不同， Redis 并没有选择 libevent 。 Libevent 为了迎合通用性造成代码庞大 ( 目前 Redis 代码还不到 libevent 的 1/3) 及牺牲了在特定平台的不少性能。 Redis 用 libevent 中两个文件修改实现了自己的 epoll event loop(4) 。业界不少开发者也建议 Redis 使用另外一个 libevent 高性能替代 libev ，但是作者还是坚持 Redis 应该小巧并去依赖的思路。一个印象深刻的细节是编译 Redis 之前并不需要执行 ./configure 。

CAS 问题。 CAS 是 Memcached 中比较方便的一种防止竞争修改资源的方法。 CAS 实现需要为每个 cache key 设置一个隐藏的 cas token ， cas 相当 value 版本号，每次 set 会 token 需要递增，因此带来 CPU 和内存的双重开销，虽然这些开销很小，但是到单机 10G+ cache 以及 QPS 上万之后这些开销就会给双方相对带来一些细微性能差别 (5) 。

3. 单台 Redis 的存放数据必须比物理内存小

Redis 的数据全部放在内存带来了高速的性能，但是也带来一些不合理之处。比如一个中型网站有 100 万注册用户，如果这些资料要用 Redis 来存储，内存的容量必须能够容纳这 100 万用户。但是业务实际情况是 100 万用户只有 5 万活跃用户， 1 周来访问过 1 次的也只有 15 万用户，因此全部 100 万用户的数据都放在内存有不合理之处， RAM 需要为冷数据买单。

这跟操作系统非常相似，操作系统所有应用访问的数据都在内存，但是如果物理内存容纳不下新的数据，操作系统会智能将部分长期没有访问的数据交换到磁盘，为新的应用留出空间。现代操作系统给应用提供的并不是物理内存，而是虚拟内存 (Virtual Memory) 的概念。

基于相同的考虑， Redis 2.0 也增加了 VM 特性。让 Redis 数据容量突破了物理内存的限制。并实现了数据冷热分离。

4. Redis 的 VM 实现是重复造轮子

Redis 的 VM 依照之前的 epoll 实现思路依旧是自己实现。但是在前面操作系统的介绍提到 OS 也可以自动帮程序实现冷热数据分离， Redis 只需要 OS 申请一块大内存， OS 会自动将热数据放入物理内存，冷数据交换到硬盘，另外一个知名的“理解了现代操作系统 (3) ”的 Varnish 就是这样实现，也取得了非常成功的效果。

作者 antirez 在解释为什么要自己实现 VM 中提到几个原因 (6) 。主要 OS 的 VM 换入换出是基于 Page 概念，比如 OS VM1 个 Page 是 4K, 4K 中只要还有一个元素即使只有 1 个字节被访问，这个页也不会被 SWAP,  换入也同样道理，读到一个字节可能会换入 4K 无用的内存。而 Redis 自己实现则可以达到控制换入的粒度。另外访问操作系统 SWAP 内存区域时 block 进程，也是导致 Redis 要自己实现 VM 原因之一。

5. 用 get/set 方式使用 Redis

作为一个 key value 存在，很多开发者自然的使用 set/get 方式来使用 Redis ，实际上这并不是最优化的使用方法。尤其在未启用 VM 情况下， Redis 全部数据需要放入内存，节约内存尤其重要。

假如一个 key-value 单元需要最小占用 512 字节，即使只存一个字节也占了 512 字节。这时候就有一个设计模式，可以把 key 复用，几个 key-value 放入一个 key 中， value 再作为一个 set 存入，这样同样 512 字节就会存放 10-100 倍的容量。

这就是为了节约内存，建议使用 hashset 而不是 set/get 的方式来使用 Redis ，详细方法见参考文献 (7) 。

6. 使用 aof 代替 snapshot

Redis 有两种存储方式，默认是 snapshot 方式，实现方法是定时将内存的快照 (snapshot) 持久化到硬盘，这种方法缺点是持久化之后如果出现 crash 则会丢失一段数据。因此在完美主义者的推动下作者增加了 aof 方式。 aof 即 append only mode ，在写入内存数据的同时将操作命令保存到日志文件，在一个并发更改上万的系统中，命令日志是一个非常庞大的数据，管理维护成本非常高，恢复重建时间会非常长，这样导致失去 aof 高可用性本意。另外更重要的是 Redis 是一个内存数据结构模型，所有的优势都是建立在对内存复杂数据结构高效的原子操作上，这样就看出 aof 是一个非常不协调的部分。

其实 aof 目的主要是数据可靠性及高可用性，在 Redis 中有另外一种方法来达到目的： Replication 。由于 Redis 的高性能，复制基本没有延迟。这样达到了防止单点故障及实现了高可用。

小结

要想成功使用一种产品，我们需要深入了解它的特性。 Redis 性能突出，如果能够熟练的驾驭，对国内很多大型应用具有很大帮助。

</div>