分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo

前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの本質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか？」「データフローは

[NineGates]

分散プログラミングモデルおよびデザインパターンの考察 その2 前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム

[uehaj]

p

[vanbraam]

途中に出てくる参考資料が凄く参考になる;特にJepsenは初めて知ったが非常に興味深い.Split brainは分散システムの問題の中でも(一見正常に動作してる様見える分)最も悩ましい問題の1つかもしれない

[Nyoho]

このシリーズ楽しいな

[t-wada]

"現実の分散システムがどのように対処しているかというと、故障を検知でき故障したら復旧しないというFail-Stop故障モデルを仮定した上で、発見の難しいバグに関しては目を瞑り、起きた順に穴を塞いでいる"

[kuenishi]

わたしよりも数段よく書けていてあいかわらず素晴らしい

[cco]

その2出てた “特殊なミドルウェアが出てくるたびに頭を捻り直すよりは、通信パターンを網羅するために通信レイヤーだけで頑張っているミドルウェアの実例から学ぶのが良いと思う。具体的には ZeroMQ のドキュメント”

[kimutansk]

「最悪の状況」は分散システムというよりは人間のシステムで発生し、対処すべきな気はしますね・・・Jepsenは毎回面白い。