一..memcache应用场景
1.应用场景一： 缓解数据库压力，提高交互速度。它的一个总原则是将经常需要从数据库读取的数据缓存在memcached中。这些数据也分为几类：
（1）、经常被读取并且实时性要求不强可以等到自动过期的数据。例如网站首页最新文章列表、某某排行等数据。也就是虽然新数据产生了，但对用户体验不会产生任何影响的场景。
这类数据就使用典型的缓存策略，设置一过合理的过期时间，当数据过期以后再从数据库中读取。当然你得制定一个缓存清除策略，便于编辑或者其它人员能马上看到效果。
（2）、经常被读取并且实时性要求强的数据。比如用户的好友列表，用户文章列表，用户阅读记录等。
这类数据首先被载入到memcached中，当发生更改（添加、修改、删除）时就清除缓存。在缓存的时候，我将查询的SQL语句md5（）得到它的
hash值作为key,结果数组作为值写入memcached，并且将该SQL涉及的table_name以及hash值配对存入memcached中。
当更改了这个表时，我就将与此表相配对的key的缓存全部删除。
（3）、统计类缓存，比如文章浏览数、网站PV等
此类缓存是将在数据库的中来累加的数据放在memcached来累加。获取也通过memcached来获取。但这样就产生了一个问题，如果
memcached服务器down 掉的话这些数据就有可能丢失，所以一般使用memcached的永固性存储，这方面新浪使用memcachedb。
（4）、活跃用户的基本信息或者某篇热门文章。
此类数据的一个特点就是数据都是一行，也就是一个一维数组，当数据被update时（比如修改昵称、文章的评论数），在更改数据库数据的同时，使用Memcache::replace替换掉缓存里的数据。这样就有效了避免了再次查询数据库。
（5）、session数据
使用memcached来存储session的效率是最高的。memcached本身也是非常稳定的，不太用担心它会突然down掉引起session数据的丢失，即使丢失就重新登录了，也没啥。
（6）、冷热数据交互
在做高访问量的sns应用，比如贴吧和论坛，由于其数据量大，往往采用了分表分库的策略，但真正的热数据仅仅是前两三页的100条数据，这时，我们就可以把这100条数据，在写进数据库之后，同时作为memcache的缓存热数据来使用。
通过以上的策略数据库的压力将会被大大减轻。检验你使用memcached是否得当的方法是查看memcached的命中率。有些策略好的网站的命中率可以到达到90%以上。后续本专题也会讨论一下memcache的分布式算法,提高其命中率;
2.应用场景二： 秒杀功能。
其实，本场景严格的说应该也属于场景一，单独拎出来说是由于其广泛的应用性。
一个人下单，要牵涉数据库读取，写入订单，更改库存，及事务要求， 对于传统型数据库来说，压力是巨大的。
可以利用 memcached 的 incr/decr 功能， 在内存存储 count 库存量， 秒杀 1000 台每人抢单主要在内存操作，速度非常快，抢到 count < =1000 的号人，得一个订单号，这时再去另一个页面慢慢支付。
3.应用场景三：中继 MySQL 主从延迟数据
摘自"http://www.cnblogs.com/nixi8/p/4934009.html"；
二。memcache 存储原理
i.Memcache采用键值对存储方式。它本质是一个大的 hash表，key的最大长度为255个字符，最长过期时间为30天。
ii. 它的内存模型如下：Memcache预先将可支配的内存空间进行分区（Slab），每个分区里再分为多个块（Chunk）最大1M，但同一个分区中块的大 小是固定的。然后，插入数据时，会根据数据大小寻找最合适的块，然后插入，当然这样也就会有部分内存浪费，但可一定程度上减少内存碎片，总体上，利大于 弊。当Memcache的内存满后，它清除旧数据的原则为：LRU闲置>过期>最少访问。而且它采用的是惰性删除，它并没有提供监控数据过期 的机制，而是惰性的，当查询到某个key的数据时，如果过期，那么直接抛弃
三.常见BUG及解决办法
1.缓存雪崩
一般是由于某个节点失效，导致其它节点的缓存命中率下降，缓存中缺失的数据直接去数据库查询，短时间内造成数据库服务器崩溃。
或者是由于缓存周期性失效，比如设置每隔6个小时失效一次，那么每6个小时将会有一个请求峰值，严重的话，也会导致数据库崩溃。
重启DB后，短期内又被压垮，但缓存又会恢复一点，DB反复重启多次，直至缓存重建完毕，才能恢复稳定。
2.永久数据被踢
（1）.数据在内存中失效后，并不会立马被删除，只有在下次get时候，系统才会将其删除。 Memcache可以因此，被一些未被及时删除的数据占满空间。加之LRU淘汰机制，永久数据如果很少被访问的话，在内存空间被占满的情况下，再有新数据被缓存，则永久数据，就有可能被删除。
（2）.解决方案：
永久数据和非永久数据分开放。
3.Cache失效后的拥堵问题
（1）.通常我们会为两种数据做Cache，一种是热数据，也就是说短时间内有很多人访问的数据；另一种是高成本的数据，也就说查询很很耗时的数据。当这些数据过 期的瞬间，如果大量请求同时到达，那么它们会一起请求后端重建Cache，造成拥堵问题，就好象在北京上班做地铁似的，英文称之为：stampeding herd，老外这里的用词还是很形象的。
（2）.一般有如下几种解决思路可供选择：
首先，我们可以主动更新Cache。前端程序里不涉及重建Cache的职责，所有相关逻辑都由后端独立的程序（比如CRON脚本）来完成，但此方法并不适应所有的需求。还有一些特殊情况没有考虑到：设想一下服务重启；或者某个Cache里原本没有的冷数据因为某些情况突然转换成热数据；又或者由于LRU机制导致某些键被
意外删除，等等，这些情况都可能会让上面的方法失效，因为在这些情况里就不存在所谓的旧数据，等待用户的将是一个空页面。
好在我们还有Gearman这根救命稻草。当需要更新Cache的时候，我们不再直接查询数据库，而是把任务抛给Gearman来处理，当并发量比较大的时候，Gearman内部的优化可以保证相同的请求只查询一次后端数据库
4.Multiget的无底洞问题
（1）只 要保证Multiget中的键只出现在一台服务器上即可！比如说用户名字（user:foo:name），用户年龄（user:foo:age）等数据在 散列到多台服务器上时，不应按照完整的键名（user:foo:name和user:foo:age）来散列的，而应按照特殊的键（foo）来散列的
5.缓存无底洞
（1）.一个较为简单的解决方案：
NoSQL和传统的RDBMS，并不是水火不容，两者在某些设计上，是可以相互参考的。对于memcached,Redis,这种kv存储，key的设计，可以参考MySQL中表与列的设计。
比如：user表下有age列,name列,身高列，对应的key，可以用user:133:age=23,user:133:name=’lisi’,user:133:height=168;
可以将某一组key，按其共同前缀来分布，比如按照’user-133’来计算，而不是以user-133-age，user-133-name，user-133-height来计算，这样3个关于个人信息的key，都落在同一个节点，访问个人主页时，只需连接一个节点
.