I. Introduction
The last article was written 2 weeks ago. I have been a bit lazy recently. I was originally reluctant to write this article, but after paying attention to the data in the past two days, I found that I have gained 4 fans in the new year. First of all, thank you all. I will try my best to write more in the future. This article talks about the problems encountered during testing in our microservice reconstruction project today. We have a function to put products on and off the shelves. When the switch button is clicked, the products are set to be put on the shelves, but the front-end page still shows the off-shelf status. Here Two interfaces are called, one interface updates the status (product database DB, product ES), and then immediately calls the query interface (using ES). It is found that the returned data is still in the off-shelf status, but at this time, go to the Kinaba console to check the status. It's already on the shelves.
2. Cause of the problem
When ES performs a write operation, it will first cache a piece of data in the memory, and then adopt a certain strategy to write the data to the disk. This process is called Refresh. Each Refresh will generate a new Lucene segment, but too many segments will cause problems. It will consume file handles and memory, so there are certain strategies to merge these smaller segments into larger segments. The refreshed ES defaults to regular refresh every 1 second, so the data just written in is likely to be checked immediately. Not found.
3. Solution
1. Directly modify the ES refresh frequency
Note: This solution is not recommended for production environments, and it is difficult to determine the refresh time.
2. Force refresh after requesting the interface request
Note: ES8 syntax, including newly written data, changed data, and deleted data, has the problem that it will not be refreshed immediately.
4. ES update principle
