Bypass the cache

Note that data is written to the database before the cache is deleted
- So why not update the cache instead of deleting it?
  - Think 1. If we updated the cache every time a write occurred to the database; If a scenario has a high number of database writes but a low number of queries, is it not necessary to update the cache every time there is a write? Would it not be more reasonable to delete the data and then go to the database and add it to the cache when there is a read request?
  - Consider 2. If we update the cache every time a write occurs to the database; Suppose the data in the cache is queried by a table or the SQL is complicated, so we check the DB every time we write the data and update the cache, right? Is it not necessary?
  - Summary: after writing to db, delete the cache. When a read request is added to the cache, it is essentially aLazyThe idea is that when I use it, when I read db and set it to cache, then I go to cache for the next read, then I delete the cache when I write to the database, and so on ~~~ ~.

The cache to penetrate

In this case, a client (usually a malicious attacker) deliberately bypasses a key that might exist in the cache and creates a key that does not existbypassCache, straight to DB. (bypassIs this word graphic??

1. Verify both the front and back ends. If the request does not meet the requirements, return the request directly
1. Caches user:-1 and returns the default value when accessing the key, but what if it passes user:-2,user:-3,user:-n? So let’s do the third method
1. Bloom filter, when the database is modified, take out the data splicing as key, synchronization to bloom filter. Every time a request comes in, check it. If it’s in the Bloom filter, it’s in the databaseIf bloom's filter tells you it doesn't, it definitely doesn't. Direct return
1. Maybe in some cases we don’t have a lot of data and we don’t want to suffer from a bloom filter, so we can use a hash structure to store the key and look it up in the hash every time we get a request.
1. Or we can use a bitMap similar to a hash, depending on the situation, but also need to be aware of the disadvantages of bitmaps. I’ll write about this bitmap in a future article.

When a request is made, the client (or a malicious attacker) deliberately queries only one key (or several keys) in the cache. These keys are in the cache, but if they are not, the request will be sent to your DB.It’s like shooting at A certain point on A’s body, and when A’s body armor fails, A’s body will be gg. (Maybe this example is not reasonable, let's assume that body armor also has an expiration date haha)

1. In fact, according to the cause of the breakdown we can think of 100000 requests all query for a data, (or a few data, in order to facilitate we assume 100000 request parameters are the same), then I have to add a distributed lock ah, now that you requested data are the same, that I only make a request to the db, you wait for a while, He updates the cache as soon as he’s done, so you can query the cache for all of your (99,999) requests.
1. Level 2 cache, but it’s one more cache to maintain, and it’s a little bit more complicated, and I think it’s a little bit less used but I haven’t used it yet.
1. Set the hotspot key to not expire. What is a hotspot key depends on the business.

As the name implies, the key in redis fails at the same time (like the collapse of snow mountain).Generally, the set expiration time is the same, or a batch of keys is cleared periodically, then the customer’s request at this moment will also be directly sent to our DB.

1. Delete keys in batches periodically
1. The hot key is always in Redis, and when it is updated (which needs to be determined by our business), it is good to update the hot key.
1. What if some keys are non-hot keys? Okay, so let’s just set a random value when we set the expiration time. Avoid avalanche problems caused by simultaneous failures

Well, that's the end of this article, ready for the next bitMap