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

陈科 2015-12-13 10: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的格式为:


 
 
 
\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数据库迁移中的各种坑》。

 

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告