架构师日记——Memcached的限制和使用建议

Memcached的限制

• 在Memcached中可以保存的item数据量是没有限制的，只要内存足够
• Memcached单进程最大使用内存为2G，要使用更多内存，可以分多个端口开启多个Memcached进程
• Memcached设置Item为最大30天的过期时间,设置为永久的也会在这个时间过期，常量REALTIME_MAXDELTA为60*60*24*30控制
• Memcached缺乏认证以及安全管制，应该将Memcached服务器放置在防火墙后
• Memcached本身是为缓存而设计的服务器，因此并没有过多考虑数据的永久性问题，当内容容量达到指定值之后，就基于LRU(Least Recently Used)算法自动删除不使用的缓存
• 最大键长为250字节，大于该长度无法存储，常量KEY_MAX_LENGTH 250控制
• 单个item最大数据是1MB，超过1MB数据不予存储，使用常量POWER_BLOCK1048576进行控制，它是默认的slab大小，修改后需要重新编译
• 最大同时连接数是200，通过 conn_init()中的freetotal进行控制，最大软连接数是1024，通过settings.maxconns=1024 进行控制

Memcached不实现冗余机制，也不做任何的容错处理

在节点失效的情况下，集群没有必要做任何容错处理。如果发生了节点失效，应对的措施完全取决于用户。节点失效时，下面列出几种方案供您选择：
1：忽略它！在失效节点被恢复或替换之前，还有很多其他节点可以应对节点失效带
来的影响
2：把失效的节点从节点列表中移除。做这个操作千万要小心！在余数式哈希算法下，客户端添加或移除节点，会导致所有的缓存数据不可用！因为哈希参照的节点列表变化了，大部分key会因为哈希值的改变而被映射到不同的节点上
3：启动热备节点，接管失效节点所占用的IP。这样可以防止哈希紊乱
4：如果希望添加和移除节点，而不影响原先的哈希结果，可以使用一致性哈希算法
5：两次哈希（reshing）。当客户端存取数据时，如果发现一个节点down了，就再做一次哈希（哈希算法与前一次不同），重新选择另一个节点（需要注意的时，客户端并没有把down的节点从节点列表中移除，下次还是有可能先哈希到它）。如果某个节点时好时坏，两次哈希的方法就有风险了，好的节点和坏的节点上都可能存在脏数据

通常使用Memcached的目的

通过缓存数据库查询结果，减少数据库访问次数；还有就是缓存热点数据，以提高Web应用的速度、提高可扩展性，比如：
1：缓存简单的查询结果：查询缓存存储了给定查询语句对应的整个结果集，最合适
缓存那些经常被用到，但不会改变的SQL语句对应查询到的结果集，比如载入特
定的过滤内容
2：缓存简单的基于行的查询结果
3：缓存的不只是SQL数据，可以缓存常用的热点数据，比如页面，以节省CPU时间

使用分层的缓存

Memcached可以高速处理大量的缓存数据，但是还是要根据系统的情况考虑维护多层的缓存结构。除了Memcached缓存之外，还可以通过本地缓存（如ehcache、oscache等）建立起多级缓存。
例如，可以采用本地缓存缓存一些基本数据，例如少量但访问频繁的数据（如产品分类，连接信息，服务器状态变量，应用配置变量等），缓存这些数据，并让他们尽可能的接近处理器是有意义的 , 这样可以帮助减少生成页面的时间，并且在 memcached 失效的情况下可以增加可靠性。

• 特别注意：当数据更新时需要更新缓存
• 预热你的缓存
  如果有一个很高访问率的站点，一开始缓存是空的，然后一大群人点击站点，在填充缓存的过程中，数据库可能会承受不住压力。
  解决：可以先把常用的需要缓存的数据想办法填充到Memcached里，比如：可以写一些脚本来缓存通用的页面；也可以写一个命令行工具来填充缓存

Memcached的典型适用场景

1：分布式应用
2：数据库前段缓存
3：服务器间数据共享
4：变化频繁，查询频繁的数据，但是不一定写入数据库，比如：用户在线状态
5：变化不频繁，查询频繁，不管是否入库，都比较适合使用

不适合使用Memcached的场景

1：变化频繁, 一变化就要入库类的应用，比如股票，金融
2：那些不需要“分布”的，不需要共享的，或者干脆规模小到只有一台服务器的应用，memcached不会带来任何好处，相反还会拖慢系统效率，因为网络连接同样需要资源
3：缓存对象的大小大于1MB
4：key的长度大于250字符
5：虚拟主机不让运行memcached服务
如果应用本身托管在低端的虚拟私有服务器上，像vmware, xen这类虚拟化技术并不适合运行memcached。Memcached需要接管和控制大块的内存，如果memcached管理的内存被OS交换出去，memcached的性能将大打折扣。
6：应用运行在不安全的环境中
Memcached为提供任何安全策略，仅仅通过telnet就可以访问到memcached。如果应用运行在共享的系统上，需要着重考虑安全问题。
7：业务本身需要的是持久化数据或者说需要的应该是database

通常，不应该对Memcached中的item进行批量导入导出

因为Memcached是一个非阻塞的服务器。任何可能导致memcached暂停或瞬时拒绝服务的操作都应该值得深思熟虑。想象看，如果缓存数据在导出导入之间发生了变化，您就需要处理脏数据了；如果缓存数据在导出导入之间过期了，您又怎么处理这些数据呢？不过在一个场景倒是很有用。如果您有大量的从不变化的数据，并且希望缓存很快热（warm）起来，批量导入缓存数据是很有帮助的。

如果确实需要把memcached中的item批量导出导入，怎么办？

在某些场景下，确实需要批量导出和导入，比如处理“惊群”问题（ 节点都失效了，反复的查询让数据库不堪重负），或者存在优化不好的查询等。
一种可行的解决方案是：使用MogileFS（或者CouchDB等类似的软件）来存储item，然后把item计算出来并dump到磁盘上。MogileFS可以很方便地覆写item，并提供快速地访问。甚至可以把MogileFS中的item缓存在memcached中，这样可以加快读取速度。MogileFS+Memcached的组合可以加快缓存不命中时的响应速度，提高应用的可用性。