Memcached缓存性能极高、稳定性极强，可以放心使用。

---

设置特殊的前缀或后缀

同一个应用程序中，针对Memcached缓存的使用，可能不仅仅是针对一个使用场景的；因此，不同的使用场景中的键名很容易会重复，从而造成莫名其妙又很难发现的Bug。

而解决这种问题的最佳实践方案就是在所有的键名命名时添加一个含有特殊符号、暗示使用场景的前缀字符串；或者后缀字符串也行，但是要使用前缀就全部使用前缀，要使用后缀就全部使用后缀，保持统一。

比如针对使用场景1的键名就可以明明为“scene1-$.-#name1”，“name1”是场景中的本来要用作键名的字符串，而“scene1-$.-#”则是针对场景1而设置的特殊前缀；同理，而针对场景2就可以用“scene2-$.-#”作为前缀；这样，场景1和场景2中的本来想用的键名即使发生重复，也没影响，因为加上不同的特殊前缀后就不一样了。

---

注意，前缀或后缀字符串，一定要足够特殊，尽可能地用特殊符号组合地看起来非常特殊。

---

满则溢，留余地

Memcached主要吃的是内存，启动时根据“-m ”的方式可设置最大使用内存限制，比如下述代码设置了3000MB的最大使用内存限制：

$ memcached ­-p 12007 -l localhost ­-m 3000

但是要注意的是，别把内存全用掉了，要留有余地！比如一台机器4个GB内存，那就最多使用3GB吧；因为操作系统、别的运行程序、Memcached的内存管理器（slab allocator）等，都需要使用内存。至于要留多少内存，这个视不同情况而定，经验上来说，Memcached使用内存别超过机器内存的75%吧。

需要注意的点

在Memcached使用中，还有一些需要注意的细节：

• 32位操作系统中的Memcached单进程最大使用内存为2GB，若想使用更多内存，可在多个端口开启多个Memcached进程；不过，更好的方式直接放弃使用32位操作系统，改用64位操作系统，因为64位操作系统是可以突破2GB的限制，想用多少就用多少，为所欲为。
• 默认情况下，即使不设置过期时间的，或设置1000年后过期的缓存数据，也会在30天后数据过期时间，因为这是由Memcached内置的常量REALTIME_MAXDELTA 60*60*24*30进行控制的，也可手动修改，但是没必要管，毕竟是缓存嘛，不必要太在意这个限制。
• 默认情况下，最大键长为250字节（byte），大于该长度的键无法被Memcached接受，这是Memcached内置的常量KEY_MAX_LENGTH 250控制，可手动修改，但是没必要；知道这件事即可，一般的键（key）的大小不会太大，若是超出这个限制，那就绝对是使用者自身的问题。
• 有个事情要着重注意一下，默认情况下，存入Memcached的单个数据大小不可超过1MB，它是默认的slab大小，也就是之前提到的单个page大小；1MB对于文本信息来说，已经完全足够大了；除非是特殊需求，才应考虑手动修改；具体修改的方式可在Memcached的启动参数中通过设置-I <num>或--max-item-size=<num>的方式进行修改，<num>换成具体的大小即可，默认为1m，最小可以修改成1k，最大可修改成128m。

与Redis的对比

都是基于内存的，比性能没啥大意思。关键是了解两者不同的特性，根据不同的场景需求，选择最合适的选择。

---

生产环境中，如若对缓存的依赖性和稳定性要求较高，请果断使用云计算平台提供的缓存服务；若非要求太高，还是推荐自己在主机上手动运行一个简单的Memcached进程来用即可；对于个人来说，有时拿出50MB的内存用于Memcached缓存，就足以解决大部分问题了。