运维及系统架构的两大主题
1数据保护
项目经验
全网数据备份解决方案
数据库数据 图片资源等 程序 运维配置文件 其他相关的
数据库数据 主从（物理故障） 实时同步 半同步插件 事务提交
百度案例
M1-S1（不提供服务 专做备份 实时同步brbd 半同步插件 事务提交）
S2
图片资源等
1每晚全量备份 1T
增量
01.rsync 小文件比对时间很长
02.brbd浪费资源 备节点不可用
03.按时间增量 201404 201405
04.更新资源写LOG 就增量了 一边写LOG 另一边通过RSYNC同步具体的文件 不需要比对了
05.inotify，sersync等
程序双写 提交数据写到两个存储 PHP能写 （还需要备份吗 还需要增量吗 ）
如何保证数据库不丢数据
如何保证存储不丢数据
全量
01.brdb
02.程序双写 提交数据写到两个存储
03.分布式存储 NOSQL mysql mongodb同步机制做存储（本身是全量和增量）
分布式存储简单方案（软件方案和自己的程序方案）
通过数据库做一个相当于路由一样 路径在哪台机器上都存在服务器上
每个图片服务器有自己的资源 当用户访问时 先查数据库 知道哪台机子哪个路径
04.分布式架构方案
按天备份
办公室----IDC测试----正式
程序 ，运维配置文件都要放到SVN里 ，向外发布
办公室SVN---->IDC测试
---->IDC正式
备份思想：
需求分析：对于每个项目或者业务点：事先定好 备份规划
数据库：10分钟，可以丢一天，根据需求出方案
存储备份：可以丢一天，根据需求出方案
测试数据：谁定，运维总监，开发总监，团队讨论。30分钟内恢复
机房迁移，OPENSLL升级，数据库升级
=====================================================================================
2维护7*24小时不间断服务
集群lvs nginx haproxy f5 netscaler
高可用 keepalive heartbeat nginx haporxy
性能\扩展：优化，用户体验要好，业务可以扩展
监控：运维级别，业务级别（按产品线监控，流量，负载，访问请求，错误日志50X 40X
接口存活 以及流量）
