Twitter用的Kestrel队列的应用实践 博客分类： JAVA Twitter应用服务器memcachedPHPRedis
程序员文章站
2024-03-17 12:42:34
...
新的公司准备上消息队列，用于统一用户发布信息后续处理流程。考虑到网站的流量已经比较大了，选择一个消息队列产品成为当务之急。
运行环境：LAMP,PHP服务器6台。
要求：速度快；简单易用；运行稳定（数据一般不丢失);支持子队列
稳定性，应该包含下面一些情况：
1. 如果队列服务出错，能够有failover的队列保证业务正常运行
2. 已经在队列中的数据，能够在队列恢复时，得到处理
3. 如果处理脚本出现错误，当前正在处理的数据不会丢失。
之前用过redis/resque，感觉很不错。可惜不满足数据丢失，和取数据的事务。
本来就不想用很复杂的商用产品，又看了一些文章后
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
准备用Kestrel。
部署方案
在两台机器上部署kestrel，前端用负载均衡设备作load balance和fail over。在PHP逻辑中也进行错误处理，写入失败则自动重试。
出现的问题：
流量低的时候一切正常，流量高后，kestrel队列响应非常慢，直到kestrel出现异常退出。
分析：
看java的错误日志，以及在网上搜，发现时最新的JDK的bug。
http://forums.sun.com/thread.jspa?threadID=5424728
换成推荐的版本后，退出的问题解决了，但是速度还是很慢。
经过反复研究后，以及编写了测试脚本进行大量连接的测试后，发现kestrel(也许是scala/mina）,对大量短连接的响应速度很慢。
这下把我给急坏了。本来就是因为twitter的人说kestrel比较适合web下，大量producer，但是consumer比较少的情况。也许twitter用的ruby，用长连接比较方便。但是我们是PHP，长连接相对比较麻烦。怎么办呢？
后来就想，既然你连接慢，我给你转成长连接。于是开始找agent做代理。幸好协议是memcache，找到两个memcache的代理工具。因为magent比较好编译，就先试它吧。
在每个kestrel前面加两个magent，再测试。发现速度很快了。且经过长时间运行，系统很稳定，没有出现任何问题。
总结：
1. 没有东西是完美的，各有各的问题
2. 开放的协议救了我一命啊
运行环境：LAMP,PHP服务器6台。
要求：速度快；简单易用；运行稳定（数据一般不丢失);支持子队列
稳定性，应该包含下面一些情况：
1. 如果队列服务出错，能够有failover的队列保证业务正常运行
2. 已经在队列中的数据，能够在队列恢复时，得到处理
3. 如果处理脚本出现错误，当前正在处理的数据不会丢失。
之前用过redis/resque，感觉很不错。可惜不满足数据丢失，和取数据的事务。
本来就不想用很复杂的商用产品，又看了一些文章后
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
准备用Kestrel。
部署方案
在两台机器上部署kestrel，前端用负载均衡设备作load balance和fail over。在PHP逻辑中也进行错误处理，写入失败则自动重试。
出现的问题：
流量低的时候一切正常，流量高后，kestrel队列响应非常慢，直到kestrel出现异常退出。
分析：
看java的错误日志，以及在网上搜，发现时最新的JDK的bug。
http://forums.sun.com/thread.jspa?threadID=5424728
# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xb04a3705, pid=3301, tid=2948414352 # # JRE version: 6.0_18-b07 # Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode linux-x86 ) # Problematic frame: # C 0xb04a3705 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0894f800): GCTaskThread [stack: 0xafb53000,0xafbd4000] [id=33 08] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000 0 Registers: EAX=0xb04a2618, EBX=0xdf07ae68, ECX=0xb04a2608, EDX=0x00000000 ESP=0xafbd31f8, EBP=0xafbd3278, ESI=0xafbd32c8, EDI=0x00000000 EIP=0xb04a3705, CR2=0x00000000, EFLAGS=0x00010212 Top of Stack: (sp=0xafbd31f8)
换成推荐的版本后，退出的问题解决了，但是速度还是很慢。
经过反复研究后，以及编写了测试脚本进行大量连接的测试后，发现kestrel(也许是scala/mina）,对大量短连接的响应速度很慢。
这下把我给急坏了。本来就是因为twitter的人说kestrel比较适合web下，大量producer，但是consumer比较少的情况。也许twitter用的ruby，用长连接比较方便。但是我们是PHP，长连接相对比较麻烦。怎么办呢？
后来就想，既然你连接慢，我给你转成长连接。于是开始找agent做代理。幸好协议是memcache，找到两个memcache的代理工具。因为magent比较好编译，就先试它吧。
在每个kestrel前面加两个magent，再测试。发现速度很快了。且经过长时间运行，系统很稳定，没有出现任何问题。
总结：
1. 没有东西是完美的，各有各的问题
2. 开放的协议救了我一命啊