memcached&redis等分布式缓存的实现原理
12月9日，河狸家资深架构师陈科老师，在【DBA+社群】中间件用户组进行了一次主题为“memcached & redis 等分布式缓存的实现原理”的线上分享。小编特别整理出其中精华内容，供大家学习交流。同时，也非常感谢陈科老师对DBA+社群给予的大力支持。
陈科
河狸家资深架构师
有十多年互联网从业经验，曾就职阿里华为58等企业架构部门
memcached&redis是现在比较常见的缓存软件。我们今天对它进行一番剖析。这两个软件麻雀虽小，五脏俱全，对他们进行分析也有助于我们学习如何阅读c程序，以及如何进行开源软件的分析工作。
针对这样的服务器软件，我对它分析一般分为几个步骤：
服务器的模型
请求的协议
内存管理机制
memcached和redis都采用了事件机制的模型，比如在linux下，都是封装了epoll的实现。memcached采用了libevent的解决方案，而redis为了考虑性能，则直接封装了epoll。
另外，memcached在后端的工作采用了线程池的模型，select线程和工作进程进行通信采用了pipe管道的模式。
而redis则是把工作流程拆分成了多个步骤，然后交由epoll异步来完成，这样让一个线程尽量利用了cpu。所以，它是单线程的模式。
关于请求协议，相对都比较简单，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的二进制协议。
在后端工作内容上，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数据库迁移中的各种坑》。
DBA+社群是全中国最大的涵盖各种数据库、中间件及架构师线条的微信社群！有100+专家发起人，建有15大城市微信群，6大专业产品群，多达10000+跨界DBA加入队伍。每天1个热议话题，每周2次线上技术分享，不定期线下聚会与原创专家团干货分享，更多精彩，欢迎关注dbaplus微信订阅号！
扫码关注
DBAplus社群
超越DBA圈子，连接的不仅仅是DBA