面临的问题
对于高并发高訪问的 Web应用程序来说。数据库存取瓶颈一直是个令人头疼的问题。
特别当你的程序架构还是建立在单数据库模式，而一个数据池连接数峰值已经达到500的时候，那你的程序执行离崩溃的边缘也不远了。非常多小站点的开发者一開始都将注意力放在了产品需求设计上。却忽视了程序总体性能，可扩展性等方面的考虑。结果眼看着訪问量一天天往上爬，可突然发现有一天站点由于訪问量过大而崩溃了，到时候哭都来不及。所以我们一定要未雨绸缪，在数据库还没罢工前，想方设法给它减负。这也是这篇文章的主要议题。
大家都知道，当有一个request过来后，webserver交给appserver。app处理并从db中存取相关数据，但db存取的花费是相当高昂的。特别是每次都取同样的数据，等于是让数据库每次都在做高耗费的无用功，数据库假设会说话。肯定会发牢骚，你都问了这么多遍了，难道还记不住吗？是啊。假设 app拿到第一次数据并存到内存里，下次读取时直接从内存里读取。而不用麻烦数据库。这样不就给数据库减负了？并且从内存取数据必定要比从数据库媒介取快非常多倍。反而提升了应用程序的性能。
因此，我们能够在web/app层与db层之间加一层cache层
主要目的：
1. 降低数据库读取负担；
2. 提高数据读取速度。
并且，cache存取的媒介是内存。而一台server的内存容量一般都是有限制的，不像硬盘容量能够做到TB级别。所以，能够考虑採用分布式的cache层，这样更易于破除内存容量的限制，同一时候又添加了灵活性。
Memcached 介绍
Memcached 是开源的分布式cache系统，如今非常多的大型web应用程序包含 facebook，youtube，wikipedia。yahoo等等都在使用memcached来支持他们每天数亿级的页面訪问。
通过把cache层与他们的web架构集成。他们的应用程序在提高了性能的同一时候。还大大降低了数据库的负载。 详细的memcached资料大家能够直接从它的官方站点[1]上得到。
这里我就简单给大家介绍一下memcached的工作原理：
Memcached处理的原子是每个（key，value）对（下面简称kv对），key会通过一个hash算法转化成hash-key，便于查找、对照以及做到尽可能的散列。同一时候，memcached用的是一个二级散列。通过一张大hash表来维护。
Memcached 有两个核心组件组成：服务端（ms）和client（mc），在一个memcached的查询中，mc先通过计算key的hash值来确定kv对所处在的ms位置。当ms确定后，client就会发送一个查询请求给相应的ms，让它来查找确切的数据。由于这之间没有交互以及多播协议，所以 memcached交互带给网络的影响是最小化的。
举例说明：考虑下面这个场景，有三个mc各自是X。Y，Z，还有三个ms各自是A，B，C：
设置kv对 X想设置key=”foo”,value=”seattle” X拿到ms列表，并对key做hash转化。依据hash值确定kv对所存的ms位置 B被选中了 X连接上B，B收到请求，把（key=”foo”,value=”seattle”）存了起来
获取kv对 Z想得到key=”foo”的value Z用同样的hash算法算出hash值，并确定key=”foo”的值存在B上 Z连接上B。并从B那边得到value=”seattle” 其它不论什么从X，Y，Z的想得到key=”foo”的值的请求都会发向B。
【推广】
免费学中医，健康全家人