問題タブ [durability]

同時接続からシリアル整数を生成するには、クラウド上にアトミック カウンターを実装する必要があります。背後にあるビジネスは追跡サーバーです。

優先度別の要件:

1. (MUST) 耐久性- クライアントが番号を取得したら、他のクライアントが同じ番号を取得しないようにしてください。重複なし...
2. (MUST) スケーラブル- 現在の負荷は 10K/秒で、将来的には 200 ～ 1000 の同時クライアント接続で 1M/秒になります。100 ずつインクリメントするスケーラビリティ機能
3. (MUST) < +-15ms 平均(postgres/mysql/redis は優れています。DynamoDB のような HTTP レイテンシは問題外です)これは単に遅いソリューションを除外するためのものです
4. (あると便利) 増分これは、クライアントがチャンク (たとえば 100) ずつ増分し、アプリケーションのメモリ内の増分を管理するスケーラビリティです。
5. (あると便利) 運賃は 5k/s で 150 ドル未満で、それ以上の低価格の成長が期待されます。
6. (あると便利) HA (高可用性) - 0.01% の障害を処理できますが、耐久性が重要です。番号が重複しないようにする必要があります。

私の代替案は次のとおりです。

1. postgres のシーケンスCREATE SEQUENCE serial CACHE 100; SELECT nextval(sequence)- 140$/m MultiAZ AWS RDS db.m3.medium は redis ほど高速ではありませんが、平均で 7 ミリ秒未満だと思います。「キャッシュ」は、パフォーマンスを向上させる強力な機能です。
2. Redis Sentinel /RDS MultiAZを使用した Redis INCR - cache.m3.medium MultiAZ - 120$/m - 耐久性が問題です。

redisにはINCRBYがあり、postgresにはDBへの往復を必要とするシーケンスの「キャッシュ」機能しかありません。

入力はありますか？それらの2つの代替案またはその他に関して？

関連資料:

1. アトミックカウンター Postgres vs MongoDB
2. http://redis.io/topics/persistence
3. https://www.quora.com/When-should-I-use-redis-as-my-primary-data-store
4. https://muut.com/blog/technology/redis-as-primary-datastore-wtf.html
5. https://discuss.elastic.co/t/replaceing-redis-with-elasticsearch-get-query-speed-counters-and-lists/5609/2

Docker で rabbitMQ を使用しています。
rabbitmq を実行するときに、メッセージの Durability を設定したいと思います(durable/transient)。
耐久性を設定する方法はありますか？(Queue と Exchange を宣言する場合を除く)

http://www.h2database.com/html/advanced.html#durability_problemsを読んでいて、見つけました

一部のデータベースは耐久性を保証できると主張していますが、そのような主張は間違っています。H2、HSQLDB、PostgreSQL、および Derby に対して耐久性テストが実行されました。これらのデータベースはすべて、コミットされたトランザクションを失うことがあります。テストは H2 ダウンロードに含まれています。org.h2.test.poweroff.Test を参照してください。

また、それは言う

取引の損失が許容できない場合は、ラップトップまたは UPS (無停電電源装置) を使用する必要があります。

耐久性のあるデータベースはありますか。ドキュメントには fsync() コマンドについて記載されており、ほとんどのハード ドライブは fsync() に従いません。また、ハードドライブのバッファをフラッシュする信頼できる方法がないことについても語っています

それで、コミットされたトランザクションが永続的になる時間があるので、最小限の電力供給のバックアップを提供するアップを購入できます.

また、コミットされたトランザクションが永続的であることを知る方法はありますか。アップを購入せず、トランザクションが永続的であることがわかった後、成功メッセージを表示できるとします。

公式ドキュメントより

オーバーヘッドが高くなりますが、Session.createDurableSubscriber メソッドを使用して永続サブスクライバーを作成できます。永続サブスクリプションは、一度に 1 つのアクティブなサブスクライバーのみを持つことができます

デザインが選ばれた理由を教えてください。

私の観点から言えば、このトピックは、特に多くの加入者がいる状況について調べました。

プライマリに永続的または一時的に障害が発生した場合、またはネットワーク レベルでレプリカ セットの残りの部分から分離された場合のシナリオでのデータの耐久性に関連して、MongoDB が提供する保証があれば、それを理解したいと思います。

w:1 書き込み懸念で何が起こるかを理解しています。ジャーナリングの役割を理解しています。

新しいプライマリが選択されたときに、MongoDB がどの書き込みを保持し、どの書き込みを破棄するかを決定する方法がわかりません。N1 がプライマリで、N2、N3、N4 がセカンダリの 4 ノード (+ アービター) クラスタで、次のシナリオを実行します。

1. {w:majority, j:true} 書き込みがプライマリにヒットします。
2. セカンダリは変更をポーリングし、プライマリは過半数が確認されるのを待ちます。
3. N2 は変更を確認します。
4. N3 は変更を受け取り、適用中です。
5. プライマリがダウンします。
6. N3 は、変更を適用したことをプライマリに確認できません。
7. 選挙は強制。

質問:

• 選挙が完了した後、書き込みは利用可能になりますか?
• どのノードが新しいプライマリになるかは重要ですか?
• ステップ 4 が行われなかった場合、結果は異なりますか?
• プライマリーが N3 から確認を受け取った場合、結果は異なりますか?
• プライマリが書き込みを確認し、N2 が書き込みが過半数で確認されたという事実を複製した場合、結果は異なりますか?
• N2 と N3 の両方が書き込みが多数決で確認されたという事実を複製した場合、結果は異なりますか?