本资料只是个人研究，无实际操作
解决问题切分功能
-
负载均衡
-
IO均衡
- 网络IO
- 日志IO
- 存储IO
-
数据共享
- 只读共享
- 更改推送
- 并发控制
- 会话共享
-
多机协调工作
- 中心服选举
- 线上注册节点
- 程序异常处理
- 请求异常容错处理
- 交互优先访问相邻节点
-
-
数据挖掘
- 实时分析
- 异步分析
- 分析任务分发
- 统计收集
- 领域分析
-
物理存储容灾
- 方案1 mysql 主从服
- 方案2 定时备份数据库
- 方案3 定时镜像mysql 物理储存文件
- 方案4 物理盘做阵列
切分设计说明
设计原则
- 按用户规模设计
- 按实际需求设计
- 潜在问题同未来可预测问题分析设计
程序员比较关注的是功能正常运行，业务逻辑会不会出错。底层通信、协调、物理容灾是不关心的，我认为物理容灾交给运维同事负责比较好，他们或者会想出更好方案，数据挖掘是后期工作，前期只设计支持模型.
而我们只负责负载均衡部份
什么样的程序需要分布式？
- 大规模用户
- 单个应用支撑用户数1W人
- 单个应用内存占4G运行空间
- 单物理服每秒宽带
- 开物理服 = 预测需求用户/ ( 单台物理内存/ 单个应用内存 * 单个应用支撑用户数 )
- 个人研究
百万级别以上的用户用分布式好点，少于百万还是单机吧
分析案例
-
内容网站
-
只读部份 主页,列表页
-
修改部份 评论，广告
-
小结
-
主页访问量大，可弄个静态缓存集群组然后直接CDN技术解决
-
评论变动频烦，可按一周7天切分7个集群，轮盘式发布处理
-
视频网站
- 可用P2P技术分流，扩展web插件支持p2p
- 主页，列表页，评论同内容网站一样
-
社交网站
-
消息推送，可按小时/天 切分集群，轮盘式发布处理,FIFO策略控制集群，入库或完全丢去
-
小结
-
消息生命周期完全由缓存控制
-
消息上限可控制
-
集中精力处理缓存,消息共享
-
所有消息都是在线推送，推送成功再记录，减少IO压力
-
-
图片分享网站(不是这方面专业，没什么好说的感觉跟视频服一样烧钱)
- 对高清图片进行优化
- 专门的图片存储集群(硬盘、内存性能要好,cpu 可以差点)
- 热扩展物理硬盘
- 路由服来分配策略
-
电商网站
- 大量图片资源同图片服一样
- 定期执行推荐算法，刷新一级缓存
- 水平扩展产品，每种产品应独立开发
-
总结
- 一级缓存集群(主页)负责今天的热点内容，以及推荐内容等
- 二级缓存集群(节点)负责缓存本地节点数据
功能细节实现
越写越发现注意的细节太多了，可以出一本书，以后有空再补上