原子计数器 - redis vs postgres或其他？ [关闭]

Question

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

优先级要求：

1. （必须）耐用 - 确保一旦客户获得号码，其他客户将永远不会获得相同的号码。没有重复...
2. （必须）可扩展 - 当前负载为 10K/秒，未来 1M/秒，来自 200-1000 个并发客户端连接。递增 100 的可扩展性功能
3. （必须）（postgres/mysql/redis 很棒，像 DynamoDB 这样的 http 延迟是不可能的）这只是为了过滤掉缓慢的解决方案
4. （很高兴）增量 这是一种可伸缩性，客户端增量为一个块（例如 100）并管理应用程序内存中的增量。
5. （很高兴拥有）5k/s 的票价 ，预计价格将进一步增长。
6. （很高兴拥有）HA（高可用性） - 我可以处理 0.01% 的故障，但持久性很重要，我需要没有重复的数字。

我的选择是：

1. postgres 序列CREATE SEQUENCE serial CACHE 100; SELECT nextval(sequence) - 140$/m MultiAZ AWS RDS db.m3.medium 不如 redis 快，但我认为平均
2. Redis INCR 与 Redis Sentinel/RDS MultiAZ - cache.m3.medium MultiAZ - 120$/m - 耐用性存在问题。

redis有INCRBY，postgres只有sequence的“缓存”特性，需要往返DB。

任何输入？关于这两个替代方案或其他方案？

相关参考资料：

1. Atomic counters 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

Answer 1

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

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

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

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

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