何时要用分布式
- 单台服务器无法承受压力。
- 需要实现发生错误时候,自动切换
- 学习或者测试分布式技术
应用分布式的场景
一、提供多个对外的接口,按照一定规则,分派不同请求由不同接口来处理。
这时候需要考虑:
- 如何实现负载均衡
- 在哪个层次实现转移负载
- 负载的均衡如何实现
- 如何实现故障转移
- 如何监控故障
- 如何切换服务
二、把一个功能拆分成多个功能,不同功能分布部署到不同服务器上
- 对外功能的拆分
- http://news.sina.com.cn/ http://sports.sina.com.cn/ http://mobile.sina.com.cn/
- http://www.microsoft.com/china/ http://www.microsoft.com/downloads/
- SOA
- n层架构,其中的一些层分布到不同服务器上
- WEB + DB 模式
网站请求中的分布式
按照请求流程,我们可以在以下环节按照一定规则,把用户的请求分流到不同服务器上:
- Web Client Level
- 例子:QQ 设置中你可以选择登陆的服务器IP
- DNS Based Selection
- 优点:
- 缺点:
- 不能区分服务器的差异,也不能反映服务器的当前运行状态。
- DNS 的刷新需要时间,无法及时故障切换。
- TCP balancing proxies
- 硬件
- 软件
- HTTP-aware routers
- URL重定向
网站应用中的分布式
- 代理服务器实现请求的分离
- Squid是Linux下一个缓存Internet数据的代理服务器软件
- 拆分网站对外功能
- 不同域名前、后缀
- URL 重写
- SOA
- 每个Service 分布到一台服务器上
- n 层架构
- 缓存分布式部署
- 文件Cache
- 内存Cache (memcached )
- http://www.danga.com/memcached/
- https://sourceforge.net/projects/memcacheddotnet/
- DB分布式集群部署
- 故障转移
- 发布订阅
- 分布式分区视图
- 应用服务器(比如定时发送邮件通知的服务)
- 相关技术:
- 企业服务
- .net Remoting
- WCF
- Web Service
- 缓存分布式部署
如何判断一个应用是否支持分布式
如果发现某一部分应用需要做分布式了,就可以按照以下思路来考虑如何改造:
从应用所用数据看是否支持分布式
- 多份并存数据(一个数据存在多份)最大多长时间同步一次是可接受的。
- 内存缓存的数据跟数据库的数据(页面级缓存和业务逻辑缓存)
- 静态文件跟数据库
- 查询数据库跟业务变更数据库
- 数据按照一定规则拆分(一个数据只存在一份)对业务是否有影响
- 过去每年的数据迁移到一个对应历史库中。
- 专用的图片服务器 http://pics.ebaystatic.com/
此处可分析:QQ的在线用户数据,会是如何处理的呢?
从应用逻辑过程看是否支持分布式
- 是否可以并行执行这个逻辑过程
- 这个逻辑过程是否可以拆分成几个松耦合的过程