as we all know, Redis can be well used in data caching scenarios, which can greatly improve the read and write efficiency compared to MySQL.
however, I have found that many of the application scenarios advertised by Redis enthusiasts actually do not exist, or are not feasible.
for example, the following
Commodity second kill system
to put it simply, it means reducing inventory and increasing orders to complete a transaction. In this scenario, the problem to be solved is
- how can the server be snapped up by a large number of users without downtime in the case of high concurrency
- how to prevent overselling under high concurrent requests for limited goods
in this link, https://www.zhihu.com/questio.
@ Ali Yunqi community says, intercepting redundant requests layer by layer.
so when it comes to caching the number of remaining items, Redis is responsible for that layer.
but in fact, isn"t it possible for us to use a file to record the quantity of the remaining goods there? You can also cache the request for querying the number of remaining items for MySQL.
as for preventing overselling, this is MySQL"s specialty.
use a update goods set count=count-1 where id=x and count > 0; and then take the number of affected rows.
We can even put new orders and inventory reduction into the same transaction, and can prevent "underselling" (reducing inventory, but the program is interrupted without new orders) .
although in the actual test, my test results on a low-configuration VPS show that MySQL can only handle about 100 transactions per second, but we can allocate goods to 100 MySQL tables / instances to achieve tens of thousands of order processing per second.
I don"t use a high-end server. Maybe on a high-end server, a single MySQL instance can handle tens of thousands of transactions per second.
since MySQL can easily solve the typical application scenarios of Redis, what other application scenarios are there for Redis?