memcached&redis等分布式缓存的实现原理

memcached&redis等分布式缓存的实现原理

DBAplus社群(陈科)
· 2015-12-13 07:00





12月9日，河狸家资深架构师陈科老师，在【DBA+社群】中间件用户组进行了一次主题为“memcached & redis 等分布式缓存的实现原理”的线上分享。小编特别整理出其中精华内容，供大家学习交流。同时，也非常感谢陈科老师对DBA+社群给予的大力支持。

嘉宾简介

陈科

河狸家资深架构师

有十多年互联网从业经验，曾就职阿里华为58等企业架构部门

演讲实录

memcached&redis是现在比较常见的缓存软件。我们今天对它进行一番剖析。这两个软件麻雀虽小，五脏俱全，对他们进行分析也有助于我们学习如何阅读c程序，以及如何进行开源软件的分析工作。

针对这样的服务器软件，我对它分析一般分为几个步骤：

服务器的模型

请求的协议

内存管理机制

1服务器的模型

memcached和redis都采用了事件机制的模型，比如在linux下，都是封装了epoll的实现。memcached采用了libevent的解决方案，而redis为了考虑性能，则直接封装了epoll。

另外，memcached在后端的工作采用了线程池的模型，select线程和工作进程进行通信采用了pipe管道的模式。

而redis则是把工作流程拆分成了多个步骤，然后交由epoll异步来完成，这样让一个线程尽量利用了cpu。所以，它是单线程的模式。

2请求的协议

关于请求协议，相对都比较简单，memcahced和redis都实现了文本协议，比如memcached的格式为：

<command name> <key> <flags> <exptime> <bytes>\r\n

redis的文本协议分为了两种：inline单行和mutibulk多行。

例如，如果想要批量set，格式为：“*3\r\n$3\r\nSET\r\n$3\r\foo\r\n$3\r\bar\r\n”。*开头代表了mutibulk类型。

另外，memcached也支持binary的二进制协议。

3内存管理机制

在后端工作内容上，memcached相对比较简单，只是一个内存存放的过程，至于内存管理的方式，我们后面再介绍。redis则相对比较复杂，它不只是一个缓存，还实现一些服务端的数据结构。比如list,map,set等。

在内存管理的方式上，memcached采用了预分配的方式，slab机制可以做到内存复用，减少碎片的产生。当然缺点就是会造成内存的浪费。



这张图说明了memcached的内存管理机制。

顺便补充一下memcached和redis的服务器模型图：





redis的内存分配相对简单，直接利用了malloc:



由于malloc和free这样的机制会造成内存碎片，所以很多人会替换成jemalloc这样的机制来替换。

还有类似tcmalloc这样的算法。这个分配器可以在编译的时候自己选择。

我之前自己测试过tcmalloc时碎片率是最低的为1.01，jemalloc为1.02，而libc的分配器碎片率为1.31。大家也可以自己去测试下看看。

很多人把在使用redis和memcached的选型时，经常会不知道使用哪一个。其实很多场景只需要考虑防止数据库被击穿。其实memcached就够用了。而且客户端hash做分库也没什么大问题。

spymemcached这样的客户端软件也封装了连接池，序列化和反序列化的工作也都已经做了，相对操心少一些。

假如需要做一些持久化，以及内存计算的工作，可以使用redis，这样就需要考虑一些HA和分库的解决方案。

其实一个redis实例，平常支撑上万的TPS是没什么大问题的，基本上世面上很多小公司根本没那么大的量。短期内，采用master/slave这样的机制。来支撑，并且做读写分离就够用了。至于官方的集群模式，短期内我个人还是不太建议采用。还不如自己做一些分区，例如结合zookeeper来做一套这样的方案。

另外，redis做一些定制，用来做一些内存计算还是不错的选择。例如geohash，类似uber/滴滴，这样的公司。他们的geohash之前都是基于mongodb来实现的。

mongodb可以做位置的索引。但是mongodb本身这块是一个针对多边形的算法实现，geohash只是其中一部分，算法相对复杂，还要考虑持久化。所以性能相对差一些。需要按照全国来根据田字格划分区域来分库。

有人基于redis开发了geohash的实现。每秒支撑7-8000的TPS没问题。而且是单个节点。所以类似的需求大家有兴趣也可以基于redis定制开发玩玩。

再次感谢河狸家资深架构师陈科老师，对DBA+社群活动给予的大力支持！

“DBA+社群”将陆续在各大城市群进行线上专题分享活动，以后每周一、周三晚上为【DBA+专业群】的固定时间，每周二、周四晚上为【DBA+各城市群】的固定时间，每周五晚上为【DAMS架构师精英群】的固定时间，欢迎大家积极加入我们。无论是内容还是形式，有好的建议我们都会积极采纳。

想入群的小伙伴们请关注DBA+社群微信公众号：dbaplus，回复“加群”即可。

小编精心为大家挑选了近日最受欢迎的几篇热文：

回复001，看丁俊的《【重磅干货】看了此文，Oracle SQL优化文章不必再看！》；

回复002，看吕海波的《去不去O，谁说了算？》；

回复003，看胡怡文《PG，一道横跨oltp到olap的梦想之桥》；

回复004，看郭耀龙《假事务之名，深入研究UNDO与REDO》；

回复005，看宋日杰《Oracle后台专家解决library cache锁争用的终极武器》；

回复006，看周俊《被埋没的SQL优化利器——Oracle SQL monitor》；

回复007，看袁伟翔《揭秘Oracle数据库truncate原理》；

回复008，看郑晓辉《存储和数据库不得不说的故事》；

回复009，看丁启良《LINUX类主机JAVA应用程序占用CPU、内存过高分析手段》；

回复010，看黎君原《扒一扒Oracle数据库迁移中的各种坑》。