服务器开发模式.pptVIP

服务器开发模式 常用模型和技巧 What’s the server? 应用服务器需要解决的问题 通讯问题－快慢之道 并发问题－轻重之道 存储问题－张驰之道 载衡问题－分合之道 可用问题－缓急之道 平衡是关键 通讯问题－快慢之道 建立合适的通讯模型 选择正确的通讯方式 制定合理的通讯协议 快要有快的手法 慢要有慢的道理 信息传输特性 完整性－丢点行么？ 顺序性－乱点行么？ 时效性－迟点行么？ 解决完整性问题 信息分割机制 丢包检测机制 可靠重传机制 文件服务是经典的完整性案例 解决顺序性问题 数据排队机制 丢包检测机制 可靠重传机制 远程终端服务是经典的顺序性案例 解决时效性问题 过时检测机制 状态同步机制 应用纠错机制 视频流服务是经典的时效性案例 TCP 还是 UDP? 面向连接流模型 滑动窗重传机制 有流量控制 保证传输顺序 协议层无边界 丢包影响传输速度 点对点数据报模型 协议层不做重传 无流量控制 不保证传输顺序 协议层边界 丢包影响传输成功率 互控型服务模型 C-S之间互为因果 高完整性要求 高顺序性要求 低时效性要求 选择TCP方式通讯 应用层仅检测和简单处理传输成功或失败 互控型服务也叫事务型服务 单控型服务模型 C-S单向控制 高完整性要求 低顺序性要求 低时效性要求 可以选择UDP方式追求更快速度 应用层需要丢包检测和有效重传机制 互不控型服务模型 C.S互不控制 低完整性要求 低顺序性要求 高时效性要求 采用UDP通讯方式 应用层需要有合适机制保证数据一致性 协议制定的基本原则 流量控制 校验法则 向上的扩展性 向下的兼容性 几种协议载体 XML方式是扩展性最好的文本协议载体 TVL方式是扩展性最好的二进制协议载体 XML方式实例 XML方式优缺点 扩展性好 可读性好 解析方式统一 大量库支持 开放式协议 信息密度低 占用带宽大 处理较耗时 TLV方式实例 TLV方式优缺点 自解码方式 扩展性好 统一方式解析 信息密度大 编解码效率高 可读性较差 电信设备协议方式，未被广泛支持 并发问题－轻重之道 合理选择进程模型 合理设计调度模型 优化进程关键路径 完美境界在均衡 如何让CPU占用100％？ 有没有多个CPU是长相问题 设不设计多进程是人品问题 平衡的进程结构充分利用CPU资源 多进程的误区 多进程是充分利用系统资源的手段 多进程是改善客户响应速度的手段 多进程是实现功能合理分布的手段 最理想的架构是每进程占用一个CPU转到吐血 多进程不是简化程序设计的手段 过多的进程导致上下文切换开销增大和系统不稳定 为每事务创建一个进程是糟糕的设计 要避免单进程阻塞导致系统停止吞吐 如何让CPU占用0％？ 磁盘I/O和循环是影响性能的主要因素 剔除垃圾操作 简化关键路径 优化关键路径中的耗时算法 执行频率最高的路径就是关键路径 常用的并发模型 迭代模型 并发模型 分发模型 线程池模型 迭代模型 最原始的服务模型 单进程运作，通讯和业务逻辑并存 一般采用非阻塞方式工作 简单并发模型 主进程处理连接请求，有新连接到来时创建子进程处理数据 请求由子进程处理，处理完后子进程退出 每个子进程只处理一个连接 预创建模型 - 子进程accept 主进程预先fork一些进程 各个子进程竞争accept，然后处理数据传输 一个子进程可以处理一个连接，也可以同时处理多个连接 预创建模型 – 主进程accept 主进程accept，通过流管道转发fd到子进程 子进程收到fd后，处理数据传输，处理结束后通知父进程 父进程处理的事情比较简单，容易监控子进程 分发模型 通讯进程管理所有连接，实现海量接入 通讯进程只负责分发消息，包括上行和和下行消息 业务进程不关心通讯 通讯进程和业务进程之间通过内存管道共享数据 Linux下的epoll技术 实现海量的TCP接入 实现轻量级的数据收发和链路管理 目前测试到的稳定链接数为50000 TCP服务器可以考虑使用epoll+logic的分发模型 线程池模型 主线程管理所有通讯过程 可配置预分配线程池 以任务为单位来分配处理请求 每个线程同时只执行一个任务 提供稳定性能的服务 存储问题－张驰之道 没有存储操作的应用是最快的应用 存储问题的关键在于硬盘的随机读写速度 I/O繁忙的机器，CPU运算一般很空闲 存储问题的解决之道，就是要善用CPU和内存来缓解磁盘读写的压力 Cache策略 磁盘内容在内存中的镜像就是Cache 在Cache中保存访问频率最高的磁盘内容 当该内容被再次访问时，从Cache中取，节省磁盘读操作 当该Cache被多次更新后，再同步到磁盘，节省磁盘写操作 善用顺序读写 磁盘的顺序读写性能要远远大于随机读写 延迟写会导致异常崩溃下的更新丢失 使用另一设备的顺序日志记录历