实现C\S日志上传系统

场景：需要将客户端的日志上传至服务端；

方案一：

客户端：

1、本地打日志；

2、用一个日志进程将本地进程A、进程B...打的日志文件每隔一段时间收集起来；

3、将收集起来的日志文件压缩后，通过ZeroMQ 上传至服务端；

服务端：

1、将接收到的日志文件，根据客户端的标志符，分类存储在服务端；

2、覆盖存储的每份日志；

方案二：

客户端：

1、每个程序在本地的日志系统里包含两部分：本地打印+远程打印；（远程打印根据配置控制是否开启）

2、在打印日志前判断是否需要远程打印日志，如果需要远程打印就将要打印的日志投入到消息队列中；（消息队列大小要控制上限）

3、消息队列要做同步处理，因为消息远程发送，用单独的一个线程做；（目的：日志的发送不影响本地业务线程）

4、远程发送的消息的线程，每次从消息队里取出一个消息；如果没有消息，就进入阻塞等待；（阻塞式的消息队列）

5、消息的发送和接收，借助zeroMQ处理；（思考：断网重连、客户端服务端启动顺序对日志丢失的情况）

6、每次发送的日志内容以protocolbuff进行格式控制；（思考：字符串、json、protocolbuff的选择）

服务端：

1、zeroMQ进行消息接收；

2、接收到用protocolbuff进行反序列化；

3、服务端日志系统：根据接收到的消息创建对应的日志文件，且每个客户端的日志根据：客户机名 分文件夹存储；且每个文件存储两天的；

两个方案对比：

方案一:

优点：实现简单。使用到了压缩技术zip+zeroMQ + 本地日志系统（只打印本地日志）;

缺点：1、每次收集起来的日志，存在大量冗余，浪费了大量带宽；2、每次对收集起来的文件进行压缩时，耗用大量的CPU；3、日志上传时间是固定的，及时性不高；

方案二：

优点：解决了方案一存在的缺点；日志的及时性和带宽、CPU降下来了；

缺点：实现相对复杂，要考虑：阻塞式消息队列+格式控制+多线程；

最终选择的是：方案二；