理解高并发的真正含义

1).什么是高并发？
  1s内我们能够处理多少个请求，并发. 如果并发成绩特别的漂亮-->这叫高并发;
  每个请求的复杂度，是不是决定了我们并发的多少？
  2核心-->2个线程-->业务量处理完一个请求需要1s，那么最多并发差不多2个左右；
  
  业务的逻辑复杂度，决定了我们的并发因素之一；
  能够做到不让CPU休眠，做到高占用率的CPU下，我们最多能处理的并发请求-->高并发；
  做到,1s内多少个请求-->cpu核心都占满了；
  1s，系统，2个核心-->1s，另一个核心在休眠，这个时候，系统就没有做到高并发，因为本来能处理更多请求，不让cpu休眠，说明没有充分利用系统硬件资源；

2).高并发的本质到底是什么？
  1.业务越简单，我们处理的速度越快；
  2.业务不简单，卡主线程在计算，然后计算的过程中，我们可以利用多线程，多进程等，我还可以响应其它请求.
  3.高并发并不是说处理10W请求，而是和硬件设备资源有限的情况下，

3).高并发的2种解决方案？
  1.核心业务逻辑，不做复杂运算，如果有？我们则用线程池去计算，这样核心业务逻辑还可以继续接入其他人请求；
    1.异步IO就是这个思路； 本来读取IO是一个耗时操作，业务逻辑线程不等在IO上面，做好后通知，这样核心业务逻辑不被卡住；node.js
、redis就是这样搞。
  
  优点: 核心业务逻辑编写起来非常简单；
  缺点：1.大量异步 + 回调-->你编写的代码其实非常不爽； 3个等待条件的业务逻辑，一个逻辑写起来会很不方便；-->能忍受
        2.主业务逻辑，使劲的搞，毕竟只有一个-->36核心的CPU-->做多利用18个核心； -->18个核心在休息，那无法忍受-->解决方案：多进程(但是需要人工干预);	
		 
        核心业务逻辑放在一个线程，这个线程所能处理的始终有限制，所以原子操作得并发是有上限-->结果18个核心就把这些工作做了，那么另外18
        个核心就用不上了，所以不能高并发-->可能调度不到18个线程

         	
  2.核心业务1s，卡主就卡主了，没有关系，我们可以另外的线程来接入你的请求；每个核心业务是看做一个完整的流程，高并发；
  
  实现思路：
  step1： 读取cpu的核心数目，启动我们的线程池，核心*2；
  step2：你可以把你的业务请求，做成一个一个的任务，线程池来调度这些任务；
       

  优点： 任务-->一路写下去就ok，没有异步的烦恼；
  缺点：
      1.请求和任务独立分开了-->假设他们之间有些依赖的时候，这个时候也会很麻烦； 尤其是访问共同的资源；
  
4).NB的逻辑服务器都用那些方案？
  实现方案1的案例：很多公司都在用-->redis-->主线程带我们的很多游戏场，多线程来支撑我们的复杂计算-->没有锁，比较简单。
  
  实现方案2的案例： -->skynet-->开源的服务器底层框架；-->多个游戏场有多个线程在带动，一个游戏场可能有多个线程带动
  
  卡主可以，但是其它的核心能接入，而是能把多核利用起来；而不是卡主1个，卡死全家；
  
  房间1，房间2，房间3，房间4....很多房间   有耗时计算，有问题，卡死一个线程，卡死全家
  
5)分析我们的游戏服务器，是否合理； 同时在线人数上不去时：

  1)
    1.分析cpu；
    2.分析带宽；
    3.分析磁盘IO；
    4.分析内存；  
  
    如：cpu(50%),上不去了，尽可能的让我们的业务量，更轻巧； 让我们的业务量更轻巧-->由于某种需求，真的无法轻巧了，我们需要用多进程来部署了。
  
    算法最好要好-->耗时的算法,尽量搬到多线程中去做-->耗时的算法-->多线程来做，不卡主其它；
  
  2)
  不要轻易动手-->猜猜猜，可能有什么问题，怎么改，怎么搞都用处不大；
  
  基本原理，胆大，心细，找证据，想办法
  
6)
  os的基本原理
  
  做服务器，我们需要搞基础, os线程调度基础，锁的lock开销；
  
  多核心开发的本质到底是什么；
  
  做业务逻辑，如状态同步，帧同步，断线重连等；
理解高并发的真正含义

猜你喜欢
