广告投放系统网络基础架构简要描述

一：底层网络以及http servera：在多线程和多进程中选择多线程的模式
b：使用epoll模型，支持大量的http短连接，并且使用高效的边缘触发方式c：使用master，slave形式的结构，master线程负责接收请求，然后将fd分配给slave线程来监听读写事件d：设计定时器，支持超时处理。e：设计协议，包括http协议，可以选择使用开源的http协议解析，设计自定义协议，供内部客户端和服务端使用
二：异步调用客户端a：异步调用也设计了一些线程，和slave线程对应。初始化的时候将invoke客户端线程对应的连接都建立好。b：当slave线程需要做invoke操作时，选择一个invoke线程，将数据发送出去之后，只是发送出去，不需要返回，则发送则完毕，如果需要invoke的返回，则在invoke线程中设置对该套接字的读监听，一旦服务端有消息回来，则会被invoke线程接收到，协议解析之后进行相应的回调处理。c：异步调用能实现的根本原因是发送请求的时候设置一个唯一的sequence id，服务端接收消息之后，返回的时候需要将该sequence id写回来，那么客户端收到消息之后，就知道是哪个fd发送过去的信息，只要保存了发送消息之前的信息，回调之后则可以继续执行。d：adexcheng的异步调用则有些不同，异步invoke时带有一个唯一的request id，dsp服务返回内容也带一个request id，那么久可以关联到返回和发送，主要是组织数据结构比单个的invoke复杂一些，多线程以及锁的使用也要非常注意，一旦用的不好或者设计的不好，效率也不会高。e：异步调用最大的特点就是invoke出去之后不用等返回，可以继续执行后面的操作，如果等到设置的超时时间之后还没有返回，则认为超时（adexcheng超时处理也会比单个请求的要复杂）。
三：存储在广告行业中，调用存储服务都需要1到2毫秒就能返回，这就注定了传统的sql数据库不能满足广告后台的需求，只能选择nosql，目前市面上我认为最合适广告投放的nosql数据库则是redis。当然也有的公司选择使用自己写nosql数据库，以满足自己多变灵活的需求，但是我个人觉得如果自己认为能写的比redis好，才考虑自己去写，而且如果自己去写的话，至少需要一个人几个月的时间。
总结：这样的一套服务器框架和异步调用框架，设计的初衷就是高性能，设计好的话，肯定不会比任何大公司的框架慢，至少是行业领先的框架。我以前经历的两家公司，一家使用apache做http server，并且没有实现异步调用，使用这套框架性能方面肯定是秒杀那套方案（因为线上可以轻松的达到上w甚至几w的qps，而使用apache，并且使用非异步调用的rpc操作，线上几乎不可能达到上w的性能），另外一家公司使用的seda架构编写的框架，从性能和稳定性以及负责性来讲，这套框架无疑都会显得更优秀。
缺点：由于没有设计和slave想对应的work线程，所以任何消息都不会放到队列中，这就要求slave线程每一次处理请求都只能是1到2个毫秒之间能完成，如果要花上秒级别的时间，则slave线程则根本处理不过来。在广告系统中最耗时间的就是rpc调用，而rpc使用了异步调用的方式，所以之前的线程可以腾出来去执行，invoke线程回调之后由invoke线程继续执行。所以这套框架并不是对所有应用都适用的。当然如果非要使用该框架的话，将耗时的操作全部转换到其他服务去执行，这样也是ok的。
原文写于2015年，来自网易博客