由于项目需要,产品的部署必须考虑到安全和灾难的解决办法.由于之前一直做的的小项目,基本都是单服务器,单数据库结构,但是由于一次灾难,把这个问题提上了日程.
本人资历浅薄,很多东西还不是很熟悉,最近在网上百度了一大堆相关的东西,基本有了大概的思路,
思路就是,
1..用多个服务器做集群,做压力负载均衡,这样第一可以分流,减轻每个服务器的压力,提高稳定性,再者就是,一个服务器崩溃了,其他服务器可以继续运行.提供服务.
2..做文件同步式,自动把多台服务器上的一些特殊文件夹做文件同步,比如一些图片资源文件,静态的html.这样一台服务器做更新,其他服务器可以同步更新,并且,用户上传的文件也同步在每个服务器上,即使部分服务器崩溃了,保证用户的使用不受影响.
3.就是难住我的了,也就是数据库集群,或叫数据库同步,不知道专业学名是什么,反正我要实现的功能就是,有多个数据库服务器,这些数据库上的内容是完全相同的,不同来源的访问可能会被分配到不同的数据库上.当我对A1数据库,添加,修改,删除的时候,其他所有的数据库同步更新,应用程序在运行的时候,会被自能解析到压力最小的数据库服务器上,当一个数据库服务器挂了的时候,它对应的程序就转移到别的数据库服务器上,但是关键是,数据不能丢失,即使那个服务器的硬盘烧掉了,之前的数据也不能丢失.
我查到mssql有数据库同步的功能,但是有一个大问题就是,当2个人同时对2个数据库进行添加操作的时候,会生产2个同样的自增长id,这样2个服务器就发生了并发的冲突.导致数据出现了不一致.这个问题很致命.
以上就是我的问题描述,我把帖子共享在这里,一共以后的小菜们学习,希望各位大神多多给予指导,想必这些技术已经在很多商业公司运用的很成熟了,但是还有很多像我这样的小菜没有掌握,大家多多交流一下吧,这几天我实在是太困了,我都睡了,88.
------解决方案--------------------
【用多个服务器做集群,做压力负载均衡】
mssql这个比较难，最多是：
先加重 主服务器 的负担，把主服务器的记录同步到 只读服务器，
分流读的用户到此服务器来读，减轻主服务器的读压力
写压力基本是没办法简单分流，除非是应用自行规划
------解决方案--------------------
如果只考虑容灾，，可考虑自动切换的订阅复制，需要增加一个见证服务器，具体可查看联机帮助。
------解决方案--------------------
------解决方案--------------------
阿对了，写压力的话
可以通过ＳＳＢ实现，当然需要存储过程做独立处理，也可以自己写程序控制一致性
但实际存在写压力的情况很少，除非你的项目是大型电子商务性质
没有直接的技术可以解决写压力的分散