Twitter用のKestrelキューの応用実践
2473 ワード
新しい会社は、ユーザーが情報を公開する後続の処理プロセスを統一するためにメッセージキューを用意します.Webサイトのトラフィックが比較的大きいことを考慮して、メッセージキュー製品を選択することが急務です.
運転環境:LAMP、PHPサーバー6台.
要求:速度が速い;簡単で使いやすい;運転が安定している(データは一般的に失われない);サブキューのサポート
安定性には、次のような状況が含まれます.
1.キューサービスにエラーが発生した場合、failoverのキューによって業務の正常な運行を保証できる
2.既にキューに存在するデータは、キューが回復したときに処理を得ることができる
3.処理スクリプトにエラーが発生した場合、現在処理中のデータは失われません.
前にredis/resqueを使ったことがありますが、いい感じです.残念ながら、データの損失、およびデータを取得するトランザクションを満たしていません.
もともと複雑な商用製品を使いたくないので、いくつかの文章を読んでから
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
Kestrelを使うつもりです.
導入シナリオ
2台のマシンにkestrelを配備し,フロントエンドは負荷等化装置をload balanceとfail overとした.PHPロジックでもエラー処理が行われ、書き込みに失敗すると自動的に再試行されます.
問題:
トラフィックが低い場合はすべて正常で、トラフィックが高い場合、kestrelキューの応答は非常に遅く、kestrelが異常に終了するまで発生します.
分析:
Javaのエラーログを見たり、ネットで検索したりして、発見したときの最新のJDKのバグを見たりします.
http://forums.sun.com/thread.jspa?threadID=5424728
推奨バージョンに変更すると、終了の問題は解決しましたが、まだ速度が遅いです.
繰り返し検討した後,テストスクリプトを作成して大量に接続するテストを行ったところ,kestrel(scala/minaかもしれない)は,大量の短い接続に対する応答速度が遅いことが分かった.
これで私をいらいらさせた.もともとtwitterの人がkestrelがwebの下に向いていると言っているので、大量のproducerがありますが、consumerが少ない場合です.Twitter用のrubyかもしれませんが、長い接続が便利です.しかし、私たちはPHPで、長い接続は比較的面倒です.どうしようかな?
後で考えて、あなたが接続が遅い以上、私はあなたに成長して接続します.そこでagentをエージェントとして探し始めました.幸いプロトコルはmemcacheで、2つのmemcacheのエージェントツールが見つかりました.magentはコンパイルしやすいので、まず試してみましょう.
各kestrelの前にmagentを2つ追加し、テストします.スピードが速いことに気づいた.長時間の稼働により、システムは安定しており、問題は発生していません.
まとめ:
1.完璧なものはなく、それぞれに問題がある
2.オープンな合意が命を救った
運転環境:LAMP、PHPサーバー6台.
要求:速度が速い;簡単で使いやすい;運転が安定している(データは一般的に失われない);サブキューのサポート
安定性には、次のような状況が含まれます.
1.キューサービスにエラーが発生した場合、failoverのキューによって業務の正常な運行を保証できる
2.既にキューに存在するデータは、キューが回復したときに処理を得ることができる
3.処理スクリプトにエラーが発生した場合、現在処理中のデータは失われません.
前にredis/resqueを使ったことがありますが、いい感じです.残念ながら、データの損失、およびデータを取得するトランザクションを満たしていません.
もともと複雑な商用製品を使いたくないので、いくつかの文章を読んでから
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
Kestrelを使うつもりです.
導入シナリオ
2台のマシンにkestrelを配備し,フロントエンドは負荷等化装置をload balanceとfail overとした.PHPロジックでもエラー処理が行われ、書き込みに失敗すると自動的に再試行されます.
問題:
トラフィックが低い場合はすべて正常で、トラフィックが高い場合、kestrelキューの応答は非常に遅く、kestrelが異常に終了するまで発生します.
分析:
Javaのエラーログを見たり、ネットで検索したりして、発見したときの最新のJDKのバグを見たりします.
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で、2つのmemcacheのエージェントツールが見つかりました.magentはコンパイルしやすいので、まず試してみましょう.
各kestrelの前にmagentを2つ追加し、テストします.スピードが速いことに気づいた.長時間の稼働により、システムは安定しており、問題は発生していません.
まとめ:
1.完璧なものはなく、それぞれに問題がある
2.オープンな合意が命を救った