服务器开发模式

server model

导读

参加“服务器开发模式”的技术讲座，写一篇简单的笔记，后续可以以此为框架，补充对应的知识。重视底层硬件约束，基本的架构（如冯·诺依曼结构），和数学抽象。没有数学，不深刻，无以揭示本质，陷入繁芜丛杂的细节，只见树木，不见森林；没有底层硬件和项目实践，理论的知识会苍白，不鲜活，无法学以致用。

图灵和哥德尔不完备定理

Server模型

迭代模型

最单纯的服务模型

并发模型

子进程accept

关键词：thundering herd

n computer science, the thundering herd problem occurs when a large number of processes or threads waiting for an event are awoken when that event occurs, but only one process is able to handle the event. After all the processes wake up, they will start to handle the event, but only one will win. All processes will compete for resources, possibly freezing the computer, until the herd is calmed down again. from wiki

主进程accept

关键词：MSGHDR

分发模型

关键词：SPP

线程池模型

关键词：CQRS，Schedule Thread Pool，Session Map，Session Thread Pool，Event Map，Connection Thread Pool

Server要素

von Neumann结构

控制器用于调度，运算器才是实际做事情的部分。控制器类似于管理者，无实际产出，运算器类似于员工。技术人员常说想专心做技术，其实是一件成本很高的事情，在这个随机的世界里，需要其他很多部分来配合，才能产生有序的价值。

计算问题：提高CPU的利用率

基本的门电路原理（加法器）

多进程

存储问题

磁盘的读写

磁盘性能问题的解决办法

cache策略：充分利用CPU和内存资源来缓解

分级处理：区分热点数据和非热点数据

利用顺序读写，减少寻道次数

当需要写入数据的时候，可以先写日志，即使此时数据库的数据没有完成写入，也没有关系。写日志的速度大于写数据库的速度。原因在意：写日志是顺序写的，而顺序是由时间保证的，即按照时间顺序写入即可。写入日志了，即使此时断电了，也没有关系，可以根据日志恢复数据。而数据库的写入，有各种各样的关联，不是完全的顺序读写，相比之下，要比写日志慢。

问题：如果写入日志成功了，但数据库数据没有完成，此时访问相关的数据怎么办？Redis之类的内存数据库来解决此问题？

SSD

IO问题

OSI模型

通讯模型

信息传输的三大特性：

  1. 完整性-丢点行么
  2. 顺序性-乱点行么
  3. 时效性-慢点行么

侧重完整性

http协议？

侧重顺序性

侧重时效性

如音视频的传输协议，就不注重完整性，可以丢帧，但注重时效性。

TCP

内网如果无充分的流量竞争的情况下，可以使用无流量控制的协议，不用慢启动控制（e为底数的算法，如生物的繁衍的种群增长就是以e为底数的曲线）

UDP

应用协议

考察角度：可读性，流量，编解码，可拓展性，兼容性

Server服务

集成方式

性能指标

并发量和单次延迟要一起考察，只考察其中一个是没有意义的。如吞吐量最大的方案，莫过于使用飞机运送硬盘，但延迟太大。

负载均衡

过载保护

灰度

为什么要灰度

如何灰度

平滑扩容

数据层很难扩容。数据库数据一般情况下不敢轻易修改。从开始的时候，就要考虑数据库的扩容。如通过路由分发，分片存储。

自服务和诊断

change log