服务器开发模式

服务器开发模式常用模型和技巧What’stheserver?应用服务器需要解决的问题•通讯问题－快慢之道•并发问题－轻重之道•存储问题－张驰之道•载衡问题－分合之道•可用问题－缓急之道•平衡是关键通讯问题－快慢之道•建立合适的通讯模型•选择正确的通讯方式•制定合理的通讯协议•快要有快的手法•慢要有慢的道理信息传输特性•完整性－丢点行么？•顺序性－乱点行么？•时效性－迟点行么？解决完整性问题•信息分割机制•丢包检测机制•可靠重传机制•文件服务是经典的完整性案例解决顺序性问题•数据排队机制•丢包检测机制•可靠重传机制•远程终端服务是经典的顺序性案例解决时效性问题•过时检测机制•状态同步机制•应用纠错机制•视频流服务是经典的时效性案例TCP还是UDP?•面向连接流模型•滑动窗重传机制•有流量控制•保证传输顺序•协议层无边界•丢包影响传输速度•点对点数据报模型•协议层不做重传•无流量控制•不保证传输顺序•协议层边界•丢包影响传输成功率互控型服务模型•C-S之间互为因果•高完整性要求•高顺序性要求•低时效性要求•选择TCP方式通讯•应用层仅检测和简单处理传输成功或失败•互控型服务也叫事务型服务单控型服务模型•C-S单向控制•高完整性要求•低顺序性要求•低时效性要求•可以选择UDP方式追求更快速度•应用层需要丢包检测和有效重传机制互不控型服务模型•C.S互不控制•低完整性要求•低顺序性要求•高时效性要求•采用UDP通讯方式•应用层需要有合适机制保证数据一致性协议制定的基本原则•流量控制•校验法则•向上的扩展性•向下的兼容性几种协议载体•XML方式是扩展性最好的文本协议载体•TVL方式是扩展性最好的二进制协议载体XML方式实例?xmlversion='1.0'?Client_Servercommandid=“GetAddress”type=“Request”paramsparam1type=“Integer”1234/param1param2type=“String”ShenZhen/param2…/params/command/Client_ServerXML方式优缺点•扩展性好•可读性好•解析方式统一•大量库支持•开放式协议•信息密度低•占用带宽大•处理较耗时TLV方式实例0x000x120x810x040x000x000x000x030xA20x080x810x020x000x040x830x020x000x05T(AG)：表示字段的标签，包含子编号和类型信息L(ENGTH)：表示字段的长度V(ALUE)：表示字段的内容TLV方式优缺点•自解码方式•扩展性好•统一方式解析•信息密度大•编解码效率高•可读性较差•电信设备协议方式，未被广泛支持并发问题－轻重之道•合理选择进程模型•合理设计调度模型•优化进程关键路径•完美境界在均衡如何让CPU占用100％？•有没有多个CPU是长相问题•设不设计多进程是人品问题•平衡的进程结构充分利用CPU资源多进程的误区•多进程是充分利用系统资源的手段•多进程是改善客户响应速度的手段•多进程是实现功能合理分布的手段•最理想的架构是每进程占用一个CPU转到吐血•多进程不是简化程序设计的手段•过多的进程导致上下文切换开销增大和系统不稳定•为每事务创建一个进程是糟糕的设计•要避免单进程阻塞导致系统停止吞吐如何让CPU占用0％？•磁盘I/O和循环是影响性能的主要因素•剔除垃圾操作•简化关键路径•优化关键路径中的耗时算法•执行频率最高的路径就是关键路径常用的并发模型•迭代模型•并发模型•分发模型•线程池模型迭代模型•最原始的服务模型•单进程运作，通讯和业务逻辑并存•一般采用非阻塞方式工作服务进程连接池请求1请求2请求3请求n简单并发模型•主进程处理连接请求，有新连接到来时创建子进程处理数据•请求由子进程处理，处理完后子进程退出•每个子进程只处理一个连接主进程子进程1子进程2子进程N预创建模型-子进程accept•主进程预先fork一些进程•各个子进程竞争accept，然后处理数据传输•一个子进程可以处理一个连接，也可以同时处理多个连接连接池主进程子进程1子进程2子进程N预创建模型–主进程accept•主进程accept，通过流管道转发fd到子进程•子进程收到fd后，处理数据传输，处理结束后通知父进程•父进程处理的事情比较简单，容易监控子进程主进程流管道子进程子进程子进程...流管道流管道分发模型•通讯进程管理所有连接，实现海量接入•通讯进程只负责分发消息，包括上行和和下行消息•业务进程不关心通讯•通讯进程和业务进程之间通过内存管道共享数据通讯进程内存管道业务进程业务进程业务进程...内存管道内存管道Linux下的epoll技术•实现海量的TCP接入•实现轻量级的数据收发和链路管理•目前测试到的稳定链接数为50000•TCP服务器可以考虑使用epoll+logic的分发模型线程池模型•主线程管理所有通讯过程•可配置预分配线程池•以任务为单位来分配处理请求•每个线程同时只执行一个任务•提供稳定性能的服务ThreadPool...MainThreadActiveThreadActiveThreadSleepingThreadSleepingThreadSleepingThreadTask1Task2存储问题－张驰之道•没有存储操作的应用是最快的应用•存储问题的关键在于硬盘的随机读写速度•I/O繁忙的机器，CPU运算一般很空闲•存储问题的解决之道，就是要善用CPU和内存来缓解磁盘读写的压力Cache策略•磁盘内容在内存中的镜像就是Cache•在Cache中保存访问频率最高的磁盘内容•当该内容被再次访问时，从Cache中取，节省磁盘读操作•当该Cache被多次更新后，再同步到磁盘，节省磁盘写操作善用顺序读写•磁盘的顺序读写性能要远远大于随机读写•延迟写会导致异常崩溃下的更新丢失•使用另一设备的顺序日志记录历次更新可以在不影响效率的情况下保证数据一致存储问题实例－数据库•使用内存池存放磁盘Cache页面•使用淘汰算法保证磁盘Cache的命中率•使用顺序物理日志记录Cache更新•异常崩溃下使用物理日志和逻辑日志恢复数据一致载衡问题－分合之道•合理界定功能类型•合理分布处理能力•合理选择扩展方式•终极目标还是平衡功能类型界定•少更新、多读取可谓之下载型服务器•多更新、少读取可谓之采集型服务器•多更新、多读取可谓之交换型服务器•少更新、少读取可谓之无态型服务器处理能力分布•下载型服务器采用一对多的中心分发策略•采集型服务器采用多对一的中心汇聚策略•交换型服务器需要使用前端索引分布•无态型服务器可用作中枢，任意分布•视界越广的节点，功能越轻扩展方式选择•集中的分布配置利于方便扩展•有效的重定向手段利于平滑切换•单纯的节点功能利于平行扩展•适当的无态节点引入利于理清架构同步分布模型•客户方在发起请求后进入阻塞，直到服务方处理请求后返回响应或者等待超时•优点是良好的封装性•缺点是效率低下，一般和线程池模型配合使用•RPC技术和NFS是典型应用客户对象服务对象请求响应异步分布模型•底层框架实现跨平台的软件总线进行消息分发和寻址•客户方和服务方作为符合总线标准的对象挂入总线异步通讯•优点是效率高，扩展性好•缺点是程序模型复杂，开放性稍差软件总线网络主机客户对象客户对象网络主机服务对象服务对象网络主机网络主机网络主机分布示例-QQGame分布图DirServerDBServerMainServerMainServerDBServerProxyProxyDBServerMainServerDirServerDirServerLCDServerMainServerMainServerMainServer可用问题－缓急之道•故障是不可避免的•高可用的目的在于避免单点故障造成整体故障•一般使用节点冗余提高系统可用性•解决可用问题的关键在于把握投入和产出的平衡服务安全等级划分•业务安全性-用户在系统中能否正常使用某项业务功能•系统安全性-用户能否正常使用系统•数据安全性-用户在系统中的数据能否保证不被破坏解决可用性问题•业务安全性节点一般使用故障感知和快速重起的手段•系统安全性节点需要使用热备手段作服务无缝切换•数据安全性节点需要定期在线备份和离线备份的手段常用HA模型•热备方式-不间断状态•冷备方式-不间断服务•N+M方式-整体策略热备模型•双机相互独立，但对外提供单一服务视图•双机状态随时保持同步，互通有无•FailOver•不影响正在使用服务的用户•冗余级别最高的备份模型主用服务器备用服务器主用数据备用数据冷备模型•双机共享存储设备•双机状态不保持同步•主机故障，备机接管服务•服务不会中止，但正在使用的用户将受到影响主用服务器备用服务器共享数据FailOverN+M模型•服务器群组概念•N为主用设备数•M为备用设备数•任何主用设备设备故障，即按一定次序启用备用设备•允许出现最多M次故障•一般用于无态服务器服务器群组备用设备主用设备一般HA策略•系统+数据安全性节点使用热备方式•系统安全性节点使用冷备方式•业务安全性节点使用N+M模型