9

我需要在云上实现一个原子计数器，以从并发连接中生成一个串行整数。背后的业务是跟踪服务器。

优先级要求：

  1. （必须）耐用- 确保一旦客户获得号码，其他客户将永远不会获得相同的号码。没有重复...
  2. （必须）可扩展- 当前负载为 10K/秒，未来 1M/秒，来自 200-1000 个并发客户端连接。以 100 递增的可扩展性功能
  3. （必须）< +-15ms 平均（postgres/mysql/redis 很棒，像 DynamoDB 这样的 http 延迟是不可能的）这只是为了过滤掉缓慢的解决方案
  4. （很高兴） increment by这是一种可伸缩性，客户端以一个块（例如 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 INCR 与Redis Sentinel /RDS MultiAZ - cache.m3.medium MultiAZ - 120$/m - 耐用性有问题。

redis 具有 INCRBY，而 postgres 仅具有需要往返数据库的序列的“缓存”功能。

有输入吗？关于这两种选择或其他选择？

相关参考：

  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/replacing-redis-with-elasticsearch-get-query-speed-counters-and-lists/5609/2
4

1 回答 1

14

我认为您高估了 redis 故障导致它无法刷新到磁盘的风险，而低估了任何 RDBMS 这样做的风险。通过将写入同步到磁盘可以降低这两种风险。

在 redis 中，这意味着切换到 AOF（仅附加文件）模式，如您已经链接到的持久性链接中所述。

没有必要做任何过期的关键诡计。incr和的原子行为incrby足以确保唯一性和持久性，尤其是与 AOF 持久性结合使用时。

Redis 非常适合这个用例。它足够快且可扩展。Redis 已经存在了一段时间。对于 PostgreSQL 或 MySQL 来说，没有任何合法的持久性问题也不会成为问题。

正如@Solarflare 所指出的，让应用程序一次抓取 ID 块更具成本效益和可扩展性。这可以在 redis 中使用incrby.

于 2016-10-25T06:55:24.277 回答