分布式程序设计

本资料只是我的研究，无实际操做

解决问题切分功能

• 负载均衡
  • IO均衡
    • 网络IO
    • 日志IO
    • 存储IO
  • 数据共享
    • 只读共享
    • 更改推送
    • 并发控制
    • 会话共享
  • 多机协调工做
    • 中心服选举
    • 线上注册节点
      
    • 程序异常处理
    • 请求异常容错处理
    • 交互优先访问相邻节点
• 数据挖掘
  • 实时分析
  • 异步分析
  • 分析任务分发
  • 统计收集
  • 领域分析
• 物理存储容灾
  • 方案1 mysql 主从服
  • 方案2 定时备份数据库
  • 方案3 定时镜像mysql 物理储存文件
  • 方案4 物理盘作阵列

切分设计说明

设计原则

• 按用户规模设计
• 按实际需求设计
• 潜在问题同将来可预测问题分析设计

程序员比较关注的是功能正常运行，业务逻辑会不会出错。底层通讯、协调、物理容灾是不关心的，我认为物理容灾交给运维同事负责比较好，他们或者会想出更好方案，数据挖掘是后期工做，前期只设计支持模型.
而咱们只负责负载均衡部份
什么样的程序须要分布式？

• 大规模用户
  • 单个应用支撑用户数1W人
  • 单个应用内存占4G运行空间
  • 单物理服每秒宽带
  • 开物理服 = 预测需求用户/ ( 单台物理内存/ 单个应用内存 * 单个应用支撑用户数 )
• 我的研究

百万级别以上的用户用分布式好点，少于百万仍是单机吧

分析案例

• 内容网站
• 只读部份 主页,列表页
• 修改部份 评论，广告
• 小结
• 主页访问量大，可弄个静态缓存集群组而后直接CDN技术解决

• 评论变更频烦，可按一周7天切分7个集群，轮盘式发布处理

• 视频网站
  • 可用P2P技术分流，扩展web插件支持p2p
  • 主页，列表页，评论同内容网站同样
• 社交网站

  • 消息推送，可按小时/天 切分集群，轮盘式发布处理,FIFO策略控制集群，入库或彻底丢去

  • 小结
  • 消息生命周期彻底由缓存控制
  • 消息上限可控制
  • 集中精力处理缓存,消息共享

  • 全部消息都是在线推送，推送成功再记录，减小IO压力

• 图片分享网站(不是这方面专业，没什么好说的感受跟视频服同样烧钱)
  • 对高清图片进行优化
  • 专门的图片存储集群(硬盘、内存性能要好,cpu 能够差点)
  • 热扩展物理硬盘
  • 路由服来分配策略
• 电商网站
  • 大量图片资源同图片服同样
  • 按期执行推荐算法，刷新一级缓存
  • 水平扩展产品，每种产品应独立开发
• 总结
  • 一级缓存集群(主页)负责今天的热点内容，以及推荐内容等
  • 二级缓存集群(节点)负责缓存本地节点数据

功能细节实现

越写愈加现注意的细节太多了，能够出一本书，之后有空再补上