我有一个应用程序，它适用于API调用。在每次 API 调用中，我都会执行一些任务并为其收费(可以是发送邮件或短信或任何类似的东西(。
目前，我将用户余额/信用数据以以下形式保存在MYSQL表中：
|user|balance|
|a |1200 |
|b |1200 |
|c |1300 |
|d |1400 |
|e |1212 |
|f |9000 |
|g |8000 |
|h |7000 |
但是，当单个用户每分钟点击数千个 API 时，这会产生问题。在每个 API 上，我都会更新用户的余额，如果没有足够的余额，我会返回一些错误.
当没有 API 命中数时，没有问题，但是当它很大时，更新余额会在该行上创建一个锁，其他 API 必须等待处理。
我正在考虑将此表移动到某个缓存或内存数据库，以便我可以快速完成此过程。
早些时候我想到了 Memcache，但它是易变的等等搜索，我读到了 Redis.
但是我很困惑，我的问题会因此而解决吗？至于不同的密钥，从 Redis 获取数据可能很快，因为它只保存在内存/RAM 中，但如果有数千个更新和搜索查询相同/单个密钥，它将如何工作。
如果您有这方面的任何知识或经验，或者如果有人比 Redis 有更好的解决方案，请分享，请提供帮助。
简而言之，是的，Redis将完成您想要做的事情。它可以处理非常高的吞吐量，可以配置为持久，并且您可以使用 Sentinel 以 HA 方式对其进行设置。让它每分钟处理数千次 API 调用的水平应该完全没有问题。
也就是说，这也不一定是绝对必要的。如果您愿意在用户用完积分时向用户声明时有几秒钟的延迟，我还建议您缓存每个框的 API 调用次数，并每隔几秒钟刷新到数据库(Redis 或 MySQL(在此期间每个框使用/添加的积分总量。添加/减去这些数字应该是幂等的，并且每隔几秒钟刷新一次应该可以解决您无法在随机时间处理意外大量MySQL命中的主要问题。
所以，你在这里有几个不错的选择。选择对您的用例最有意义的方法。
redis背后的人当然声称这种速度。 但是，redis也是"易变的"，所以如果这就是导致你放弃memcache的原因，那么redis有什么不同？ 它也没有持久性层。
您可以使用 MVCC(乐观并发模型(查找内存数据库，以避免读/写/删除任务阻塞读取器。 您可以通过使用 NVDIMM(如果您的服务器足够现代并且您选择的 IMDB 支持在 NVDIMM 中恢复数据库的功能(或复制来缓解波动性问题。