Redis之缓存一致性

Redis之缓存一致性

  • 1 缓存更新策略
    • 1.1 内存淘汰
    • 1.2 过期删除
    • 1.3 主动更新
    • 1.4 三种缓存更新策略的对比
  • 2 更新缓存的两种方式
  • 3 缓存更新策略的实现方式
    • 3.1 先更新DB，后更新缓存
    • 3.2 先更新DB，后删除缓存
    • 3.3 先更新缓存，后更新DB
    • 3.4 先删除缓存，后更新DB
    • 3.5 延迟双删
    • 3.6 异步删除缓存
      • 3.6.1 基于消息队列的异步删除缓存
      • 3.6.2 基于MySQL的bin log+消息队列删除缓存
      • 3.6.3 异步删除缓存的优缺点
      • 3.6.4 基于 阿里canal实现
    • 3.7 几种实现方式的对比

1 缓存更新策略

按照缓存更新的方式大致分为： 内存淘汰、过期删除、主动更新。

1.1 内存淘汰

利用Redis的内存淘汰策略，当内存不足时自动进行淘汰部分数据，下次查询时更新缓存，一致性差，无维护成本。

因为Redis是基于内存的，如果内存超过限定值(Redis配置文件的maxmemory参数决定Redis最大内存使用量)，导致新的数据存不进去，此时Redis会根据淘汰策略删除一些数据。

淘汰策略由Redis配置文件的maxmemory-policy参数决定设置，默认为noeviction模式。

淘汰策略的执行过程：

  • 执行写请求时，Redis会检查内存使用情况，内存使用超过限定值，按照淘汰策略删除key。
  • Redis写入新数据。

具体的淘汰策略：redis.windows-service.conf中可以查到

  1. noeviction：默认策略，当写入新数据后的内存超过限定值时，写请求直接返回错误，只读请求可以正常执行。
  2. allkeys-lru：当写入新数据后的内存超过限定值时，从所有key中使用LRU算法（最近最少使用算法）淘汰最久没有使用过的key。
  3. volatile-lru：当写入新数据后的内存超过限定值时，从设置了过期时间的key中使用LRU算法淘汰最久没有使用过的key。
  4. allkeys-random：当写入新数据后的内存超过限定值时，从所有key中随机淘汰key。
  5. volatile-random：当写入新数据后的内存超过限定值时，从设置了过期时间的key中随机淘汰key。
  6. volatile-ttl：当写入新数据后的内存超过限定值时，从设置了过期时间的key中根据过期时间淘汰key，越快过期越早淘汰。
  7. allkeys-lfu：当写入新数据后的内存超过限定值时，从所有key中使用LFU算法（最少频率访问算法）淘汰使用频率最低的key。
  8. volatile-lfu：当写入新数据后的内存超过限定值时，从设置了过期时间的key中使用LFU算法淘汰使用频率最低的key。

1.2 过期删除

缓存添加过期时间，到期后根据过期删除策略自动进行删除缓存，下次查询时更新缓存，一致性一般，维护成本低。

  1. 定时删除：key设置了过期时间，一旦过期立即删除。
    • 优点：key一旦过期就会立即删除，不会占用内存。
    • 缺点：过期key较多时，删除key会占用CPU时间，影响服务器的响应时间，吞吐量，性能。
  2. 惰性删除：过期key不会马上被删除，而是继续保存在内存中，当key被访问时检查key的过期时间，若已过期则删除。
    • 优点：只在访问时才会对检查key的过期时间，没使用的key不会占用CPU的时间去检查过期时间，不会影响服务器的响应时间，吞吐量，性能。
    • 缺点：没有被访问的过期key继续保存在内存中，导致内存不会被释放，消耗内存资源。
  3. 定期删除：每隔一段时间(时间可以自行设置，Redis配置文件的hz参数表示1s执行多少次定期删除策略，默认值10)，随机抽取设置了过期时间的key检查它们的过期时间，删除已过期的key。
    • 优点：可以指定频率来减少删除操作对CPU性能的影响，定期删除也能释放没有被访问的过期key占用的内存。
    • 缺点：频率高影响CPU的性能，频率低过期key占用的内存不会及时释放。

1.3 主动更新

应用程序中修改DB，修改缓存，一致性好，维护成本高。

主动更新大致分为： Cache Aside Pattern、Read/Write Through Pattern、Write Behind Caching Pattern。

  1. Cache Aside Pattern：即旁路缓存模式，旁路路由策略，最经典常用的缓存策略。由应用程序负责缓存和DB的读写。读写操作步骤：
    • 读操作时，先读缓存，缓存存在直接返回；缓存不存在则读DB，然后把读的DB数据存入缓存，返回。
    • 写操作时，先更新DB，再删除缓存。
  2. Read/Write Through Pattern：即读写穿透模式，该模式下应用程序只与缓存管理组件交互，缓存管理组件负责缓存和DB的读写。
    • Read Through：读操作时，缓存管理组件先读缓存，缓存存在直接返回；缓存不存在则读DB，然后把读的DB数据存入缓存，返回。
    • Write Through：写操作时，缓存管理组件同步更数DB和缓存。
  3. Write Behind Caching Pattern：即异步缓存写入，该模式下应用程序只与缓存管理组件交互操作，缓存管理组件负责缓存和DB的读写，通过定时或阈值的异步方式将数据同步到DB，保证最终一致。该模式和Read/Write模式相似，不同点在于Read/Write模式更新DB和更新缓存是同步的，而Write Behind Caching Pattern模式更新DB和更新缓存是异步的。
    • 优点：减少了更新DB的频率，读写响应非常快，吞吐量也会有明显的提升。
    • 缺点：不能实时同步，数据同步DB过程服务不可用，导致数据丢失。

三种主动更新策略的对比：

策略说明优点缺点
Cache Aside Pattern应用程序负责缓存和DB的读写使用简单，直接操作缓存和DB需要编写对缓存和DB读写的代码
Read/Write Through Pattern应用程序只与缓存管理组件交互，缓存管理组件负责缓存和DB的读写使代码更简洁缓存管理组件需要提供对DB和缓存读写的方法
Write Behind Caching Pattern应用程序只与缓存管理组件交互，缓存管理组件负责缓存和DB的读写性能最好，在高并发场景下可以降低数据库的压力缓存管理组件，需要提供对DB和缓存读写的方法；
不能实时同步，数据同步DB过程DB不可用，导致数据丢失；
一致性不强，对一致性要求高的系统不适用

1.4 三种缓存更新策略的对比

策略说明一致性维护成本
内存淘汰使用Redis的内存淘汰策略，当内存不足时自动进行淘汰部分数据，下次查询时更新缓存差无
过期删除缓存添加过期时间，到期后根据过期删除策略自动进行删除缓存，下次查询时进行更新缓存低低
主动更新修改数据库时也修改缓存，使用硬编码方式或者硬编码+中间件方式在修改数据库时同步或异步的修改缓存好高

2 更新缓存的两种方式

  1. 删除缓存：更新DB时删除缓存，查询时再从DB中读取数据并更新到缓存。
  2. 更新缓存：更新DB时更新缓存，频繁更新缓存开销大，且并发时可能导致请求读取的缓存数据是旧数据。

3 缓存更新策略的实现方式

3.1 先更新DB，后更新缓存

1 并发写场景
所有线程都是先更新DB再更新缓存，在某个写线程更新DB后继续更新缓存时，可能因为网络原因出现延迟，这时其他写线程也更新了DB和缓存，导致缓存和DB数据不一致。

具体步骤：

  1. 线程1更新DB
  2. 线程2更新DB
  3. 线程2更新缓存
  4. 线程1更新缓存

总结：
理论上先更新DB的线程理应也会先更新缓存，但是并发场景下线程的执行顺序无法保证：

  • 若更新缓存的顺序是： 先线程1再线程2，则不会出现数据不一致问题。
  • 若更新缓存的顺序是： 先线程2再线程1，此时缓存是线程1的数据，DB是线程2的数据，导致缓存和DB数据不一致。

2 并发读写场景
在写线程更新DB和更新缓存之间，读线程可以获取到旧数据，但最终会一致。
具体步骤：

  1. 线程1更新DB
  2. 线程2查询，命中缓存返回
  3. 线程1更新缓存

总结：
线程2获取的缓存是旧数据，但最终都会一致。

3.2 先更新DB，后删除缓存

1 并发写场景
所有线程都是先更新DB再删除缓存，无论哪个线程先更新DB再删除缓存，缓存都会被删除，不会导致缓存和DB数据不一致。

具体步骤：

  1. 线程1更新DB
  2. 线程2更新DB
  3. 线程2删除缓存
  4. 线程1删除缓存

总结：
无论哪个线程先更新DB再删除缓存，缓存都会被删除，不会导致缓存和DB数据不一致。

2 并发读写场景
在写线程更新DB再删除缓存之间，读线程可以获取到旧数据，但最终会一致。

具体步骤：

  1. 线程1更新DB
  2. 线程2查询命中缓存返回
  3. 线程1删除缓存

总结：
线程2获取的缓存是旧数据，但后续最终都会一致。

3.3 先更新缓存，后更新DB

1 并发写场景
所有线程都是先更新缓存再更新DB，在某个写线程更新缓存和更新DB之间，其他写线程也更新了缓存和DB，导致缓存和DB数据不一致。

具体步骤：

  1. 线程1更新缓存
  2. 线程2更新缓存
  3. 线程2更新DB
  4. 线程1更新DB

总结：理论上先更新缓存的线程也会先更新DB，但是并发场景下线程的执行顺序无法保证：

  • 若更新DB的顺序是： 线程1再线程2，则不会出现数据不一致问题。
  • 若更新DB的顺序是： 线程2再线程1，此时缓存是线程2的数据，DB是线程1的数据，导致缓存和DB数据不一致。

2 并发读写场景
在写线程更新缓存和更新DB之间，读线程也可以获取到最新的缓存，不会导致缓存和DB数据不一致。

具体步骤：

  1. 线程1更新缓存
  2. 线程2查询，命中缓存返回
  3. 线程1更新DB

总结：
可以保证缓存和DB数据一致，虽然线程1更新DB的操作还没有完成，但是更新缓存的操作已经完成了，读请求可以获取到最新的缓存。

3.4 先删除缓存，后更新DB

1 并发写场景
所有线程都是先删除缓存再更新DB，无论哪个线程先删除缓存再更新DB，缓存都会被删除，不会导致缓存和DB数据不一致。

具体步骤：

  1. 线程1删除缓存
  2. 线程2删除缓存
  3. 线程2更新DB
  4. 线程1更新DB

总结：
无论哪个线程先删除缓存再更新DB，缓存都会被删除，不会导致缓存和DB数据不一致。

2 并发读写场景
在写线程删除缓存和更新DB之间，读线程根据查询的DB结果更新了缓存，导致缓存和DB数据不一致。

具体步骤：

  1. 线程1删除缓存
  2. 线程2查询，未命中
  3. 线程2查询DB
  4. 线程2根据查询的DB结果更新缓存
  5. 线程1更新DB

总结：
线程1删除缓存和更新DB之间，线程2根据查询的DB结果更新了缓存，导致缓存和DB数据不一致。

3.5 延迟双删

因为3.4 先删除缓存，再更新DB，在并发读写场景会导致数据不一致。
延迟双删是基于先删除缓存再更新DB的基础上的改进，在更新DB后延迟一定时间，再次删除缓存。

延迟是为了保证第二次删除缓存前能完成更新DB操作，延迟时间根据系统的查询性能而定。
第二次删除缓存是为了保证后续请求查询DB(此时数据库中的数据已是更新后的数据)，重新写入缓存，保证数据一致性。

1 并发写场景
无论哪个线程都会删除缓存，所以不会导致缓存和DB数据不一致。

具体步骤：

  1. 线程1删除缓存
  2. 线程2删除缓存
  3. 线程2更新DB
  4. 线程1更新DB
  5. 线程1延时删除缓存
  6. 线程2延时删除缓存

2 并发读写场景
具体步骤：

  1. 线程1删除缓存
  2. 线程2查询，未命中
  3. 线程2查询DB
  4. 线程2根据查询的DB结果更新缓存
  5. 线程1更新DB
  6. 线程1延时删除缓存

总结：
线程1第一次删除缓存之后，线程2根据查询的DB结果更新缓存，此时查询得到的结果是旧数据，线程1延迟第二次删除缓存之后，后续查询DB(此时数据库中的数据已是更新后的数据)，重新写入缓存，不会导致缓存和DB数据不一致。

3 延时双删的缺点：

  1. 需要延时，低延时场景不合适，如秒杀等需要低延时，需要强一致，高频繁修改数据场景。
  2. 不能保证强一致性，在更新DB之前，查询线程查询得到的结果是旧数据，可但可以减轻缓存和DB数据不一致的问题。
  3. 延时的时间是一个不可评估的值，延时越久，能规避一致性的概率越大。

3.6 异步删除缓存

因为3.2 先更新DB，后删除缓存 在并发写场景不会导致数据不一致，但是在并发读写场景会短暂的导致数据不一致，但是由于删除缓存失败不会重试，并发写场景、并发读写场景都可能长时间导致数据不一致。

异步删除缓存是对先更新DB，后删除缓存的改进：更新DB之后，基于消费队列异步删除缓存。

根据消费队列不同大致分为：消息队列、bin log+消息队列。

3.6.1 基于消息队列的异步删除缓存

1 并发写场景
无论哪个线程先更新DB再删除缓存，缓存都会被删除，不会导致缓存和DB数据不一致。

具体步骤：

  1. 线程1更新DB
  2. 线程2更新DB
  3. 线程2把删除缓存放入消息队列
  4. 线程1把删除缓存放入消息队列
  5. 异步：消息队列消费删除缓存

总结：
无论哪个线程先更新DB再删除缓存，缓存都会被删除，不会导致缓存和DB数据不一致。

2 并发读写场景
异步删除缓存期间，读线程获取的缓存是旧数据，短暂出现数据不一致，异步删除缓存后最终会一致。

具体步骤：

  1. 线程1更新DB
  2. 线程2查询缓存，命中返回
  3. 线程1把删除缓存放入消息队列
  4. 异步：消息队列消费删除缓存

总结：
异步删除缓存期间，读线程获取的缓存是旧数据，短暂出现数据不一致，异步删除缓存后最终会一致。

3.6.2 基于MySQL的bin log+消息队列删除缓存

1 并发写场景

具体步骤：

  1. 线程1更新DB
  2. 线程2更新DB
  3. 异步：bin log日志收集中间件定时收集DB的bin log日志
  4. 异步：bin log日志收集中间件发送日志消息到消息队列
  5. 异步：消息队列消费删除缓存

总结：
无论哪个线程先更新DB再删除缓存，缓存都会被删除，不会导致缓存和DB数据不一致。

–
2 并发读写场景
具体步骤：

  1. 线程1更新DB
  2. 线程2查询缓存，命中返回
  3. 异步：bin log日志收集中间件定时收集DB的bin log日志
  4. 异步：bin log日志收集中间件发送日志消息到消息队列
  5. 异步：消息队列消费删除缓存

总结：
异步删除缓存期间，读线程获取的缓存是旧数据，短暂出现数据不一致，异步删除缓存后最终会一致。

3.6.3 异步删除缓存的优缺点

优点：

  1. 删除缓存的操作与主流程代码解耦。
  2. 中间件自带重试机制，增加了操作缓存的成功率。

缺点：
引入中间件，提升了系统的复杂度，在高并发场景可能会产生性能问题。

3.6.4 基于 阿里canal实现

canal是阿里开发的基于数据库增量日志解析，提供增量数据的订阅和消费，目前主要支持MySQL的bin log解析。基于canal的实现方案完全避免了对业务代码的侵入，核心业务代码只管更新数据库，其他的不用care。

canal地址：https://github.com/alibaba/canal

MySQL会将操作记录在bin log日志中，通过canal去监听数据库日志二进制文件，解析bin log日志，同步到Redis中进行增删改操作。

canal的工作原理：canal是模拟MySQL slave的交互协议，伪装自己为MySQL slave，向MySQL master发送dump协议；MySQL master收到dump请求，开始推送bin log给slave (即canal)；canal解析bin log象(原始为byte流)。
在这里插入图片描述

3.7 几种实现方式的对比

参看：redis之缓存一致性 最后一部分

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/155266.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

【数据结构C/C++】稀疏矩阵的压缩

【数据结构C/C++】稀疏矩阵的压缩

文章目录 什么是稀疏矩阵？使用C语实现对稀疏矩阵的压缩408考研各数据结构C/C代码（Continually updating） 什么是稀疏矩阵？ 稀疏矩阵（Sparse Matrix）是一种矩阵，其中大多数元素都是零。与稠密矩…
阅读更多...
蓝桥杯 使用sort排序（c++）

蓝桥杯 使用sort排序（c++）

sort是一个C已经为我们实现好的工具&#xff0c;当我们要用它时&#xff0c;需要先引入一个算法的库—— < algorithm >。需要说明的是&#xff0c;sort可以排序任何类型的元素&#xff0c;包括我们自己定义的结构体。 我们将需要在C文件的开始位置加上&#xff1a; #in…
阅读更多...
C++: 继承

C++: 继承

学习目标 1.继承的概念及定义 2.基类和派生类对象赋值转换(切片) 3.继承中的作用域(隐藏/重定义) 4.派生类的默认成员函数 5.继承与友元 6.继承与静态成员 7.菱形继承与菱形虚拟继承 8.总结 1.继承的概念及定义 1.1概念 继承: 它允许你创建一个新的类&#xff08;称为子类或派…
阅读更多...
【pytorch】模型的保存与加载|| Dataloader数据加载器

【pytorch】模型的保存与加载|| Dataloader数据加载器

Pytorch模型保存与加载&#xff0c;并在加载的模型基础上继续训练 系统学习Pytorch笔记三&#xff1a;Pytorch数据读取机制(DataLoader)与图像预处理模块(transforms) 一、只保存参数 1. 保存 一般地&#xff0c;采用一条语句即可保存参数&#xff1a; torch.save(model.s…
阅读更多...
Docker系列--网络的配置

Docker系列--网络的配置

原文网址&#xff1a;Docker系列--网络的配置_IT利刃出鞘的博客-CSDN博客 简介 说明 本文介绍Docker的网络的配置。 官网网址 https://docs.docker.com/engine/reference/commandline/network/ 网络的默认设置 Docker启动之后&#xff0c;系统中会产生一个名为docker0的…
阅读更多...
开发者职场“生存状态”大调研报告分析 - 第一版

开发者职场“生存状态”大调研报告分析 - 第一版

听人劝、吃饱饭，奉劝各位小伙伴，不要订阅该文所属专栏。 作者：不渴望力量的哈士奇(哈哥)，十余年工作经验, 跨域学习者，从事过全栈研发、产品经理等工作，现任研发部门 CTO 。荣誉：2022年度博客之星Top4、博客专家认证、全栈领域优质创作者、新星计划导师，“星荐官共赢计…
阅读更多...
iOS 获取模拟器沙盒路径

iOS 获取模拟器沙盒路径

xcrun simctl get_app_container booted Bundle Identifier data
阅读更多...
C# redis通过stream实现消息队列以及ack机制

C# redis通过stream实现消息队列以及ack机制

redis实现 查看redis版本 redis需要>5.0 Stream 是 Redis 5.0 引入的一种专门为消息队列设计的数据类型&#xff0c;Stream 是一个包含 0 个或者多个元素的有序队列&#xff0c;这些元素根据 ID 的大小进行有序排列。 它实现了大部分消息队列的功能&#xff1a; 消息 ID…
阅读更多...
TensorFlow入门(二十、损失函数)

TensorFlow入门(二十、损失函数)

损失函数 损失函数用真实值与预测值的距离指导模型的收敛方向,是网络学习质量的关键。不管是什么样的网络结构,如果使用的损失函数不正确,最终训练出的模型一定是不正确的。常见的两类损失函数为:①均值平方差②交叉熵 均值平方差 均值平方差(Mean Squared Error,MSE),也称&qu…
阅读更多...
Vue思考题_01v-for与v-if的优先级谁更高

Vue思考题_01v-for与v-if的优先级谁更高

目录 vue2vue3 官方文档上说不推荐将v-for与v-if在同一个标签上使用&#xff0c;因为两者优先级并不明显。 那么到底是那个指令的优先级比较高呢&#xff1f; 在vue2与vue3中答案是相反的。 vue2 在vue2中将2个指令放在同一个标签上 <template><ul><li v-fo…
阅读更多...
Vue3中reactive, onMounted, ref,toRaw,conmpted 使用方法

Vue3中reactive, onMounted, ref,toRaw,conmpted 使用方法

import { reactive, onMounted, ref,toRaw,conmpted } from vue; vue3中 reactive &#xff0c;ref &#xff0c; toRaw&#xff0c;watch&#xff0c;conmpted 用法 toRaw 返回原响应式对象 用法&#xff1a; const rowList toRaw(row) reactive:ref: ref和reactive都是V…
阅读更多...
关于链表指针的深刻理解

关于链表指针的深刻理解

以下列代码为例 //终于给我搞清楚指针的指向究竟是怎么看的了// 按编号对职工记录进行递增排序 void sortById(List* list) {Employee* p, * q, * tail NULL;// tail 变量则是一个边界指针&#xff0c;初始值为 NULL。while (list->head->next ! tail) // tail 变量则是…
阅读更多...
【通信系列 1 -- GSM 和 LTE】

【通信系列 1 -- GSM 和 LTE】

文章目录 1. LTE(Long Term Evolution)1.1 FDD&TDD简介1.1.1 3G与4G差异1.1.2 频点与band关系1.1.3 band 与运营商的关系 1.2 TDD&FDD区别1.2.1 FDD帧结构1.2.2 TDD帧结构1.2.3 TDD&FDD优势对比1.2.4 TDD缺点 1.3 VoLTE1.3.1 VoLTE 优点11.3.2 VoLTE 优点21.3.3 Vo…
阅读更多...
【ARM Coresight 系列文章19 -- Performance Monitoring Unit（性能监测单元）

【ARM Coresight 系列文章19 -- Performance Monitoring Unit（性能监测单元）

文章目录 1.1 PMU 介绍1.2 PMU 寄存器1.2.1 PMU 管理寄存器1.2.2 PMU 外设识别寄存器1.2.3 PMU 组件识别寄存器1.3 性能监控事件1.3.1 Cortex-A9 特定事件1.1 PMU 介绍 许多体系结构都包含 PMU（Performance Monitoring Unit）硬件，用于跟踪、计数系统内部的一些底层硬件事件…
阅读更多...
MySql运维篇---009：分库分表：垂直拆分、水平拆分、通过MyCat进行分片，读写分离：一主一从、 双主双从

MySql运维篇---009：分库分表：垂直拆分、水平拆分、通过MyCat进行分片，读写分离：一主一从、 双主双从

3.分库分表 3.1 介绍 3.1.1 问题分析 使用单个数据库存储所有的数据&#xff0c;如果磁盘和内存和内存不足了可以增大磁盘和内存&#xff0c;但是对于一台服务器的磁盘和内存不可能无限制的扩张下去&#xff0c;它是受我们服务器的硬件影响的&#xff0c;如果说数据库所存储…
阅读更多...
mp4音视频分离技术

mp4音视频分离技术

文章目录 问题描述一、分离MP3二、分离无声音的MP4三、结果 问题描述 MP4视频想拆分成一个MP3音频和一个无声音的MP4文件 一、分离MP3 ffmpeg -i C:\Users\Administrator\Desktop\一个文件夹\我在财神殿里长跪不起_完整版MV.mp4 -vn C:\Users\Administrator\Desktop\一个文件…
阅读更多...
机器学习之自训练协同训练

机器学习之自训练协同训练

前言 监督学习往往需要大量的标注数据&#xff0c; 而标注数据的成本比较高 &#xff0e; 因此 &#xff0c; 利用大量的无标注数据来提高监督学习的效果有着十分重要的意义&#xff0e; 这种利用少量标注数据和大量无标注数据进行学习的方式称为 半监督学习 &#xff08; Semi…
阅读更多...
Java进击框架：Spring-Bean初始化过程（五）

Java进击框架：Spring-Bean初始化过程（五）

Java进击框架&#xff1a;Spring-Bean初始化过程&#xff08;五&#xff09; 前言源码初始化配置加载Bean加载Bean对象加载Bean切面 Bean工厂后置处理器注册Bean后置处理器初始化消息源初始化应用程序事件多播器注册监听器完成Bean工厂初始化Bean初始化完成刷新应用上下文创建完…
阅读更多...
VSCODE+PHP8.2配置踩坑记录

VSCODE+PHP8.2配置踩坑记录

VSCODEPHP8.2配置踩坑记录 – WhiteNights Site 我配置过的最恶心的环境之一&#xff1a;windows上的php。另一个是我centos服务器上的php。 进不了断点 端口配置和xdebug的安装 这个应该是最常见的问题了。从网上下载完php并解压到本地&#xff0c;打开vscode&#xff0c;安装…
阅读更多...
【网路安全 --- Linux，window常用命令】网络安全领域，Linux和Windows常用命令，记住这些就够了，收藏起来学习吧！！

【网路安全 --- Linux，window常用命令】网络安全领域，Linux和Windows常用命令，记住这些就够了，收藏起来学习吧！！

一&#xff0c;Linux 1-1 重要文件目录 1-1-1 系统运行级别 /etc/inittab 1-1-2 开机启动配置文件 /etc/rc.local /etc/rc.d/rc[0~6].d## 当我们需要开机启动自己的脚本时&#xff0c;只需要将可执行脚本丢在 /etc/init.d 目录下&#xff0c;然后在 /etc/rc.d/rc*.d 中建…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023