原子反redis vs postgres或其他

Question

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

优先级要求:

1. (必须)持久 -确保一旦客户端获得一个数字，其他客户端将永远不会获得相同的数字。没有重复…
2. (必须)可扩展 -当前负载为10K/秒，将来从200-1000并发客户端连接到1M/秒。增加100
的可扩展性特性
3. (必须)& lt;+-15ms平均 (postgres/mysql/redis是伟大的，http延迟像DynamoDB是不可能的)这只是为了过滤掉缓慢的解决方案
4. (很好)增量这是一个可伸缩性，其中客户端增量一个块(例如:
5. (很高兴有)票价<$ 150 为5k/s，并期望更低的价格增长。
6. (很高兴有)HA(高可用性) -我可以处理0.01%的失败，但持久性很重要，我需要没有重复的数字。

我的选择是:

1. postgres CREATE SEQUENCE serial CACHE 100; SELECT nextval(sequence) - 140$/m MultiAZ AWS RDS db.m3序列。中等，没有redis快，但我认为是<平均7毫秒。"cache&quot;是一个强大的功能，应该提高性能。>
2. Redis INCR与Redis Sentinel/RDS MultiAZ - cache.m3medium MultiAZ - 120$/m -耐久性有问题。

redis有INCRBY，而postgres只有"cache"需要往返数据库的序列特征。

输入吗?关于这两种选择还是其他选择?

Answer 1

我认为你高估了redis失败导致无法刷新到磁盘的风险，低估了任何RDBMS做同样事情的风险。可以通过同步写入磁盘来降低风险。

在redis中，这意味着切换到AOF(只追加文件)模式，如您已经链接到的持久性链接所述。

不需要做任何即将过期的密钥欺骗。incr和incrby的原子行为足以保证惟一性和持久性，特别是在与AOF持久性结合时。

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

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