Git 是分布式的，而 Svn 不是分布的;

Git 把内容按元数据方式存储，而 SVN 是按文件;

Git 没有一个全局版本号，而 SVN 有：目前为止这是跟 SVN 相比 Git 缺少的最大的一个特征;

Git 的内容的完整性要优于 SVN: GIT 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏;

Git 下载下来后，在 OffLine 状态下可以看到所有的 Log,SVN 不可以; SVN 必须先 Update 才能 Commit,忘记了合并时就会出现一些错误，git 还是比较少的出现这种情况。

克隆一份全新的目录以同样拥有五个分支来说，SVN 是同时复製 5 个版本的文件,也就是说重复五次同样的动作。而 Git 只是获取文件的每个版本的 元素，然后只载入主要的分支(master)在我的经验,克隆一个拥有将近一万个提交(commit),五个分支,每个分支有大约 1500 个文件的 SVN,耗了将近一个小时！而 Git 只用了区区的 1 分钟！

版本库（repository):SVN 只能有一个指定中央版本库。当这个中央版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而 Git 可以有无限个版本库。或者，更正确的说法，每一个 Git 都是一个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库（例如：置於 GitHub 的版本库）发生了什麼事，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！

分支（Branch）在 SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开啟新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样,你改一个分支，还得让其他人重新切分支重新下载，十分狗血。而 Git，每个工作成员可以任意在自己的本地版本库开啟无限个分支。

Git 的分支名是可以使用不同名字的。例如：我的本地分支名为 OK，而在主要版本库的名字其实是 master。

提交（Commit）在 SVN，当你提交你的完成品时，它将直接记录到中央版本库。当你发现你的完成品存在严重问题时，你已经无法阻止事情的发生了。如果网路中断，你根本没办法提交！而 Git 的提交完全属於本地版本库的活动。而你只需“推”（git push）到主要版本库即可。Git 的“推”其实是在执行“同步”（Sync）。

总结：SVN 的特点是简单，只是需要一个放代码的地方时用是 OK 的。

Git 的特点版本控制可以不依赖网络做任何事情，对分支和合并有更好的支持(当然这是开发者最关心的地方)，不过想各位能更好使用它，需要花点时间尝试一下。

master 将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）slave 将 master 的 binary log events 拷贝到它的中继日志 (relay log) slave 重做中继日志中的事件，将改变反映它自己的数据。或从库生成两个线程，一个 I/O 线程，一个 SQL 线程；

i/o 线程去请求主库 的 binlog，并将得到的 binlog 日志写到 relay log（中继日志） 文件中；

主库会生成一个 log dump 线程，用来给从库 i/o 线程传 binlog；

SQL 线程，会读取 relay log 文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；

> show processlist;
#查看下进程是否 Sleep 太多。发现很正常。

> show master status;也正常。

> show master status;
+------------------+-----------+--------------+------------------+-------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+-----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 692143213 |              |                  |                   |
+------------------+-----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

> show slave status\G
Slave_IO_Running: Yes Slave_SQL_Running: No 
#可见是 Slave 不同步

> stop slave; 
#表示跳过一步错误，
后面的数字可变 
> set global sql_slave_skip_counter =1; 

>start slave; 
#开启同步

> show slave status\G
#查看主从状态
Slave_IO_Running: Yes Slave_SQL_Running: Yes ok
#现在主从同步状态正常了。。。

> flush tables with read lock; 
#先进入主库，进行锁表，防止数据写入
#注意：该处是锁定为只读状态，语句不区分大小写

$ mysqldump -uroot -p -hlocalhost > mysql.bak.sql 
#进行数据备份

> show master status;
+------------------+-----------+--------------+------------------+-------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+-----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 692143213 |              |                  |                   |
+------------------+-----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

$ scp mysql.bak.sql root@10.103.25.11:/tmp/ 

> stop slave; 

> source /tmp/mysql.bak.sql 
#然后到从库执行 mysql 命令，导入数据备份

> change master to master_host = '10.103.25.10',master_user = 'bak', master_port=3306, master_password='******', master_log_file = 'mysqld-bin.000001', master_log_pos=692143213; 

> start slave; 
#重新开启从同步 

> show slave status\G
#查看同步状态
Slave_IO_Running: Yes Slave_SQL_Running: Yes

–slave-net-timeout=seconds 单位为秒，默认设置为 3600 秒
#参数含义：当 slave 从主数据库读取 log 数据失败后，等待多久重新建立连接并获取数据

– master-connect-retry=seconds?
#单位为秒?默认设置为 60 秒 #参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试。通常配置以上 2 个参数可以减少网络问题导致的主从数据同步延迟 MySQL 数据库主从同步延迟解决方案;

作为消息队列来说，企业中选择 mq 的还是多数，因为像 Rabbit，Rocket 等 mq 中间件都属于很成熟的产品，性能一般但可靠性较强.而 kafka 原本设计的初衷是日志统计分析，现在基于大数据的背景下也可以做运营数据的分析统计，而 redis 的主要场景是内存数据库，作为消息队列来说可靠性太差，而且速度太依赖网络 IO，在服务器本机上的速度较快，且容易出现数据堆积的问题，在比较轻量的场合下能够适用。

RabbitMQ,遵循 AMQP 协议，由内在高并发的 erlanng 语言开发，用在实时的对可靠性要求比较高的消息传递上。

kafka 是 Linkedin 于 2010 年 12 月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。

软连接，其实就是新建立一个文件，这个文件就是专门用来指向别的文件的（那就和 windows 下的快捷方式的那个文件有很接近的意味）。软链接产生的是一个新的文件，但这个文件的作用就是专门指向某个文件的，删了这个软连接文件，那就等于不需要这个连接，和原来的存在的实体原文件没有任何关系，但删除原来的文件，则相应的软连接不可用（cat 那个软链接文件，则提示“没有该文件或目录“）

硬连接是不会建立 inode 的，他只是在文件原来的 inode link count 域再增加 1 而已，也因此硬链接是不可以跨越文件系统的。相反是软连接会重新建立一个 inode，当然 inode 的结构跟其他的不一样，他只是一个指明源文件的字符串信息。一旦删除源文件，那么软连接将变得毫无意义。而硬链接删除的时候，系统调用会检查 inode link count 的数值，如果他大于等于 1，那么 inode 不会被回收。因此文件的内容不会被删除。

硬链接实际上是为文件建一个别名，链接文件和原文件实际上是同一个文件。可以通过 ls -i 来查看一下，这两个文件的 inode 号是同一个，说明它们是同一个文件；而软链接建立的是一个指向，即链接文件内的内容是指向原文件的指针，它们是两个文件。

软链接可以跨文件系统，硬链接不可以；软链接可以对一个不存在的文件名(filename)进行链接（当然此时如果你 vi 这个软链接文件，linux 会自动新建一个文件名为 filename 的文件）,硬链接不可以（其文件必须存在，inode 必须存在）；软链接可以对目录进行连接，硬链接不可以。两种链接都可以通过命令 ln 来创建。ln 默认创建的是硬链接。使用 -s 开关可以创建软链接

$ grep -rn "A" ./ 

或

$ find ./ -name "*.*" | xargs grep  "A"

$ ps -ef | grep "^a" | grep -v grep | cut -c 9-15 | xargs kill -9 

或

ps x | grep a | grep -v grep | awk '{print $1}' | xargs kill -9

Linux 服务管理两种方式 service 和 systemctl

systemd 是 Linux 系统最新的初始化系统(init),作用是提高系统的启动速度，尽可能启动较少的进程，尽可能更多进程并发启动。

systemd 对应的进程管理命令是 systemctl

systemctl 命令兼容了 service, systemctl 命令管理 systemd 的资源 Unit

iptables 其实不是真正的防火墙，我们可以把它理解成一个客户端代理，用户通过 iptables 这个代理，将用户的安全设定执行到对应的"安全框架"中，这个"安全框架"才是真正的防火墙，这个框架的名字叫 netfilter iptables 其实是一个命令行工具，位于用户空间，我们用这个工具操作真正的框架。

所以说，虽然我们使用 service iptables start 启动 iptables"服务"，但是其实准确的来说，iptables 并没有一个守护进程，所以并不能算是真正意义上的服务，而应该算是内核提供的功能。

iptables 有 4 表 5 链：

 - filter 表——过滤数据包
 - Nat 表——用于网络地址转换（IP、端口）
 - Mangle 表——修改数据包的服务类型、TTL、并且可以配置路由实现 QOS
 - Raw 表——决定数据包是否被状态跟踪机制处理
 - INPUT 链——进来的数据包应用此规则链中的策略
 - OUTPUT 链——外出的数据包应用此规则链中的策略
 - FORWARD 链——转发数据包时应用此规则链中的策略
 - PREROUTING 链——对数据包作路由选择前应用此链中的规则（所有的数据包进来的时侯都先由这个链处理）
 - POSTROUTING 链——对数据包作路由选择后应用此链中的规则（所有的数据包出来的时侯都先由这个链处理）

 - 服务器带宽跑满
 - 服务没有启动
 - 端口没有正常监听
 - 防火墙或者防火墙策略限制

 - web 服务没有正常启动
 - 端口没有正常监听
 - 防火墙/安全组/ACL等拦截

 - 通过查看其配置文件，并检测其配置文件语法，发现语法正常；
 - 通过ps等命令行查看其 web 服务端口运行正常，没有进程僵尸状况；
 - 具体读配置文件，然后再查找客户客户配置文件所指定的具体目录；
 - 查看磁盘IO或磁盘空间使用率

 - 桌面系统（6/GNOE2.x、7/GNOME3.x）
 - 文件系统（6/ext4、7/xfs）
 - 内核版本（6/2.6x、7/3.10x）
 - 防火墙（6/iptables、7/firewalld）
 - 默认数据库（6/mysql、7/mariadb）
 - 启动服务（6/service 启动、7/systemctl 启动）
 - 网卡（6/eth0、7/ens192）等。