SpringBoot micro electric service providers to develop practical projects avalanche --- Redis cache, the cache penetrate the cache to prevent breakdown

Has recently launched quite a few SpringBoot + Dubbo + Redis + Kafka's electrical article, today returned to service once again distributed micro-projects in the past, before the start of a series of five articles written today, my first review under the previous content.

Series (a): The main use of IDEA, said the creation of SpringBoot project, the basic Maven project dependent on Web and Its Implementation in SpringBoot architecture.

Series (B): Major topics of the Maven project to create a parent-child dependent, sub-deployment configuration environment and port services unified configuration, integrated access Dubbo, the service layer (provider) sub-module implementation provider (four) and consumption by (a) configuration and service calls, micro-ground service implementation.

Series (three): start talking about the project and dependent on the version number of the unified configuration management (sub-modules and third-party dependent Jar), connect to the database configuration and Redis access, distributed cache implementation.

Series (four): Interface to achieve security (anti-malicious requests, data tampering, etc.), filter configuration and signature, token intercept test, Aop signature implementation, anti-SQL injection.

The time and learning, not a pleasure. As I launched this series of articles, the purpose is very simple purpose to help small partners who understand the development of micro-distributed service landing. The current IT market, the development of micro-distributed service floor has become mainstream. SpringBoot, Dubbo, Zookeeper, Redis, Kafka, SpringCloud, etc. are also often asked interview topic, if you want to diving in this industry, which is already a basic technical knowledge you need to learn, and then I will run my last two years distributed micro-services development experience to introduce more articles. But in front of or next article said that if there is less than a place, but also hope that many instructions AC (alternating current micro letter I may add), prompted us to grow and progress together, a qualified technician.

Today I want to say is content access and security Kafka Redis cache implementation. Such as: penetrating cache, and cache avalanche breakdown of how to solve? Cache server is down or restarted, the cache data will not be lost and other issues. We take these issues into the topic.

Redis Cache security

Redis project uses a distributed cache, greatly enhance the performance and efficiency of applications, especially in terms of data query. But at the same time, it also brings some problems. The most crucial issue is the consistency of the data, in the strict sense, this problem has no solution. If the conformance requirements of data is high, you can not use the cache. In addition some of the typical questions that penetrate the cache, the cache and cache avalanche breakdown.

|| cache penetration

Cache penetration, refers to certain data query a database does not exist. Normal use caching process generally, data query to cache queries, if there is no key or key has expired, then query the database, and the query to the object into the cache. If the database query object is empty, the cache is not putting them in. If the user initiates data id "-1" id particularly large or nonexistent. At this time is likely to be the attacker, the attacker can cause excessive pressure on the database.

solution:

1, the interface layer increases checksum. Id foundation for verification, id <= 0 direct interception;

2, taken not from the cache data, in the database does not get to this time may be the key to the key-value written as key-null, the cache valid time point can be set short as 60 seconds (set too long It will lead normal circumstances would not be able to use), which can prevent attacks repeatedly use the same user id violent attacks.

|| cache avalanche

Cache avalanche, refers to a certain period of time, centralized cache expired. One of the causes avalanches, such as immediately to 618, and will soon usher in a wave of panic buying, to buy these commodities at the same time points (17, 23 points put) are concentrated into the cache assumptions cache for two hours. So that by the time one o'clock in the morning, the cache on these commodities have expired. At a time when access to these commodities questioned, who fell to the database, then for the database, it will bring great pressure.

solution:

1, in the setting data cache lifetime, after time plus a random factor.

2, the dispersion cache expiration time, the data cache popular class bit longer, shorter popular class.

3, set the hot data never expires.

|| Cache breakdown

缓存击穿,是指一个key非常热点,高并发集中对这个点进行访问,当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像春运期间火车站售票大厅,本来那些设在门口和广场的自助机可以办理售票,结果自助机瞬间全部瘫痪,造成大量买票的人涌进售票大厅人工窗口。

解决方案:

1,设置热点数据永远不过期;

2,加互斥锁,互斥锁参考代码如下:

|| 缓存数据持久化

Redis提供了将数据定期自动持久化至硬盘的能力,包括RDB和AOF两种方案,两种方案分别有其长处和短板,可以配合起来同时运行,确保数据的稳定性。

RDB

RDB方式是一种快照式的持久化方法,将某一时刻的数据持久化到磁盘中。并在启动时自动加载rdb文件,恢复之前保存的数据。可以在配置文件中配置Redis进行快照保存的时机:

save [seconds] [changes]

例如:save 60 100, 会让Redis每60秒检查一次数据变更情况,如果发生了100次或以上的数据变更,则进行RDB快照保存。可以配置多条save指令,让Redis执行多级的快照保存策略。Redis默认开启RDB快照。

AOF

采用AOF持久方式时,Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时,会把AOF文件中记录的所有写操作顺序执行一遍,确保数据恢复到最新。AOF默认是关闭的,如要开启,进行如下配置:

appendonly yes

  • AOF提供了三种fsync配置,always/everysec/no,通过[appendfsync]指定:appendfsync no:不进行fsync,将flush文件的时机交给OS决定,速度最快;

  • appendfsync always:每写入一条日志就进行一次fsync操作,数据安全性最高,但速度最慢;

  • appendfsync everysec:折中的做法,交由后台线程每秒fsync一次;

推荐阅读:

Spring Boot实现分布式微服务开发实战系列(四)

Spring Boot实现分布式微服务开发实战系列(三)

Spring Boot实现分布式微服务开发实战系列(二)

Spring Boot实现分布式微服务开发实战系列(一)

获取项目源代码,请扫码关注公众号,并发送Springboot获取。

 

Guess you like

Origin www.cnblogs.com/lyn20141231/p/11210278.html