在去年的Data@Scale大会和USENIX的USENIX的NSDI(联网系统设计和实现座谈会)上我们就提过会将缓存换成我们自主开发的分布式软件系统,我们称之为mcrouter(发音“mick-router”)。Mcrouter是一个memcached协议的路由器,被facebook用于在他们遍布全球的数据中心中的数十个集群几千个服务器之间控制流量。它适用于大规模的级别中,在峰值的时候,mcrouter处理接近50亿的请求/秒。Mcrouter同样也可以作为独立的二进制包工作于AWS中,去年之前Instagram使用它来完全过渡到Facebook的基础设施。
今天,我们激动的宣布我们将发布mcrouter的源代码(开源BSD协议)。我们相信它可以帮助更多的网站通过Facebook的大规模系统的知识以一种更容易理解更容易发布的方式扩大其系统的规模。
由于任何要接入memcached服务的客户端,都会使用标准ASCII编码的memcached协议,我们可以采用memcached的通用API作为通信方式(参看下图)。对于memcached客户端,mcrouter完全像一个memcached服务器。对于服务器,mcrouter完全像一个普通的memcached客户端。但mcrouter丰富的可配置性,使得它更像一个简化的proxy。
下面列举了一些mcrouter的特性。其中“destination”指memcached 主机(或者其他能兼容memcached协议的缓存服务实现)。“pool”指集群化的destinations,并能通过配置将负载均衡分配给不同的destination--例如,可通过hash方式均衡,亦可通过冗余数据均衡(读操作)。无论何种方式,pools最终都能以集群的方式进行管理。
支持标准开源的memcached ASCII编码协议:支持memcahed协议的所有客户端无需做任何修改即可被mcrouter支持.只需要将mcrouter连接客户端和memcached盒子便能让其正常工作.
连接池:mcrouter能让客户端共享连接池,以减少连接个数
多种散列方法:mcrouter提供了一个行之有效的consistent hashing算法(furc_hash),算法允许给多个memcached实例分配哈希值。Hostname hashing再根据分配的哈希值为客户端选择一个独一无二的副本.在特定的应用中很有很多其他的有用的散列方法.
前缀路由:mcrouter可以根据key前缀把客户端分配到不同的memcahed池.比如,你可以把以”foo"为前缀的所有key分配到一个“foo"池,把以"bar"为前缀的所有key分配到另外一个"bar"池,其他的key都分配到"wildcard" 池.这是一种简单的均衡负载的方法.参照下图:
memcached池备份:在多个主机上保存一份相同数据的备份.做写错做时向所有的主机写入同一份数据,但是做读操作时只从客户端对应的缓存区读取一份数据.这样就可以处理由于主机数据的限制造成分片池不能处理的读出率的问题;而且还能增强数据的可用性(比如:由于故障自动转移,即使一份备份坏掉也不会影响其正常操作).
演示路径跟踪: 在测试新缓存设备时,能够路由从客户端到缓存设备的所有可能路径是非常有用的. Mcrouter支持灵活的跟踪配置,通过重新哈希值范围跟踪测试不同大小的memcached池,或只跟踪哈希值范围的一部分,或在运行时动态修改跟踪环境.
热加载:mcrouter监控它所有的配置文件.一旦检测到任何配置文件被修改,mcrouter的一个后台线程将自动的重新加载,分析这些文件.在这个操作完成之后,mcrouter会根据新配置来处理新请求.这个过程对客户端而言是透明的.
灵活的路由方式: "路由句柄"是由小路由模块组合而成,这些路由模块公用一个接口(路由一个请求,返回一个回复),也可以自由组合.单个路由句柄更容易理解、创建和测试. 利用路由句柄创建复杂的逻辑.比如:名为"all-sync"路由句柄是由多个子句柄组成的, 它发送一个请求给所有的子句柄,只有在所有的子句柄发回回复时,"all-sync"才发回其中的一个回复. 还有其他的类似的例子:"all-async"(发送请求到所有的子句柄,但不会等待子句柄的回复), "all-majority"(舆论调查),"failover"(顺序的发送请求到每个子句柄直到收到一个无错误的回复). 通过"cold cached warmup"句柄能快速扩充一个memcached池(把旧的memcached服务器作为"暖缓存").
Destination心跳检测和自动故障转移: Mcrouter能够检测每个destination的心跳.一旦mcrouter将一个destination标记为无响应,它将直接将所有的请求转移到另一个可用的destination. 同时,后台形成将向无响应destination发送心跳请求,只要destination的心跳恢复正常,mcrouter将会重新启用这个destination."软错误"(比如:数据超时)允许连续发生多次,但是一旦发生"硬错误"(比如:拒绝连接)mcrouter立即将该destination标记为无响应. 不用说,这个过程对客户端完全是透明的.
自动填充新增缓存:mcrouter通过指定的"warm"缓存区主动填充新增的缓存区域的方式来消除新增缓存区造成的性能影响.
广播操作:通过在请求关键字里面增加一个特殊的前缀,能够很容易把请求备份到多个memcached池或者集群里面.
可靠的删除操作:在一个有求必应的缓冲区里,保证所有的删除操作都送到目的地是非常重要的.mcrouter将所有的删除操作都记录到硬盘上以防止由于网络中断或者原因导致destination不可访问.当连接修复之后,mcrouter将启动一个单独的进程异步的重新执行这些删除操作.这个过程对客户端是透明的,并且客户端接受到的操作结果通常是成功的.
支持多集群:mcrouter能通过的简单的配置管理大的多集群.单个配置通过命令行参数分发到所有的集群,mcrouter根据命令行参数的位置解释配置.
丰富的stats和debug命令:mcrouter通过"stats"命令导出很多的内部计数器(或者以JSON格式导出到文件系统).mcrouter提供自我调试命令,这种命令能够反应在运行时一个特定的请求被分配到哪一个主机.
保障服务质量:mcrouter允许以主机,池或者集群为单位设置任何请求(比如:get/set/delete)的速率的阀值,当请求个数超过阀值,剩下的请求将会被拒绝. 同事也支持限制请求的速度以减缓请求的发送速度.
分割数据块:当传入的数据超过memcached slab的大小,mcrouter能根据slab的大小自动分割或重组数据块.
多级缓存:mcrouter支持本地/远程缓存设置.请求数据时先从本地缓存区查找,如果在本地缓存区查找失败再从远程缓存区查找,如果在远程缓存区找到该数据,mcrouter会自动的将数据缓存到本地缓存区.
支持IPv6:在Facebook,mcrouter支持IPv6. 同样,在Faceboo局域网以外的地方,mcrouter也支持IPv6.
支持SSL:mcrouter就支持双向SSL(输入或者输出),只要客户端或者目标主机其中的一方支持SSL即可。串联多个mcrouter, 在两两mcrouter之间的连接支持SSL也是可能的.
多线程架构:mcrouter通过一个内核一个线程的方式充分利用多核系统的优势.
Mcrouter使用C++开发(使用了大量的C++ 11特性),其余用C开发了功能库部分,用Ragel开发了协议解析部分。并借用了Facebook的开源库Folly和fbthrift(用于异步网络处理)。
一个Mcrouter的进程,会启动多个相互独立的线程,用于异步处理网络事件(基于libevent的实现)。当线程处理请求包/响应包时,它会使用内部的轻量级线程/或称"纤程(fiber)"。纤程的实现是基于boost::context。
Mcrouter采用JSON格式的配置,支持通过任意方式的路由处理(route handle scheme),以适应各种路由需求。这里有一些常用的示例可供参考。
我们邀请软件工程师使用Memcached,在任何地方评估Mcrouter,看看它是否能帮助简化站点的管理。与此同时,它还提供了许多新功能,上面的列表列出的(诸如:shadow testing,cold cache warmup 等等)。在过渡到Facebook的基础架构之前,Instagram使用了一年多的Mcrouter,因此Mcrouter在Amazon Web Services上被证明是可行的。在(项目)开源之前,我们与Reddit合作,他们提供了一套限定的β测试(方案),现在他们还在许多生产环境的cache上运行Mcrouter。
我们乐于看到持续的改进,这将让Mcrouter更有助于在Memcached社区的你和其他人。
Mcrouter的源代码已经被开源,并放在了https://github.com/facebook/mcrouter。我们一直在寻求改进Mcrouter性能的方法(修复bugs,添加新特性)。我们将会持续不断更新外部的Github repo和我们内部的更改,因此,你将会受益于这项工作。我们会在Github wiki上维护Mcrouter的文档。我们还建立了一个Facebook讨论组。
评论删除后,数据将无法恢复
评论(20)
应该是这吧?