面临的问题
对于高并发高访问的Web应用程序来说数据库存取瓶颈一直是个令人头疼的问题特别当你的程序架构还是建立在单数据库模式而一个数据池连接数峰值已经达到的时候那你的程序运行离崩溃的边缘也不远了很多小网站的开发人员一开始都将注意力放在了产品需求设计上缺忽视了程序整体性能可扩展性等方面的考虑结果眼看着访问量一天天网上爬可突然发现有一天网站因为访问量过大而崩溃了到时候哭都来不及所以我们一定要未雨绸缪在数据库还没罢工前想方设法给它减负这也是这篇文章的主要议题
大家都知道当有一个request过来后web服务器交给app服务器app处理并从db中存取相关数据但db存取的花费是相当高昂的特别是每次都取相同的数据等于是让数据库每次都在做高耗费的无用功数据库如果会说话肯定会发牢骚你都问了这么多遍了难道还记不住吗？是啊如果app拿到第一次数据并存到内存里下次读取时直接从内存里读取而不用麻烦数据库这样不就给数据库减负了？而且从内存取数据必然要比从数据库媒介取快很多倍反而提升了应用程序的性能
因此我们可以在web/app层与db层之间加一层cache层主要目的 减少数据库读取负担 提高数据读取速度而且cache存取的媒介是内存而一台服务器的内存容量一般都是有限制的不像硬盘容量可以做到TB级别所以可以考虑采用分布式的cache层这样更易于破除内存容量的限制同时又增加了灵活性
Memcached 介绍
Memcached是开源的分布式cache系统现在很多的大型web应用程序包括facebookyoutubewikipediayahoo等等都在使用memcached来支持他们每天数亿级的页面访问通过把cache层与他们的web架构集成他们的应用程序在提高了性能的同时还大大降低了数据库的负载
具体的memcached资料大家可以直接从它的官方网站[]上得到这里我就简单给大家介绍一下memcached的工作原理
Memcached处理的原子是每一个（keyvalue）对（以下简称kv对）key会通过一个hash算法转化成hashkey便于查找对比以及做到尽可能的散列同时memcached用的是一个二级散列通过一张大hash表来维护
Memcached有两个核心组件组成服务端（ms）和客户端（mc）在一个memcached的查询中mc先通过计算key的hash值来确定kv对所处在的ms位置当ms确定后客户端就会发送一个查询请求给对应的ms让它来查找确切的数据因为这之间没有交互以及多播协议所以memcached交互带给网络的影响是最小化的
举例说明考虑以下这个场景有三个mc分别是XYZ还有三个ms分别是ABC
设置kv对
X想设置key=foovalue=seattle
X拿到ms列表并对key做hash转化根据hash值确定kv对所存的ms位置
B被选中了
X连接上BB收到请求把（key=foovalue=seattle）存了起来
获取kv对
Z想得到key=foo的value
Z用相同的hash算法算出hash值并确定key=foo的值存在B上
Z连接上B并从B那边得到value=seattle
其他任何从XYZ的想得到key=foo的值的请求都会发向B
Memcached服务器(ms)
内存分配
默认情况下ms是用一个内置的叫块分配器的组件来分配内存的捨弃c++标准的malloc/free的内存分配而采用块分配器的主要目的是为了避免内存碎片否则操作系统要花费更多时间来查找这些逻辑上连续的内存块（实际上是断开的）用了块分配器ms会轮流的对内存进行大块的分配并不断重用当然由于块的大小各不相同当数据大小和块大小不太相符的情况下还是有可能导致内存的浪费
同时ms对key和data都有相应的限制key的长度不能超过字节data也不能超过块大小的限制 MB
因为mc所使用的hash算法并不会考虑到每个ms的内存大小理论上mc会分配概率上等量的kv对给每个ms这样如果每个ms的内存都不太一样那可能会导致内存使用率的降低所以一种替代的解决方案是根据每个ms的内存大小找出他们的最大公约数然后在每个ms上开n个容量=最大公约数的instance这样就等于拥有了多个容量大小一样的子ms从而提供整体的内存使用率
缓存策略
当ms的hash表满了之后新的插入数据会替代老的数据更新的策略是LRU（最近最少使用）以及每个kv对的有效时限Kv对存储有效时限是在mc端由app设置并作为参数传给ms的
同时ms采用是偷懒替代法ms不会开额外的进程来实时监测过时的kv对并删除而是当且仅当新来一个插入的数据而此时又没有多余的空间放了才会进行清除动作
缓存数据库查询
现在memcached最流行的一种使用方式是缓存数据库查询下面举一个简单例子说明
App需要得到userid=xxx的用户信息对应的查询语句类似
SELECT * FROM users WHERE userid = xxx
App先去问cache有没有user:userid（key定义可预先定义约束好）的数据如果有返回数据如果没有App会从数据库中读取数据并调用cache的add函数把数据加入cache中
当取的数据需要更新app会调用cache的update函数来保持数据库与cache的数据同步
从上面的例子我们也可以发现一旦数据库的数据发现变化我们一定要及时更新cache中的数据来保证app读到的是同步的正确数据当然我们可以通过定时器方式记录下cache中数据的失效时间时间一过就会激发事件对cache进行更新但这之间总会有时间上的延迟导致app可能从cache读到髒数据这也被称为狗洞问题（以后我会专门描述研究这个问题）
数据冗余与故障预防
从设计角度上memcached是没有数据冗余环节的它本身就是一个大规模的高性能cache层加入数据冗余所能带来的只有设计的复杂性和提高系统的开支
当一个ms上丢失了数据之后app还是可以从数据库中取得数据不过更谨慎的做法是在某些ms不能正常工作时提供额外的ms来支持cache这样就不会因为app从cache中取不到数据而一下子给数据库带来过大的负载
同时为了减少某台ms故障所带来的影响可以使用热备份方案就是用一台新的ms来取代有问题的ms当然新的ms还是要用原来ms的IP地址大不了数据重新装载一遍
另外一种方式就是提高你ms的节点数然后mc会实时侦查每个节点的状态如果发现某个节点长时间没有响应就会从mc的可用server列表里删除并对server节点进行重新hash定位当然这样也会造成的问题是原本key存储在B上变成存储在C上了所以此方案本身也有其弱点最好能和热备份方案结合使用就可以使故障造成的影响最小化
Memcached客户端（mc）
Memcached客户端有各种语言的版本供大家使用包括javac等等具体可参见memcached api page[]
大家可以根据自己项目的需要选择合适的客户端来集成
缓存式的Web应用程序架构
有了缓存的支持我们可以在传统的app层和db层之间加入cache层每个app服务器都可以绑定一个mc每次数据的读取都可以从ms中取得如果没有再从db层读取而当数据要进行更新时除了要发送update的sql给db层同时也要将更新的数据发给mc让mc去更新ms中的数据
假设今后我们的数据库可以和ms进行通讯了那可以将更新的任务统一交给db层每次数据库更新数据的同时会自动去更新ms中的数据这样就可以进一步减少app层的逻辑复杂度如下图
不过每次我们如果没有从cache读到数据都不得不麻烦数据库为了最小化数据库的负载压力我们可以部署数据库复写用slave数据库来完成读取操作而master数据库永远只负责三件事更新数据同步slave数据库更新cache如下图
以上这些缓存式web架构在实际应用中被证明是能有效并能极大地降低数据库的负载同时又能提高web的运行性能当然这些架构还可以根据具体的应用环境进行变种以达到不同硬件条件下性能的最优化
未来的憧憬
Memcached的出现可以说是革命性的第一次让我们意识到可以用内存作为存储媒介来大规模的缓存数据以提高程序的性能不过它毕竟还是比较新的东西还需要很多有待优化和改进的地方例如
如何利用memcached实现cache数据库让数据库跑在内存上这方面tangent software 开发的memcached_engine[]已经做了不少工作不过现在的版本还只是处于实验室阶段
如何能方便有效的进行批量key清理因为现在key是散列在不同的server上的所以对某类key进行大批量清理是很麻烦的因为memcached本身是一个大hash表是不具备key的检索功能的所以memcached是压根不知道某一类的key到底存了多少个都存在哪些server上而这类功能在实际应用中却是经常用到
