网站分布式集群思考

何时要用分布式

• 单台服务器无法承受压力。
• 需要实现发生错误时候，自动切换
• 学习或者测试分布式技术

应用分布式的场景

一、提供多个对外的接口，按照一定规则，分派不同请求由不同接口来处理。
这时候需要考虑：

• 如何实现负载均衡
  • 在哪个层次实现转移负载
  • 负载的均衡如何实现
• 如何实现故障转移
  • 如何监控故障
  • 如何切换服务

二、把一个功能拆分成多个功能，不同功能分布部署到不同服务器上

• 对外功能的拆分 
  • 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 ）
  • DB分布式集群部署
    • 故障转移
    • 发布订阅
    • 分布式分区视图
  • 应用服务器（比如定时发送邮件通知的服务）
  • 相关技术：
    • 企业服务
    • .net Remoting
    • WCF
    • Web Service

 

如何判断一个应用是否支持分布式

如果发现某一部分应用需要做分布式了，就可以按照以下思路来考虑如何改造：

从应用所用数据看是否支持分布式

• 多份并存数据（一个数据存在多份）最大多长时间同步一次是可接受的。
  • 内存缓存的数据跟数据库的数据（页面级缓存和业务逻辑缓存）
  • 静态文件跟数据库
  • 查询数据库跟业务变更数据库
• 数据按照一定规则拆分（一个数据只存在一份）对业务是否有影响
  • 过去每年的数据迁移到一个对应历史库中。
  • 专用的图片服务器

此处可分析：QQ的在线用户数据，会是如何处理的呢？

从应用逻辑过程看是否支持分布式

• 是否可以并行执行这个逻辑过程
• 这个逻辑过程是否可以拆分成几个松耦合的过程