互联网日志、数据推送、吞吐量的设计

互联网应用部署在线上为大众或者企业提供服务，每天提供千万次或上亿的服务，大型的互联网公司那就是更不必说了。如果某一天公司服务出现异常，那后果是灾难性的不仅当天颗粒无收，还要承担宕机带来的赔偿。服务的稳定性、容灾性、隔离性都是线上应用考虑的重中之重，本篇从互联网应用常见的日志、数据推送、执行效率的三大方面提供解决思路，当然这只是互联网设计的冰山一角，茫茫的知识海洋还要等着程序猿们探索和实践。

提升服务的吞吐量

提升服务的执行效率反应在两个点上，一个是响应性能；一个是吞吐量。《Java性能优化权威指南》中提到，提供性能分析有两个方法：自顶上下和自底向上，那么提升程序的执行效率也是这两种方式

自底向上

自底向上是不同平台（指底层的CPU架构或CPU数量不同）上进行性能调优，性能专家常使用自底向上的方法将应用迁移到其他操作系统上，也常用这种方法改善性能。另一种方式是借用Nginx高性能负载均衡器来增强服务的能力，怎么部署高容灾性的负载均衡器呢？我们知道Nginx原理是反向代理和负载均衡，同时我们也要考虑的负载均衡器的容灾性，当Nginx服务器宕调了，依托于Nginx负载的服务均不可使用，那么如何避免这个问题呢，使用成本更高的LVS物理负载，相信很多公司承担不起这个高昂的费用，可以使用虚拟ip解决这个问题，将两台服务器配置同一个虚拟IP地址，服务的地址配置为虚拟IP，两台服务器分配配置Nginx环境。这样还增加了Nginx代理能力，唯一的缺点是当修改配置项时两台集群要同时修改。

自顶向下

自底向下是从应用层提高程序的性能，如果一个应用执行的频率很高而且比较耗时，可使用多线程通过增加线程数来提升效率，由于fork线程需要比较长的时间，创建一个线程还是Copy符线程中的堆栈数据，占用程序的内存，java程序中一个线程大概占用程序的1MB内存，创建1000个线程则需要消耗1G的内存，对于计算机的性能是一个相当大的消耗，我们可以创建线程池，重复利用线程来节省系统的资源。

一般程序耗时是在IO上，不管是磁盘IO、网络IO、还是数据库IO，IO执行需要排队等待，等待的过程中还有Linux用户态和内核态的切换，大约程序的70%~80%时间是等待依赖任务时被消费，异步编程可以最大限度地利用CPU，一旦进程将任务传递给另一个进程（web请求），当前进程就会保存状态并可用于执行另一个任务，当web请求完成时，可以进一步处理它。Netty就是基于异步IO和管道来实现高性能Web通讯。Java创建线程有2种方式，一种是直接继承线程；另一种是实现Runnable接口，这2种方式地缺陷是：在任务完成后无法获取执行结果，获取结果就要实现线程间的通讯，Java 1.5开始提供Callable和Future两个接口来实现。

日志收集

线上应用访问量巨大的，为保证服务的高负载通过将服务节点负载到多台机器，增加服务的负载能力，同时也增加了问题排查难度，线上的数据难免会遇到异常，通常我们会通过查询组件的日志来排查问题，假定我们不知道数据负载到那台服务器上执行，那就需要一台一台服务器上找，程序员的一天在日志查找中度过，这种既浪费时间个人技术水平又得不到提升，只能锻炼Linux脚本的熟练程度的活要想办法解决。搭建日志管理平台就很有必要了，以下是一个线上日志管理平台的架构图

日志通过消息队列kafka最终到达es中，执行成功的数据标记为success失败的数据标记failed，并记录失败原因。通过kibana日志可视化查询平台定位异常失败原因。
日志的数据量是海量的，最好日志存储的索引按天来，写一个shell脚本定时删除前5天的数据，保留最近5天的日志。

数据推送机制

数据经过互联网服务处理后，最终产生结果数据。这个结果是用户或者局方需要的，有的局方需要结果数据并作为结算的依据，有的局方在合同中签订了每天数据的成功率。怎么把数据回传局方呢？将数据存储在数据库中，定时查数据库推送，如果没有成功放在下一次轮询中，这种机制给数据库造成巨大压力，同时一次性数据存放在数据库中造成了数据库资源的巨大浪费，定期还要清理来保证数据的查询效率，这给程序的维护带来巨大的工作。这里介绍使用基于Kafka消息队列的经典案例，解决上述问题。