引言
接下来将会写一个分析twemproxy的系列。该系列会对twemproxy最新版v0.4的源码进行分析,对设计原理进行剖析,力求用通俗的语言和图来表达设计思想,并结合实际的使用达到深入浅出的效果。
概述
twemproxy是一个redis和memcached的轻量级分布式代理,本文介绍twemproxy0.4的基本功能、特征和总体架构。
twemproxy的总体架构
twemproxy的总体使用架构如下图所示:
从图中可以看出twemproxy可以支持redis和memcached这两个目前比较高效的缓存系统的集群。
而且twemproxy可以支持多个不同的redis和memcached集群。
因为后台的不管是redis还是memcached都是集群,所以必然要支持分片。twemproxy当然支持key/value数据的自动分片。twemproxy还支持为集群中的各个节点配置权重。
后台的redis或memcached集群可以通过以下几种算法进行key/value的分配:
- ketama: 一个实现一致性hash算法的开源库
- modula: 通过取模的hash算法来选择一个节点
- random:随机选择一个节点
支持一致性Hash算法的架构
从图中可以看出:twemproxy支持多个redis或memcached服务器集群,每个集群可以配置根据不同的hash算法进行key的分配。
twemproxy的其他特点的说明
- 快速&轻量级
twemproxy采用了高效异步的事件驱动框架,可以有三种方式:evport,epoll,kqueue。
- 和后台的服务器池保存长连接
twemproxy和后台的每个redis或memcached服务器保持一个长连接,这样在进行命令或数据传输时不需要再和后端的节点进行连接,加快了传输效率。
- 支持多个节点,且支持多个节点池
- 支持redis和memcached两种缓存系统
- 可以根据hash算法进行数据的分片
twemproxy可以改进的地方
服务节点宕机问题
twemproxy和后端的redis或memached服务器保持的长连接,可以实现一个保活机制,当后端服务节点发生宕机时,自动踢掉该服务节点,该动作要对使用者来说透明的。
事件驱动机制问题
twemproxy带动的是多个服务池,但目前所有的事件都基于一套异步的事件驱动机制,是单线实现的,这种架构在并发量小时没有问题,而在高并发量时可能出现延迟。
建议把这个改成master-worker模型,让master负责接收连接,worker负责处理请求,这也是高性能服务的惯用做法,比如:memcached或nginx。
单点问题
twemproxy管理的是一个或多个集群,但本身却是单点。虽然我们可以通过系统手段来实现高可用(比如:keepalive等),但毕竟没有通过分布式来实现得高效。
实际部署上的优化考虑
从以上的介绍我们可以看出twemproxy是一个高效的软件,但也存在自己的一些问题,为了减少twemproxy的并发量,我们可以根据业务把缓存的集群进行拆分,从而部署多个twemproxy点。如下图所示:
也就是说,让每个业务线维护一个redis或memcached集群,保证twemproxy的高效性。
总结
本文从总体架构上对twemproxy进行了分析,并对twemproxy的优缺点进行了一些探讨。接下来后面的文章会对twemproxy的各部分实现原理进行分析。