协议的组成部分,协议定义是,协议的组成部分,协议定义为

　　在I/o密集型的程序中，协议生成线程的切换远远小于CPU的操作，所以往往需要CPU等待I/o操作。IO的同步需要切换线程，以便操作系统可以在IO期间执行其他内容。这样代码符合人类的思维习惯，但是大量的线程切换带来了大量的性能浪费，尤其是IO密集型的程序。

　　异步IO之后，人们发明了异步IO。就是在数据到达时触发回调。可以减少线程切换造成的性能损失。但是，这样的缺点也很大。主要缺点是操作“切片”。代码不是“一口气写出来的”。每次数据到达，都要判断数据是否经过充分的处理。如果处理得当，那就处理吧。如果处理得不够好，就等着吧。这段代码可读性很低，不符合人类习惯。

　　最后，提出了解决方案。协和式飞机可以很好地解决这个问题。例如，IO操作被写成索引。当I/o操作被触发时，CPU会自动将其传递给其他伙伴。要知道，协和的开关很轻。通过对异步IO的封装，该协议保证了性能和代码的可写性和可读性。在高I/o负载的程序下。然而，CPU密集型程序没有任何好处。此外，还表明I/o负载高的服务适合该协议。

　　Concord协议就是为了解决低速IO和高速CPU之间的协调问题而诞生的。解决这类问题有三种有效的方法。

　　异步网络编程(如libevent、libev、redis、Nginx、memcached)、golang、gevent、lightweight thread)在语言层(erllevent)进行抽象。

　　为什么不用异步回调？健康人的思维基本是线性的。当然，你可以做出部分发散的判断，但你的思维只能沿着那个发散一致地前进。异步回调最大的问题是破坏了人类的线性思维模式。逻辑上线性的过程必须分成几个部分。每个片段的开始和结束是异步事件的完成和开始。经过一些训练，你可以适应这种思维模式，但你还是要付出额外的精神负担。与人类思维模式相对应的是，很多常用的编程语言都是命令式的，程序本身呈现大致的线性结构。异步回调不仅破坏了思维的一致性，也破坏了程序的一致性，所以你在读程序的时候可以花更多的精力。这些因素都是软件项目额外的维护成本，所以大部分企业都不喜欢异步回调框架，比如node.js和RxJava，虽然可以提高程序的并发性。

　　比如为了了解APP解决了哪些问题，就要搞清楚线程存在哪些问题。首先，让我们考虑最简单的web服务器。显然，服务线程的数量与处理器的数量相同。如果将每个请求合并到一个线程中进行同步处理，CPU将不会得到充分利用。处理一个请求包括两个部分：IO和计算。处理的IO不需要占用CPU，但是可以提高CPU的利用率。

　　增加服务线程数，按需制作线程，从线程数不限的线路qjdyb获取线程。处理IO时，线程处于睡眠状态，不消耗CPU。因此，可以提高系统的线程调度能力。服务线程的数量是固定的，但是IO部分是异步处理的。当只处理计算部分时，向有限数量的服务线程发送请求的方法具有这样的优点，即在处理请求时也可以使用同步逻辑。缺点是线程太多会增加线程调度开销，影响服务器性能。并发越大，线程越多，系统需要保证线程调度的公平性。所以线程越多，线程上下文切换的次数就越多，切换开销也就越大。其实这种方法并不适用。第二种方式是服务线程数量固定，但是IO部分异步处理。只有当计算部分被处理时，请求才会被传递给有限数量的服务线程。优点是性能高，缺点是同步处理最直观的任务需要改成异步处理。当然，制作web server的现成库有很多，IO异步处理的逻辑已经完成。然而，web服务器只是使用多线程的场景之一。有些任务改成异步处理比较麻烦。此外，将同步流程改为异步流程的基础设施本质上是不足的，需要改变APP的应用层逻辑来优化性能。两种方法各有利弊，但协和要解决的问题是结合两种方法的优点，避免其缺点。协调任务使用同步逻辑，只要同时数量相等就可以创建协调。所以也有比用协和更适合线程的领域。那么为什么说协和是轻量级线程不合适呢？协和协议越多，进度开销越大？简而言之，协议更像是一个任务，而不是一个不断运行代码的处理器。系统不需要保证协调调度的公平性，只能在特定时间从一个协调切换到另一个协调。例如，当执行多个协议时，CPU被主动转移/阻塞等。由于增加协议数量不会增加单位时间的协议切换次数，所以不需要考虑任务调度和大量的协议。

　　以及协议和线程的区别，协议实际上可以认为是比线程更小的执行单元。为什么他是执行单元，是因为他有CPU上下文。只要这是正确的时间，我们可以将一个协和呼叫切换到另一个。只要在此过程中保存或恢复了CPU上下文，程序就可以运行。

　　Python可以使用多核CPU是因为一个线程可以有多个协议，一个进程可以分别有多个协议。

　　线程是同步机制，它们是一致的和异步的。

　　协议可以保持上一次调用的状态，相当于每次重新进入进程都要进入上一次调用的状态。

　　但是协同学有个问题，就是系统感知不到，所以操作系统不会帮你切换。那么谁会帮你做这个转变呢？为需要执行的进程获取更多的CPU时间是关键。我知道目前协同学实现相关的协同学框架一般都是1:N模式设计的。所谓1:N就是一个线程作为一个容器，里面有多个协程。那么谁来及时切换这些流程呢？答案是有主动放弃CPU的协程序，即每个协qjdyb中都有一个调度器，这个调度器是被动调度的。说明他不会主动派遣。

　　当一个协程发现自己无法执行时(例如，异步等待来自网络的数据，但是还没有数据)，这个协程可以通知调度器。这时就会执行调度器的代码，调度器会根据预先设计的调度算法找到最需要CPU的协程。切换该协同进程的CPU上下文，将CPU的运行权交给该协同进程，直到该协同进程无法执行，以此类推，或者调用主动放弃CPU的API，触发下一次调度。没错，没错。它类似于领导者模型。那么这个实现有问题吗？其实是有问题的。假设这个线程中有一个协程是CPU密集型的，他没有IO操作，也就是不会主动触发调度器的调度进程，那么其他的协程就不会被执行，这种情况需要程序员自己去避免。这是一个问题，如果业务开发人员不了解这个原理，可能会有问题。

　　为什么博客认为协作是一种趋势？