原子计数器 - redis 与 postgres 或其他？

Atomic counter - redis vs postgres or other?

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

优先级要求：

  1. (必须) 耐用 - 确保一旦客户获得一个号码，其他客户将永远不会获得相同的号码。没有重复...
  2. （必须）可扩展 - 当前负载为 10K/秒，未来 200-1000 个并发客户端连接为 1M/秒。递增 100
    3. 的可伸缩性特征
  3. （必须）< +-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 快，但我认为平均 < 7ms。 “缓存”是一项强大的功能，可以提高性能。
  2. Redis INCR with Redis Sentinel/RDS MultiAZ - 缓存。m3.medium MultiAZ - 120$/m - 耐用性有问题。

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

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

我认为您高估了 redis 故障导致其无法刷新到磁盘的风险，而低估了任何 RDBMS 执行相同操作的风险。两者都可以通过同步写入磁盘来降低风险。

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

无需进行任何过期密钥欺骗。 incr 和 incrby 的原子行为足以确保唯一性和持久性，尤其是与 AOF 持久性结合使用时。

Redis 非常适合这个用例。它足够快且可扩展。 Redis 已经存在一段时间了。对于 PostgreSQL 或 MySQL.

来说，没有合法的持久性问题。

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

来完成