The problem of data loss can be solved through master-slave replication of redis. However, I think there are ways to reduce the risk and scope of data loss. Ticket grabbing is a typical high-concurrency scenario. You can consider only storing the ticket inventory information in the memory, and storing other information through a more reliable database.
Specific solution:
1. Redis enables master-slave replication and can use more than two slaves to solve single-point problems and load balancing when providing external read services;
2. As for the crashed data recovery solution, you can log out of the queue operation to record the log. If the service crashes, you can quickly restore the inventory through the log after restarting;
3. Solutions to reduce the risk of data loss. For example, use the queue data structure of redis to save the ticket inventory. If you successfully exit the queue, you will get the ticket. Then save the ticket grabbing relationship to the database, and then place the order & pay;
4. In actual use experience, the probability of redis crashing is low, but it is really troublesome to recover data after it crashes. So it’s best to look at the usage scenarios. If the data is very important, it is recommended to avoid placing it in the memory database as much as possible. It is better to implement the data.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Enable
AOF(append-only file).The problem of data loss can be solved through master-slave replication of redis. However, I think there are ways to reduce the risk and scope of data loss. Ticket grabbing is a typical high-concurrency scenario. You can consider only storing the ticket inventory information in the memory, and storing other information through a more reliable database.
Specific solution:
1. Redis enables master-slave replication and can use more than two slaves to solve single-point problems and load balancing when providing external read services;
2. As for the crashed data recovery solution, you can log out of the queue operation to record the log. If the service crashes, you can quickly restore the inventory through the log after restarting;
3. Solutions to reduce the risk of data loss. For example, use the queue data structure of redis to save the ticket inventory. If you successfully exit the queue, you will get the ticket. Then save the ticket grabbing relationship to the database, and then place the order & pay;
4. In actual use experience, the probability of redis crashing is low, but it is really troublesome to recover data after it crashes. So it’s best to look at the usage scenarios. If the data is very important, it is recommended to avoid placing it in the memory database as much as possible. It is better to implement the data.