分布式程序设计

本资料只是个人研究,无实际操作

解决问题切分功能

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

切分设计说明

设计原则

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

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

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

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

分析案例

  • 内容网站
  • 只读部份 主页,列表页
  • 修改部份 评论,广告
  • 小结
  • 主页访问量大,可弄个静态缓存集群组然后直接CDN技术解决
  • 评论变动频烦,可按一周7天切分7个集群,轮盘式发布处理

  • 视频网站
    • 可用P2P技术分流,扩展web插件支持p2p
    • 主页,列表页,评论同内容网站一样
  • 社交网站
    • 消息推送,可按小时/天 切分集群,轮盘式发布处理,FIFO策略控制集群,入库或完全丢去

    • 小结
    • 消息生命周期完全由缓存控制
    • 消息上限可控制
    • 集中精力处理缓存,消息共享
    • 所有消息都是在线推送,推送成功再记录,减少IO压力

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

功能细节实现

越写越发现注意的细节太多了,可以出一本书,以后有空再补上

你可能感兴趣的:(分布式程序设计)