原子计数器-Redis vs Postgres还是其他？

Question

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

优先要求：

1. （必须）持久 -确保一旦一个客户获得一个号码，就不会再有其他客户获得这个相同的号码。没有重复...
2. （必须）可伸缩 -当前的负载为200-1000个并发客户端连接时的当前负载为10K /秒和将来的1M /秒。可扩展性增加100
3. （必须）平均<+ -15ms（postgres / mysql / redis很棒，像DynamoDB这样的http延迟是不可能的），这只是为了过滤慢速的解决方案
4. （很高兴）increment by 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快，但我认为平均<7ms。“缓存”是一项强大的功能，可以提高性能。
2. 带Redis Sentinel的 Redis INCR / RDS MultiAZ-cache.m3.medium MultiAZ-120 $ / m-持久性存在疑问。

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

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

相关参考：

1. 原子计数器Postgres和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。