从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

18 | 单服务器高性能模式:PPC与TPC

李运华 2018-06-07
高性能是每个程序员的追求,无论我们是做一个系统还是写一行代码,都希望能够达到高性能的效果,而高性能又是最复杂的一环,磁盘、操作系统、CPU、内存、缓存、网络、编程语言、架构等,每个都有可能影响系统达到高性能,一行不恰当的 debug 日志,就可能将服务器的性能从 TPS 30000 降低到 8000;一个 tcp_nodelay 参数,就可能将响应时间从 2 毫秒延长到 40 毫秒。因此,要做到高性能计算是一件很复杂很有挑战的事情,软件系统开发过程中的不同阶段都关系着高性能最终是否能够实现。
站在架构师的角度,当然需要特别关注高性能架构的设计。高性能架构设计主要集中在两方面:
尽量提升单服务器的性能,将单服务器的性能发挥到极致。
如果单服务器无法支撑性能,设计服务器集群方案。
除了以上两点,最终系统能否实现高性能,还和具体的实现及编码相关。但架构设计是高性能的基础,如果架构设计没有做到高性能,则后面的具体实现和编码能提升的空间是有限的。形象地说,架构设计决定了系统性能的上限,实现细节决定了系统性能的下限。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(62)

  • 鹅米豆发
    不同并发模式的选择,还要考察三个指标,分别是响应时间(RT),并发数(Concurrency),吞吐量(TPS)。三者关系,吞吐量=并发数/平均响应时间。不同类型的系统,对这三个指标的要求不一样。
           三高系统,比如秒杀、即时通信,不能使用。
           三低系统,比如ToB系统,运营类、管理类系统,一般可以使用。
           高吞吐系统,如果是内存计算为主的,一般可以使用,如果是网络IO为主的,一般不能使用。

    作者回复: 赞,分析到位

    2018-06-07
    86
  • W_T
    老师在文章和留言里已经透露答案了。
    首先,PPC和TPC能够支持的最大连接数差不多,都是几百个,所以我觉得他们适用的场景也是差不多的。
    接着再从连接数和请求数来划分,这两种方式明显不支持高连接数的场景,所以答案就是:
    1. 常量连接海量请求。比如数据库,redis,kafka等等
    2. 常量连接常量请求。比如企业内部网址

    作者回复: 回答正确😃😃

    2018-06-08
    31
  • 武坤
    我怎么觉得,凡是高并发请求的系统都适合本节讲的高性能模式?!

    作者回复: 高并发需要根据两个条件划分:连接数量,请求数量。
    1. 海量连接(成千上万)海量请求:例如抢购,双十一等
    2. 常量连接(几十上百)海量请求:例如中间件
    3. 海量连接常量请求:例如门户网站
    4. 常量连接常量请求:例如内部运营系统,管理系统
    你再尝试分析一下看看😃

    2018-06-07
    1
    29
  • 正是那朵玫瑰
    根据华仔回复留言的提示,分析下
    1. 海量连接(成千上万)海量请求:例如抢购,双十一等
    这样的系统,我觉得这讲所说的模式都不适应,面对海量的连接至少要使用IO复用模型或者异步IO模型,针对海量的请求,无论使用多进程处理还是多线程,单机都是无法支撑的,应该集群了吧。
    2. 常量连接(几十上百)海量请求:例如中间件
    常量连接,我觉得这讲的模式应该可以适用,如使用TPC的preyhtead模型,启动几十上百的线程去处理连接,应该问题不大吧,但是老师举的列子是中间件是这类系统,我就有点疑问了,是不是中间件系统都可以是阻塞IO模型来实现,比如activemq既支持BIO也支持NIO,但是NIO只是解决了能处理更多的连接,而真正每个请求的处理快慢还得看后面的业务的处理;而阿里的rocketmq也是使用netty这样的NIO框架实现的。但在面对常量连接的场景下,NIO并没有优势啊。
    3. 海量连接常量请求:例如门户网站
    这种系统我觉得非常适合使用netty这样的NIO框架来实现,IO复用模型可以处理海量的连接,而每个连接的请求数据量会很小,处理会很长快,如华仔说的门户网站,只要简单返回页面即可。
    4. 常量连接常量请求:例如内部运营系统,管理系统
    这种系统,本讲的模式就很适合了。

    水平有限,望华仔指点下。

    作者回复: 写的很好,你的疑问补充如下:
    1. 常量连接模式下NIO除了复杂一点外,也没有缺点,因此也可以用。

    2. 海量连接情况下,单机也要支持很多连接,不然集群成本太高

    2018-06-08
    1
    17
  • JackLei
    看到这篇文章,这个专栏的价值远远远远远远远远远远远远远远远远大于专栏购买的价格。

    作者回复: 这篇这么值呀😄其实我觉得前面的更值,架构本质,架构设计目的,架构设计原则,架构设计流程……都是就此一家,别无分店😄

    2018-06-13
    12
  • peison
    请教一个比较小白的问题…为什么说门户网站是海量连接常量请求的情况?海量连接下为什么会常量请求,一直想不通

    作者回复: 海量连接:连接的用户很多
    常量请求:每个用户请求数量不多,大部分都是看完一篇文章再去点击另外的文章

    2018-07-24
    1
    8
  • 公号-代码荣耀
    BIO:一个线程处理一个请求。缺点:并发量高时,线程数较多,浪费资源。Tomcat7或以下,在Linux系统中默认使用这种方式。可以适用于小到中规模的客户端并发数场景,无法胜任大规模并发业务。如果编程控制不善,可能造成系统资源耗尽。

    NIO:利用多路复用IO技术,可以通过少量的线程处理大量的请求。Tomcat8在Linux系统中默认使用这种方式。Tomcat7必须修改Connector配置来启动。
    NIO最适用于“高并发”的业务场景,所谓高并发一般是指1ms内至少同时有成百上千个连接请求准备就绪,其他情况下NIO技术发挥不出它明显的优势。
    2018-06-07
    8
  • LakNeumann
    大神, ……纯新手感觉这里读起来已经有点吃力了 ~ 好难啊

    作者回复: 这是操作系统基础,可以看看《UNIX网络编程 卷一》

    2018-06-23
    5
  • qpm
    PPC和TPC对那些吞吐量比较大,长连接且连接数不多的系统应该比较适用。两种模式的特点都比较重,每个连接都能占有较多计算资源,一些内部系统,如日志系统用于实时监控的估计可以采用。这类型的系统一般连接数不多,吞吐量比较大,不求服务数量,求服务质量。不知道这样的假设符不符合?

    作者回复: 回答正确

    2018-06-07
    5
  • james
    互联网高并发的系统全部适应啊,现在C10K已经不是问题了,有些可优化度较高的系统(例如读多写少的系统)C100k的性能都很常见了

    作者回复: 互联网用ppc和tpc的不多呢,尤其是海量连接的场景

    2018-06-07
    5
  • 孙振超
    本章中提到的几个概念,比如阻塞、非阻塞、同步、异步以及主要的两种方式ppc和tpc,以前都是记住了,今天通过这篇文章是理解了而不再是记住了。
    ppc和tpc都是有一个进程来处理链接,收到一个请求就新创建一个进程或线程来处理,在处理完成之前调用方是处于阻塞状态,这种机制决定了单机容量不会太大。
    但在文章中提到数据库一般是ppc模式,但数据库通常是链接数少请求量大的场景,为什么会采用这种模式呢?reactor模式为什么不适合数据库?还望老师解惑,多谢!

    作者回复: 数据库链接数少请求量大,所以单线程或者单进程io轮询性能也高,因为一直都有数据处理,不会浪费时间阻塞等待,但数据库的引擎可以是多线程或者多进程,也就是说一条链接的请求交给引擎后,引擎可以是多线程来处理。

    reactor适应于连接数很大但活动连接并没有那么多的场景,例如互联网web服务器,reactor功能上也可以用于数据库,只是关系数据库都是历史悠久,久经考验,没有必要把原来的模式改为reactor

    2018-07-09
    4
  • 星火燎原
    像您说的这种多进程多线程模式好似更加稳定,但是tomcat为什么采用单进程多线程模型呢?

    作者回复: tomcat是java语言开发的,java用线程是最好的

    2018-06-07
    3
  • 无聊夫斯基
    我无法想到ppc比tpc更适合的场景

    作者回复: tpc异常时整个服务器就挂了,而ppc不会,所以ppc适合数据库,中间件这类

    2018-08-22
    2
  • 文竹
    PPC适合对稳定性要求高,但并发量不大的场景,对于互联网的场景不适合。

    TPC支持的并发量大,适合互联网产品场景。对于支持稳定性,需要创建冗余进程。

    作者回复: TPC支持的并发量也不大呢

    2018-08-19
    2
  • 海军上校
    如何系统的学习liunx~ 包括网络~文件系统~内存管理~进程管理~然后串起来形成面呢😂

    作者回复: 系统学习最好的方式就是看书,推荐《Unix环境高级编程》《Linux系统编程》

    2018-08-08
    2
  • blacknccccc
    ppc和tpc模式一般如何根据硬件配置计算可支持的并发数呢

    作者回复: 一般按照CPU核数*2来计算

    2018-07-23
    2
  • 孙晓明
    李老师,看完文章后查了一下bio和nio,还有一种aio,看的不是太明白,能麻烦您解答一下,并且它与nio的差别在哪里?

    作者回复: bio:阻塞io,PPC和TPC属于这种
    NIO:多路复用io,reactor就是基于这种技术
    aio:异步io,Proactor就是基于这种技术

    2018-06-22
    2
  • 大光头
    高吞吐和高稳定是互斥的,如果要高吞吐就要采用prethread模式,如果要高稳定就需要高preprocess,如果要综合,线程进程同时

    作者回复: 这就是apache的其中一个模式,线程进程结合

    2018-06-09
    2
  • xinsz08
    单台数据库服务器可以支撑多少并发?单台nginx 可以支撑多少呢

    作者回复: nginx反向代理可以达到3万以上,具体需要根据业务和场景测试

    2018-06-09
    2
  • ranger2
    游戏服务器还是比较注重于性能,一般都会特意挑选一个适合的线程模型:既要保证对单用户请求的顺序处理,还要保证内存可见性。

    在游戏服务器中,如果一个线程只用于处理一个连接的所有请求,那就是太浪费资源了
    2018-06-07
    2
收起评论
62
返回
顶部