Q4M - a high-performance message queue for MySQL

  • 11,485 views
Uploaded on

Explains the design, usage, and user senarios of Q4M.

Explains the design, usage, and user senarios of Q4M.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
11,485
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
104
Comments
1
Likes
8

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Q4M a high-performance message queue for MySQL Cybozu Labs, Inc. Kazuho Oku
  • 2.
    • What is a Message Queue?
    • from Distributed Systems (Tanenbaum / Van Steen)
  • 3. What is a Message Queue?
    • Middleware for persistent asynchronous communication
        • 持続的な非同期コミュニケーションのためのミドルウェア
    • A.k.a. Message-Oriented Middleware
        • 別名 : MOM
  • 4. Message Queue (cont.)
    • MQ is an intermediate storage
        • MQ は中間的なストレージ
      • vs. RDBMS (long-term persistent storage)
        • vs. RDBMS ( 永続的なストレージ )
    • Senders and/or receivers may go down
      • 送受信プロセスが任意に停止可能
  • 5. Minimal Configuration of a MQ ( 最小構成 )
    • Senders and receivers access a single queue
        • 送信プロセスと受信プロセスが同一のキューにアクセス
    Sender Receiver Queue
  • 6. MQ and Relays
    • Separate queue for sender and receiver
        • 送信プロセスと受信プロセスが別個にキューをもつ
    • Messages relayed between queues
        • メッセージリレーでキュー間を接続
    Sender Receiver Relay Queue Queue
  • 7. Merits of Message Relays ( リレーの意義 )
    • Destination can be easily changed
        • 宛先の変更が容易
      • Relays may transfer messages to different locations depending on the header
        • ヘッダを見て転送先を変えるとか
    • Robustness against network failure
        • ネットワーク障害の影響を受けない
    • Logging and Multicasting, etc.
        • ロギングやマルチキャストが可能
  • 8. Message Brokers
    • Transform (filter) messages within the relay agent
        • リレーエージェント内でメッセージの変換を行う
    • Publish / subscribe model
      • Separation between logic and data transfer
        • ロジックとデータ転送の分離
  • 9. Q4M
    • Q4M (can) support all models
        • Q4M は全モデルに対応 ( 可能 )
    • Message transfer by q4m-forward
        • メッセージ転送は q4m-forward で
    • APIs for routers and message brokers
        • ルータやメッセージブローカ用の API
  • 10.
    • Architecture of Q4M
  • 11. File Format
    • Log-based file format
        • ログベースのファイルフォーマット
    • Each row ( queue_row_t ) consist of:
        • Row Header (4 bytes) -- row type and body size
        • Source Row ID -- optional, for message transfer
        • Body -- < 512MB
  • 12. Row Header
    • Row Types: 3bits
        • Normal row
        • Removed row
        • Normal row with source rowid
        • Removed row with source rowid
        • Checksum
          • Used to recovering successful INSERTs
          • 29-bit adler32
        • Number of Rows Removed
          • Used for recovering rowids
    • Body Size: 29bits
  • 13. Data Consistency
    • INSERTs group-commited using writev
        • INSERT は writev を利用してグループコミット
      • Each group has a checksum prepended
        • 各グループの先頭にチェックサムが存在
      • Crash recovery is an iteration through the logfile until reaching a block with an invalid checksum
        • クラッシュリカバリの際は、チェックサム比較に失敗するブロックに到達するまでログを舐める
  • 14. Data Consistency (cont.)
    • DELETEs are modifs. of row headers
      • DELETE は行ヘッダの型変更
          • Normal row -> Removed row
          • Normal row w. source rowid -> Removed row w. source rowid
      • Either by pwrite or mmap(PROT_WRITE) + msync
          • pwrite あるいは mmap(PROT_WRITE) + msync で削除
      • Multirow DELETEs aren’t atomic
          • 複数行 DELETE は非アトミック
        • Not a problem; no API to consume multiple rows at once
          • 複数行を一度に消費する API がないので問題ではない
  • 15. Row IDs
    • 64bit Int
    • Starts from one and incremented per each row
      • 1 から始まって1行毎にインクリメント
    • Used to detect and block duplicates by relays
        • メッセージリレーが重複を検出・除外するために使用
  • 16. Restritions in SQL of Q4M
    • No indexes
    • No UPDATE
      • Why need UPDATE a queue row?
        • キューのデータを UPDATE する必要なんてない
    • SELECT and DELETE are supported for queue administration
        • SELECT DELETE を使ってキューを管理可能
      • ex. select count(*) from queue;
  • 17. Why no Indexes Support?
    • There is generally no reason to support indexes with mysql-based queues, since mysql cannot handle a large number of connections requesting data under various conditions
        • インデックスが必要になるほど多様な条件を指定して同時に購読できるほど、 mysql の同時接続数は大きくない
  • 18. Why no Indexes Support?
    • Instead use conditional subscription
        • Conditional subscription 機能を使うべき
    • Or route data after reading from Q4M
        • あるいは Q4M からデータを読んだ後にルーティングすべき
  • 19.
    • Tutorial
  • 20. Sending a Message
    • INSERT into queue values (1,’Hello World!’);
  • 21. Receiving a Message
    • while (1) {
    • SELECT queue_wait(‘queue’);;
    • my @row = SELECT ROW * FROM queue;
    • or next;
    • }
    • SELECT queue_end(‘queue’);;
  • 22. OWNER Mode and NON-OWNER Mode
  • 23. OWNER Mode and NON-OWNER Mode (cont.)
    • Within OWNER mode, only the owned row are visible
        • OWNER モードでは、所有中の行のみが見える
    • Within NON-OWNER mode, rows owned by other connections are invisible
        • NON-OWNER モードでは、他の接続が所有している行は見えない
  • 24. Function for Entering OWNER Mode
    • queue_wait
      • Used to enter OWNER mode
        • OWNER モードに ( 再 ) 切替するために使用
      • When called within OWNER mode, the owned row is deleted
  • 25. queue_wait
    • Two forms
        • queue_wait(tbl_cond)
        • queue_wait(tbl_cond,[tbl_cond…,timeout])
  • 26. queue_wait(tbl_cond)
    • Wait max. 60 seconds until any data becomes available on given table under given condition
        • 最大 60 秒間、指定された条件に合致する行が指定されたテーブルに登録されるまでブロック
    • Returns 1 if successful, 0 if no data
        • 成功すれば 1 、データがなければ 0
    • Enters OWNER mode even if no data
        • データがない場合でも OWNER モードへ切り替わる
  • 27. queue_wait(tbl_cond)
    • Table name (and optionally condition) should be specified
        • テーブル名と ( オプションで条件 ) を指定
    • Only numeric columns may be used within condition
        • 条件節では数値型のカラムのみ使用可能
      • See queue_share_t::init_fixed_fields
      • tbl_cond ::= table [ “:” cond]
  • 28. queue_wait(tbl_cond) (cont.)
    • SELECT queue_wait(‘table:v<3’);
  • 29. queue_wait(tbl_cond,[tbl_cond…,timeout])
    • Accepts multiple tables and timeout
      • 複数のテーブルとタイムアウトを指定可能
    • Data searched from leftmost table to right
        • データは左端のテーブルから右方向に探索
    • Returns table index (the leftmost table is 1) of the newly owned row
        • 獲得した行の属するテーブルのインデックス ( 左端のテーブルが 1) を返す
  • 30. Functions for Exiting OWNER Mode
    • queue_end
      • Deletes the owned row and exits OWNER mode
        • 所有中の行を削除して OWNER モードを脱出
    • queue_abort
      • Releases (instead of deleting) the owned row and exits OWNER mode
        • 所有中の行を非所有状態に変更して OWNER モードを脱出
      • Close of a MySQL connection does the same thing
        • MySQL の接続切断時も同様
  • 31. Receiving a Message (revisited)
    • while (1) {
    • SELECT queue_wait(‘queue’);;
    • my @row = SELECT ROW * FROM queue;
    • or next;
    • if (consume_row(@row) != SUCCESS) {
    • exit(1);
    • }
    • }
  • 32.
    • Applications of Q4M
  • 33. Connecting Distant Servers
    • Pathtraq uses Q4M queues and a relay to communicate with its content analysis service running in a different iDC
        • Pathtraq では、 Q4M キューとメッセージリレーを使用して、別の iDC にあるコンテンツ分析サービスと接続している
    Content Analysis Service Pathtraq DB MySQL conn. over SSL,gzip Queue Queue
  • 34. User Notifications
    • For sending notifications from web services
        • ウェブサービスでユーザ通知送信のために使用可能
    DB App. Logic SMTP Agent IM Agent Queue(s)
  • 35. Asynchronous Updates
    • Asynchronous updates leads to faster response of web services
        • 非同期更新に利用することでウェブサービスの応答性を向上可能
    DB App. Logic DB Queue
  • 36. Scheduling Web Crawlers
    • Web crawlers with retry-on-error
        • リトライ機能つき Web クローラー
    URL DB Spiders Re- scheduler Store Result Read URL If failed to fetch, store URL in retry queue Request Queue Retry Queue
  • 37.
    • Current Limitations and the Future of Q4M
  • 38. Current Limitations
    • Table compactions is a blocking operation
        • テーブルコンパクションが他の処理をブロックする
      • Runs when live data becomes <25% of log file
        • ライブデータが 25% 以下になると実行
    • Relays are slow
      • Not a problem for Cybozu Labs :-p
  • 39. Future of Q4M
    • API for consuming multiple rows at once
        • 複数行を一度に受信処理するモード
      • Necessary for speeding up relays
        • リレーの高速化に必要
    • Simple “delete-on-SELECT” mode for novices
        • 初心者向けの「 SELECT 時に削除」モード
    • Support for transaction w. InnoDB?
        • InnoDB とのトランザクション処理
  • 40. Configuration Options of Q4M
    • --with-sync=no|fsync|fdatasync|fcntl
      • Controls synchronization to disk, see --help for detail
    • --enable-mmap
      • Mmap’ed reads lead to higher throughput
    • --enable-mmap-writes
      • DELETEs commited using mmap(PROT_WRITE) and msync, recommended on linux>=2.6.20 if you need really high performance