有时候程序运行了很久就会打印特别多的日志，比如我们只需要保留近7天的日志文件其他的全部删除，该怎么操作呢？一个一个地删除太麻烦了，

下面编写个shell小脚本(比如： test.sh )就可以轻松完成：

#!/bin/bash
# 直接在执行删除脚本的时候从外界传入2个参数
folder=$1
delta=$2
echo "删除文件夹地址为：${folder}"
files=$(ls ${folder})
# 获取delta天前的时间戳
thres_date=$(date -d "${delta} day ago" +%s)
for file in ${files}
do
# 文件更新日期的时间戳
  file_date=$(date +%s -r ${file})
#  更新日期小于设定时间时进行删除
  if [ ${file_date} -le ${thres_date} ]
  then
    echo "删除的文件为： ${file}"
    rm -f ${file}
  fi
done

程序运行时 只需执行：  sh  test.sh   /opt/data/homework/logs   7

就可将logs文件夹下的7天前的旧日志删除掉！

00
还是上次那个问题，运维同学发现一台CentOS 7的服务器空间快满了，服务器告警。
于是要清除掉服务器上没用的文件，但是怎么找到服务器上的无用文件，然后选择性删除呢？
这里我们提供两个思路，一个是大文件，删除一个就能腾挪很多空间，例如安装包什么的；一个是很多天以前的文件，如日志文件，可能再留存也没什么意义了。
01
首先，我们来找大文件。
关键字 find 、-size。
find / -type f -size +500M
-> 从根目录开始查找，500M以上文件。
-> -type f: f为普通文件类型，f改为d则是目录文件，l则是符号链接文件，-type 还有其他参数，不在这里一一列举。
-> -size +500M ：500MB以上 。
-> 一般磁盘空间不够，删除垃圾文件时会使用到此命令。

如果这500M以上的文件都是无用的，怎么删除呢？使用xargs。
find / -type f -size +500M | xargs rm -rf
-> xargs : 命令传递参数过滤器，与管道符“|”一同使用，将前面的命令传递给后面的命令使用

如果这些文件中有一些不想删除怎么办？加上grep -v，来反排除。我们看示例。
find / -type f -size +500M | grep -v '我不能删*' | xargs rm -rf
-> 查找500M以上文件删除，但是排除掉“我不能删”开头的文件

02
其次，第二种思路，我们查找N天以前的文件进行删除。
关键字 find 、-mtime。
find /var/log/ -mtime +30 -name '*.log'
> 查找/var/log/目录下，30天前操作过的log文件
-> -mtime：代表修改时间，最常用，类似参数有-atime、-ctime
-> -atime：代表访问时间，查看过就算
-> -ctime：文件状态改变时间
-> -30：代表30天以内，30为n，数字自己填写
-> +30：30天以前
-> 30：距今第30天
 
find /var/log/ -mtime +30 -name '*.log'| xargs rm -f
-> 删除30天前的log文件

xargs : 命令传递参数过滤器，与管道符“|”一同使用，将前面的命令传递给后面的命令使用
03
总结下本次我们学习的知识点：
1、find的两种很常用的命令参数，-size +N 大小查找，-mtime +N 时间查找。
2、grep -v 反向排除。
3、还学了使用xargs + rm 命令来进行批量删除。
你还知道哪些批量删除的方法呢？下期我们再说说各种批量删除文件的方法吧。

百度网盘好友太多，不方便管理，并且有一大部份还是单向好友，消息也发不了，怎么找出来删除掉，下面介绍怎么操作实现这个目的。

一、首先百度下载网盘消息群发工具

二、在帐号管理中登录并获取COOKIE，保存后，右键帐号登录

三、在第二个选项卡好友管理中，选中要删除的好友，可以筛选单向/双向好友，选中后，点击右边功能栏中的“批量删除好友”按钮。程序将自动运行，下方日志框中有运行结果提示，如图：

写这篇文章是因为之前有一次删库操作，需要进行批量删除数据，当时没有控制好删除速度，导致产生了主从延迟，出现了一点小事故。
主从常见架构
随着日益增长的访问量，单台数据库的应接能力已经捉襟见肘。因此采用主库写数据，从库读数据这种将读写分离开的主从架构便随之衍生了出来。
在生产环境中，常见的主从架构有很多种，在这里给大家介绍几种比较常见的架构模式。
主从复制原理
对于主从来说，通常的操作是主库用来写入数据，从库用来读取数据。这样的好处是通过将读写压力分散开，避免了所有的请求都打在主库上。同时通过从库进行水平扩展使系统的伸缩性及负载能力也得到了很大的提升。
但是问题就来了，读从库时的数据要与主库保持一致，那就需要主库的数据在写入后同步到从库中。如何保持主库与从库的数据一致性，主库又是通过什么样的方式将数据实时同步到从库的？
基本原理
Mysql主从复制时有两个很重要的日志文件
binlog (二进制日志文件)
relay log (中继日志文件)
在主从同步的过程中，主库会将所有的操作事件记录在 binlog 中，从库通过开启一个 I/O 线程保持与主库的通信，并在一定时间间隔内探测 binlog 日志文件是否发生改变。如果 binlog 日志发生了变化，主库生成一个 binlog dump 线程向从库 I/O 线程传送 binlog。从库上的 I/O 线程将 binlog 复制到自己的 relay log 中。最终由从库中的 SQL 线程读取 relay log 中的事件重放到从库上.
主从复制原因
上面的流程我们已经知道了主从复制的相关过程了，但是主库有更新就会同步从库，那为什么会出现主从延迟的情况呢？
随机重放
Mysql 主库中写 binlog 的操作是顺序写的，之前我们提到过，磁盘的顺序读写速度是很快的。同样的，从库中的 I/O 线程操作日志的速度效率也是很高的。但是别忘了，还有一个 SQL 线程来进行数据重放，而重放的过程是随机写盘的。到这里你应该就明白了吧，某一时刻 relay log 里的数据来不及重放进从库，就会产生主从延迟的情况
主库并发高
知道了从库中 SQL 线程的重放情况，对于主库并发高导致主从延迟肯定就不难理解了。某一时刻，大量写请求打到主库上，意味着要不断对 binlog 进行写入，此时从库中的 SQL 线程就会应接不暇，自然会产生主从延迟。
锁等待
对于 SQL 单线程来说，当遇到阻塞时就会一直等待，直到执行成功才会继续进行。如果某一时刻从库因为查询产生了锁等待的情况，此时只有当前的操作执行完成后才会进行下面的操作，同理也就产生了主从延迟的情况。
主从延迟处理
知道了主从延迟的原因，接下来我们看看如何来进行处理。
并行复制
既然 SQL 单线程进行重放时速度有限，那么能不能采用多线程的方式来进行重放呢？MySQL 5.6 版本后，提供了一种并行复制的方式，通过将 SQL 线程转换为多个 work 线程来进行重放，这样就解决了主从延迟的问题。
降低主库并发
你可能会说了，我现在用的低版本的数据库，也没法升版本啊，那我怎么整。对于主库并发高的情况，这种方式你只能通过控制并发来解决延迟了，多用用 Redis。
读主库
这种情况你肯定不陌生，对于一些实时性要求比较高的数据，你总不能读从库去拿吧，万一延迟个大半天，你不得贡献自己的年终奖啊。
总结
主从复制原理
主从复制中有两个很重要的日志文件，binlog和relay log，分别位于主库与从库中。其中 binlog 是主从复制的基础，通过将操作事件写入 binlog 通过 I/O 线程传送至从库进行同步。
主从复制原因
从库中 SQL 线程重放的过程是随机写盘的，并且 SQL 线程是单线程的，因此数据来不及重放的话就会导致主从延迟。
主库并发高会导致写操作不断写入 binlog，对于 SQL 线程说可能会应接不暇，也会产生主从延迟。
重放过程中如果遇到锁等待也是产生延迟的原因之一。
主从延迟处理
MySQL 5.6版本以后通过并行复制的方式来解决 SQL 单线程产生的主从延迟问题。对于低版本来说，可以通过降低主库的并发来解决。如果对数据实时性要求比较严格的话，可以通过读主库来达到目的。