9

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

優先度別の要件:

  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
4

1 に答える 1

14

ディスクにフラッシュできなくなる redis 障害のリスクを過大評価し、同じことを行う RDBMS のリスクを過小評価していると思います。ディスクへの書き込みを同期することで、両方のリスクを軽減できます。

redis では、これは、既にリンクしている永続化リンクで説明されているように、AOF (Append Only File) モードに切り替えることを意味します。

期限切れのキートリックを行う必要はありません。とのアトミックな動作はincr、incrby特に AOF 永続性と組み合わせると、一意性と耐久性を確保するのに十分です。

Redis は、このユース ケースに最適です。十分に高速でスケーラブルです。Redis が登場してからしばらく経ちます。PostgreSQL や MySQL の懸念事項ではない正当な耐久性に関する懸念事項はありません。

@Solarflare で指摘されているように、アプリケーションが一度に ID のブロックを取得することは、さらに費用対効果が高く、スケーラブルです。これは、 を使用して redis で実現できますincrby。

于 2016-10-25T06:55:24.277 に答える