一、inotify简介
Inotify是一种强大的，细粒度的，异步的文件系统事件监控机制（软件）。
可以时刻监控某一目录的东西。这个目录只要发生变化（添加，删除，修改，移动等），它就可以通知rsync进行推送。 目前市面有这种监控的升级版（sersync相当于rsync+inotify）
单点故障：一个服务器坏了，整个集群都会瘫痪；NFS就是单点性质
高可用：一个服务器坏了，还有很多服务器顶上。
为了防止NFS的单点故障，需要给NFS备份一个（就需要用inotify+rsync进行实时同步），这样一个NFS故障，还有一个NFS顶上。
一台服务器的读写速度叫吞吐量。
分布式的缺点：网速受限，速度可无限叠加，网卡成为瓶颈，也完犊子。
还有就是扩容受限、单点问题，成本高、速度需要服务器叠加。
二、建立云YUM源与本地YUM源和偷包：
1、云yum仓库安装
从网上下载一个epel.repo的yum源
（1）先查看wget软件包是否安装，若没有则yum安装wget
# yum -y install wget
（2）# wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo
把文件下载到这个位置 从哪里下载
（3）# yum -y clean all
（4）# yum makecache
2、偷包流程：
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo
wget -O /etc/yum.repos.d/163.repo http://mirrors.163.com/.help/CentOS6-Base-163.repo
把/etc/yum.repos.d/里所有东西移到bak目录里
然后创建新的配置文件
vim rpm.repo
[benchi]
name=benchi
baseurl=file:///root/rpm
gpgcheck=0
enabled=1
yum -y install createrepo
yum -y install ansible
清缓存
生成缓存
vim /etc/yum.conf 修改配置文件
缓存保留那一行改成1（keepcache）
修改完后需要重新缓存。
cd /var/cache/yum/x86_64/6 yum的缓存路径在这个目录
mkdir -p /root/rpm
挨个查看packages 所有都移动到设定好的目录里
mv base/packages/* /root/rpm
cd /root/rpm
清空、生成缓存
缓存标记createrepo -v . 把当前目录下的安装包做一个识别标记
清空、生成缓存
卸载光盘 回滚把之前安装的16个包卸载
用本地源重新安装16个包
3、Inotify安装步骤
# yum -y install inotify-tools
# which inotifywait
4、inotifywait的几个参数
|
inotifywait参数 |
含义说明 |
|
-r --recursive |
递归查询目录 |
|
-q --quiet |
打印很少的信息，仅仅打印监控事件的信息 |
|
-m，--monitor |
始终保持事件监听状态 |
|
--exclude |
排除文件或目录时，不区分大小写。 |
|
--timefmt |
指定时间输出的格式 |
|
--format |
打印使用指定的输出类似格式字符串 |
|
-e，--event |
通过此参数可以指定需要监控的事件，如下一个列表所示 |
-e ：--event的各种事件含义
|
Events |
含义 |
|
access |
文件或目录被读取 |
|
modify |
文件或目录内容被修改 |
|
attrib |
文件或目录属性被改变 |
|
close |
文件或目录封闭，无论读/写模式 |
|
open |
文件或目录被打开 |
|
moved_to |
文件或目录被移动至另外一个目录 |
|
move |
文件或目录被移动到另一个目录或从另一个目录移动至当前目录 |
|
create |
文件或目录被创建在当前目录 |
|
delete |
文件或目录被删除 |
|
umount |
文件系统被卸载 |
四、测试人工监控
1、监控create事件
inotifywait -mrq --timefmt '%y %m %d %H %M' --format '%T %w%f' -e create /backup
-mrq：-m 进行不间断持续监听
-q 只输入简短信息
-r 递归监控整个目录包括子目录
--timefmt ’’是时间格式化 “%y %m %d %H %M”“年 月 日 时 分”
-format是对整体进行格式化，输出的不仅是时间，还有路径，按照指定的格式输出变化的路径。
--format监控目录里谁发生变化；%T（代表时间）%w（路径）%f（文件名）
-e create（指定监控create事件（文件或目录被创建在当前目录））
/backup（监控这个目录）
%w%f 表达的是路径+文件名，也就是绝对路径；
若管道符给rsync，就可以实时传送创建事件
2、监控删除事件delete
inotifywait -mrq --timefmt '%y %m %d %H %M' --format '%T %w%f' -e delete /backup
当删除指定目录的文件时，delete事件有更新跟踪
3、close_write写关闭事件
当在指定目录中，写入文件信息或创建文件预备写入信息时，写关闭时间会更新信息，记录情况。通常监控“echo”、“touch”、“vim”命令。
inotifywait -mrq --timefmt '%y %m %d %H %M' --format '%T %w%f' -e close_write /backup
Close_nowrite 只读关闭
4、测试moved_to（移动事件）
inotifywait -mrq --timefmt '%y %m %d %H %M' --format '%T %w %f' -e moved_to /backup
五、编写inotify实时监控脚本
1、将inotify放在后台
将inotify实时监控放在后台（在命令后面加“&”）
# inotifywait -mrq --timefmt '%y %m %d %H %M' --format '%T %w %f' -e moved_to /backup &
2、inotify+rsync备份脚本
ctrl+z vim切换后台 fg切回来
# backup_Server=备份服务器的IP地址
绝对路径/usr/bin/inotifywait -mrq --format ‘%w%f’ -e create,close_write,delete /data | while read line
%w%f 表达的是路径+文件名，也就是绝对路径；
-e 监控后面的三个事件
一旦有变化就通过管道符传达给管道符右边
传递的数据就会赋值给line这个变量，然后触发while循环
触发以后cd到/date这个目录里（最好提前判断date在不在）
下面启动rsync命令，-az不显示信息，推送当前目录所有内容以实时推送模式，朝着备份服务器的模块推送，然后带着密码文件推送过去
这个脚本效率很低，因为是推送当前所有，所以每次都需要比对，而且如果大量小文件是需要打包的。因此我们要对这个脚本进行修改。
如果line是一个文件，那我直接推送这个文件就可以了，如果是其他情况，就需要推送整个目录
3、脚本可以加入开机启动：
echo "/bin/sh /server/scripts/inotify.sh &" >> /etc/rc.local
上届老逼说这个不好使，有时间试试
六、关键参数调整
在/proc/sys/fs/inotify目录下有三个文件，对inotify机制有一定的限制
（1）max_user_watches:设置inotifywait或inotifywatch命令可以监视的文件数量（单进程）
（2）max_user_instances:设置每个用户可以运行的inotifywait或inotifywatch命令的进程数
（3）max_queued_events:设置inotify实例事件（event）队列可容纳的事件数量。
七、Inotify实时并发：每秒200文件并发，数据同步几乎无延迟（小于1秒）
（1）优点
监控文件系统事件变化，通过同步工具实现实时数据同步。
（2）缺点
A. 并发如果大于200个文件（10-100k），同步就会有延迟
B. 我们前面写的脚本，每次都是全部推送一次，但确实是增量的。也可以只同步变化的文件，不变化的不理。
C. 监控到事件后，调用rsync同步是单进程的，而sersync为多进程同步。既然有了inotify-tools，为什么还要开发sersync？
八、sersync功能多：（inotify+rsync命令）
1）支持通过配置文件管理
2）真正的守护进程socket
3）可以对失败文件定时重传（定时任务功能）
4）第三方的HTTP接口（例如：更新cdn缓存）
5）默认多进程rsync同步
九、高并发数据实时同步方案小结：
1）inotify（sersync）+ rsync，是文件级别的。
2）drbd文件系统级别，文件系统级别，基于block块同步，缺点：备节点数据不可用
3）第三方软件的同步功能：mysql同步（主从复制），oracle，mongodb
4）程序双写，直接写两台服务器。
5）利用产品业务逻辑解决（读写分离，备份读不到，读主）
十、优化模式
1、读写分离模式：
架构解析：
NFS的单主双写模式（当读取压力大时使用该架构，但为单点、不可扩容）
NFS的两个缺点：单点（只能一对一）、不可扩容。
用户上传的图片、附件存储在主NFS中（属于写模式）写到主NFS服务器里，主NFS通过rsync+inotify进行实时同步，同步两个完全一样的作为备份：NFS备份1、NFS备份2；
Web服务器再读取NFS备份里数据，这样Web服务器读取的压力不再给主NFS，而是均衡负载到NFS备份1、NFS备份2上。
而写入的压力给了主NFS，读取的压力在NFS备份上，这种方法称为读写分离，可以提高NFS性能（通常，互联网20%的压力在写入，80%的压力在读取，相当于多台NFS分担压力）。
但是这个模式成本很高，需要备份两个一样的
2、NFS的双主双写模式（当写入压力大时使用该架构）
NFS的双主双写模式（当写入压力大时使用该架构）
环境后方为两个双主NFS服务器（记一个为IP1，一个为IP2），若开发时设定图片写入到IP1里，视频写入到IP2里，这样图片和视频的写入压力被分散。
假设，每个Web服务器的挂载目录都有两个共享目录（一个为/backup1,、另一个为/backup2），把IP1的主NFS服务器挂载到/backup1上，把IP2的主NFS服务器挂载到/backup2上；
读数据的时候先到/backup1目录中读取，若/backup1中没有找到到，就去/backup2中读取，因为数据是分开装的，1目录装图片，2目录装视频等，两个目录里的东西不一样。
使用这个模式用来缓解写入的压力。