传统MySQL+ Memcached架构遇到的问题

实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：

1. MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。
2. Memcached与MySQL数据库数据一致性问题。
3. Memcached数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。
4. 跨机房cache同步问题。

众多NoSQL百花齐放，如何选择

最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几种问题

1. 少量数据存储，高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。
2. 海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。
3. 这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。
4. Schema free，auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。

面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。

 

 

Redis适用场景，如何正确的使用

前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢？

Redis与Memcached的比较

1. 网络IO模型

Memcached是多线程，非阻塞IO复用的网络模型，分为监听主线程和worker子线程，监听线程监听网络连接，接受请求后，将连接描述字pipe 传递给worker线程，进行读写IO, 网络层使用libevent封装的事件库，多线程模型可以发挥多核作用，但是引入了cache coherency和锁的问题，比如，Memcached最常用的stats 命令，实际Memcached所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。

 

（Memcached网络IO模型）

Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。

1. 内存管理方面

Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存储，内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数据也可能会被剔除，原因可以参考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/

Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎片，Redis跟据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致swap也不会剔除任何非临时数据（但会尝试剔除部分临时数据），这点上Redis更适合作为存储而不是cache。

1. 数据一致性问题

Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断。

1. 存储方式及其它方面

Memcached基本只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能

Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS

进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供了持久化和复制等功能。

1. 关于不同语言的客户端支持

在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一些，目前看在客户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新的功能等，对应第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。

根据以上比较不难看出，当我们不希望数据被踢出，或者需要除key/value之外的更多数据类型时，或者需要落地功能时，使用Redis比使用Memcached更合适。

关于Redis的一些周边功能

Redis除了作为存储之外还提供了一些其它方面的功能，比如聚合计算、pubsub、scripting等，对于此类功能需要了解其实现原理，清楚地了解到它的局限性后，才能正确的使用，比如pubsub功能，这个实际是没有任何持久化支持的，消费方连接闪断或重连之间过来的消息是会全部丢失的，又比如聚合计算和scripting等功能受Redis单线程模型所限，是不可能达到很高的吞吐量的，需要谨慎使用。

总的来说Redis作者是一位非常勤奋的开发者，可以经常看到作者在尝试着各种不同的新鲜想法和思路，针对这些方面的功能就要求我们需要深入了解后再使用。

总结：

1. Redis使用最佳方式是全部数据in-memory。
2. Redis更多场景是作为Memcached的替代者来使用。
3. 当需要除key/value之外的更多数据类型支持时，使用Redis更合适。
4. 当存储的数据不能被剔除时，使用Redis更合适。

后续关于Redis文章计划：

1. Redis数据类型与容量规划。
2. 如何根据业务场景搭建稳定，可靠，可扩展的Redis集群。
3. Redis参数，代码优化及二次开发基础实践。

 

解决memcached网络io瓶颈的问题

1166466950人评论512人阅读2013-01-12 14:00:20

解决memcached网络io瓶颈的问题

 

    在大型互联网的网络应用中，很多都会使用到Memcached或者类型似的Cache服务，用来提高网络响应的速度以及减少对数据库的访问，因为数据库是直接对硬盘进行操作，相对Memcached的直接内存操作，那肯定是要慢很多的了，因而适当的使用Memcached，提高系统的响应能力及吞吐量，这个效果还是明显的，特别是高并发的情况下效果更明显。

    任何东西都有个适当原则，并不是任何东西都放到Memcached中，再从Memcached中读出来，就一定可以保证系统的性能，相反的，使用不当，Memcached反而会成为一个性能瓶颈，当然还不是Memcached本身的问题，而是根据使用场景的不同需要调整相应的策略，更加充份发挥其功效，并且不让它产生负担而成为性能瓶颈，毕竟Memcached是作为中央集群服务，和应用本身是不会在一台机子上，即使是通过内网访问，也是在存在着IO开销的，如果并发越大，这种IO开销尤为明显，毕竟Memcached也只是一个服务，任何服务对于高并发的访问，反应都会变慢的

    我所在的小组，负责中文站的应用及菜单，这些应用以及菜单的数据量本身并不大，全量应用的数据及菜单数据读入到内存也分别只有几十K，并且这些数据都不是经常变化的，因而为了提高响应速度，就将这些数据以全量的开式放到了Memcached中，后面的验权工作就直接根据这些全量数据进行验权，再把符合用户权限范围的菜单显示给用户，这种逻辑本来是没有什么问题的，日常的访问也比较正常，并发一直维持在一个可接受的范围之内，CPU的load也是在一个合理的范围之内。

    可是这种状况在昨天一下就被打破了，早上8点到10点的这段时间之内，4核服务器的LOAD曾一度是彪到10几了，并且响应非常慢，这个就让整个小组的人整个提高了注意力，经过排查，是有一个URL访问并发在这段时间之内很高，这个URL是被旺旺客户端调用的，旺旺客户端在升级完成后，新版的旺旺会调用这个URL展示给用户符合用户权限的应用，难怪一下LOAD就突然的上来了。可是后面分析，旺旺那边的升级的用户本次约20%，并且在那两个小时的请求数也才几万，LOAD这么高，肯定是程序中有什么处理不正确的问题，Memcached负责人提供给我们那两小时的cache调用情况，并发最高时的TPS达到了3000多，流量是16M/S，超过中文站最高的应用的cache使用量的好几倍，虽然响应没有堵上，但是Memcached的响应时间肯定是慢了不少，这些时候Memcached就成了我们应用的性能瓶颈了。

    经过和大家的商量，再考虑到我们应用的特殊性，数据都不是经常变化的，那就在我们的应用本身中增加一份cache，让应用在读Memcached数据之前，先检查本地内存中是否有数据，如果有数据，那再看一下当前是否是到了需要和Memcached的数据进行同步了，这个同步是通过时间控制的，如果到了同步时间，那就先让本地内存与Memcached进行一次同步，再把结果返回给应用，可以用一个简单的图区分一下原来的cache读取方式和现在的cache读取方式：

    

    这样处理起来看似麻烦一点，看效果还是很显著的，我们设置了10秒钟的同步时间，也就是原来每秒钟都要访问数十次或者更多的，到现在只需要10秒钟去访问一次，这样一处理后，由空闲时间的每秒3M/S多从Memcached获取数据，到后来只有300K/S左右，也就是说性能一下提交了10倍，达到了这样的效果，大家都非常高兴，我们现在对下周一高峰并发有了信心，可以回家去睡个安稳觉了。

 

 
本人自己的修正建议：

可以把memcached作为二级缓存，首先应用访问本地内存(本地应用的缓存设置为5分钟)，如果发现没有数据，就从memcached里取数据，然后写入本地内存，再返回都应用中；

写入数据的时候直接写入memcached,然后清空各个web服务器的该键的缓存，这样就可以保持各web服务器的数据同步。