yanchendage的博客

规定好最大延迟，测出单台机器最大qps，再根据你预计的人数，就知道了需要多少台机器参考。

什么是event loop呢，中文翻译为事件循环，怎么讲呢，你雇了一个看门大爷，让他一直在门口巡逻，有事情就通知你来处理，这就是event loop，我理解把这种不断监听事件、有事件就通知别人处理（自己不处理）的工作模式就叫做event loop，比如多路复用的select，他就需要不断监听accept、read、write事件的到来，来了再通知别人处理，这种工作模式就是event loop，简单点你就理解就是一个看门大爷。另一个是 workerGroup, 用于处理与各个客户端连接的 IO 操作。

其实mutil 和 paxos已经很接近了，我这里只是说一下区别吧。最大的区别是日志Paxos的日志Raft的日志其实就是raft的日志更整齐一些，当需要重新选举leader的时候直接选择日志最完整的就可以了，但是paxos存在所谓的日志空洞，当重新选举leader的时候需要通过计算补齐一下日志。这就比raft在选择leader时候理论上慢了一些。

有一个东西叫io模型、还一个东西叫线程模型。io主要讲的是通过多路复用技术通过一个进程或者线程接受成千上万请求，你接受到了请求怎么处理就是我们今天聊到的线程模型。你到底是只有一个进程/线程，还是多个进程/线程就看你自己的。reactor叫反应堆，还一个外号叫dispatcher。dispatcher分配的意思，分配什么啊？当然是你有事件来了我给你分配啊，这里的事件不就是io请求么，通过多路复用来了一个io事件，我给你分配一个方法处理一下。说白了就是又当爹又当妈，爹妈是一个进程，通过select获取到事件后

这是三高专题的第二篇，我想了很久应该怎么去串联这个专题，后来我觉得就按照流量的方向来聊吧，从用户请求到服务端再到用户。我们一台服务器能承受住200万个请求么？答，可以，但是有条件只能是三次握手后的空链接，我们知道linux中一切皆文件，因此一个请求对一个linux来说也是一个文件fd，那只要我的linux文件数量足够大就可以接收200万个请求，一个请求默认为4k，200w * 4k 不过8M左右的内存是没有问题的，但是前提这些都是空链接，如果客户端发送了大量的数据到服务端，服务端又需要通过做cpu做大量的计

虽然日常curd boy，但是也要有点追求，没有场景我们自己造场景，那我就定一个200万并发秒杀的场景吧。就是来了多少人啊，比如618，xxx直播间某件商品有100万人秒杀，那并发量就100万，但是不是说你来了100万我就能同一时间全给你处理了，咱们可以10万10万的处理。吞吐量是单位时间内系统处理客户请求的数量。说白了就是1秒内能处理多少。在并发量较低的情况下，吞吐量与并发量成正比，此时后台处理能力充足。当并发量到达一定的数量后，服务器处理能力不足（线程切换），吞吐量反而降低。比如刚开始并发是10个，每个