14.4 并发模型在线视频

下面的话我们会来

继续下一部分

前面

其实我们讲到就说一款游戏

它可能会有海量的玩家

大家会有大量的玩家过来去玩

这些玩家

他需要有各种各样的一些需求

比如说

那么我们常见的

玩游戏里面放一个技能呀

还有我们购买一次

购买一次道具

这些相关的的游戏内的操作

最终都会通过网络

把它发送到云端的游戏服务器

那么这些服务器程序拿到之后

都会把这些业务转换成

代码

并且最终会在CPU的

变成CPU的一个执行单元

实际上最终来看的话

它都是一个CPU的一个执行单元的一个

调动

大家都知道我们海量的

海量的玩家的时候

他也需要大量的机器

但是我们的机器不可能

我们的硬件设备不可能是无限的

那么他是有成本的

所以我们需要去考虑

如何让游戏的分布式系统中的

每一个程序

都尽可能的

去提高CPU的利用率

来更多的去

处理玩家的一个请求

这样的话做到一个

硬件成本的一个

最低化或者将降低硬件成本

那么到这里来的话

大家可以注意到一个关键词叫

提高CPU的利用率

那么这里就是我们

并发模型

需要去重点去解决的

如何去提升CPU的流量

在这里大家就可以来看一下右边

右边这张图

这张是一个很简单的示意

就说CPU的一个时间片

在执行的过程中

我们可以先看上半部分

需要串行执行

但我们有A B两个请求

或者叫AB两个任务的时候

那么A是分为两部分叫A1和A2

那么B它也有两部分叫B1和B2

那么在创新执行的时候

我们会先执行

这个请求

请求A的第一部分叫A1

那么A1执行完了之后

他

可能会需要一些数据

这些数据

比如说我们是一个IO读磁盘文件

或者是他需要数据库里面的

某一行数据

那么这个时候

A1

后续执行A2的时候

A2一定要等到数据到来

那么这段时间

可能是一个空闲的时间

那么这个时候如果按计划执行的话

那么叫同步执行

那么这个时候这段时间

CPU是不能做事情的

因为

他需要等待数据的到来

才能继续执行A2

那么A2执行完了之后开始执行B1

那么B1执行完了之后

等到B2的时候

这时候又需要等待一个数据的到来

比如又去了一次数据库

那么这样的话就变成了A1

它的整个执行过程变乘A1

等待A2 B1等待B2

那么大家可以看到它的CPU利用率

大概只有三分之二

剩下三分之一的时间都是在等待在这里

那么这是只有两个任务

如果我们有很多个任务同时在执行的时候

那么它等待的时间会更长

这就是创新化或者叫同步执行

那如果我们可以把它改成一个叫并发执行的话

就代表的

当我的CPU执行A1任务完了之后

我需要等待数据

才能执行A2的时候

那么可以先

就是不要等在这里

我们去执行B1

因为这个时候B1是可执行的状态

那么转到B1那里执行

等B1执行完了之后

数据就已经到达了

我们再去执行A2

A2执行完同样的

你会发现它的B2需要的数据也到了

那么就变成了A1 B1

A2 B2没有任何等待的时间

所以这就是我们把一个简单的模拟一下CPU

它的时间片

从一个串行的同步执行

变成了一个并发的执行的过程

CPU的利用率

从66%左右 67%

提升到100%

那么在实际运行中

那么这CPU的利用率是差别是非常大的

那么

我们把这个

这个过程可能听起来

好像就是很简单

那或者是叫

就是不是很接地气

我们把它转成在游戏中

它假如说我们的游戏中的场景

就说有两个玩家

第一个玩家登陆上来了之后

它发了一个登录请求

那么这个登录请求我们需要的第一步

先去数据库加载他的账号

我们把它定义为A1

那么第二步就是我要更新它的数据库

比如说把他的

登录时间要改一改

他的一些登录次数啊

相关的数据改一改

那么会有两步A1和A2来做

同样的另外一个玩家

刚好点了个购买道具请求

那么它这个购买道具请求

也分为两步

去第三方扣款

第三方扣款对吗

假若是B1

那么第二步更新数据库是B2

那么其实把这个场景

带到我们右边

那个图里面

大家就能清晰的感受得到

其实大家玩家的请求

发送到游戏服务器测

就会被进行任务的分解

那么任务分解的话就是执行

就需要有个调度的一个CPU调度

提升效率

CPU利用率的一个场景

那么需要等待的地方

像有我们常见的有等待数据库

有等待磁盘IO

还有等待第三方的RPC的数据

那么

我们为什么要做这种

并发模型的目的就是为了提高

单个程序的

他的一个吞吐量

他的一个处理请求

处理玩家的请求的一个能力

这样的话从而

提高单台设备他的一个承载

降低整个的系统的成本

同时还有延迟要低

点一个技能

大家玩游戏

放一个技能

总希望他立马就有反应

而不是希望他过了一段时间或者过了几秒钟

他感觉

才开始有所反映

比如说伤害出现对吧

有特效效果播放

那这样的话

大家会第一个反应是我卡对吧

太卡了

没法玩

还有一个就说我们要考虑我们的编码的开发效率

那么除了我们前面说

并发

他其实有很多种方式来实现这种

这种并发

那么像我们理解常见的有一些

比如说多进程的模型

大家做Web的话

大家会可以了解Nginx

Nginx它其实是一个

多线程的

多进程的一个调度模型

它是有一个Master进程

和一堆的Worker进程

那么通过Master对Worker的进程之间

进行一个调度

从而充分的提高这个CPU的利用率

那么还有多线程的一个模型

像Java的线程池

它就是

线程池本身是一组线程

那么这组线程上面运行的一些任务

我们叫Task

那么对于应用侧来讲的话

它会不断的提交

他的Task或者叫所谓的计算任务

提交给

任务队列

任务队列的话会有

会有其他的有叫线程池的线程

会不停的去取

我们可以叫他work线程

它不停的去对立面去取任务

去执行

从而实现一种

前面提到的

这种调度模型

也是为了提高这个CPU的一个利用率

那么还有一个就是现在

就是也比较火的就是协程模型

大家协程模型

协程大家可以理解为

用户它的或者叫轻量级的一个线程

这道线程的调度是操作系统来维护的

用户或者叫我们写程序的开发者

对他的掌控

相对来讲不是很大

因为它的什么时候

什么时候开始进行调度

什么时候开始让它运行

什么时候让它Bloken在哪里那么很多是由操作系统决定的

那么协程的话

它是由用户能决定的

也就是说所以

程序或者叫开发者

他能够去控制的

这块的协程之间的一个调度

那么它的特点是

它是用户级的一个CPU的调度模型

那么

可控力度会更强一些

对开发者来讲

那么它是一个非抢占式

意思就是说

别人是你在

占用这个CPU时间的过程中

别人是没有办法把你直接抢占

同时

如果说那既然别人不能抢了

别人什么时候用呢

那么这时候就靠

当前的运行的执行单元

它自己能够主动出道

当它发现我对它这个任务执行到后面

需要去等待第三方数据

等待别的数据的时候

我要主动去调用

类似它的yield的接口

就说我现在让出CPU

同时

要把整个系统里面的

同步等待的操作要变成一步的

因为如果你同步等待在那里CPU在空转

其他的协程也用不到

那么这里就讲到一个很重要的一个地方

就说我们的携程

它需要有一个协程之间的一个调度

那么

这个调度还有个调度算法

那么通常有

有的编译器或者语言层面

它自己就已经帮你实现了

第二种就是我们自己来实现

那么现在在业界来讲的话

我们一些代表性的

像Golang和Lua里面都是语言层面支持的这种协程

那么协程的调度也是交给

应该是语言层面自己去解决

那么用户台

就说开发者来实现的话那么像

LibCo

这是由腾讯的微信部门

它们开元出来的一套协程的一套框架

那么内部就是完全由自己来实现的

协程之间的一个

调度

来实现CPU的一个调度的一个过程

那么这一块的话

大家有兴趣可以去看一看

LibCo比如说它的源码的一些实现

里面会涉及到一些汇编的一些知识

然后语言层面的话

Golang和Lua都可以去

去自己去动手写一些代码或测试用例

让整个模型区并发起来

这样的话

大家可以能够体会的到

当一个程序能够同时服务于多个

客户端或者多个用户的时候

让他们并行的跑起来

而不是在那里

创新的等待

这样的话

这个对整个CPU的利用率

以及他的一个时延

都会是一个非常好的一个体验