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

Question

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

优先级要求：

1. （必须）耐用 - 确保一旦客户获得一个号码，其他任何客户都不会获得相同的号码。没有重复......
2. （必须）可扩展 - 将来当前负载为10K /秒和1M /秒，来自200-1000个并发客户端连接。递增100的可扩展性特征
3. （必须）＆lt; + -15ms平均值（postgres / mysql / redis很棒，像DynamoDB这样的HTTP延迟是不可能的）这只是为了过滤掉缓慢的解决方案
4. （很高兴）增加这是一种可扩展性，其中客户端增加一个块（例如100）并管理应用程序内存中的增量。
5. （很高兴）票价＆lt; 150美元，速度为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那么快，但我认为＆lt;平均7毫秒。 ＆＃34;缓存＆＃34;是一个强大的功能，可以提高性能。
2. Redis INCR与Redis Sentinel / RDS MultiAZ - cache.m3.medium MultiAZ - 120 $ / m - Durablity有问题。

redis有INCRBY，而postgres只有＆＃34;缓存＆＃34;序列的特征，需要往返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块更具成本效益和可扩展性。这可以使用incrby以redis方式完成。