分类 linux 下的文章

Redis缓存有以下几种模式
一、Cache-Aside (旁路缓存)
Cache-Aside Pattern,也称为Lazy-Loading Pattern,是由应用程序负责直接从缓存中读取和写入数据。如果缓存未命中,应用程序将从数据库加载数据,并将其存储在缓存中以供未来使用

读取数据:
   ·应用程序首先查询缓存
   ·如果缓存命中,直接返回数据
   ·如果缓存未命中,应用程序从数据库查询数据,然后将数据存储在缓存中,并返回给用户
更新数据:
   ·应用程序直接更新数据库
   ·接着,应用程序移除或更新缓存中的相应数据

二、Read-Through (透读缓存)
Read-Through Pattern是由缓存层负责从数据源(如数据库)加载数据。当应用程序请求数据时,如果缓存中存在该数据,则直接返回;如果不存在,则缓存层负责从数据源加载数据,存入缓存,并返回给应用程序。
读取数据

    ·应用程序请求数据
    ·如果缓存命中,缓存层直接返回数据
    ·如果缓存未命中,缓存层从数据源加载数据,更新缓存

更新数据:

    ·应用程序更新数据源
    ·缓存层可以更新或删除缓存

三、Write-Through (透写缓存)
Write-Through Pattern是由应用程序在更新数据时同时更新缓存和后端数据源(如数据库)。这种策略确保了缓存和数据源之间的一致性,并减少了数据丢失的风险
更新数据:

    ·应用程序同时更新缓存和数据源
    ·这确保了缓存中的数据总是最新的,并与数据源保持一致

四、Write-Back / Write-Behind (写后缓存)
Write-Back / Write-Behind Pattern是由应用程序首先将数据写入缓存,然后再异步地更新后端数据源(如数据库)。这种策略可以减少对数据源的即时写操作,从而提高应用程序的性能,提升系统的TPS
更新数据:

    ·应用程序首先将数据写入缓存
    ·缓存系统异步地将数据更新到数据库

五、Write-Through-Back (透写后缓存)
Write-Through-Back Pattern是结合了Write-Through和Write-Back模式的缓存方法。在这种模式下,数据首先被写入缓存,然后立即异步地更新到数据库。这种模式旨在平衡写操作的即时性和减少对数据源的直接压力。注:Write-Back通常再写入缓存与数据库存在较大一段时间间隔,Write-Through-Back通常立即执行异步操作,能较大程度减少最终一致性时长
更新数据:

   ·应用程序首先将数据写入缓存
   ·然后,缓存系统异步地将数据更新到数据源

六、Refresh-Ahead (预刷新缓存)
Refresh-Ahead Pattern用于主动刷新即将过期的缓存项。在这种模式下,系统会监控数据的访问模式,并在缓存项接近过期时自动从数据源刷新数据。这有助于保持缓存数据的新鲜度,减少缓存未命中的情况,通常也可用于定时刷新不常用的数据减少RPC远程调用的开销
缓存刷新:

   ·系统监控缓存项的访问模式和过期时间
   ·当缓存项接近过期时,系统自动从数据源刷新数据,并更新缓存

七、Lazy-Loading (懒加载)
Lazy-Loading Pattern模式下,数据仅在首次请求时被加载到缓存中。当应用程序请求数据时,如果数据不在缓存中,则从数据源加载数据并将其存储在缓存中,注:其和Cache Aside Pattern的区别在于,后者是前者的一种实现,后者提供了更多控制缓存何时更新的灵活性,适用于需要精细管理数据一致性的场景,前者仅侧重于按需加载数据
读取数据:

   ·应用程序请求数据。
   ·如果缓存命中,返回缓存中的数据。 
   ·如果缓存未命中,从数据源加载数据,存入缓存,并返回数据

八、Write-Around (绕写缓存)
Write-Around Pattern下数据在更新时直接写入后端数据源(如数据库),而不是首先写入缓存。接着通过异步的方式再写入缓存。这种模式可以减少缓存中不常用数据的写入,从而节省缓存空间并提高缓存的有效性。
更新数据:

   ·应用程序直接更新数据源
   ·缓存不会立即更新,只有在数据被请求时才可能从数据源加载到缓存中

模式汇总图:

文章来源:https://blog.csdn.net/weixin_38522648/article/details/135175188

问题描述:今天收到腾讯云通知短信,服务器有多条异常登录,登录地址皆为国外ip
处理方式:
一、登录云服务器,找到防火墙先关闭tcp 22端口并修改服务器账号密码
二、查找恶意登录的前十个IP:

sudo lastb | awk '{ print $3}' | awk '{++S[$NF]} END {for(a in S) print a, S[a]}' | sort -rk2 |head

三、直接封掉ip

iptables -I INPUT -s 5.75.172.121 -j DROP
,如果不担心被误封,可以直接封掉ip段
iptables -I INPUT -s 5.0.0.0/8 -j DROP

四、开启防火墙

sudo systemctl start firewalld

五、修改tcp登录端口号,然后重启ssh服务

sudo vim /etc/ssh/sshd_config
sudo systemctl restart sshd.service

六、开放新端口

sudo firewall-cmd --add-port=xxx/tcp --permanent

六、在腾讯云防火墙里面新增自定义规则,加上刚才修改的端口ip

结论:如果服务器被暴力破解登录,可以尝试上述方式处理,当然,有条件的可以购买服务商的防护服务。

使用grep在指定文件中查找内容:

grep -nr 'wuliao' ./ | grep .php  

附grep参数说明
-i:忽略大小写
-v:只显示不匹配的行
-n:显示匹配行的行号
-c:统计匹配的行数
-r:递归搜索子目录
-E:使用扩展正则表达式
-F:禁用正则表达式,使用固定字符串匹配
-w:只匹配整个单词,而不是单词的一部分
-A:显示匹配行之后的若干行
-B:显示匹配行之前的若干行
-C:显示匹配行前后的若干行

今天在supervisor添加一个服务脚本,在服务器启动一段时间后,自动退出,并报错FATAL Exited too quickly (process log may have details),查看日志时,发现日志并没有错误信息,于是手动执行php artisan 命令,没有报错信息,但是发现脚本在执行后立即就退出了,考虑到supervisor在监测服务异常或者退出后,会自动尝试重启服务,应该是重启次数超过startretries重启次数,导致进程终止。

注:出现这个错误,可自行先检查一下自己的脚本是否为常驻脚本,如果每次只去一次数据,建议修改为定时任务来处理
附supervisor子进程相关配置信息


[program:sync_merge_mobile] #
command=php /var/www/yunying/artisan consumer:merge-mobile-kafka #执行命令
process_name=%(program_name)s_%(process_num)d
autostart=true #自启动
autorestart=true #自动重启
user=admin #启动时用户权限
numprocs=2 #开启进程数
numprocs_start=0 #起始数字,默认为0
redirect_stderr=true #把 stderr 重定向到 stdout,默认 false
stdout_logfile=/home/admin/yunying/kafka_sync_merge_mobile_%(process_num)08d.log #日志位置
loglevel=info #日志级别,默认info,其它: debug,warn,trace

问题描述:
因为业务需要使用rabbitmq进行数据通信,所以使用laravel搭建了服务,但是在部署到测试服务器后,服务器开始报错:

dev.ERROR: AMQP error while attempting pop: ACCESS_REFUSED - Login was refused using authentication mechanism AMQPLAIN. For details see the broker logfile.(0, 0)

看错误描述是rabbitmq拒绝普通用户登录,但是我账号是管理员权限,没有理由被拒绝,于是开始排查
排查过程:
1、因为推送消息通过守护进程方式执行的,首先去掉自己的服务脚本,然后执行supervisorctl reload,确认自己脚本未执行,此时查看日志,发现还有报错
2、因为是测试环境,然后停止supervisor,继续查看日志,发现日志没有报错,确定是某个脚本报错,然后逐一排查,最后确定是一个脚本也是用queue队列,于是查看代码,发现当前脚本并没有使用mq,但是为什么触发报错
3、继续查看自己的代码,突然想起在.env里面里面配置了rabbitmq相关配置,突然发现一段代码

QUEUE_DRIVER=rabbitmq

,查看queue.php,里面默认是redis,到此,基本确认问题,于是注释掉QUEUE_DRIVER,然后重新supervisor,日志再没有报错信息
总结:
因为代码是参考网上示例,直接复制的,没有注意到消息队列被改为rabbitmq,导致其他消息队列报错,在此记录一下。从网上查找的资源,需要在校验是否可用的同时,涉及到环境变量的内容一定要特别注意