redis 可以在单个键值对上每秒执行数百个事务吗
Can redis do hundreds of transactions per second on single key-value pair
我有一个应用程序，可用于 API 调用。在每次 API 通话中，我都会执行一些任务并为此收费（可以发送邮件或短信或任何此类内容）。
目前我将我的用户 balance/credit 数据保存在 MYSQL table 中，格式如下：
|user|balance|
|a |1200 |
|b |1200 |
|c |1300 |
|d |1400 |
|e |1212 |
|f |9000 |
|g |8000 |
|h |7000 |
但是，当单个用户每分钟点击数千次 API 时，就会产生问题。每次 API 我都会更新用户的余额，如果余额不足，我会 return 出错。
当 API 命中数较小时，没有问题，但当它很大时，更新余额会在该行上创建一个锁，其他 API 必须等待处理。
我正在考虑将此 table 移动到某个缓存或内存数据库中，以便我可以加快此过程。
早些时候我想到了 Memcache，但它是不稳定的，所以在搜索时，我了解了 Redis。
但是我很困惑，我的问题会不会被这个解决？
对于不同的键，从 Redis 中获取数据可能很快，因为它只保存在 memory/RAM 中，但是如果 same/single 键有数千个更新和搜索查询，它将如何工作。
如果您对此有任何知识或经验，或者如果有人对我的问题有比 Redis 更好的解决方案，请提供帮助。
redis 背后的人们肯定声称拥有那种速度。但是，redis 也是 'volatile' 所以如果那是导致您放弃 memcache 的原因，那么 redis 有什么不同？它也没有持久层。
您可以寻找具有 MVCC（乐观并发模型）的内存数据库，以避免 read/write/delete 任务阻塞读取器。您可以通过使用 NVDIMM（如果您的服务器足够现代并且您选择的 IMDB 支持在 NVDIMM 中恢复数据库的能力）或复制来缓解波动性问题。
简而言之，是的，Redis 会完成您想要做的事情。它可以handle very high throughput, can be configured to be persistent, and you can set it up in an HA manner with Sentinel。让它在一分钟内处理数千个 API 呼叫应该完全没有问题。
也就是说，这也不是绝对必要的。如果您可以在用户用完信用时向用户声明几秒钟的延迟，我还建议缓存每个框的 API 调用次数，然后刷新到数据库（Redis 或 MySQL) 每隔几秒，在此期间每个盒子的积分总数 used/added。 Adding/subtracting 这些数字应该是幂等的，每隔几秒刷新一次就可以解决您的主要问题，即无法随机处理意外的大量 MySQL 命中。
所以，这里有一些不错的选择。选择最适合您的用例的那个。
我有一个应用程序，可用于 API 调用。在每次 API 通话中，我都会执行一些任务并为此收费（可以发送邮件或短信或任何此类内容）。
目前我将我的用户 balance/credit 数据保存在 MYSQL table 中，格式如下：
|user|balance|
|a |1200 |
|b |1200 |
|c |1300 |
|d |1400 |
|e |1212 |
|f |9000 |
|g |8000 |
|h |7000 |
但是，当单个用户每分钟点击数千次 API 时，就会产生问题。每次 API 我都会更新用户的余额，如果余额不足，我会 return 出错。
当 API 命中数较小时，没有问题，但当它很大时，更新余额会在该行上创建一个锁，其他 API 必须等待处理。
我正在考虑将此 table 移动到某个缓存或内存数据库中，以便我可以加快此过程。
早些时候我想到了 Memcache，但它是不稳定的，所以在搜索时，我了解了 Redis。
但是我很困惑，我的问题会不会被这个解决？
对于不同的键，从 Redis 中获取数据可能很快，因为它只保存在 memory/RAM 中，但是如果 same/single 键有数千个更新和搜索查询，它将如何工作。
如果您对此有任何知识或经验，或者如果有人对我的问题有比 Redis 更好的解决方案，请提供帮助。
redis 背后的人们肯定声称拥有那种速度。但是，redis 也是 'volatile' 所以如果那是导致您放弃 memcache 的原因，那么 redis 有什么不同？它也没有持久层。
您可以寻找具有 MVCC（乐观并发模型）的内存数据库，以避免 read/write/delete 任务阻塞读取器。您可以通过使用 NVDIMM（如果您的服务器足够现代并且您选择的 IMDB 支持在 NVDIMM 中恢复数据库的能力）或复制来缓解波动性问题。
简而言之，是的，Redis 会完成您想要做的事情。它可以handle very high throughput, can be configured to be persistent, and you can set it up in an HA manner with Sentinel。让它在一分钟内处理数千个 API 呼叫应该完全没有问题。
也就是说，这也不是绝对必要的。如果您可以在用户用完信用时向用户声明几秒钟的延迟，我还建议缓存每个框的 API 调用次数，然后刷新到数据库（Redis 或 MySQL) 每隔几秒，在此期间每个盒子的积分总数 used/added。 Adding/subtracting 这些数字应该是幂等的，每隔几秒刷新一次就可以解决您的主要问题，即无法随机处理意外的大量 MySQL 命中。
所以，这里有一些不错的选择。选择最适合您的用例的那个。