②のプロセスは頻繁にエラーで落ちてしまうため、プロセス監視により落ちたら自動的に再起動するようにしています。
いやいや、なんで頻繁にエラーで落ちちゃうの…?
Node.jsでも早々落ちない高耐久のサーバー組めるはずだよ。
まずはつまらないエラーで落ちないように自動テストを埋めていこう。
socket.ioなどで、ソケット通信を用いてプロセス間通信を試みようと思いますが、②が落ちていることで、通信が確立されず、①もエラーで落ちてしまうことなどを危惧しております。
いやいや、2が落ちてれば検知出来るよね?
Promiseなら.catch
で拾えるし、
非同期処理ならコールバック引数の第一引数がerrだからそれ見て対応変えられるはずだよ
プロセス間通信について疎い
速度だけならいろいろと手はあるね。
UNIXドメインソケットとかね。
でもそこまでシビアなパフォーマンスを要求しないなら、
普通にTCPのサーバを立ち上げて、localhost:xxxx
として繋いだ方がいいね。
①は通信がうまくいっているかを気にせずひたすら②へデータを送り続ける
そもそも頻繁に死ぬ2を何とかしようという話なんだけど、
2が頻繁に死ぬならSocket.ioじゃダメ、直接つなげるのはやめたほうがいい。
例えば両方は直接接続せずにMySQLなどのデータベースを経由して通信する。
1はメッセージをとにかくMySQLへ保存して、
2は3秒に一度みたいなペースでMySQLを巡回してメッセージを取り出して、仕事が終わったら消すというのはどうだろう?
MySQLみたいなデータベースは高耐久なアプリだから、落ちないメッセージ置き場として中々適切だと思うよ。
私だったらPubSub導入する路線で考えるかな。
Kafkaとか、Pulsarとか触ってみたいね。
AWSが使えるならSQSが理想。
PubSubというのはメッセージキューのサービス(サーバ)で、
1のような仕事を発注したい人がとりあえずメッセージを投げまくったのを保存しておき、
2のようなプロセスが蓋を開けると仕事がバサバサ落ちてくるという仕組みを提供している。
これはSQSの機能の話で他のPubSubで使えるかは調査の必要があるけど、
チケットを受信したら受信しましたよフラグが一旦建ち、
その後仕事終了と称してチケットを削除しないと10〜30分程度でチケットが復活する仕組みになっている。
なので2がチケットを10件受け取って、7件目の仕事中で死んだら4件の未処理チケットが宙ぶらりんで残ってしまうのだけど
時間が経てばこの4件のメッセージが未受信状態に戻ってまた別のタスクが受け取れるようになるわけ。
これでまさに1はメッセージを投げて、2は勝手に受け取るという仕組みが実現出来るね。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/01/12 10:45 編集