rpc的几种服务端模型分析

rpc(Remote Procedure Call)是一种通过网络从远程计算机程序上请求服务而不用了解细节的协议。通常client端为服务的调用方,server端为服务的提供方。他们之间可以在不同的网络、不同的机器,使用不同的语言。

server端作为一个网络的服务提供者,需要能为多个client端提供高质量的服务,如下总结了几种服务端的模型。

    (一)单线程模型

一个线程顺序处理所有请求。

优:简单

缺:同一时刻只能处理一个连接请求

    (二)多线程模型(短连接)

一个线程处理一个请求后即刻关闭该连接,重新接受新的连接请求。

优:可以同时处理多个请求

缺:频繁的建立连接&关闭连接,额外开销大;并发多少请求就需要多少个线程。

    (三)多线程模型(长连接)

一个线程处理一个连接上的多个请求,每个请求完毕后不关闭连接,继续监听该连接,直到对方关闭连接。

优:长连接模式,一个线程顺序处理一个连接上的所有请求

缺:线程数固定,当请求量小时浪费资源,请求量大时可能线程数不够而使得有的请求失败

一般将线程数设置的足够大。

    (四)线程池模型

生产者+消费者模式

一个accept线程处理所有的连接请求,建立连接&将请求放入任务队列。

多个worker线程从任务队列取请求进行处理。

优:

1、将接受请求和处理请求分开,使用单独的线程处理轻量的工作(建立连接and接受请求),线程数不用再与并发连接数相同;

2、提前创建好线程,避免频繁创建&销毁线程带来的开销;

3、使用epoll同时监听多个socket,IO复用

缺:

如果线程数设置的不够,导致任务队列满,后续的请求被拒绝。

【处理】

  • 连接fd数超限制:直接关闭连接、拒绝请求
  • 队列满:直接关闭连接、拒绝请求

【多少线程合适】

里特尔法则

L = f W

L - 系统里的请求数量

f  - 请求到达的速率

W - 每个请求的处理时间

如果f(请求达到的速率)为100/s,W(每个请求处理的时间)为10ms,如果是单线程,1s到来的请求刚好可以在1s内处理完;如果f变为1000,则L=1000*0.01=10,因此需要10个线程才能使请求不堆积。

  • 线程数少了

无法充分利用资源,任务堆积,客户端长时间等待

  • 线程数多了

系统资源消耗

【远端调用】

如果该服务的处理还需要调用其他的远程服务,那该服务的性能很大程度上依赖于远端服务的性能。如果远程服务的性能下降,系统中的线程数量就会迅速达到线程池的上限,其他后续到达的请求就会被丢弃。

  • 隔离不同远程服务

如果不同的请求依赖不同的远程服务,一个服务出问题可能影响到其他服务。针对不同的后端服务请求,设置不同的线程池可以解决。

  • 截止时间

给需要远程调用的请求规定一个截止时间,如果规定的时间没有响应,就丢弃这个请求。避免远程服务给本服务带来的影响。

  • 快速失败

对后端服务做请求监控,将判定出问题的远程服务标记为失效。当后端服务被标记为失效时,所有的后续请求都会迅速失败,而不是进行不必要的等待。当然,也需要一种机制判断远程服务何时恢复为可用的。

  • 并发

如果一个请求需要独立地请求多个后端服务,那么这个请求就应该能并行地调用这些服务,而不是串行地调用。

时间: 2024-10-14 13:07:53

rpc的几种服务端模型分析的相关文章

使用 neon-wallet-db + neon-js + NEO-cli /rpc 搭建轻钱包服务端

本文将搭建一个不具有任何功能的NEO轻钱包,所有的精力都仅集中于成功运行neon-wallet-db项目并搭配全节点的neo-cli /rpc接口为轻钱包客户端提供服务. 首先需要准备几个项目: neon-wallet-db neon-js neo-cli 然后是劝退部分,即笔者完成壮举准备的环境: 4台debian虚拟机,均运行共识节点 4台虚拟机中一台作为RPC节点运行提供/rpc接口 4台虚拟机中另一台运行neon-wallet-db项目 运行neon-wallet-db项目的前提如下:

使用Thrift RPC编写程序(服务端和客户端)

1. Thrift类介绍 Thrift代码包(位于thrift-0.6.1/lib/cpp/src)有以下几个目录: concurrency:并发和时钟管理方面的库processor:Processor相关类protocal:Protocal相关类transport:transport相关类server:server相关类 1.1 Transport类(how is transmitted?)负责数据传输,有以下几个可用类:TFileTransport:文件(日志)传输类,允许client将文件

Hadoop RPC源码阅读-服务端Server

RPC服务端的实例代码: public class Starter { public static void main(String[] args) throws IOException { RPC.Builder build = new RPC.Builder(new Configuration()); build.setBindAddress("localhost").setPort(10000).setProtocol(LoginServiceInterface.class).s

性能测试-服务端瓶颈分析思路

概述 性能测试中,对服务端的指标监控也是很重要的一个环节.通过对各项服务器性能指标的监控分析,可以定位到性能瓶颈. 后端性能指标有CPU,内存,网络,I/O等等 分析思路 整体系统CPU利用率 内存利用率 磁盘I/O的利用率和延迟 网络利用率 CPU定位分析 CPU利用率大于50%,需要注意:大于70%,需要密切关注:高于90%,情况比较严重. 监控命令:vmstat.sar.dstat.mpstat.top.ps 类型 度量方法 衡量标准 利用率 1.vmstat 统计1-%idle 2.sa

Jquery Ajax处理,服务端三种页面aspx,ashx,asmx的比较

常规的Jquery Ajax 验证登录,主要有3种服务端页面相应 ,也就是 aspx,ashx,asmx即webserivice . 下面分别用3种方式来(aspx,ashx,asmx)做服务端来处理 Jquery  Ajax 传过来的用户名和密码验证! 例: Login.html 请求用户名和密码验证! <head> <script type="text/javascript"> $(document).ready(function() { $("#

游戏服务端架构 介绍

游戏服务端架构 介绍 端游.手游服务端常用的架构是什么样的? http://www.zhihu.com/question/29779732 根据知乎问答文章整理而成. 作者:韦易笑 谢邀,手游页游和端游的服务端本质上没区别,区别的是游戏类型. 类型1:卡牌.跑酷等弱交互服务端 卡牌跑酷类因为交互弱,玩家和玩家之间不需要实时面对面PK,打一下对方的离线数据,计算下排行榜,买卖下道具即可,所以实现往往使用简单的 HTTP服务器: 登录时可以使用非对称加密(RSA, DH),服务器根据客户端uid,当

用http请求thrift服务端出现了内存溢出的情况

记一次内存溢出的分析经历 - Janti - 博客园 https://www.cnblogs.com/superfj/p/8474288.html 说在前面的话 朋友,你经历过部署好的服务突然内存溢出吗? 你经历过没有看过Java虚拟机,来解决内存溢出的痛苦吗? 你经历过一个BUG,百思不得其解,头发一根一根脱落的烦恼吗? 我知道,你有过! 但是我还是要来说说我的故事.................. 背景: 有一个项目做一个系统,分客户端和服务端,客户端用c++写的,用来收集信息然后传给服务

端游及手游服务端的常用架构

这篇文章还是讲的不错的: http://www.cocoachina.com/game/20150924/13545.html <开发者详解:端游及手游服务端的常用架构> 整理自知乎,文/韦易笑 开始的部分讲的比较简略.讲到后面大型MMO以及战网游戏,就比较入流了. 开宗明义,手游页游和端游的服务端本质上没区别,区别的是游戏类型. 类型1:卡牌.跑酷等弱交互服务端 卡牌跑酷类因为交互弱,玩家和玩家之间不需要实时面对面PK,打一下对方的离线数据,计算下排行榜,买卖下道具即可,所以实现往往使用简单

端游、手游服务端常用的架构(转)

http://www.skywind.me/blog/ 作者:韦易笑链接:https://www.zhihu.com/question/29779732/answer/45791817来源:知乎著作权归作者所有,转载请联系作者获得授权. 类型1:卡牌.跑酷等弱交互服务端 卡牌跑酷类因为交互弱,玩家和玩家之间不需要实时面对面PK,打一下对方的离线数据,计算下排行榜,买卖下道具即可,所以实现往往使用简单的 HTTP服务器:登录时可以使用非对称加密(RSA, DH),服务器根据客户端uid,当前时间戳