运维及系统架构的两大主题


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 

接口存活 以及流量)