前回の記事Pulsar3.0 アップグレード ガイドでは、 Pulsar クラスターのアップグレードの主要な手順と災害復旧について説明しましたが、今回は主にいくつかのPulsar3.0新機能と考えられる問題について説明します。
アップグレード後に発生した問題
アップグレード後に発生する問題について話しましょう。
私たちにとってより明らかな問題が 2 つあり、特に最初の問題です。
トピックは削除されました
先月某日の早朝に から に2.11.2アップグレードした後、3.0.1前回の記事で述べた機能テストを行ったところ、問題なく順調に進んだように感じ、30分ほどで退社しました。
翌日、思いがけず電話で目が覚めると、一部の事業者から業務再開後にパルサーに接続できなくなったと報告がありました。
最終的な位置付けは、トピックが削除されたということです。
かなり細かい作業があり、修理の工程も紆余曲折があるので、この工程については後ほど別記事で詳しく整理したいと思います。
この問題と PR には詳細な説明があります: https://github.com/apache/pulsar/issues/21653 https://github.com/apache/pulsar/pull/21704
興味のあるお友達もまずは覗いてみてはいかがでしょうか。
監視インジケーターが失われる
2 番目の問題はそれほど深刻ではありません。アップグレード後、ブックキーパーのいくつかの監視インジケーターが失われていることがわかりました。たとえば、ここでの書き込み遅延などです。長い間
探していましたが、公式の Docker イメージもソース コードも見つかりませんでした。コンパイルするとこの問題が再現できます。
最終的な損失指標は次のとおりです。
- bookkeeper_server_ADD_ENTRY_REQUEST
- bookkeeper_server_ADD_ENTRY_BLOCKED
- bookkeeper_server_READ_ENTRY_BLOCKED
- bookie_journal_JOURNAL_CB_QUEUE_SIZE
- bookie_read_cache_hits_count
- bookie_read_cache_misses_count
- bookie_DELETED_LEDGER_COUNT
- bookie_MAJOR_COMPACTION_COUNT
詳細については、この問題を参照してください: https://github.com/apache/pulsar/issues/21766
新機能
発生したバグについて説明した後、使用できる機能に焦点を当てて、それによってもたらされる新機能を見てみましょう。
低負荷分散をサポート
ブローカーをアップグレードまたは再起動すると、すべての再起動が成功した後、最後に再起動したブローカーにトラフィックがないことが実際にわかります。
この原理と最適化は、実際には以前に書いた「パルサー負荷分散の原理と最適化」で詳しく紹介されています。
今回 3.0 ではついにその最適化機能がリリースされ、その後は設定さえすれば、lowerBoundarySheddingEnabled: trueこの低負荷分散機能をオンにできるので、低負荷ブローカーは引き続きトラフィックを受信できるようになります。
空のメッセージをスキップする
Pulsar は、メッセージの異常な消費によりカーソルにホールを引き起こし、その結果ディスクが解放されなくなる可能性があります。
したがって、メッセージ トピックのバックログを定期的にスキャンして空のメッセージがあるかどうかを確認するスケジュールされたタスクがあります。空のメッセージがある場合は、管理コンソールで SkipMessage API を使用して空のメッセージをスキップし、ディスクを解放できます。
ただし、このスキップ API は 3.0 より前ではバグがあり、スキップ数が 8 を超えている限り、実際のスキップ数は 8 未満になってしまいます。
具体的な問題と修復プロセスは次のとおりです: https://github.com/apache/pulsar/issues/20262 https://github.com/apache/pulsar/pull/20326
つまり、この問題は 3.0 以降では修正されており、同じようなニーズを持つ友人も使用できるようになりました。
新しいロードバランサー
新しいロード バランサーもサポートされており、次の問題が解決されています。
- 以前の負荷分散は ZooKeeper に大きく依存していたため、トピックの数が増加するとスケーラビリティの問題が発生しました。
- 新しいロード バランサーは
non-persistent負荷情報の保存に使用され、zk には依存しなくなりました。
- 新しいロード バランサーは
- 以前のロード バランサーは、
leader broker特定のブローカーへのリダイレクトに依存する必要がありましたが、実際、これらのリダイレクトには意味がなく、システムのオーバーヘッドが増加するだけでした。- 新しいロード バランサーは、SystemTopic を使用してトピック所有権情報を保存するため、各ブローカーがデータを取得できるようになり、リーダー ブローカーからリダイレクトする必要がなくなります。
詳細については、PIP: PIP-192: 新しい Pulsar Broker Load Balancerを参照してください。
大規模な遅延メッセージのサポート
2 番目の大きな特徴は、大規模な遅延メッセージのサポートです。遅延メッセージをネイティブでサポートしているため、Pulsar を選択する企業が多いと思います。
私たちのビジネスでも遅延メッセージを多く使用していますが、以前は遅延メッセージには次のような問題がありました。
- メモリのオーバーヘッドが大きすぎます。遅延メッセージのインデックスはメモリに保存されます。複数のブローカーに分散して保存できたとしても、消費量は依然として大きいです。
- インデックスのメモリ フットプリントの最適化に重点を置きます。
- ブローカーを再起動すると、インデックスを再構築するのに時間がかかります。
- インデックス スナップショットをサポートし、インデックス構築のリソース消費を最小限に抑えます。
最適化する機能
監視パネルの最適化
最後に、3.0 にアップグレードした後でも、最適化する必要がある機能がいくつかあります。前回の記事、Pulsar クライアントの原理から監視パネルまでの記事で、クライアントにいくつかの監視情報が追加されたと述べました。
実際、私が毎日遭遇した最も一般的な問題は、突然消費しなくなる (または消費が遅すぎる) ことでした。 。
現時点でこのような時間のかかるパネルがある場合は、まず消費者自体に問題があるかどうかを判断できます。
まだ開発中ですが、おそらくこのデータと同様です。
要約する
Pulsar3.0 は Pulsar の最初の LTS バージョンです。長期サポートを受けるには、できるだけ早くアップグレードすることをお勧めします。ただし、LTS 版であってもソフトウェアである限りバグは存在します。日常使用でバグに遭遇した場合は、コミュニティにフィードバックを提供し、協力して Pulsar の進歩を促進することをお勧めします。
MySQL 5.7、Moqu、Li Tiaotiao... 2023 年に「停止」される (オープンソース) プロジェクトと Web サイトの総まとめ. Kingsoft WPS がクラッシュ. Linux の Rust 実験は成功. Firefox は チャンスを掴めるか... 10 の予測オープンソースについて 中学校が「インテリジェント・インタラクティブ・カタルシス・デバイス」を購入 - これは実際には任天堂 Wii のシェルだ Redis の父「Ruiping」、LLM プログラミング: 全知全能&& 愚か 「ポスト・オープンソース」の時代は到着しました: ライセンスの有効期限が切れているため、一般公開はできません Vim 9.1 がリリースされ、フロントエンド サークルの Bram Moolenaar 2024 年「新年の戦い」に捧げられました: React は穴を掘りますが、埋めることはできません、ドキュメントに依存する必要がありますそれらを満たしますか？ チャイナユニコムブロードバンドが突然アップロード速度を制限し、多くのユーザーから苦情が寄せられ、 パスカルの父ニクラス・ヴィルトが死去した。